On 1/13/07, Roman Haefeli <reduzierer@yahoo.de> wrote:

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
messages.
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
much.

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.

cheers
roman

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

_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list