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