8:00 – 6:00 FP

• Put all my arduino communication work in SVN in my sandbox folder. Pulled down a copy to the laptop to check later
• PAD lab meeting at 10:00
• It looks like you really have to be careful with the memory on the UNO. The aJson print() function seems to be sloppy about the strings it creates, even if you re-use the object. I created a function that stitches together the force values inside a JSON compatable string and sends it straight over the wire. That’s been working fine for about an hour now (it’s 5:45). I think I’ll let it burn for the weekend.

Start: 10:00

• Went to get some more wire and smaller bolts
• Made a bus for to I2c
• Populated another board
• 3rd board is mostly populated minus the amp and midi shield
• The third board only has half the electronics as it only controls one finger instead of two
• Had some trouble soldering the midi controllers because there was solder stuck in the hole.  The connections don’t look pretty but it trying to get them perfect was breaking the boards.  The midi and reset pins have jumper pads which made them a bit easier to deal with.
• There are still a few things to do.  I need a ground bus for the shared ground, wires for the midi to arduino, wires for sensors to the arduino, and the amp and mid controller on the third board need to be attached.  I crimped most of the other wires but have not put them in the harness yet, some may need to be redone.  I plan on being in at 7:00 or 7:30 tomorrow to finish this stuff.  It is realistic to expect me to be done with this part by either 10 or 11.

End:  10:00

Start: 10:00

• Fixed the problem with the states getting stuck during the echo test
• Tested large data transfer.  The data looks fine but it doesn’t stop cycling on the last packet
• Working on changing the states to something a bit more predictable and clear.  there are too many weird problems as it currently is.

End: 6:00

Start: 10:00

ComMgr testing:

• Send Data works with one byte both sides
• receive Data works with one byte both sides
• It turns out that the receive buffer on the arduino side only accepts 63 bytes now instead of 127

ComUtil

• Initializes properly
• Both get to ready state properly with no loaded data
• Single pass writing from PC to Arduino moves through states properly
• loaded 504 bytes of data in to test packet counter.  It properly returned 8 packets of 63 bytes each
• There may be a problem with multi packet send terminating improperly on the last packet
• Tested transfer from arduino to pc.  This works and printed out correctly.
• In the echo test the computer can receive and respond but it gets stuck on the arduinos response.  The arduino sends the first time fine.

End: 5:30

Start: 10:00

• The states of the ComUtil now cycle properly.  If data starts on the PC side but the data doesn’t print out properly when transfered back from the arduino
• When starts on the arduino side, its prints out properly but then gets stuck after the trys to send then goes into a state that it shouldn’t be able to get to.
• There is something wrong with the receive method on the arduino.
• The Mega has 4 serial ports.  I can print out variables and stuff on another port without interfering with the data transfer.
• Noticed that TRUE on the arduino is defined as !FALSE.  On the PC TRUE is 1.  I can’t see why this would cause me to get into odd states but considering the code is identical on both sides and the arduino is being more wacky than the PC maybe this is the problem.

End: 6:00