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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
