Re: [PD] Pduino: change read speed

2007-01-14 Thread Roman Haefeli
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


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


Re: [PD] Pduino: change read speed

2007-01-13 Thread Roman Haefeli

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


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


Re: [PD] Pduino: change read speed

2007-01-13 Thread Roman Haefeli
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


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


Re: [PD] Pduino: change read speed

2007-01-13 Thread Roman Haefeli
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( 

Re: [PD] Pduino: change read speed

2007-01-13 Thread alejo d

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 [EMAIL PROTECTED] 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 

[PD] Pduino: change read speed

2007-01-12 Thread Roman Haefeli
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


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


Re: [PD] Pduino: change read speed

2007-01-12 Thread Christian Klippel
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

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


Re: [PD] Pduino: change read speed

2007-01-12 Thread Martin Peach

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


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