Mark & Adrian's Ham Radio Blog High-Altitude Balloon Chasing, Direction-Finding, and more!

Blog Move!

I'm now co-authoring a blog with Adrian Snell (VK5ZSN), at http://rfhead.net/

That blog will probably be updated far more often than this one, so please check it out!

Vaisala RS92-SGPW Digital Radiosonde Reverse-Engineering

Recently, Joel, Adrian and I acquired a number of Vaisala RS92-SGPW digital radiosondes, with the intention of making them usable on the 70cm amateur radio band. I've talked about these radiosondes and how we obtain them in a previous post.

A (not so) brief look inside...

RS92-SGPW Mainboard

The RS92-SGPW consists of a GPS receiver, a sensor module (temperature, humidity & pressure), a 400MHz transmitter module, and a micro-controller tying it all together. Many of the ICs are custom-made by Vaisala, making reverse engineering the device difficult.

Micro-controller

The micro-controller is an interesting beast, labelled with 'DSP1C'. My suspicions are that it is a dsPIC core on custom silicon, but I haven't been able to confirm this. Further investigation will look at finding the programming pins and interrogating the IC for information. The micro runs at 16MHz, provided by the GPS module, and talks to peripherals using mostly SPI. The code for the micro-controller is stored in a 256Kbit SPI EEPROM, which will be discussed later in this post.

GPS Receiver

The GPS receiver is a uBlox uN8021 RF front-end, which demodulates the  GPS L1 signal, and sends samples to the micro-controller. This module is controlled via SPI on a shared bus, and also provides a 16.3676MHz clock signal to the rest of the board.

Sensor Module

This module, which extends outside the main sonde casing, incorporates a temperature sensor, two humidity sensors, and a pressure sensor. At the moment I am unsure how it communicates with the micro-controller, as my focus has been on the radio module.

400MHz Radio Module

400MHz Radio Module

This module contains a Vaisala TX1B GMSK modulator, which is programmed via SPI on the shared bus. The output frequency and power are programmed from the micro-controller on boot-up. The module accepts 2400-baud synchronous serial data on pins 2 and 3 of the module, which are transmitted using GMSK modulation.

Code & Configuration Storage - The 95256 EEPROM

On the bottom left of the RS92-SGPW main-board is a small SO-8 EEPROM IC. This EEPROM contains the software for the micro-controller, as well as configuration and calibration parameters for the rest of the sonde. Adremko, from the Sondemonitor Yahoo Group, provided information on what a few of the addresses within the EEPROM mean, allowing manipulation of the output frequency and power.

To allow us to experiment with the EEPROM, Joel and I soldered wires to each pin. These wires were then hooked up to a Bus Pirate, a universal bus interface, which talks SPI along with many other serial protocols.

Attaching the Bus Pirate to the EEPROM

Using the bus pirate, we were able to see the micro-controller pull program data off the EEPROM during boot-up, and then watch other communications on the SPI bus (mainly the GPS) during sonde operation. I was able to write a number of scripts for the bus-pirates interface to read and write to addresses in the EEPROM, allowing me to read and change the output frequency control bytes. One of the bytes steps the output frequency in units of 2.56MHz, while the other steps it in units of 10KHz. A lot of trial and error later, I was able to find the upper limit of the transmitter was 423MHz. Around this point the PLL within the transmitter module cannot lock, and no output signal is produced.

To make programming the sonde easier, I wrote a Python script which uses the Bus Pirate's binary mode to talk to the EEPROM. Sample output from the script appears below:

darkside-macbook:Python darkside$ python set_frequency.py
Enter new frequency (MHz): 420.050
Chosen Frequency = 420.05MHz
Hex values are 0xd5,0x7
Opening serial connection to bus pirate...
Entering binmode:  OK.
Entering raw SPI mode:  OK.
Configuring SPI.
3V3 Power On.
SPI Speed set to 125KHz.
SPI Configuration Finished.
Reading current frequency:  400.800MHz
Confirm Programming of new frequency (420.05)? y
Clearing Status Bits.
Status Register:  0x0
Writing f1.
Writing f2.
Confirming Write:  OK - Frequency set to 420.050MHz.

