[PD] Pduino: change read speed
alejo d
alejoduque at gmail.com
Sat Jan 13 18:20:36 CET 2007
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 at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20070113/7b275c11/attachment.htm>
More information about the Pd-list
mailing list