About a year ago I put the LM565 modem on the air and have had success in several events since while still pursuing a solution that uses the newer/CMOS CD4046B PLL chip and preferably Arduino instead of RS232.
While pursuing a solution that is more 21st-century than the TTL-based (and mostly retired) LM565 circuit I was getting hung up on the tendency for Arduino communication to be geared toward higher speeds (>9600 baud) while forsaking lower ones (below 300 baud). This limitation is understandable since the need for such a low serial rate is an anomaly these days save for a few legacy equipment situations such as this.
The learning curve over this has shed light on the fact that the USB communication with the Arduino must be at least 9600 before ASCII text will pass correctly between it and anything on the host side. Another limitation, even when using an Arduino Mega board, each of the hardware serial ports can only go as low as 245 baud, evidently a limitation from the standard 16MHz system clock. Software serial is going to be the answer to this, it goes as low as you want, just need to adapt it to 5 bits at some point.
I had gotten partial decode with the 4046 using RS232 and running on a 13.8V bus, but then switched to Arduino and its 5V bus to see what I would get, and due to the challenges mentioned, got nowhere.
So after resetting to the 13V/RS232 scheme it didn't take long to get a partial decode, and then by experimenting with different C1/R1-R2 combinations we arrived at a perfect decode of some recorded RTTY (part if it is fldigi-generated text and then some W1AW bulletins recorded off air).
So at this point I have a slightly updated modem that does exactly the same thing as the previous design. I believe the earliest signs of decoding were with the 4046's Comparator II which is more geared toward clean, locally-generated signals, tried as a hail-mary. But the final answer, not surprising, is Comparator I which is geared toward high signal rejection which is crucial when you need it to lock onto the tuned signal.
Working with the LM565 version has shown that its sensitivity is lacking when the signal is marginal, especially when running the rig's decoder which seems to lock onto anything the ear can detect. That got me to thinking that a preamp might be prudent, as the 4046 spec says it will accept either an AC signal or a biased signal with swing as large as the supply voltage.
I had been thinking that biased amps were very complex, but that's only true of biased filters. Didn't take long to find a paper from an MIT course that spells out a simple biasing op amp that can have variable gain, and best of all, I can use all standard components to get it tuned properly to the standard 2125/2295 Hz range. For the prototype I had to estimate the capacitors but that didn't seem to matter. I also had guessed that ~6x gain would suffice and not overload the 4046, but I quickly realized that the 4046 still decodes fine when overloaded with a clipped signal.
And so, I ended up with a 1 meg pot that can produce up to 100x gain. Didn't take long to determine that this brings the sensitivity on par with the rig's decoder. This means a lot of junk characters and such hitting the screen, but isn't that better than nothing at all? I am just thankful that it's not eating up paper as in the good old days.
Much of the circuit is essentially held over from the LM565 version, there's still the filter stage that leads into the op-amp comparator that in turn feeds the TTL drive circuit. One quirk is adding a jumper between the serial's TX to the TTL interface circuit, as it was originally designed. For some reason that was omitted before and I'm frankly not sure how it worked without it. Oh well.
I am also going to switch to CMOS op amps to replace the 741s, more modernization that will run with less current. Not that the rig's 1-amp supply suffers when powering the older TTL chips, good to be as efficient as possible. Was going to add a power LED just to help knowing that all is alive and well once things are wrapped in a box...nahhh.
At this point we have a wonderfully successful proof of concept that is worth wiring up, even at the prospect of getting the Arduino version into play, this will make a great backup unit if ever needed. At this point I'm tempted to think the immediacy of a hardware serial port is always going to be ideal, but time will tell.
Trying to keep the gain pot at a place where the input doesn't clip going into the 4046, but the 4046 doesn't care, this is while copying W1AW bulletin and the idea is to keep the input just at the supply swing (or a little less) to test copy off the air to see how it does when the band ebbs and tides.
This captures the shifting between mark and space (2125/2295 - yes I have an ancient scope and love it, have yet to try one of the new USB ones):
Once again the SerialRTTY terminal captures it all:
In the end it seemed best to not bother using a pot for the gain and just fix at 100x with a 1 meg feedback resistor and be done with it. If I want to clamp off the RX stream momentarily it's easy enough to just kill the AF gain on the rig.
Another adventure was working through the TL072 in the soldered version without having tested it in the breadboard version. Not surprisingly there was a bit of learning curve here, but the answer came down to adding in some decoupling caps near the ground of the ICs and then the 10 uF one that the 565 circuit employs - right away this added some stability. After that it came down to just finding the the right timing and filter components for this particular board since we know how certain layouts will add their own capacitance.
I've also given in to adding contest automation and logging to the serialRTTY project, should just be a matter of three input fields below the center bar and most control will be done with Alt-keys.
After working the WAE again recently it's hard to resist the appeal of those QTCs, such a cool aspect that the DARC folks baked in, so we may have to see what can be done to accommodate those as well.
Sources:
