Illruminations

Recently, I decided to set up packet radio capability for my station. This is primarily in order to be able to reach the local Winlink Radio Message Server (RMS) gateway and have email access when power and/or internet are down, as has happened in the past after massive tornado damage in the area. I learned some interesting things while doing this, so I thought I’d share. I’ll include links and explanations of some of the radio-related terms, so I hope this is accessible to everyone.

I have a good station with excellent backup power sources, and I serve as an Official Emergency Station for Amateur Radio Emergency Services, (ARES). Adding Winlink email capability seemed like a good thing to do.

The RMS gateway station is in a facility a few miles from me, with redundant power and internet backup, and operates on the amateur radio two meter band.

Since the gateway is close to me and shouldn’t take much transmit power to access , I decided to try to put together a small package combining a handheld transceiver and interface which could serve me at my home location, or be portable if needed. For the interface, I chose a TinyTrak4 (TT4). While this device is commonly used as an APRS position reporter, it also functions as a Terminal Node Controller (TNC) which has a KISS Mode interface that can be used by the Winlink software.

TinyTrak4 (with my input level adjust modification)

I decided to try using one of the incredibly inexpensive Chinese handheld radios as the transceiver, and bought a Baofeng UV-3R for $30 on Amazon. It’s not hard to connect this to the TT4 – the radio has a four-wire plug and jack that connects the audio output, Mic input, and Push to Talk (PTT) signals.

The Baofeng puts out about 2 Watts of RF transmit power, which should be enough given that I’m close to the gateway and can transmit through a 3-element yagi antenna mounted on my roof, about 30 feet high.

Hooking all this up, I found I could not get a good connection to the gateway. My first thought was that it was low transmit power, but I decided to troubleshoot the entire functionality in a sensible order, and switched to monitoring APRS packet transmissions on 144.39 MHz. Received packet decode was terrible. I was successfully decoding less than 10% of what I could hear.

I know from prior experience that some packet decoders are very sensitive to input level, and I spent a lot of time fiddling with this. There’s a good procedure in the TT4 documentation, and I followed this.

Carrier Detect (CD) is a signal that’s present when another station is transmitting, and is used by the TT4 to determine when it’s OK to transmit, and also (presumably) when to try to decode received packets. The TT4 has three selectable options for determining that Carrier Detect (CD) has been asserted. The first is with an external wired connection. This option is not available for most radios, including the Baofeng, so I was limited to the second and third choices. The second is “Level” detection, which detects when the audio level exceeds a certain threshold. The reason that this works is that most radio transceivers are set to Squelch the audio output, or turn it off, unless there’s a signal present. The third method used by the TT4 is to detect the presence of the tones used to transmit the packet data.

I noticed that with the squelch turned on, and CD mode set to “Level”, I was unable to successfully decode a single packet. I figured that this was because the radio was slow to break squelch, and the beginning of the actual data was getting chopped off. With the squelch turned off on the radio, I was able to get a few packet decodes.

The next thing I did was to hook the TT4 up to another radio, an Icom 2200H. I immediately got decode of most packets I could hear, and when I adjusted the audio level, it went to near 100%. I tried this with the squelch both on and off on the Icom, and had good results both ways. There’s a software adjustment for “Audio Gain” as a configuration option in the TT4, and after playing with that in combination with actual input voltage level, it seems that any audio level between about 200 mV and 1.5V P-P will work well with the TT4.

A digression about what I can infer about the way the TT4 works:

The input circuit on the TT4 is worth understanding. The schematic diagram is in the kit manual, which is available here as a PDF document.

The TT4 audio input has a DC blocking capacitor (.1 uF) and is biased by two 220K resistors in a ladder from the A/D Reference pin of the MEGA644P microcontroller to ground. The ATMEGA controller allows you to output a selectable reference voltage on this pin, and that’s what the designer is using to bias the input. The choices are 1.1V or 2.56V. The input to the A/D converter sits at about 1.2 Volts, from which I infer that he’s using 2.56V. This can be seen in the following oscilloscope captures. It’s impossible to tell what the software design actually does (TT4 is not open source software), but with a 2.56 reference voltage for the A/D converter, this makes 2.56V the highest voltage that can be read accurately.

