I changed them to put the new book on them, and I modified the TI-84+SE to a TI-84+CE. They didn't seem too broken, so I didn't think there was anything to fix. To be honest, I didn't think we had discussed changing them, just to add the new programming guide handout that we need to design together.

I expanded diameter of the battery model by 1mm and enlarged the space for the washer; it seem to fit together better now. I need to make the screw holes slightly larger, and I really need to fix my adhesion problems (is my bed out of level on the right side again?), but it's getting there. I definitely need to make it 1mm or 2mm longer to get a snugger fit against the spring.

I still don't see why you can't just hook alligator clips or something directly to the terminals.

Experience with what holds up to two full days of people touching things.

so route the wires through a hole in the battery cover and add a stress relief behind the door?

No.

1) Most alligator clips are wider than AAA batteries.
2) You can't clip alligator clips onto positive battery terminals.
3) We don't want to cut holes in our calculators.

Kerm: Fair enough on the tickets, I'm absolutely fine if one of the maker tickets goes to someone else who might need it more. I'd just have a longer wait to get in, if that's the case

Also, just to be sure would you like just the arduinos, or the arduinos plus various electronics (LEDs, wires, etc)? I can definitely supply a crap tonne of wires and also a breadboard or two.

Arduinos and a breadboard or two should be enough to save us from any shortages of parts for the displays and/or emergeny repairs. I'll certainly let you know if that changes closer to the Faire.

*bump* I cut out some 749 Cemetech bookmarks today, in between handing in doctoral dissertation forms. I also placed a Digikey order for parts we need for the Whack-a-Mole demo.

*bump* Current important tasks:
- Christopher: Build CDS cell + RGB LED + MSP432 Launchpad circuit, test out the Whack-a-Mole idea.
- Tim: Build the sandwich as discussed above if this works?
- Christopher/Tim: Figure out what plexi and blackboard we have, get more, cut it.
- Tim: Write the Launchpad code for Whack-a-Mole
- Christopher: Write the TI-84+CSE code for Whack-a-Mole
- Tim: Get the computer with calculator keypad working for the programming demo
- Christopher: Design and fab the instructional board for the programming demo

What have I missed?

Seems about right. I have a pc possibility for that weekend a friend might lend me the hardware for the weekend. I have to help him locate it in his storage shed first...yeahhhh. See how that pans out.

as for everything else a large amount of it is logistics of getting everything where it needs to be. Like the cds cell and stuff. Kinda at a stall on my end for now. Seems good shy of that.

If needed, I can stop my current projects over vacancies and try to make an interactive coding "teacher" (basically TI-Basic exercises) for TI-83+'es with GUI and such things... But I don't know how much time I will have till September, what the quality will be and if it will work at all, because I just had the idea and haven't planned anything, so I cannot guarantee anything.

That's very kind of you to offer, and that might be something we'll want in the future. For Maker Faire, though, we have a specific example program in mind and a good way to teach it to visitors to our booth. Thanks again for offering!

*bump* Things I need to do for Maker Faire in the next two days:
- Bring geekboy parts for the LVDS adapter, CDS cells, and crystals.
- Use $10 off $10 coupon for Staples to buy paper to print out programming guides. After this week, I'll work on creating the programming guides and the big programming board.
- Tim should find out shirt pricing and exact sizing before I forget where I put my list of shirt sizes.

Below: testing out a push-pull way of activating 9 RGB LEDs with 12 data lines, followed by a simplified schematic of the plan. I'm a little concerned about the LED brightness with 5V, but maybe I'll be able to find some brighter RGB LEDs for us, since I need to buy more anyway.

Can you make a printable PDF version of those? I would like to print my own

Absolutely! You can download the PDF of the bookmarks here. Just print it out double-sided on thick paper and cut them out.

Edit: Elfprince, geekboy, qazz42, Eeems: I have the free Maker tickets this year. If your family members/SOs are coming, I have exactly a very small number of discounted ticket codes that I can share. General Cemetech members: I'm afraid I can't help you on admission, but it's relatively cheap given the huge number of things to see and do at the Faire.