I also made a cable to connect the Bus Pirate to the sonde, this time using the un-populated 16-pin header to the right of the EEPROM. All of the EEPROMs connections are present on this header, and by using a IDC connector with a pin-header inserted I can connect to the sonde without any soldering.

The new cable connecting the Bus Pirate to the Radiosonde's 16-pin header.

A closer view of the 16-pin header connection.

Future Work

Changing the output frequency is only the first step to making full use of these radio-sondes. If we can understand how the micro-controller is programmed, we may be able to use the radiosondes as a full-featured telemetry platform.

My Hobbies: Met Balloon Hunting

Every 6  hours (0,6,12,18 UTC), the Bureau of Meteorology (the BOM), launch a weather balloon. Where they land depends on mainly on atmospheric wind conditions at the time of launch. Some days, I'm out chasing them.

There are generally 3 types of payloads attached to these balloons:

Radar Reflector Only

These balloons are used for wind-finding - measuring the wind speeds in the upper atmosphere. They consist of the balloon and a radar corner reflector. They are tracked using a ground based radar, and are usually launched daily at 6Z and 18Z.

A Wind-Finding sonde, just before launch. See the launch video at: http://vimeo.com/19826431

Radar Reflector + Analog Radiosonde

A Vaisala Analog Radiosonde

On these balloons, the radar reflector is used for wind-finding, and the analog radiosonde measures temperature, pressure, and humidity data and transmits it as a sequence of tones. They are called analog sondes as the is it not binary data that is transmitted. Rather, a sequence of 6 tones is transmitted, consisting of high and low calibration tones, then other tones for the weather parameters measured. To obtain meaningful data from the tones, calibration data (calculated just before launch) is required. The analog radiosondes transmit WFM modulated tones between 400.3 and 403MHz.

In most cases, the BOM will launch an analog sonde around 0Z and 12Z each day, to collect temperature traces, along with wind-finding data.

Digital Radiosonde (+ Radar Reflector)

A Vaisala RS92-SGP Digital Radiosonde

Digital radiosondes have the usual array of weather sensors, along with a GPS receiver which allows wind-finding without a radar. Data from a digital sonde is transmitted as 2400 baud GMSK (Gaussian multiple-shift keying), and can be decoded using software such as SondeMonitor. The digital sondes also transmit in the 400.3-403MHz band, but use narrowband FM.

Digital sondes are reasonably expensive (~$200/sonde) and are used instead of an analog sonde in locations where a radar is not available. They are also often used when the local wind-finding radar is down for maintenance.

Balloon Chasing

The Vaisala radiosondes are very interesting from an amateur radio standpoint, as they are are a full-featured sensor package in quite a small size. Potential also exists to re-use the sondes, though they would need to be modified to operate in the 70cm amateur band (420-450MHz).

To learn more about the radiosondes, we need samples to investigate. This means collecting radiosondes, which means tracking and chasing them.

To get a rough idea of where the balloon will land, we make use of prediction software written by students at the Cambridge University. The predictor is available online at http://habhub.org/predict/, and can predict the landing site of a weather balloon with reasonable accuracy (within 20km or so).

Once a balloon is launched, how it is tracked depends on whether it's an analog or digital radiosonde. Analog sondes have to be found using traditional direction-finding methods, such as with a doppler array, or a yagi antenna that is pointed at the target.

Digital sondes are much easier to track, as the transmit positioning data from their inbuilt GPS module. SondeMonitor can plot the positions of digital sondes on an internal map, and also makes the sondes position information available via a COM/OLE Automation interface.

SondeMonitor showing the path of a radiosonde as it comes in for landing.

Since Sondemonitor's internal mapping system can't handle large map files (i.e. files that cover very large areas), I wrote some code to read data from SondeMonitor and plot it in OziExplorer, a commonly used GPS mapping program. Flight-path predictions are also run every 30 seconds to help us navigate to the landing site for quick retrieval.

