I’ve tried using the serial read sample app for v3 and v5 of OF and encountered the same problem with both. Serial read doesn’t exactly read my values correctly.
I’ve already downloaded a sample app that I’ve found in the forums which basically spits back “ABC” to OF when an “A” is received at the Arduino. That works fine.
However, when I hook up a potentiometer to the Arduino and send out the pot value as a string, it always sends back partial bits of the number it should be. For instance, 1023 might be 31 or 2 or 231 or 0, but it is never 1023. I’ve tried varying the baud rate and both adding and removing pauses from the Arduino code, but always the same story.
I figure that I could just detect an incoming serial communication in OF from the Arduino and then ping back the Arduino with an “A” and then have the Arduino send one instance of the value it is currently reading. That, in theory, should work, but it is an ugly work-around if I’m trying to get a string of sensor data flowing into the computer.
So, the question is, how is the read function handing incoming serial data? Has anyone encountered/dealt with this? And are there any good resources on this subject?
Oh… after looking into it more, I’ve realized that the sample code is only reading 3 bytes.
Possibly reading more than 3 bytes at a time may easily solve my problem, but I think I still might have clocking issues since it doesn’t appear there is anything in place that determines where one communication ends and another begins. I suppose that I could always add a garbage character to every string and always look for that.
Anyhow… suggestions still welcome.
in the example code we use a model of call and response and read as much as possible, both to deal with the problem of byte order.
in the example code, if you are able to read three (and the next read is zero) you should be gaurenteed that the bytes are in the right order.
the problem of course is clock rate, communicate rate, etc, but here are some points that I’ve found out :
a) helpful to use call and response as a model for reading (rather then getting data sent all the time)
b) you have to try to read as much as possible in order to flush the serial buffer.
c) if you try to read as much as possible and you read the amount you know you are supposed to get, and the next read is zero, the last amount you read should definitely be in the right order. I don’t think you’d ever get out of order that way. also the data you get will be the freshest.
anyway, the call and response method is what I’ve used (it’s also what I use sometimes in tcp/udp communication) and it seems to work ok. I think it’d be trivial to hack the example code to take a larger known length sequence.
anyway, the (a) (b) and © above is to deal with exactly the problem you are describing so that you don’t have to deal with terminiating characters, being smart, etc and can just try to get data as fast as possible.
ps : folks on this forum working on c++ version of firmata protocol communication, which would be infintiely easier to code, since you can avoid the overhead of programming the arduino. search for “cpp glue” on google code. it’s a work in progress but it might be something worth considering.
These examples I made for the tinker.it workshop in London might be handy too.
One is for reading an analog value in pin 0 of the arduino and then sending that value as a number to openFrameworks.
The other reads from the daventech sonar sensor and also sends to OF as a number.
Both use the call and response approach zach was talking about. They also do something quite clever which is they pack the 0 - 1024 number into two bytes before sending it. This means that the same amount of data gets sent to openFrameworks whether the number you are sending is 10 or 1000. This makes things a lot easier as you always know that your message will be two bytes long.
Included is an OF app (xcode 005 FAT) that shows the number coming in and scrubs a movie file with it. The OF app handles the decoding of the two bytes into a int number so you don’t have to worry too much about the bitshifting that is involved.
Instructions included in the zip
just wanted to say thank you for posting the source… i have been using it for a few months now to read from a sonic range sensor and its working great!
id like to extend on your code by reading from multiple sensors.
how does this fit into the call and response approach?
wondering if i should be calling for each sensor individually and sending back two bytes for each, or if to call once for all the sensors and send back the sensor values in more then two bytes?