Edit #2: On my way to visit geekboy and work on Maker Faire stuff, I put together a better schematic for the Whack-a-Mole game:


Edit #3: With geekboy and on my way home, routed a board and ordered it through DirtyPCB. I'm gambling that 8 days turnaround + 1-2 weeks shipping will get the boards to me in enough time for Maker Faire, so we'll see what happens.

*bump* The PCB is at the fab house, and with any luck it'll be shipped within the week. I started (on Wednesday) and finished (today) a list of everything I can think of that we need to pack, bring, show, and do before Maker Faire. Please suggest additions accordingly.


Code:

In regards to the wackamole demo you sent me an API list quoted below. I have some questions on some implementation details



Implementation details needed currently is what is the order of the cells?

Across then down?
Or down then across?

Now to dispute some of the requests in the API and to maybe simplify it.

The send Function is fine I like it.

The Get command. I am not 100% sure how I would handle that. Does giving a get request give me the variable N or do I assume the last sent RGB is the current panel to poll.

Now to dispute the calculator software side. Why are we doing the hysterisis on the calculator? We could do it on the MSP and save cpu time/make a more responsive game.

As well with that I see an issue if it trys to "Quick Cal" (as I am going to call your method) with your hand over the sensor. It will call to a state we can not get a reading from. Instead of doing a debouncing with a different style of Quick Calibration.

Also If we wanted to make it so that you can return a miss on a miss clicked panel. I could just have you send me a Send(({N>10}) and I could respond with a Un/Triggered list for all 9 cells.

Like you said in person the other day. We both have very different approches to this. I'm trying to make the hardware work for me your trying to design software around hardware. Just food for thought there.

So yeah. Rebuttle please

Top-left is #1, across then down. #4 is the first one in the second row. Note that because 0 = shut everything off, the cells are 1-indexed.

I said Get(), but what I meant was the API "Get" command, which sends a one-element list containing a digit 1-9.

Much of it is ideological: I want to treat the MSP432 more like a fancy CBL2 in this case, because I believe our larger goal is to demonstrate how kids can do cool things with a microcontroller and a calculator. If they write TI-BASIC code to sample and get a range of possible values combined with a pre-written MSP432 program, I think that's an easier first step than having to both customize the basic output-to-PWM/read-from-analog program template while also writing game logic in TI-BASIC.

Yes, you're right, it will make an error if your hand is already over the sensor. However, in that case it will just detect a severe change when you take your hand away, and that's just as good for this kind of demo. It would be less frustrating to accept a false positive from the player, I think.

I didn't think of that. The Get API command (ie, Send({10}), I think), should just return a 9-element list of the 0-1023 values for all cells. Some very simple list math can let us get the averaged samples for all of the cells in advance (ie, just a vectorized version of the algorithm I outlined in my email).

And I think that the version I'm proposing will be a faster, easier first step: if it doesn't work, reprogramming the MSP432 to do more complex averaging should be something we'll still have time for.

Ok that works for me. It honestly makes my life easier I just wanted a concrete answer on the _Why_

I shall do some tests to see if the send{10} is efficient enough (really just reading on how fast we can do a 14bit sample.)


Shy of that issue I should have something for you come next tuesday. Hopefully I will have some preliminary hardware wiring done as well.

We need to come up with a proper design for the displays this year. Do we want to make proper stands that we can dissemble? Ill draw something up in a bit. It will cost a pretty penny more in material but it should last us for years to come. Unlike last years mess My dad is wondering what exactly we want to make so he can help us design it and all that and make it right

I'm confident that the speed of sending a 9-element list at the calculator's line rate will dominate the speed of Energia's analogRead(), although it might be interesting to see just what the analogRead() costs.

Awesome.

I really appreciate his professional help with this. I think we do want them to be disassemble-able. As far as I see it, the displays should be able to:
1) Have the plexi detach from the standoffs (obviously)
2) Have the stands underneath detach or fold. If they fold, we should come up with a way to make them not collapse like last year.
3) Optionally, have the standoffs detach too, depending how much we're willing to spend on strong magnets. That would make transport easier.