Tracking of a digital radiosonde using SondeMonitor and OziExplorer. The green line represents the sonde's flight path, the orange line represents the predicted flight path, and the red arrow indicates the chase car's position.

Once we get near the landing site, we switch to traditional direction-finding methods, as the sonde usually loses GPS lock once on the ground. Our standard method involves driving around the landing area, collecting (using a yagi antenna) and plotting bearings to the sonde on a map. The bearings will cross each other (intercept points), indicating where the sonde is located. We then either drive or walk to the sonde, using bearings from the yagi antennas to lead the way.

Bearings intercepting over a radiosonde's landing location.

At the controls in VK5ZSN's Land Cruiser.

Adrian's Truck, with direction-finding yagi and doppler array on the roof, along with many other antennas.

HAB Telemetry Design – Radiometrix RF Modules

This post is intended to provide a bit of an idea as to why we use Radiometrix UHF and VHF modules in our balloon payloads, and how we operate them.

The modules we most often use on the Project Horus launches is the Radiometrix NTX2, a UHF transmitter module operating at 434.650MHz.

MobSenDat Telemetry board, with NTX2 transmitter module

We have also used TX1H VHF modules (151.3MHz), but for now I'll talk about the NTX2 modules, they operate the same anyway.

These transmitter modules are really just VCO's (Voltage Controlled Oscillators) in nice packages. The NTX2 has a 'TXD' (transmitted data) input pin, which is filtered slightly, and fed into a VCXO (Voltage Controlled Crystal Oscillator), producing a carrier with variable frequency. In most applications TTL data (0 - 3.3V) data would be fed into this pin at data rates up to 9600 baud, producing 9600 baud FSK (Frequency Shift Keying), with a shift of around 6KHz. Note that FSK is a basic form of Frequency Modulation (FM), hence the label on the modules.

NTX2 Block Diagram

In a HAB application, reliability is more important than data throughput. While a 9600 baud downlink would be nice, it can be too unreliable over long distances, so we use baud rates up to 300 baud. The other trick we do is to not use TTL voltages on the TXD pin - instead, we use a voltage divider across 2 pins on our micro-controller to give a smaller voltage shift, and hence a smaller frequency shift on the output. One pin is set high, and the other low for one voltage output, and this is reversed for the other voltage. With 33K and 47K resistors we obtain a voltage shift of about 0.6V, giving an output frequency shift of around 425Hz. This setup has been used on every Project Horus balloon flight, and works very reliably.

A note about frequency drift...

The NTX2 module does have one problem - frequency drift. Inspection of the block diagram and the module itself shows the VCXO uses a 86.93MHz crystal, the output frequency of which is multiplied by 5 to give the 434.650MHz output. While the crystal itself may be temperature stable, the frequency multiplier is not. During balloon flights where the payload temperature may vary by 60 degrees C, we have seen the output frequency drift by up to 20KHz.

In the UK, where HAB enthusiasts are only allowed to use 434.650MHz for balloon flights, various methods to keep the transmitter stable have been tested, such as a PID controlled heater. In Australia, we have a number of other options, such as using modules on different frequencies. The TX1H VHF module, for example, uses a 151.3MHz crystal with no multiplier, resulting in a very stable output frequency. One of these modules was used on Horus 14, and had no noticeable drift during the flight.

Icom IC-R10 Control Interface

A few weeks ago I bought an Icom IC-R10 wideband radio scanner for the purposes of  High Altitude Balloon (HAB) tracking.

