« Step Response Checkpoint Prep | Main | Maker Faire This Weekend »

Sun, April 16, 2006 10:07 PM

Telemetry and BlueSMiRF Details

Okay, I've been beating my head against the BlueRadios wall all weekend, and I think I finally came up with enough of a solution.

Sending Telemetry

First off, I've written a buffered, interrupt-driven packet transmit API. One packet can be assembled and queued while another is being transmitted. The calling context only blocks for the time it takes to assemble the packet (and possibly copy it to the send buffer, if no packet is currently being transmitted).

It does not yet respect the RTS signal, because I don't have a good way of restarting transmission when RTS comes back. Ideally, RTS would generate an interrupt, but RTS and CTS are connected to port G, and on the ATmega128 there's no interrupt-on-change on Port G (oh, how I long for the ATmega1281…).

The alternative is to set a timer to go off and try again in some short period of time, but that solution is inelegant. I've opted to ignore the problem for now. The firmware doesn't send data until after a connection is established and data is requested, and it doesn't send it so fast that the link gets saturated. Note that as the range increases, so do transmission errors (we were unable to run in the courtyard at 76,800 bps, had to drop to something terribly slow to get it to work), and the risk of saturation is much higher. I've ordered the new BlueSMiRF module which can accommodate a better antenna, hopefully that will help guard against range issues.

BlueSMiRF Send While Receive

I was having a very serious problem sending data to the car while it was sending back telemetry. I think I've managed to solve it, thanks to some hints dropped on the BlueSMiRF forums. Basically, the BlueRadios part is overwhelmed trying to parse the input stream, and can't send data in both directions when it's busy. Switching it into "fast data mode" stops the parser, allowing overall faster transmission speeds, and seems to allow data to go both ways. The drawback is that settings cannot be changed in this mode, which means the mode cannot be exited if permanently set.

So, the Java app will do this on connect: Send +++\ratmf\r. This will put it into fast data mode until power is lost. It's the best we can do.

Comments

Nice work! With that code running, it would be easy to create some really nice graphs.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)


Please enter the security code you see here