[PD] Pduino: change read speed

Roman Haefeli reduzierer at yahoo.de
Sat Jan 13 17:53:40 CET 2007

On Sat, 2007-01-13 at 10:50 -0500, Martin Peach wrote:
> Roman Haefeli wrote:
> > On Sat, 2007-01-13 at 03:59 +0100, Christian Klippel wrote:
> >   
> >> Am Samstag, 13. Januar 2007 03:31 schrieb Roman Haefeli:
> >>     
> >>> hello
> >>>       
> >> [...snip...]
> >>
> >>     
> >>> would it be easy to change the code of the firmware, so that it sends
> >>> the values of each analog input with a fixed rate (e.g. 100 Hz)?
> >>>
> >>> i am not a c programmer, anyway i tried to search for kind of a delay
> >>> function in the code, but couldn't find anything. am i right in
> >>> assuming, that as it is now, it cycles through the code and sends each
> >>> time the values with the maximum possible rate, or in other words: there
> >>> is no speedlimit in the firmware? if so, how hard would it be to
> >>> implement kind of a speedlimit on the arduino-side?
> >>>
> >>> any suggestions are welcome.
> >>>
> >>>       
> >> the best way would be to implement a threshold and a gating function that 
> >> handles the adc readouts. i'm doing that in the multio. it works like this:
> >>
> >> the last sent value is saved. the actual readout is compared to that, and if 
> >> the difference is above a given threshold, it will open the gate for a 
> >> certain amount of time. during that time it sends all values (as long as they 
> >> change, regardless of the threhold). each time the change is above the 
> >> threshold, the open-time is reset. now, when the changes are below the 
> >> threhold during the gate-open time, the time runs out. then it closes the 
> >> gate again and the whole thing starts over.
> >>
> >> this has two advantages: when nothing happens, there are no values to send at 
> >> all. but while the gate is on, you dont miss any change, allowing for smooth 
> >> transistions, and get all values as they come in.
> >>     
> >
> > this would solve my problem, when for example i don't move a physical
> > fader, that is connected to the arduino board. but as as long as i am
> > moving that fader, the respective analogIn sends its values with the
> > maximum rate, so i will probably have jitter on the digitalOuts again.
> > of course, your proposal would be much more elegant in terms of saving
> > badwidth, when it is not used, but unfortunately i am not able to code
> > it. 
> >
> > basically, i hoped it would be as easy as inserting a line somewhere in
> > the firmware code, that says something like: 
> >
> > 'wait here for 1ms, then continue'
> >
> > i wouldn't mind, if this would lower the over all rate, as long as
> > jitter is reduced.
> >

first, thank you, martin and chris, for all your ideas and patience.

> Adding a millisecond delay would increase the jitter.

ah, ok. 

> Another way would 
> be to have the arduino only  send analog  when  requested.
> At the moment it sends digital ins only if they have changed, but sends 
> every analog value.
> Are you sure the jitter is not caused by pd?

no, i don't know how to check that. actually, i don't know, where the
bottleneck is. the only i can say is, that when analogIns are enabled,
it takes up to 10 seconds from sending the message [digital 13 1( until
i see the led light up. also the message to disable reporting of analog
inputs takes very long then. after the message arrived, jitter of
digital is not noticable anymore.

>  I tested comport with an 
> oscilloscope on the serial pin and a [metro] triggering [comport]. The 
> jitter was in the millisecond range, and could be reduced by decreasing 
> the audio block size but not eliminated.
> If the arduino is causing the jitter it should go down as you increase 
> the baud rate since the time to send an analog value goes down. 

actually, i use 115200, which is the default in the [arduino]-object. i
tried also 57600 and 230400, but then i cannot set the digital inputs
anymore, though the RX led on the board is still blinking, when i send
does the firmware also be set to another baudrate, when i change it in
the [arduino]-object?

> At some 
> point the analog conversion takes longer than the data transmission and 
> then it won't go much faster.
> What kind of precision do you want? If you need to output a periodic 
> signal it might be easier to program the arduino to do that and use pd 
> to set the period but not send the actual pulses.

i use the digitalOuts to trigger linear solenoids (is that the correct
expression? hubmagnete in german). they knock on some metal object. i
use pd to play them rhythmic patterns. that is why i care about jitter.
up to 10ms or even more should be ok, i don't think one notices that
much. but when it's 300ms or even 10s then it is not usuable to generate
rhythms anymore.   

> Also you could try changing the checkForInput function so that it stays 
> there longer:
> Change:
> void checkForInput() {
>     if(Serial.available()) { 
>         while(Serial.available()) {
>             processInput( (byte)Serial.read() );
>         }
>     }
> }
> to:
> void checkForInput() {
>     int i = 100;  
>     while (--i) {
>         if(Serial.available()) { 
>             while(Serial.available()) {
>                 processInput( (byte)Serial.read() );
>             }
>         }
>     }
> }
> it will check 100 times before returning, which might help...
> A better design would replace checkForInput with an interrupt handler 
> that would be called only when received data is available.

yeah, man! this looks really interesting. i'll try that. thank you very

nice side effect: since i have the arduino board and read the pduino
firmware and other examples on http://arduino.cc , i think i start
understanding a bit of c programming language.


Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

More information about the Pd-list mailing list