Gnuradio and gmsk demodulation

1

Hello,

I am trying to build a GMSK transceiver to communicate with the AX-2150 from GomSpace, using an ADALM-PLUTO. I have built the following flowgraph in GNU Radio, which works fine when the input comes from recorded transmissions.

However, when I tested it with live transmissions from the AX-2150, the packets are not being demodulated properly. I noticed a DC component in the signal after the Clock Recovery MM block, so I added a DC blocker, but I still observe some amplitude variations. Could these variations be the reason for the faulty demodulation? Any GMSK receiver I’ve found online has a very similar flowgraph to mine.

Additionally, regarding the transmission from the PLUTO, I am transmitting with 0 attenuation, and the distance between the Pluto and AX-2150 is about 3 meters. However, the AX-2150 is not receiving anything. Could it be that the transmit power of the Pluto is too low to reach the AX-2150’s antenna?

Can anyone suggest what I should change to achieve proper demodulation or improve the transmission?

Thanks in advance!!!
ax-softmodem_TX_Rx_chain_gmsk_20241010.pdf (35.6 KB)

2

0dBm at a few meters is still a screaming strong signal. high power can easily distort a receiver.
Use a different SDR as receiver, if the signal wipes out the entire spectrum then you’re definitely in this territory. this is also useful to verify that you’re on the correct frequency.
Look at the expected real world signal levels and try to match these, use simple low gain antennas and attenuators for transmitters.
After the quadrature demod you are aiming for the samples occupying -1 and 1, if there’s bias here it’s because of frequency mismatch. wrong amplitude is basically the wrong baud and deviation. DC block after clock recovery sounds bad, I’m no expert but that sounds like something should be managed upstream of this.

3

Thank you, @SA2KNG, for taking the time to respond.

When I was demodulating the recordings, I observed a frequency deviation of about 29kHz. I corrected this by setting the “Center Frequency” parameter of the FIR Xlating filter to 29kHz, and the demodulation was successful.

Is there a way to adjust the frequency of the Pluto automatically for lab conditions? From what I observe in real-time signals, there doesn’t seem to be any noticeable frequency shift, at least none that can be seen visually. I understand that in the real case of satellite signal reception, Doppler shift should be considered, but I also think random frequency deviations may occur due to the SDRs, which should be accounted for as well. An AFC block might be useful, but so far I haven’t found any such block to use in GNU Radio.

I am sure about the baud rate, which is set to 38400bps, and from what I’ve read, the FSK deviation equals baud/4. That’s why I initially tried to overcome the DC component by using a DC block.

Thanks again!!!

4

another thing, while you already have the fir filter there, use it to adjust the center frequency so the sdr isn’t receiving the signal in the center where the dc spike usually lurks. documented for example on the excellent pysdr site. satnogs also uses this method in the flowgraphs.

what is with the odd sampling rate btw, 520833 ? it is the lowest the device can do, but I don’t think that is a particularly good choice. it can be chosen to make the filtering/decimation easier, but I don’t know exactly how really. satnogs usually runs 1-2Msps and it runs fine on small rpi’s so selecting 1Msps will probably work just fine.

designing the fsk/gfsk/gmsk demod properly will make demodulation a lot easier. have a look at gr-satellites fsk_demod and use that after the fir filter in your flowgraph.

