skip to main |
skip to sidebar
We added an additional battery for the pump that clocks in at 11.10 V (even though it claims to be a lowly 9.6V) It delivers a steady stream of water.Finished testing today. All systems are go!
David out
We draw 110 mA according to my multimeter. 110 mA *h = 880 mAH < 1500 mAH for the battery. We're good. (Theoretical is 2100 mAH, but uses a lot of worst case calculations)
We decorated the duck and enabled the eyes. They are awesome.
There was an issue with shifting in just one time to the display, so now it does it every 600 mS based off of the 200 ms timer.
We turn off all the LEDs except the ship number at the end to indicate gameover.
We are considering adding a second battery for the pump because it is lame.
We had a full successful run, including pings during and after pairing, start game from admirals, stand down, base switching, and end game. The motors behaved as expected at all poitns.
TODO Tomorrow:
Check craft/helm pairing with others (We had successful control of the hot dog today)
Fix up pump
Take videos
Waterproofing
David out
I saw some strange things this morning.1. Motors and pump did not respond. This was due to a low voltage battery; problem disappeared when it was charged.2. Display was not correct in 7 seg. At times, the team/goal LEDs did not turn on correctly. We knocked down the baud rate to the lowest setting and stopped updating every 200 ms. Now it just updates on standdown and goal change.Tested all specials. The quack does not respond all the time. The packet sent is correct, but the timing on the PIC side needs tweaking. The pump and flagon seem to work just fine.Next step: Power budget, wet run, waterproofing, LED eyesDavid out
Laurel and I completed the code and electronics for the LED and 7 segment displays today. The bitshift can occur at speeds up to the max of what the E128 can SSP out (25 Mhz/2) For some reason, we found that bits 4 and 7 had to be switched on the charts for the LED display. Quirk: if you call the ShowBoatNumber() function, you also have to update the team affiliation. I placed the refresh for every 200 ms and it is functionally stable, though the update rate is visible.Benjie and I have hashed out a scheme where we are constantly reading the analog voltages from the drumsticks and use the average for speed every 200 ms. It works out quite nicely; we want the voltage for max speed to be (at the greatest!) about 500 (value from the analog voltage in)New iButton check on the PIC works fine. Now it will reject 0x00 and 0x00 as well as 0xff and 0xff as successive valid readsKarl was able to ping the Helm in its "looking for iButton state" and the Kraft in its "waiting to pair state." That seems solid.Our helm construction is well on its way. We have tested out hardware for the quack switch (works!) but are still seeing the pump turn on at the start. I have implemented a pump timer which will call for water until 10 seconds after the user stops yelling. The pump code currently is not functional; nor is the duck release. Those are top priority tomorrow.Agenda for tomorrow:Fix pump and duck releaseIntegrate with drumsticksMake power system more stableWaterproof the duckDavid out
Helm LEDs have been soldered onto the LED board. Should be ready to go.I implemented a simple color code to keep track of what LED is what. Black/white wires are for the stand down LED, red/white wires are for team indicators, and green/white wires are for base indicators. 7-Segment cables have been made and are ready to go. Just need a bit of software and this part should be ready.
We are also the proud owners of a Shamu and Crew lunch box. Looks like everything will fit inside, awesome.
I'm hoping that we can get the whole thing mostly together by the end of the weekend so that we'll have plenty of time to test/break/fix things.
~Laurel
EDIT: Fry's order has arrived! I'll bring it to the lab tomorrow morning/afternoon.
I wrote up a table that outlines the order bits should be clocked into the shift registers. For a given pattern, clock in the bit in column 1 first and work your way to the bit in column 16. (I'm not sure how SSP shifts data. Is LSB or MSB first? Something to look into.) Table can be found in the team folder as LEDshiftTable.xls.Logic for 7-segment display is inverted, if you want a particular segment on, set it to zero. Setting a segment pin equal to 1 turns it off. Base, team, and stand down LEDs have normal logic (1 is on, 0 off). The sheet of paper with 7-segment drawings and my scrawl all over it might be a bit confusing since the numbering on it is different from the numbering in the table (segment 1 is actually the 16th value shifted in, 2nd segment is the 15th value shifted in, etc.) Probably best to just ignore it and only use the table. Drop me a line if you have any questions. I'll try to be on-hand during programming time for question answering.LED board is practically ready to go, just need to figure out how long LED wires need to be, solder them in, and pop in the shift registers. Lunch box has been acquired, just need to mount the E128, xBee, and sensor circuitry inside.
I'm 100% serious about the beer and ice cream being up for grabs....please don't make me eat/drink it all -_-~Laurel
EDIT: Just looked it up, LSB is shifted first. So all off would be 11111111 1000000 (0xFF 0x80)
Red Team with Blue Base active, no stand down, and craft 3 would be: 00100011 10001001 (0x23 0x89)...I think I'm going to modify the table to show the bit order rather than the shift order...should be easier to understand.
Okay, I was confused. Turns out we can do LSB or MSB first depending on if the LSB first bit is set/clear in the SPICR1 register. I'm not sure how David has it set up (I'm assuming MSB first since that's the default.) The LEDshiftTable.xls file has tables for both situations so we should be covered no matter what we choose.