Today’s post is going into a somewhat different direction. I was a tech-dad for our summer swim team, the Tracy Tritons, for maybe ten years now.
My first extension was a little Ruby on Rails application to publish the meet information quickly to all the parents on a local WiFi network and on the internet. I started that in 2008 and used it until about two years ago when we switched to Hy-Tek’s MeetMobile. The application is still working with Hy-Tek MeetManager 5 backups and the sources live @ my github account;-) But that’s actually not what I wanted to write about today;-)
About a month ago we had some problems with our ageing meet laptop. So I was looking at possible backup solutions. MeetManager 5 seems to run fine on my Windows 7 64. BUT I could not find any drivers for our USB-serial adaptor:-( Others on the web described different attempts with different drivers but nothing wanted to work.
I also know that we push the cable length of our serial cable with more than 150 feed.
So I started to look at alternatives.
I’m also playing with some autonomous rovers, and there I learned about the wireless 3DR telemetry links. They are basically a serial connection over a long-range 915 MHz link. You can find them cheaper on ebay and they have a nice open firmware;-) I know, that link is working fine on my Windows 7 64;-) So those looked like a good fit to what I was trying to do;-)
But there is one more hurdle, the Colorado Consoles do have real RS-232 ports, not the TTL-levels expected by the radios. So I needed one more building block. The Ti MAX3232 is exactly what I needed and you can get complete little boards on ebay;-)
With all the hardware components sourced, I was looking at the software side. The link between the timing console and the meet computer uses 9600 Baud 8-O-1. That Odd parity bit is not supported by the original radio firmware. So I had to adapt that a little bit. I cheated a little bit there;-) my modifications accept the parity bit and ignore it on the receiving side. The error correction over the wireless link is done as it was before with the [now] normal 8-N-1. On the transmitting side, I calculate the parity bit again and send the required 8-O-1 to the target;-) While that’s not officially correct, I believe, it should be good enough since much faster links over longer distances don’t rely on the parity bit any more.
My changed firmware with support for Even and Odd parity bits lives on github as well;-) If somebody wants to have fun, feel free;-)
The link seems to be working OK for what I have tested so far;-) With one side on our living room floor, I could take the other side outside more than 200 feet away. Then there were more houses in the way, so I don’t know the maximum reach;-)
As always, take bits & pieces and combine them in new and exiting ways;-)