regarding deviation, measure it, don’t rely on claims or documentation (:
it is basically looking at the floats after the QD, I made some thread on how to do it and visualize.

5

Thanks again, @SA2KNG.

Actually, when we received the AX-2150 in the lab, I made some recordings at 3M, which I successfully demodulated using the attached GNU Radio flowgraph. Now, I just replaced the file sink with the PlutoSDR, initially using the same parameter settings. Of course, you’re right that 520833 is the lowest sample rate the device can handle. I set it to this value while trying to figure out what was going wrong.

Now, I’ve gone back to my initial approach of making some recordings, demodulating them, and reading the bits in the output, but it’s not working. This makes me think the RF cable from the AX-2150 to the antenna might be loose.

Regarding FSK deviation, thanks for your advice. I read your thread and tried to follow the procedure, but I think the arguments in gr_satellites (maint-3.8) are different, so I couldn’t follow your example exactly. From what I understand, a mismatch in FSK deviation translates to amplitude variation when the signal from the clock recovery block is plotted using a time sink, right?

So, in your thread, you’re estimating the FSK deviation by eliminating the amplitude variations of the signal, correct?

I also tried using the fsk_demod block with my initial recordings (the ones that worked), setting the baud rate to 38400, FSK deviation to 9600 (just to observe the amplitude in the time sink), and the sample rate to 3e6/50 (decimation is 50). The amplitude is about 2 peak-to-peak as you mentioned in you example also.

I also noticed that the peak of the transmission in the initial recordings was at 29 kHz, so I set the center frequency of the FIR filter to 29 kHz. The demodulation flow using the Quadrature Demod block is working, but the one using fsk_demod is not.

When I can see the preamble bits and the sync word, I assume the demodulation is correct. I’ve attached a screenshot of the time sinks in case you have time to take a look.

Again, thanks in advance for all your effort!

QD_fsk_demod
QD_fsk_demod1361×627 74 KB

working_flowgraph.pdf (35.6 KB)

6

I think I should come back to share the outcomes with you. Actually, there wasn’t any error in the demodulation flowgraph. The only issue was a faulty RF cable and the position of the PlutoSDR. Finally, I changed the cable and moved the PlutoSDR to another position, away from power supplies, and it worked.

However, I have another problem, and I would like your advice. I observed that to achieve successful demodulation, I had to change the center frequency of the FIR filter to 24,000 Hz. I think this shift is due to the PlutoSDR. Is that correct?

In the lab, I know that this is the frequency shift, but once the satellite is in space, it will be affected by Doppler shift, which should be tuned based on TLEs.

For now, is there a way to automatically lock onto the received frequency? I tried using a PLL, which seems to track the frequency well, but the amplitude I see on the time sink is very low, and the demodulation is unsuccessful. I’ve attached a photo and the flowgraph in case anyone wants to use it or offer further help.
I setup PLL based on gnuradio wiki:
max_freq=2PI()(0+26000)/3000000
min_freq=-2PI()(0+26000)/3000000
26000 is the expected deviation, 3000000 is the sampling rate
Thanks in advance.

Screenshot from 2024-10-20 21-34-33
Screenshot from 2024-10-20 21-34-331920×1080 155 KB

ax-softmodem_Rx_chain_gmsk_v1.pdf (35.6 KB)

7

Not sure what this is measuring, 24kHz unknown offset is a lot on say 70cm, but is this S-band ?
Anyways, having transmitter and receiver frequency calibrated and accurate is needed. This is most likely measuring the difference the transmitter and receiver oscillator, or some other typo :stuck_out_tongue:

Offset tuning, avoiding the SDR center DC spike is always a good practice, as done in the satnogs-flowgraps by 100kHz by default. I’d say if you’re using 1Msps and there’s no obvious birdies in the received spectrum, using something like 100-200kHz offset it pretty safe.

Now, to the doppler stuff. If you have a very wide signal and the frequency is low, like LoRA on 70cm, then you can skip doppler. Most of the time this is not the case.
Satnogs-flowgraphs use a 100ms update rate that results in phase and frequency jumps that messes with the demodulation, but works none the less.

If you want to do it properly, I’d say have a look at gr-satellites doppler block.
I have a simple implementation in the ground-station repo. And the code generating the doppler file.

8

Yes, it’s likely the difference between the transmitter and receiver oscillators. I managed to correct it manually by shifting the signal, but now I want to use a PLL to handle small frequency variations. However, I haven’t succeeded in making it work.

I’ve configured the block according to the description in this PLL Carrier Tracking wiki, but even though I can see the frequency centered correctly, the demodulation still fails. I suspect that the PLL block might be introducing a phase shift into the signal, and I don’t know how to overcome this.

I’ve tried different values for the “Loop Bandwidth” without success. Is it possible that the PLL_carrier_tracking block is only suitable for very small frequency variations? Does anyone know of a good tutorial on how PLL carrier tracking works and how to properly configure it?

9

Maybe worth asking in GNU Radio - General chat