I’m trying to measure the speed of a wheel to control a synth. I’m using an arduino and Pduino. There is bits of papers taped to the wheel and they pass through a photo interrupter module. It’s using the digital output. I’m using the realtime-object to measure the time between papers passing the interrupter.

My question is why my output from [realtime] looks like this:

print: 9.917
print: 20.032
print: 19.994
print: 10.03
print: 10.025
print: 20.043
print: 18.553
print: 11.467
print: 20.026
print: 20.007
print: 9.879
print: 20.018
print: 8.59
print: 21.44
print: 10.032
print: 20.017
print: 20.02
print: 10.034
print: 18.484
print: 21.428
print: 10.032
And so on…

The numbers are always close to a multiple of 10. I can’t find a single integer ending with 2, 3, 4, 5, 6, or 7. Since I can se the numbers directly from the arduino (in arduino IDE) I’m pretty sure it’s not a problem at the arduino or sensor end of things. The numbers there looks totally reasonable to me. So, what is going on with my patch or with Pduino that makes it look like this? I could add that when using the timer-object there is nothing but exact multiples of 10:s outputted.

Also the stream of numbers I get is way to inconsistent for my uses and jumps around a lot. As you can see in the patch attached I’m using two [moving-ave] to smooth it out to something near acceptable. Is there limitations to using Pduino or is this again something in my patch.

Fairly new to PD and arduino so I’m sure there is a lot a can do better. Any help is appreciated. Thanks!

Patch:
PduinoTest.pd

If you can see the numbers you expect in the Arduino IDE, why don't you send them to Pd without the Firmata firmwaret? You can use the [serial_print] abstraction from here https://github.com/alexdrymonitis/Arduino_Pd
It works with Arduino's built-in Serial.print(). It will also be faster, I think.

Thanks for answering.

I could have mentioned I've actually already tried that but with the same results, unfortunately...

@AndreasA You could probably round your data...... as you are always close to an integer (no 2 3 4 5 6 or 7).....
[expr int (0.5 + $f1) ]
.... maybe a [/ 10] first and a [* 10] after for the data we see....... but of course that is for a particular speed..... so maybe not?
You could also set a window large enough to accept changes as the speed varies, but filter numbers that are out of range (those around 20 in this case... or is it those around 10?) and reject them.
David.

P.S. If still available for your platform..... the mapping library had a [smooth] object which I have used in the past to stabilise moving object data......

@AndreasA I'm assuming that the numbers you are seeing in the Arduino IDE are timings you captured on the Arduino, not using [realtime], is that correct? If so I think @alexandros is suggesting that you send those timings to Pd, instead of trying to measure the times between Arduino messages on the Pd side.

I'm guessing what you are measuring with [realtime] is when the OS schedules the Pd process to handle the next Arduino message, not when the message actually arrived at your computer, so that could explain the apparent rounding to the nearest 10 mS. I first saw this kind of rounding while investigating this problem: https://forum.pdpatchrepo.info/topic/13489/realtime-detecting-lack-of-correct-delay-in-the-delay-object

Great input all of it, thanks!

@whale-av said:

@AndreasA You could probably round your data...... as you are always close to an integer (no 2 3 4 5 6 or 7).....
[expr int (0.5 + $f1) ]
.... maybe a [/ 10] first and a [* 10] after for the data we see....... but of course that is for a particular speed..... so maybe not?
You could also set a window large enough to accept changes as the speed varies, but filter numbers that are out of range (those around 20 in this case... or is it those around 10?) and reject them.

Yeah well didn’t give you enough information there. These numbers I get is at maximum speed of my wheel, or rather the lowest number that pd will output when over a certain speed. So I want it to be able to handle that and all slower speeds as well. The [smooth] is awesome, thanks for the tip!

@jameslo said:

@AndreasA I'm assuming that the numbers you are seeing in the Arduino IDE are timings you captured on the Arduino, not using [realtime], is that correct? If so I think @alexandros is suggesting that you send those timings to Pd, instead of trying to measure the times between Arduino messages on the Pd side.

Actually discovered some problems on the Arduino-side as well so I actually had both arduino and pd limit the output there for a while. But arduino is now definitely taken care of. With @alexandros method I’m closer to what I want but not quite there. Thinking about lowering the bar and deal with it as a limitation later on in the actual synth.

The thing with [realtime] was really interesting read. Good stuff to know!

Though, it would be awesome to have the resolution of serial_print but with firmata and pduino. Pduino is such a great interface for someone not use to coding and I’d like to add more sensors on the same arduino, which right now feels like a big undertaken without pduino and with my lack of knowledge.

Is there a way, do you think? Could I mess with the firmata code to add serial.print()? Obviously wrong forum, but just in case someone has tried.

@AndreasA I've never used Pduino or firmata, I've always just coded the Arduino-Pd interface using [comport] or TCP/IP. Here's my comport method: https://forum.pdpatchrepo.info/topic/13086/arduino-to-pd-vanilla/8

@jameslo said:

I've always just coded the Arduino-Pd interface using [comport] or TCP/IP. Here's my comport method: https://forum.pdpatchrepo.info/topic/13086/arduino-to-pd-vanilla/8

Hmm, okay I think I get how that works. I'll try, thanks!