[Scott] and his buddies were having some fun with their handheld transmitters one day when they decided it was time to build some add-on hardware that could transmit and receive location data. They set their sights on a set of Audio Frequency Shift Keying units that could each encoded and decipher location from the counterpart.
The build got off to an easy start, centering around an Arduino board with a GPS module for capturing precise location data. Next it was time to implement AFSK. On the transmitting side this was done by bit banging the output pins. After a look at the resulting signals on an oscilloscope the team was able to tune the firmware for a pretty tight 1200 and 2200 Hz output. But trouble was brewing on the decoding side of the equation.
The first decoding attempt used the FreqMeasure library written by [Paul Stoffregen]. After no success they moved to a hardware solution in the form of the XR-2211 FSK Demodulator chip. It should have been simple, feed it the signals and read the digital output pins to capture the desired data. This is the point at which you need to click the project link at the top to soak in all of the gory details. Long story short, a noisy power rail was causing sporadic performance of this chip. By the time this issue was discovered interest had waned and the project was ditched as a failure. Was there a quick fix that could have salvaged it such as adding a filtering circuit for that chip? Let us know how you would get this back on track by leaving a comment below.
[Thanks Lewin]
Fail of the Week is a Hackaday column which runs every Wednesday. Help keep the fun rolling by writing about your past failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.
Not sure, but is the channel via the walkie talkie ‘clean’? At least the motorola ones have both lowpass filtering and pre-emphasis to combat FM noise. Normally the pre-emph and de-emph should cancel out in the amplitude domain, but typically the combination of both is not linear phase (which may or may not be a problem)
Those look like cheap Wouxun or Baofeng ham/business band transceivers. I have a Baofeng UV-5R and the audio is extremely clean, especially considering the low price of the H/T.
Rather than a FSK chip, maybe try something simpler like the passive filters in this project:
http://hackaday.com/2013/08/20/building-an-analog-whistle-detection-device/
Can’t read the details (the site is flagged by my company’s security proxy), but I take it they tried to recreate ARPS?
From my POV, a simple solution might have been to lower the bit rate of the transmission.
I usually run two separate supply rails from the power supply connection: one for digital and one for analog. Same with grounds. In the “analog” rail, I use a series inductor and a cap to ground as a LPF. If possible, I’d then use a linear regulator to develop the analog DC supply from a higher input voltage.
I would have a ground poor if possible. more ground is better. all DC power rails should be filtered, but often a series component would cause losses that are unacceptable, in either case, having a Big Ass Cap to ground is important, but remember to have a much smaller high frequency cap in parallel. In many reference schematics 3 caps are used, one big on, one medium one and one small, the big caps act like inducters after their self resonance frequency, so at that point you need the little caps to take over and act like a short to ground.
I should also point out that, as @ashetts mentions, the problem has already been solved by APRS. Simply copy the schematic of any packet modem.
The MX614 would have been a good idea. Powering from the USB jack of a computer was probably not (at least, not without making sure they weren’t pulling too much currnet and had included heavy filtering)
Always check your power for noise first. This is the #1 reason to own an oscilliscope.
A raspberry pi and a soundcard makes a great cheap TNC that does this… no hardware needed other than the radio.
XR2211’s are THE worst chip EVER for decoding anything!
An Australian monthly electronics magazine that shall remain unnamed published a project for decoding WESAT images from NOAA and Russian Meteor satellites, it was the example circuit from the XR2211 data sheet, the original article have the Vcc and Vdd transposed (!!!), hundreds of people destroyed their XR2211, it took them 2 months to publish an errata!
I only destroyed 1 XR2211, which at the time was AUD$25, after realising the wiring diagram was wrong I got to work trying to decode images.
What a joke! the XR2211 is so unstable it’s not funny!
If you want to make weird noises, then the XR2211 is the way to go, decoding anything, forget it!
I ended up using a 4067 PLL, which worked straight up on the breadboard.
Not wanting to give up on the $25 XR2211, I had a go decoding RTTY and HF Fax broadcasts.
Same deal, hopelessly unstable, in the end I built a circuit with 2 NE567 tone decoders which worked a treat.
In short if you want to make honks, tweets and squeals then the XR2211 is a fine choice, if you want to decode anything, use another solution!
I would also recommend using two NE567 single tone decoders – they are the natural counterpart to our beloved NE555. I was working on a digital FSK transmitter with NE555 and CD4017 on the TX side and two NE567 on the other. Oh the memories :)
I dunno, this project uses a 2211, hardly modified from the app notes, and it works pretty well and is very stable. Agreed, though, reinventing APRS seems sort of pointless. Also, with zero-crossing detection or even a stripped down FFT implementation a small AVR can decode FSK in software if you pick your parameters right and keep the signal level within the dynamic range of the A/D.
http://heepy.net/mediawiki/index.php/RTTY_demodulator_using_NJM2211
Ironically when I search for XR2211, I came across this site. Someone did both analog and microcontroller versions of the AFSK modem. No Arduino – AT90S2313 Assembly language.
http://www.vfx.hu/proj/fskmodem/fskmodem_eng.html
Yes APRS has been around a long long time. Why recreate the wheel?
I’ll add this link just for reference.
“The WhereAVR is a small, lightweight, low-power, and low-cost APRS tracker with a full compliment of analog and digital I/O, as well as the ability to decode ax.25 packets.”
http://garydion.com/projects/whereavr/
It uses an ATmega8 to encode and decode ax.25 packet audio in software. No XR2211 needed.
It’s not a Wednesday… and…
Insufficient power supply filter caps are at worst a temporary, common, mundane, oversight, but nothing near a fail. I’d like to give this guy credit instead! Those that proposed workable alternative methods too! … but it just needs bigger/more filter caps! There’s plenty of good work here, as well as good alternatives.
No fail in my book here!
{I fully concur with @cyberteque about sundry MoreF@rt PLL WEASAT decoders, a failure of understanding of PLL’s}
“noise from the computer’s power supply on the USB line were causing the PLL to lock and unlock randomly”
Hams call these TU’s, Terminal Units, digital modulator/demodulators originally used with mechanical radio teletypewriters, RTTY, and their problem was with the demodulation. In fact this problem was found and solved back in the valve era.
In those days the demodulator consisted of two LC circuits resonant to the two keying audio frequencies, in this case 2200 and 1200Hz, followed by audio rectifiers in opposition. The trick was to follow this with a floating slicer, a Schmitt that followed the average DC voltage output, curing the problem of high/low pulse width bias, and producing an output with little or no bias.
Attempts to emulate this with a simple PLL like the XR-2211 produced very similar output to the two-LC-circuit demodulators, but failed when they left off the floating signal slicer.
in fact even powered from a battery *!*a PLL inherently has a random lockup time to an in band detection*!*, so some pulse jitter is introduced simply by the move to a PLL from LC; not as “identical” as they first look.
A very simple but robust frequency discriminator appeared in Electronics Australia’s Dream6800, a hard-limiting op-amp/comparator which triggers a 555 set to a time median to the short/high and long/low pulse widths, the output state of the comparator is then clocked into a D-type flip flop when the 555 times out at the H/L discrimination time.
555 set to half the difference;
1/1.2 = 0.8333mS
1/2.2 = 0.4545mS
0.8333 – 0.4545 = 0.3788
0.3788/2 = 0.1894
0.4545 + 0.1894 = 0.6439mS
check;
0.8333 – 0.1894 = 0.6439mS – check!
(but it operates on the half-cycle, so 322uS)
I’ve used this and found it to be robust over all sorts of links and with cassettes, and up to 9600baud.
lol
Morfart!!
If you remember the article he says, and I quote
“We’ll assume you’re more of a computer person than an electronics person, so we wont go into to much detail about how the circuit works.”
That was coz he copied it from the app note!
Do you still have a Dream 6800? I do!
How did ASR33’s decode serial? The way you describe?
It’s great to hear all your constructive comments. Using another PLL over an XR2211 may be a good idea… we had huge problems using a dsPIC’s onboard DAC on another project until we realised our noise problems were down to Microchip’s poor design.
To those wondering why we reinvented the wheel, well – doing it ourselves from the ground up taught us a lot. We learned about star grounding techniques, noise from USB power and other sources, how to use PLL chips, error correction and detection techniques, how to use interrupts and proper timing on an Arduino… none of which we would have gotten from simply building an AFSK kit board or similar. We seek knowledge as well as the finished product, hence taking the long way to do it!