On Jun 22, 2006, at 8:34 AM, Alexandre Quessy wrote:

Hi Hans and the PD list,

We are trying to use the PD Arduino firmware + PD patch that Hans has released. See http://at.or.at/hans/pd/objects.html and http://arduino.cc/ for more info. Our goal is to use it a inputs only. (for now)

We realized that some analog inputs values were way too high. It worked, then it broked for some unknown reason. (apparently none) Then it worked again and broke again. So, we can say it is still unstable.

We think that it mighth be because of some equations in the Pduino Arduino code. We changed line 119 from :
transmitByte = transmitByte + (2^(i+1-startPin)*digitalData);
to :
transmitByte = transmitByte + (2^(i+1+startPin)*digitalData);

Then, the analog-in stopped giving strangely high data. We found it strange the use of negative exponents (when startPin is 7). Was that a luck or what ? We had lot of fun debugging that. ;-D

Yes, that would be a bug, thanks for finding it.  I guess I never tested the higher digital inputs...  feel free to commit it directly.    I only tested analog 0-3 with sensors, but I never saw values higher than 1023.


---
Regarding the digital inputs. In both cases, they were behaving strangely. Their state are constantly changing. Some work, but some not. Maybe it is just electric noise : should we ground everyother pin ? Probably.

Yeah, the code needs to be debugged, but yes, all of the inputs, digital and analog, will have floating voltages on them unless you tie them to ground or +5V.

In the PDuino PD patch, are the serial streams always parsed as being the same length ? It is supposed to be so, but might not in every case. Maybe it would be better to use the [match] object. (because the selector, meaning that it it the beginning of the list, is 255) Maybe sometimes, because of calculation error (?), the number 255 is sent again.

The streams can vary in length, but there are some aspects that are fixed.  The 255 byte is always the cycle marker, marking the beginning of a cycle.  Then the next two bytes will always be the digital inputs, even if they are not being read, in which case those two bytes would be 0 and 0.  Then after those 3 bytes, you can have 0-6 pairs of bytes representing the analogIns.  So if you want to reduce the latency as much as possible, then you can have it only send the data for the number of analogIns that you are using.  This I have tested quite a bit and haven't seen any problems with it. 


As for [match], I think that's a bad solution since it adds a lot of latency.  [match] would output until the whole sequence is matched.  For the full sequence, that will add about 8 times the latency. If there is a calculation error that is causing a random 255 byte, that should be fixed instead of making a [match] workaround.  I haven't seen random 255 bytes at all though, have you?


FYI: I wrote up some documentation about the Pduino protocol:


http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1148554125/1



.hc





------------------------------------------------------------------------


Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.  It's about as sensible to say we declare war on night attacks and expect we're going to win that war.  We're not going to win the war on terrorism.        - retired U.S. Army general, William Odom