GNURadio implements NavTex (navigation warning telex system) demodulation_哔哩哔哩_bilibili
The video above is what I have achieved so far.
NavTex is a telex system for navigational warnings. The working frequency is around 500kHz or 4.2MHz, the latter can be directly received by PortaPack.
More introduction:
NAVTEX (Navigation Warning Telex System) Reception and Rough Understanding Guide-哔哩哔哩
I knew before that it can be considered as the modulation method of SSB+AFSK. The problem is that it is too difficult to solve. To put it simply, SSB is actually a kind of AM, and AM can be regarded as frequency shifting or frequency mixing. This part of the work itself is undertaken by SDR hardware. Therefore, this part can be ignored directly, and the rest is FSK. And FSK can be regarded as FM. This is the same as doing NRF or BTLE demodulation before.
So I first tried it with NRF's flow graph. I can see the effect, but the effect is not good. Then I found fsk-demod, a third-party gnuradio module, on the Internet. And fill in the navtex modulation frequency change freq_deviation 170Hz I found into the module, and also fill in the center frequency of the frequency selection filter based on the center frequency 1500Hz on the audio spectrogram. You can see a similar square wave pattern on the navtex software similar to Android.
I counted 10 UIs within 0.1 second, which exactly corresponds to the baud rate of 100 of navtex I found.
Later, I carefully compared the length of the waveforms at each moment, and found that they were all compatible with the Android software, indicating that the gnuradio demodulation was done.
Later, I have to simplify the flow diagram, and take the useful parts of the third-party module directly into my own flow diagram, which can also be used. This is the program used in the video.
But demodulation is only for audio baseband at present. After the portapack is launched later, use hackrf+gnuradio to receive and demodulate. Then implement HackRF step by step to demodulate and decode directly with c++. Eventually moved into portapack.
Next try to launch with portapack, and then use hackrf+gnuradio to receive.
The flow graph needs to be adjusted as follows:
There are three main adjustments here:
1. Adjust the center frequency of the receiver hardware so that it does not coincide with the center frequency of the transmitter (the difference is 30kHz), and then multiply the cosine of -31.5kHz by mathematical operations to achieve digital down-conversion. In addition to compensating for the offset of 30kHz, By the way, the 1.5kHz of the audio is moved to 0Hz. The purpose of this is to solve the interference of the dc offset of the hackrf receiver, and there is no need to adjust the center frequency of the xlating filter. In theory, this band-pass filter can be directly replaced by a low-pass filter.
2. Changed the high and low values of the bandpass filter to make the fsk deviation smaller, which can filter out the influence of the transmitter dc offset.
3. In order to hear the audio corresponding to the baseband signal again, the baseband signal near 0Hz needs to be moved back to 1.5kHz, so it is multiplied by the cosine of 1.5kHz and then output as audio. (This audio can be demodulated again with navtex to verify that processing is ok)
The upper part of the figure above is the square wave signal demodulated by radio transmission and reception. The lower part is the radio frequency spectrum, you can see two peaks, and the large peak at 0Hz is the receiver dc offset. The small peak around 31.5kHz on the right is the real signal. The difference between them is 30kHz+1.5kHz.
Just because there is a relatively large gap (greater than the original 1.5kHz gap), it can be filtered out by the filter. In fact, there is also a transmitter dc offset in the peak on the right. At 30kHz, it is also filtered by this bandpass filter with a small bandwidth. If it is not filtered, the above square wave signal will not be so perfect.
If we don't consider the receiver dc offset, then we directly set the receiver and transmitter to the same center frequency, and then the flow diagram is as follows:
The final result will be as shown in the figure below. It can be seen that the demodulation result is quite different from the square wave. This is because the baseband audio signal is at 1.5kHz and is covered by the skirt of the receiver dc offset, even if there is a Even a very narrow filter cannot separate the two signals.
Therefore, the dc offset problem is definitely unavoidable. As for whether it can be implemented in portapack, it is not clear yet. Therefore, for the time being, we only intend to implement demodulation and subsequent decoding on the gnuradio of the computer.