Tuesday, March 1, 2022

Radiosonde iGates are quite a mess, and they seriously need some fixing

I have today started to filter out radiosonde traffic coming to aprs.fi, because it's consuming quite a lot of resources, and the incoming data is quite a mess, and my log files are full of warnings about inconsistent balloon positions, just because the gateways all work differently, and they create a lot of duplicate data, at a very high rate.

Various gateways convert the same received packets to slightly different APRS packets, and the same balloons show up as many tracks on aprs.fi, which consumes resources here, and it also looks silly on the map.

The packet rates are also wild - many gateways forward packets from a single balloon every few seconds, which is much more often than any well-behaving APRS stations do. Because different gateways customize the packets by using unique destination callsigns, inserting advertisement URLs and custom comment texts, I'm getting a whole lot of packets here, many of them modified duplicates of the same original frequent packets. It's quite silly indeed.

Please note that it has also been said and written many times that the APRS-IS is designed and built to only carry amateur radio traffic, and sonde data clearly are not amateur radio traffic. I might personally be ready to make an exception, but I can't speak for others, there might be strong opposition elsewhere. One perfectly good option that all of this traffic only goes to sondehub.org and/or radiosondy.info in the future - but the improvements listed here should help that service just as well.

I can re-enable intake of this data at aprs.fi (perhaps via a different set of APRS-IS-like servers, or the sondehub.org websocket feed), but I have two simple conditions that must be fulfilled first.

1. Receivers must forward data consistently, and maintain data integrity, so that APRS duplicate packet suppression works

All gateways forwarding a single packet received from a sonde must all output the exact same APRS packet: Same source callsign, same destination callsign, and same packet contents. Similarly to APRS, the path may differ and the receiver callsign after the Q construct is naturally different.

The packet must only contain data that was received from the sonde - it must not contain identifiers, text or data that is configured on the gateway, or is somehow dependent on the receiver software version, local time, signal level at receiver, or such.

This ensures that the APRS-IS duplicate packet filtering methods work. When all the gateways emit the same packet, duplicates can be removed and a single copy will land at aprs.fi.

Yes, this requires a little co-operation and coordination by the gateway software authors. Once you sort it out, and document what the format is, and which gateways support the consistent format, let me know and I'll open it up!

The gateways may announce their own software and custom comment strings in the beacon comment text sent to indicate the position of the gateway itself. It must not go to the comment string of the balloon; the packet of the balloon must be standardised and harmonised.

2. The packet rate must be sane, and in line with APRS operations

Typical APRS stations beacon once every 30 seconds, or much less often, when they're not making tight turns. Once per 10 or 20 minutes when they're not moving. It's not acceptable for balloons to transmit on the APRS-IS once every 3 seconds, even if their data rate on RF would allow such an interval.

If you need a higher rate for the recovery / location, make it dynamic - every 20 seconds when the balloon is at low altitude and just about to fall down. When flying really high - every 40 or 60 seconds should do, it's plenty. When they're high up, the packets will be heard by many receivers, which also brings the packet rate up greatly.

The discussion on fixing this for radiosonde_auto_rx is ongoing in these two tickets, but the point is that all gateways need to work the same way.

73, and happy hacking!

Saturday, February 19, 2022

Baofeng & BTech APRS-K1 & iPhone problems

TL;DR: It seems like many Baofeng radio units (UV-5R, UV-82, etc) do not work with the aprs.fi iPhone app using the BTech APRS-K1 cable. They do not work with any iPhone app - I tried all the other APRS apps I have, and other non-APRS apps recording or playing back Audio. It seems a bit like a build quality issue as it does not depend on the radio model, but rather the individual unit. It works for some people, but for many it doesn't. Other radios I have work fine. The Android phone I have works with the UV-5R, so it must have something to do with the circuitry on that side as well.

There's a 1-capacitor fix/workaround in the end!

Many users of the aprs.fi iPhone app have purchased an affordable Baofeng radio, and the BTech APRS-K1 cable, and have then tried to use those for APRS. It has worked for some users, but for many it has failed miserably. This setup does not have a PTT line to key the transmitter – instead, VOX is enabled so that the radio will transmit whenever there's audio coming from the iPhone or iPad.

