This is a custom, amateur radio-oriented firmware for [Vaisala RS41 radiosondes](https://www.vaisala.com/en/products/instruments-sensors-and-other-measurement-devices/soundings-products/rs41).
## What are the Vaisala RS41 radiosondes and how can I get one?
The RS41 radiosondes are used extensively for atmospheric sounding by the meteorological institutes in various countries and thus easily
available to be collected once they land, an activity called radiosonde hunting: see YouTube presentation about
[Tracking and Chasing Weather Balloons by Andreas Spiess](https://www.youtube.com/watch?v=vQfztG60umI) or
[Chasing Radiosonde Weather Balloons used in Meteorology for Fun by Mark VK5QI](https://www.youtube.com/watch?v=fb9gNomWrAY)
for more details!
You can track radiosondes without any additional equipment either via [SondeHub](https://tracker.sondehub.org/) or [radiosondy.info](https://radiosondy.info/)
that both use an existing network of receiver stations. Alternatively, you can set up your own radiosonde receiver station.
For your own receiver station, you will need:
1. A cheap software-defined radio USB dongle, such as an [RTL-SDR](https://www.rtl-sdr.com/about-rtl-sdr/)
2. An antenna suitable for receiving the 400 MHz radiosonde band transmissions. Antennas for the 70 cm amateur radio band usually work fine!
3. Radiosonde tracker software: common choices are [RS41 Tracker](http://escursioni.altervista.org/Radiosonde/) for Windows
and [radiosonde_auto_rx](https://github.com/projecthorus/radiosonde_auto_rx) for Linux / Raspberry Pi.
### What can I do with an RS41 radiosonde?
The [Vaisala RS41 radiosondes](https://www.vaisala.com/en/products/instruments-sensors-and-other-measurement-devices/soundings-products/rs41)
uses an off-the-shelf [STM32F100C8](https://www.st.com/en/microcontrollers-microprocessors/stm32f100c8.html)
32-bit microcontroller, which can be reprogrammed using an [ST-LINK v2 programmer](https://www.st.com/en/development-tools/st-link-v2.html)
* There is an option to use continuous transmit mode (for either V1 or V2 mode), which helps with receiver frequency synchronization and improves reception.
* In order to use Horus 4FSK mode on a flight, you will need to request a new Horus 4FSK payload ID in GitHub according to the instructions at: https://github.com/projecthorus/horusdemodlib/wiki#how-do-i-transmit-it
* GPS NMEA data output via the external serial port pin 3 (see below). This disables use of I²C devices as the serial port pins are shared with the I²C bus pins.
* Bell 202 frequencies are generated via hardware PWM, but the symbol timing is created in a loop with delay
* There is also code available to use DMA transfers for symbol timing to achieve greater accuracy, but I have not been able to get the timings working correctly
#### Notes about Horus 4FSK
* The Horus 4FSK v1 and v2 modes have significantly [improved performance compared to APRS or RTTY](https://github.com/projecthorus/horusdemodlib/wiki).
* Use [horus-gui](https://github.com/projecthorus/horus-gui) software to receive the 4FSK mode and to submit packets to [Habhub](http://habhub.org/) high-altitude balloon tracking platform.
* See [horus-gui installation and usage instructions](https://github.com/projecthorus/horusdemodlib/wiki/1.1-Horus-GUI-Reception-Guide-(Windows-Linux-OSX)) and [horusdemodlib](https://github.com/projecthorus/horusdemodlib) library that is responsible for demodulating the signal.
* In order to use Horus 4FSK mode on a flight, you will need to request a new Horus 4FSK payload ID in GitHub according to the instructions at: https://github.com/projecthorus/horusdemodlib/wiki#how-do-i-transmit-it
The time sync feature is a simple way to activate the transmissions every N seconds, delayed by the `TIME_SYNC_OFFSET_SECONDS` setting.
Please note that the time sync requires a stable GPS signal (good visibility to the sky) to work correctly!
#### Time-slotted modes
For time-slotted modes like FT8 and WSPR, there default configuration file (`config.h`) already contains useful defaults.
##### FT8 example
The default FT8 configuration is:
```
#define FT8_TIME_SYNC_SECONDS 15
#define FT8_TIME_SYNC_OFFSET_SECONDS 1
```
The above means that transmissions should start every 15 seconds (counting from the beginning of each hour),
but delayed by 1 second. As an example, transmissions after 12:00:00 (hh:mm:ss) would happen at
12:00:01, 12:00:16, 12:00:31; 12:00:46, 12:01:01 and so on.
The offset of 1 second is just to make sure the transmission starts strictly after the 15-second periods and never before.
If the offset was 5 seconds, transmissions would happen at 12:00:05, 12:00:20, 12:00:35, 12:00:50 and 12:01:05.
In order to transmit only in even or odd time slots of FT8, you could use:
```
// Transmit every 30 seconds, even time slot
#define FT8_TIME_SYNC_SECONDS 30
#define FT8_TIME_SYNC_OFFSET_SECONDS 1
```
```
// Transmit every 30 seconds, odd time slot
#define FT8_TIME_SYNC_SECONDS 30
#define FT8_TIME_SYNC_OFFSET_SECONDS 16
```
The latter (odd time slot) example would transmit at 12:00:16, 12:00:46, 12:01:16, 12:01:46 and so on.
##### WSPR example
For WSPR, the transmissions happen every 120 seconds, so the configuration has to be:
```
#define WSPR_TIME_SYNC_SECONDS 120
#define WSPR_TIME_SYNC_OFFSET_SECONDS 1
```
The above means that transmissions should start every 120 seconds (counting from the beginning of each hour),
but delayed by 1 second. As an example, transmissions after 12:00:00 (hh:mm:ss) would happen at
12:00:01, 12:02:01, 12:04:01 and so on.
The offset of 1 second is just to make sure the transmission starts strictly after the 120-second periods and never before.
#### Manually configuring time slots for multiple payloads transmitting at different times
Sometimes it is necessary to set transmission time slots when using multiple payloads/transmitters on the same frequency.
The time slots guarantee that the transmissions from different payloads will not happen simultaneously.
The time sync settings can be used to configure this type of time slots.
In this example, we configure 3 payloads to transmit every 120 seconds, so that each payload is scheduled to transmit
evenly across the 120-second period, every 40 seconds (120 / 3 = 40).
First, the `TIME_SYNC_SECONDS` setting of the particular mode has to be set to the *full interval where all payloads are expected to have their transmissions finished*.
This setting has to be the same for every payload. Do also remember to take into account transmission length too (depending on the mode).
Next, the `TIME_SYNC_OFFSET_SECONDS` needs to be set independently for each payload. The first payload would have
an offset of 0, the second an offset of 40 and the third and offset of 80.
As an example, transmissions after 12:00:00 (hh:mm:ss) would happen at:
* A working [Vaisala RS41 radiosonde](https://www.vaisala.com/en/products/instruments-sensors-and-other-measurement-devices/soundings-products/rs41) :)
* An [ST-LINK v2 programmer for the STM32 microcontroller](https://www.st.com/en/development-tools/st-link-v2.html) in the RS41 radiosonde.
* These smaller [ST-LINK v2 USB dongles](https://www.adafruit.com/product/2548) also work well.
* [Partco sells the ST-LINK v2 USB dongles in Finland](https://www.partco.fi/en/measurement/debugging/20140-stlinkv2.html)