[PD] Re: Pduino inputs

[Hans-Christoph Steiner]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20060622/42912467/attachment.htm>