Users have reported that as soon as the aprs.fi DSP modem is enabled ("Connect TNC" is pressed in the iPhone app), the Baofeng transmitter goes on, and never goes off. When "Disconnect TNC" is pressed in the app to stop the modem, the transmitter goes off a second or two later.

Naturally, at that point, the first guess would be that the modem would be emitting some noise, which would trigger the VOX in the Baofeng. But it doesn't, if you attach earphones and listen, or if you look at the modem output with an oscilloscope.

It doesn't depend on the radio model - UV-5R or UV-82. Some units work, some don't. I had only tested the app with a Puxing PX-777, a Kenwood TH-D72 and a Kenwood TH-D74, all using the same BTech APRS-K1 cable, as they all are using the same mic/headphone connector ensemble. All of them work fine. Well, as well as a VOX-driven APRS transmitter can work, i.e. not great, as the transmitter keys up slowly and goes off very slowly due to the VOX delays.

So a few weeks ago I finally ordered an UV-5R so that I could figure out what exactly is going on. I have a Siglent digital storage oscilloscope which allows me to look at the three audio channels between the iPhone and the radio: left & right headphone outputs, and the microphone input.

I also bought a 4-wire 1-meter TRRS extension cable from Ebay, cut it up and made a 10 cm extension cable with exposed wires where I could attach the oscilloscope. The JAMEGA Gmbh cable is awful - no shielding/braid at all on the cable, and they even sell a 10-meter version. Not good for low-level audio signals. But it'll work for 10 cm.

The first thing to test: plug in just the APRS-K1 cable, without a radio at the other end, and see that the inputs and outputs on the adapters and cables are fine, and the scope sees the right things. In this oscilloscope screen shot you see the L/R headphone outputs on the bottom, when a packet starts to go out. The blue line on top is the microphone line, which has a little high-frequency noise on it, as it is a low-level high-impedance wire which is not attached to anything on the other end.

Ok, that seems fine. The lines are quiet when the app is not transmitting a packet, and the waveform seems alright when it is transmitting. But what happens when I attach the APRS-K1 cable to a Baofeng without touching oscilloscope settings? This! All the time! It does not matter whether the Baofeng is powered on or off. Attach a Kenwood or a Puxing, this does not happen. There's a high-frequency signal on the cable, on all 3 pins.

If we zoom in to it on the frequency scale, we find a 473 kHz signal on all 3 wires. The frequency is drifting, so it's probably not sourced from a good oscillator / clock reference. Click on the image to see a higher-resolution screen shot - frequency counter is in the top right corner, level measurements on the panel below the plots. Pretty high-level, so if the Baofeng is powered on, VOX probably keys up the transmitter. The frequency is so high that you won't hear any audio being transmitted if you listen to the transmission with another radio. This is how it looks with the iPhone and a Belkin Lightning-3.5mm adapter.

With the Belkin lightning-3.5mm adapter, levels are 150 & 330 mV L/R, frequency is about 470 kHz. 

If I turn on the Baofeng, the VOX triggers, transmitter goes on, and on the oscilloscope the only difference is that there's some high-frequency noise on wires, which can be expected as there is a 5W transmitter on the table. Even though it's transmitting to a dummy load instead of an antenna, this is to be expected.

This is the same thing, without the Belkin adapter, when attaching directly to the 3.5mm connector of my iPad - levels are lower at 20 & 110 mV L/R, frequency is 555 kHz. Baofeng is off, so no high-frequency noise from the transmitter.

Now, the interesting detail is that this only happens when the iPhone audio interface (A/D and D/A converter chip & amplifiers) are powered on and capturing audio. Could it be a feedback loop of some kind, between the A/D D/A converters and the circuitry on the Baofeng, with the A/D/A converter leaking the 500 kHz signal back and amplifying it? Or an oscillator is formed together with the Baofeng?

