Baofeng Packet Radio Adventures

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

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

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

Icom Breaking Squelch

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 squelch

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.


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.

About Steve

I'm Steve Conklin, AI4QR I'm employed by Salesforce, on the SRE team for Heroku. Interests include Linux, open source software and hardware, electronics and music, and amateur radio.
This entry was posted in ham and tagged , , , , . Bookmark the permalink.

5 Responses to Baofeng Packet Radio Adventures

  1. Kris Kirby says:


    The DC bias you’re seeing on the audio out is coming from the audio PA. That’s your COS signal. No invasive surgery needed, just send that to the COS pin. Some radios drive the speaker differentially (Saber and Spectra do) so there is V+ or V+/2 on the speaker outputs. Another trick would be to use some resistors and a pot to recover the signal from the audio output. Search for KE4AHR at the following page:

  2. ScW says:

    Thanks for the article. I was looking at doing some stuff with my baofeng as well… and had trouble getting anything to decode. I too observed (without the excellent spectrum analysis) that the squelch break sounded rough and figured it might be impeding decode. Not offering a solution… just thankful there’s more info to backup what I thought I was hearing.

  3. Ron says:

    Hi Steve,

    Great article, thank you for posting that. I am having the same issue with trying to get my Baofeng UV-5R radios to work with my TT4 in receive mode. I’ve been at it on and off for almost a year now. I have 2 UV-5Rs and neither of them work with the TT4.

    Besides trying the suggestions provided by Byonics, and others, I have also tried a few different approaches myself. Using a worksheet, I’ve tried every possible combination of RXAMP, CDLEVEL and radio volume. On rare occasions, I’ve been able to receive a few messages. One thing I have noticed is that if I let the radio run on batteries from a full charge to dead (~24hrs), sometimes there is a short period of time (15-30 mins) that some messages will be received. I have tried capturing the average input level (using the MONITOR command) during that time by putting at least 100 monitor values into a worksheet column and taking an average. Then I’ve gone back and tried to set that average level using the radio volume when the radio is in it’s charger. Unfortunately, that hasn’t worked either.

    Overall, this is an impractical process even if it did work. The TT4 seems to be extremely sensitive to the Baofeng output. I would also agree with you that the Baofeng could be modifying/filtering the output somehow. Like you, I’m about to give up on ever getting a Baofeng to work with a TT4. I need a process that is simple and quick and from what I’ve experienced I would say the Baofeng/TT4 combination is virtually impossible to get working in receive mode.


  4. Dave says:

    I’ve had great luck using CD TONES and leaving the squelch wide open. This is suggested by experts on the TinyTrack4 yahoo user’s group

  5. Another tactic is to capacitively couple the audio, but the value of the capacitor becomes critical depending on the impedance of the the audio sink or termination point. Motorola used a pair of 1500 uF 35 V polarized capacitors in the Mitrek driving an eight-ohm speaker, but if the sink is High-Z (> 600 ohms), 10 uF may be closer to appropriate coupling without introducing high-pass filter effects. YMMV, I usually test to determine fitness. Capacitor values will vary depending on the value and type (ESR, really) of capacitor. Other models of radios didn’t use capacitors (like the Spectra, Saber, Kenwood, Baofeng, and Ericsson), and some used transformers (Motorola Syntor X9000 and earlier types).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s