hi roman, i was having similar issues not long ago in my attempt to control a step motor from pduino, the lag was 7 seconds and there was a noise that always bounced back from the arduino to pd that was interfering with the control number i was sending, depending on the speed i was using 115200 or 9600 (in both sides .pde and pd) i was getting from the outlet of the arduino object" a number that guttered between 49 or 255 respectively to the selected baud rate speed used.
with the same arduino code i manage to control the stepper from processing so i stooped trying it with pduino. same thing happned with the pwm that was there in the patches but not ready or stable to use.
i was trying version 2 of pduino and also with comport from cvs directly sending the integers. the jitter was always present and im sure i dont have code in the pde enabling analog out pins that could send data back to pd thtrough the serial.
/a
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