The iPhone has a power management system, where unnecessary components are powered off to conserve battery power. If any application (Voice Memos, Camera app in video capture mode, or the aprs.fi app) starts to record audio from the microphone input, the electronics of the A/D and D/A converters are powered on. This explains why the transmitter goes on when you start recording audio on the iPhone, or when you turn on the modem in the aprs.fi app. If you're wearing headphones attached to the iPhone and start audio playback from any app, or start recording in one of those apps, you can even hear a small "pop" sound in the headphones - it's the D/A converter waking up! It looks like this on the oscilloscope:

Because someone reported the same Baofeng + APRS-K1 cable setup works with APRSDroid on an Android phone, I tried it with my Nokia here. Yes, it does work, so there must be some difference in the audio circuitry or how it is used!

On Android, the A/D and D/A circuits seem to be powered separately. Georg DO1GL says that APRSDroid only outputs audio samples when it is transmitting a packet, and captures audio samples continuously for the receive to work. When looking at it on an oscilloscope, there is a 260 mV DC offset on one headphone audio channel when it's not transmitting. The DC offset goes away during transmit, and some time after the packet has ended, the DC offset comes back. There is also some additional noise on the output of the Android phone for some time after the packet has gone out, and the noise stops when the 260 mV DC offset appears. It would seem to me that the D/A is powered on only when audio goes out, and it can be powered off even when A/D conversion is taking place.

On the iPhone it seems to me that the D/A cannot be powered off independently. All audio-recording applications which I tried cause the D/A to be powered up and the strong 500 kHz signal to be generated if attached to the Baofeng. I tried all the APRS apps with DSP modems, and several other audio-capturing applications, and they all trigger the noise, if my Baofeng is attached.

Oh well. If it's feedback or oscillation, can we fix it by adding capacitance? Turns out we can!

I'm not much of an electrical engineer, but sometimes you can work around issues like this by just adding a bit of inductance or capacitance somewhere in a very experimental fashion, without applying too much science or math.

If you peel off the sticker on top of the APRS-K1 dongle, and open the two small Phillips screws, you'll find a small circuit board with a few capacitors and resistors. In this picture, the radio is attached to the left side, and the iPhone is attached to the right side. Red wire is the microphone wire on each side, white is the earphone wire, and black is ground. No isolation transformers.

The iPhone-to-radio-mic connection has just a single 100 nF capacitor for blocking DC, on the bottom of the circuit board. The radio speaker -> iPhone mic path, on the upper side of the board, from left to right, has a series capacitor (10 nF), a 2-resistor voltage divider (10 kOhm top, 2.2 kOhm bottom half), a second series capacitor (guessing 10 nF but couldn't measure), and a 1.8 kOhm resistor to ground, which tells the iPhone that a microphone is connected.

I checked with the oscilloscope that the 500 kHz signal was strongest on the bottom right corner, the wire labeled Phone SP, i.e. audio output from the phone. I grabbed a box of capacitors which were small enough to likely fit within the enclosure, tried the smallest and largest values (10 nF and 470 nF) by just pressing the capacitor wires on the SP and GND pins (black and white wire), and found that the largest one stopped the oscillation completely!

Most importantly, the Baofeng UV-5R is no longer stuck transmitting!

I then tried different values, and found that when attached to the iPad, where the 500 kHz signal levels were lower, a smaller value of 220 nF was enough. With the iPhone and the Belkin 3.5 mm adapter, only 470 nF cured it.

In hindsight, I could have tried putting the cap on the other pins as well - a lower value might have worked in another location. But this worked well enough and I didn't want to spend any more time on it, so I just soldered the capacitor in place, measured the results and closed the package!

This is how it looks with Baofeng UV-5R attached and powered on:

And this is how it looks when a packet is being transmitted. Note how the left and right audio output channels look the same, even though the parallel capacitance is present on one of those channels. Seems like it doesn't affect the transmitted audio too badly. Levels are different from the very first oscilloscope screen shot, because I've reduced the volume on the iPhone a bit.

Now, when I got it transmitting, I found out that the Baofeng is deaf. I have it attached to a 2*5/8 vertical antenna on the roof, which I use with other radios normally, and the transmissions go out just fine, but the squelch on the Baofeng does not open up when the nearby digipeaters transmit. On the other hand, squelch needs to be used, otherwise VOX will not key the transmitter at all, as VOX refuses to transmit when the squelch is open. I will not investigate that issue any further. :)