Task: To send digital data in one or both directions across a pair of commercial two way radios.
Purpose: A secondary means of tracking a high altitude balloon.
Budget: A total of $120 for two devices, the cost of two TinyTrak4 kits.
Materials: PSoC Cy829466-24PXI at 3.3v, Pair of Midland GXT795VP4 two way radios with headphone and microphone jacks.
Restraints: Independent, not relying on a computer program to do all the hard work and using the module as an interface node.
The TinyTrak4 would be my fallback plan, hopefully there is a circuit out their that can accomplish the same task for a bit less. I hope this doesn’t come across as me wanting you to do all my work for me, but it would be helpful if you could give me a pointer or two in the right direction. Any critiques in my post style are welcome.
Thanks in advance.
So let me see if I understand what you want. You have the 2 radios, you want a method to encode a digital data stream into audio frequencies to input to the sending radio. Then at the receiving end you want to decode the resulting audio output from the headphone jack back into a digital data stream to be processed by something. Bascially you want 2 modems, one for the ballon and one for the base station.
I think.
And you want the cost of the 2 modem to be less than what it takes to do it w/ TinyTrak4’s, < $120.
So I’ll assume the radios provide the required range (? 5 miles ?). What bit rate do you need to send ? Seems that TinyTrak4’s can do up to 9600 baud with some unspecified error rate. What error rate do you need and how will you handle the inevitable errors ? A simple system just lets the bits fall on the floor, noting that a receive error has occured. More complicated ones request a retransmission until the packet is received error free or a timeout occurs.
My first thought (not necessarily a good one :oops: ) is that a DTMF encoder and decoder might work. I think you get 16 symbols that way, though I’m not sure what bit rate such a system would support. I’d guess maybe 1200 baud or so. Depending on the frequency response of the radios you could probably do better.
You are correct. I looked very extensively into DTMF chips, but it’s proving very difficult to track them down, specifically transceivers.The baud rate would be 1200 or less, hopefully to avoid dropping packets.
To compensate for errors, the best plan I have would be to automatically re-transmit the same string of data four or five times, each 10 seconds apart or something similar. Any other errors I am relying on the human operator to pick out.
The radios transmit surprisingly clearly, even in an urban environment.
Edit: I just looked into some DTMF chips from jameco, mouser, and digikey. Digikey requires a bulk order of 1000 or so, jameco doesn’t have any, and mouser just says to ‘call for availability.’
BudgetEngineer:
I just looked into some DTMF chips from jameco, mouser, and digikey. Digikey requires a bulk order of 1000 or so, jameco doesn’t have any, and mouser just says to ‘call for availability.’
Well that’s less than optimal. Continuing the same thought … it would be easy to make a DTMF (or QTMF) [encoder with [a PIC or similar. I’m less sure about implementing a FIR filter bank ([decoder is possible?) with one though. Perhaps a [Propeller would work though.](Propeller - Parallax)](http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en024294)](http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en011071)](http://hackedgadgets.com/2008/05/22/dtmf-phone-dialer-pic-microcontroller-based-2/)
I thought I would have to go that route…i’m a little pressed for time since lots of parts shipped out late, the balloon launches in three weeks. Encoding the data isn’t too tricky, decoding seems much more difficult though. Thanks for your help!
BudgetEngineer:
I thought I would have to go that route…i’m a little pressed for time since lots of parts shipped out late, the balloon launches in three weeks. Encoding the data isn’t too tricky, decoding seems much more difficult though. Thanks for your help!
The only other possibility that occurs to me ATM is using some [frequency-to-voltage IC and a comparator. Jumping btw 2 freqs (or more) could result in a digital bitstream w/o much effort. I don’t know what kind of bit rate or error rate would result. The comparator could be implemented in software if that’s easier. Just an idea …](http://www.national.com/ds/LM/LM2907.pdf)