hello
i recently ordered two arduino boards and now i try my first steps with it. i downloaded Pduino-0.2 and uploaded the firmware to the chip. i encountered a little, but sometimes annoying problem, when using the board with [arduino]-object. when i enable one or more analog inputs, the arduino sends so much data, that data sent from computer to arduino gets delayed, sometimes up to 10 seconds. this makes it impossible for me to use the outputs, while using the analog ins at the same time. i use the [arduino]-object as it is (with the hardcoded baudrate of 115200) and i connect the arduino-board directly to one of my laptop's usb-ports. i counted the messages i receive from the the analog input, when i enable it: 1 analog input enabled: ~960 values/s 2 analog inputs enabled: ~480 values/s per input 3 analog inputs enabled: ~320 values/s per input (and so on)
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.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
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.
roman
greets,
chris
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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.
Adding a millisecond delay would increase the jitter. 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? 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. 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. 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.
Martin
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
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
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
On Sat, 2007-01-13 at 10:50 -0500, Martin Peach wrote:
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() ); } } } }
this worked for me. messages TO the board don't get delayed anymore. many thanks again.
:-)
cheers roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Jan 13, 2007, at 12:27 PM, Roman Haefeli wrote:
On Sat, 2007-01-13 at 10:50 -0500, Martin Peach wrote:
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() ); } } } }
this worked for me. messages TO the board don't get delayed anymore. many thanks again.
:-)
Did this cause any added latency? I have seen the problems that you
have pointed out, but I haven't had a chance to debug them. I think
the key is to find ways to make things work at the full speed, rather
than find workarounds.
The processInput() stuff should probably be handled using an
interrupt so output messages don't get dropped. The tricky part
there is to handle output messages without causing jitter in the
input messages. That's the ultimate goal.
.hc
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
If you are not part of the solution, you are part of the problem.
On Sun, 2007-01-14 at 14:31 -0500, Hans-Christoph Steiner wrote:
On Jan 13, 2007, at 12:27 PM, Roman Haefeli wrote:
On Sat, 2007-01-13 at 10:50 -0500, Martin Peach wrote:
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() ); } } } }
this worked for me. messages TO the board don't get delayed anymore. many thanks again.
:-)
Did this cause any added latency? I have seen the problems that you
have pointed out, but I haven't had a chance to debug them. I think
the key is to find ways to make things work at the full speed, rather
than find workarounds.The processInput() stuff should probably be handled using an
interrupt so output messages don't get dropped. The tricky part
there is to handle output messages without causing jitter in the
input messages. That's the ultimate goal..hc
here a short (but a bit more detailed) report from my side:
i applied the proposed changes to the firmware-code and uploaded the new version to the arduino board. after enabling analogIns it was still possible to send messages to digitalOuts without any additional jitter. but when i enable more than 3 analogIns, i have the same situation again (as for now i can live with that). when 4 or more analogIns are enabled, messages TO the board don't come through anymore and sometimes i even need to close the connection in order to switch the analogIns off again (closing [comport] has immediate effect, whereas turning analogIns off might take up to 10s or more). i measured again with the patched version, how many values i receive in pd from the analogIns. Interestingly, i still get around 968 values per seconds. that means, that martin peach's patch doesn't affect performance of the arduino board, but increases the amount of enabled analogIns whitout having jitter from 0 (original version) to 3 (martin peach's version).
maybe it looks stupid from a coder perspective, but i will test if i can make it work with all analogIns enabled by increasing the while loop to 200 iterations (1 iteration = no analogIn; 100 iterations = 3 analogIns; 200 iterations = 6 analogIns?)
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
hello
i recently ordered two arduino boards and now i try my first steps with it. i downloaded Pduino-0.2 and uploaded the firmware to the chip. i encountered a little, but sometimes annoying problem, when using the board with [arduino]-object. when i enable one or more analog inputs, the arduino sends so much data, that data sent from computer to arduino gets delayed, sometimes up to 10 seconds. this makes it impossible for me to use the outputs, while using the analog ins at the same time. i use the [arduino]-object as it is (with the hardcoded baudrate of 115200) and i connect the arduino-board directly to one of my laptop's usb-ports. i counted the messages i receive from the the analog input, when i enable it: 1 analog input enabled: ~960 values/s 2 analog inputs enabled: ~480 values/s per input 3 analog inputs enabled: ~320 values/s per input (and so on)
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)?
You could always run at a baud rate like 1200, so the arduino is not able to send more than 120 bytes per second.
Martin
On Sat, 2007-01-13 at 01:17 -0500, Martin Peach wrote:
Roman Haefeli wrote:
hello
i recently ordered two arduino boards and now i try my first steps with it. i downloaded Pduino-0.2 and uploaded the firmware to the chip. i encountered a little, but sometimes annoying problem, when using the board with [arduino]-object. when i enable one or more analog inputs, the arduino sends so much data, that data sent from computer to arduino gets delayed, sometimes up to 10 seconds. this makes it impossible for me to use the outputs, while using the analog ins at the same time. i use the [arduino]-object as it is (with the hardcoded baudrate of 115200) and i connect the arduino-board directly to one of my laptop's usb-ports. i counted the messages i receive from the the analog input, when i enable it: 1 analog input enabled: ~960 values/s 2 analog inputs enabled: ~480 values/s per input 3 analog inputs enabled: ~320 values/s per input (and so on)
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)?
You could always run at a baud rate like 1200, so the arduino is not able to send more than 120 bytes per second.
the problem i have, is not that i don't want so much data, but that the analogIns eat whole bandwidth, so that i get jitter on the digitalOuts. setting another baud rate doesn't seem to solve this problem, since the analogIns send with lower rate then, but still eat whole available bandwidth. maybe i am totally wrong, but my assumption is, that when the analogIns don't send so fast, that they fill the bandwidth, there would be less jitter on the digitalOuts. when using digitalOuts without the analogIns enabled, i don't have noticable jitter at all. that is why i thought, limiting the speed of the analogIns would help.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
-
alejo d -
Christian Klippel -
Hans-Christoph Steiner -
Martin Peach -
Roman Haefeli