So in theory, input signals up to 2.5V Peak-to-Peak are fine, depending on how they’re processed. This pretty much matches with what I observed while using the Icom.

This brings us to the first examination of the receive problem with the Baofeng UV-3R. At the lowest volume setting, the voltage into the TT4 is about 600mV P-P, biased at about 2V. This is the very lowest volume setting on the Baofeng, one click off of silence. This level should work with the TT4, based on what I was seeing with the Icom. But it’s more complicated than just having the right input level . . .

Here’s what the beginning of the radio breaking squelch looks like:

Baofeng Breaking Squelch

The bottom trace is the A/D input pin, and is about the same (600 mV P-P). Note that the scales for the traces are different.

Another thing to notice here is that there are some large DC transients as the radio breaks squelch, with the A/D input going negative half a volt! It takes almost 80 mS before the bias level settles out (bottom trace). This could account for why it never decodes successfully when I have squelch enabled, but it sometimes decodes with the squelch off. I think that it just takes too long to break squelch and settle, and loses the beginning of the packet.

Here’s what the end of a packet looks like on the Baofeng:

Baofeng end of reception

You can see the end of the packet data, then a very short period of low signal (at the center of the image), then noise after the transmitting carrier stops. 100 mS later, the radio drops back into squelch. There are also DC changes from the radio here, and it takes another 150 mS for the input bias to settle.

When the squelch is turned off on the Baofeng and audio is output all the time, there are no DC shifts, so it appeared to be only related to squelch operation (more on this later).

Now, on to The Icom. Here’s a trace at the beginning of a packet when it breaks squelch:

Icom Breaking Squelch

Differences:
1. Much lower DC bias on the speaker line
2. Much less DC transient on breaking squelch
3. Much less time to settle – about 12 mS at the A/D input as opposed to 80 mS

Now, here’s the Icom end of reception:

Icom End Of Reception

There’s a larger transient here, but it probably doesn’t matter because we’re done decoding, and again, the A/D input settles fast – under 40 mS as opposed to 150 mS for the Baofeng.

After all this, I decided to add a 10K ‘volume control’ to the TT4 input, so I could turn up the Baofeng audio output a bit and then set the TT4 input level to exactly match the Icom levels which were working well.

Having done that, and doing A/B testing while monitoring APRS 144.390, with similar settings for both (Squelch enabled/disabled/ same settings for carrier detect), I got almost 100% decode with the Icom with or without squelch, zero decode on the Baofeng with Squelch enabled, and perhaps 5-10% decode with squelch turned off.

Lacking test equipment to examine the signals in more depth, I did try viewing audio from the Icom and Baofeng simultaneously on the two scope channels during packet reception, and they were nothing alike. This may be because the Baofeng claims to use “DSP”. This could lead to a delay in the audio, which would prevent it from correlating with the Icom. Or perhaps Baofeng is doing some audio processing for voice clarity, which is interfering with packet decode.

At this point, I decided that I didn’t want to put any more engineering time into looking at a $30 radio, and decided to move on and use the Icom to communicate with the gateway. I’ve been told by other local hams that they have successfully used this very same Baofeng model for packet radio, so I’m not sure why it doesn’t work for me.

And then . . .

Yesterday, this blog post was made, in which the author describes adding a Carrier Detect output signal to a different model of Baofeng radio. He was able to do this because the software in the radio only turns on power to the audio amplifier when it wants to make a sound. By connecting to the amplifier power supply inside the radio, he was able to implement hardware Carrier Detect.

AHA!

Turning on the audio amplifier when squelch breaks would explain the crazy DC transients that are seen as the the UV-3R comes out of squelch. It makes sense that Baofeng would do this on multiple models, as it saves battery power. I think the mystery of the slow squelch and DC transients has been solved, but I still don’t know why packet decode is so bad with the Baofeng.