The IC-R10 (i'll just call it the R10 from here on in) has a few features that make it great for HAB tracking:

• It has a large receive range, about 500Khz to 1.2GHz
• It can receive sideband (USB & LSB) over its entire receive range
• It has a variable gain knob, which helps when direction finding
• It can be computer controlled via Icom's CI-V interface

The last point was of great interest to me, as I've never owned a computer controllable scanner before. So, I decided to built a control cable.

A bit of research showed that Icom's CI-V interface is really just a 5V TTL serial connection, with RX and TX on the same line. In the R10's case, a 3.5mm socket is used, with the data on the 'ring', and ground on the 'sleeve'. My interface consisted of a FTDI USB to UART adaptor (from Sparkfun), with a small adaptor allowing me to attach a 3.5mm male to male cable.

IC-R10 CI-V Interface

During testing I found I was getting a lot of noise into the R10 from my laptop, so I wrapped a bit of the cable around a ferrite toroid (thanks for the suggestion Joel!) and that fixed the problem.

So now I have a way of communicating with the R10 from my computer, how do I talk to the R10? Thankfully, I didn't have to worry too much about the low level serial protocol, as a great project called Hamlib already exists for this purpose. Hamlib can be used via bindings for a few different languages, but I opted to use a helper program called 'rigctld', which allows control via a TCP connection. This also allows multiple clients to control the same scanner.

Starting up rigctld is fairly simple:

rigctld -m 336 -s 9600 -r /dev/tty.usbserial

The -m option signifies the radio's hamlib rig number (found here), the -s option is the baud rate, and the -r option is the serial device.

So now rigctld has a TCP server running, and we can try out some commands. Many radios are supported with Hamlib and so many commands are available, but most radios only support a small subset of these commands. In the R10's case, the receive frequency can be read and set, the modulation mode can be read and set, and a signal strength measure can be read. The manpage of rigctld provides a pretty good rundown of the commands, so I won't repeat that here.

After a bit of playing around in netcat, I wrote a small python class to talk to rigctld and control my R10. With this, I was able to do a few interesting things, like plot the received signal strength (RSSI) over the FM broadcast band:

RSSI over the FM broadcast band

I'm still not sure how the RSSI values relate to real-world units (i.e. dBm), but it's obvious that larger values mean a stronger signal. Sometime in the future I'll calibrate it with a signal generator from University, but for the moment the values are still useful.

A few ideas on what this could be used for:

• Use it as a slow spectrum analyzer
• Monitoring of beacon stations, to monitor tropospheric ducting conditions
• Attach R10 to a yagi, and use the signal strength data for automated direction finding.

Mini-Kits EME162 Wideband Amplifier Kit

For a future balloon launch (See this blog post for an explanation), I'm flying a re-build of my University final year project. This is a HF telemetry system, using an Analog Devices AD9835 direct digital synthesizer to generate RF at ~7MHz. This chip is controlled from a micro-controller (In my final year project, an Atmel XMega, in this flight, an Arduino board), to output FSK modulated data.

Since the output from the AD9835 is of very low amplitude (<1mW), some form of amplification is required. For my final year project I constructed a wide-band amplifier using an AD8008 op-amp, but the amplifier was reasonably large and inefficient.

To get a working amplifier going as fast as possible, I decided to try out one of the wideband amplifiers from Mini-Kits, a local RF supplier. The kit I chose was an EME162, which is based around a Mini-Circuits GALI-84+ MMIC (Monolithic Microwave Integrated Circuit).

This was the first board I had ever constructed that used entirely SMD components, and so I decided to use some tricks taught to me by a researcher at University. I was going to use reflow soldering.

EME162 Before Reflow

A whole bunch of solder-pasting and component placement later, I was ready for some reflow action!

EME162 After Reflow

With a heat blower heating the entire board, it was easy work to use a small heat-gun and melt all the solder paste, hence soldering the components to the board. A few components moved during reflow, but it just took a bit of poking with tweezers to get them back into the right place.

Next I attached the connectors:

EME162 With Connectors

Again, quite an easy job.

Next came testing. I hooked up the constructed amplifier to a network analyzer, setting it to input 0dBm of RF, sweeping between 1 and 10MHz (where I am intending to use the amplifier).

EME162 Gain Plot

I had to use an attenuator as to not destroy the network analyzer, but the plot shows the amplifier having about 23dB of gain over the band I'm intending to use it on!

With a 0dBm input, this means approximately 200mW of output power - more than enough for a high altitude balloon flight!

Playing with an SDR-IQ