Simple PI4 Beacon Transmitter in GNU Radio

(2018-04-29) PE1ITR


This webpage is about a simple PI4 mode Next Generation Beacons implementation in GNURadio. I am very interested in the next generation beacon development. The beacons in PI4 mode are easy to receive. For example, every day I receive the OZIGY beacon at 70cm over a distance of 625km. I came up with the idea to use PI4 mode in my transponder transmitter project. This transponder works with GNU radio and the hardware is a HackRF.


Fig 1: The result is a nice looking signal in Linrad. PI4 mode en FSK CW in a one minute period.


First I wanted to generate the PI4 signal into GNU radio too, but this became too difficult for me. Eventually I prepared the PI4 beacon signal in this linux bash script. The output is a wav audio file. This is then used in GNU radio to modulate the channel. Integration in the transponder transmitter is then simple. This webpage describes the development of the PI4 implementation into the transponder transmitter.

PI4 Beacon wav file

I generated the wav audio file with standard linux programs like SoX and bc. These programs are connected to each other with a bash script. In the first versions I had annoying clicks in the sound file. On air it didn't seem much a problem and it decoded well, but it puzzled me. These clicks were caused by phase discontinuities in the transitions of the fsk signal. Eventually I was able to solve it by having the next fsk symbol start as close as possible in the phase where the previous signal ended.

The PI4 signal is an FSK signal with four frequencies. The text is encoded in a prescribed manner. On the website of BO OZ2M there is a nice form with which the beacon text can be encoded. I used the scheme with the 146 characters. In this diagram each number corresponds to the 4 FSK frequencies.
message="20100113103212100302210201120311322313330231211110323321121022001133301212022011333010210032102021001102000312200132031101132330321230022313000013"
In the script, this message string is passed by character. Each symbol is transmitted for 166,667 ms on the corresponding frequency. I use SoX to create an audio file for the broadcast of each symbol. All sound files are merged into 1 file. The 146 soundfiles of each 166.667 ms are concatenated to one file of 24.333382 seconds.

After the PI4 part and a pause of 667ms, the call sign and locator is broadcast in Morse code 12WPM. I build this message in the same way as with the PI4 signal. The message is coded in a basic way in Morse code in ones and zeros. For "PE1ITR JO21QK " is this 160 symbols. This text string is also readed from left to right. 160 * 100 ms = 16 seconds. The 160 files are concatenated to one file
messagecw="1011101110100010001011101110111011100010100011100010111010000000101110111011100011101110111000101011101110111000101110111011101110001110101110111000111010111000"
The final file must be exactly 60 seconds. The file is constructed this way:
EventDuration (s)Duration Cumulative
Init0.00010.0001
PI4 message24.33338224.333482
Pause CWFSK0.66725.000482
CW message1641.000482
Pause CWFSK0.50041.500482
Carrier CWsignal17.76651859.5
Pause CWFSK0.50060

This is the final wav file.


Fig 2: This is the result when transmited with GNU radio




GNU Radio

The transmitter is a standard SSB transmitter block diagram made with GNU radio. The generated sound file described above is played in an endless loop. There are two main points of interest. The first is the stability of the HackRF. It must definitely be locked to a 10MHz GPS source.

The second is the timing of the broadcast. The broadcast must start on the whole minute. I wrote a script in bash that waits until the whole minute is over and only then gnu radio starts. In this way the transmitter was still in sync after a day of running.
#!/bin/bash

STARTPUNT=`LC_ALL=C TZ=UTC0 date +'%S'`

while [ $STARTPUNT -ne 59 ]
do

STARTPUNT=`LC_ALL=C TZ=UTC0 date +'%S'`
echo $STARTPUNT
sleep 1
done
echo "start"
python pi4_beacon.py



Fig 3: GNU Radio





Fig 4: Beacon transmitter with HackRF. Left: sma with antenna out. Right: usb to computer and connection to the 10MHz reference source




Phase discontinuities

Solving the problem with phase discontinuities was a quest. In the first versions, the broadcast of a new symbol was always started on phase 0. This no matter where the previous period ended. So it could happen in the worst case that the phase could make a jump of 90 degrees. First I tried to solve this by having the previous symbol always end on a full period. So phase 0. The new symbol is also started on phase 0. I then filled the gap with a silence. This method made no difference at all and the annoying click remained.
The solution was to determine the phase at which the previous symbol ended and letting the new symbol start at the same phase angle. A phase shift in the second symbol then continues to the third. And the shift in the third again in the fourth and so on. In SoX there is a parameter in which you can specify the phase angle at which a sine starts. This phase angle is given in a percentage of 360 degrees. I have implemented this method in the bash script and the phase clicks have now disappeared.



Fig 5: First attempt to remove the clicks. Full periods with gap. This didn't work.





Fig 6: Second attempt. In this example there where no clicks audible! The transition in the image is on 166.667ms





Fig 7: Further improvement. The transition in the image is on 166.667ms. Lowering the Sample rate from 32k to 12k and applying a lowpass filter of 3000Hz.





HOME | Go Back