Reliable 2GFSK Demodulation for AERO-VISTA CubeSat UHF Radio

[guutz]

Howdy,

I'm working on a ground station for the upcoming AERO-VISTA CubeSat mission at MIT Haystack Observatory.

We're at the early stages of development for the ground station, so we're currently working on decoding simple ping messages from the satellite that we recorded in the lab. Even though the signal is strong in the recordings, nothing I try in GnuRadio can reliably lock onto the symbol clock and detect the syncword -- there is a very high frequency of bit errors.

Specifics of the satellite radio:
-UHF (70cm)
-2GFSK (specs indicate MSK)
-3 byte preamble, 4 byte syncword
NanoAvionics, the bus supplier, has unfortunately left the rest of the details for us to guess:
-Probably 2400bps datarate / 600Hz deviation
-Packets are variable length, with length byte immediately following syncword
-Packets are framed using their custom RF Protocol which is poorly documented
-There is a CRC16 on the end but it is unclear which kind (probably CCITT false?).

Before even starting to decode the insides, I'd at least like to reliably detect every packet and verify the CRC, but I've been unable to do even that. The recordings were made with a USRP B210 tuned to the satellite's center frequency, at a sample rate of 48kHz, with a yagi antenna placed on the opposite side of the room from the satellite, which was set to minimum transmission power.

I've tried the following variations of flowgraphs:

File source
Throttle
Squelch? (Hard to get the right threshold to exclude noise but not cut off any of the signal)
RRC Filter? (Unknown what filter we should be matching)
FSK demodulator (Have tried Quadrature Demod, the FSK Demod block from gr-satellites, and also an integrate-dump filter based on one of Daniel's blog posts)
Resampler? (Sometimes have had more luck setting the baudrate on the demod block higher, then resampling down to the correct rate. I have to imagine this is bad practice.)
Symbol Sync? (mixed success)
Binary slicer
Sync and create packed PDU (length set to 255, even though I know the pings aren't that long, but I don't know how long they should be because I don't know exactly which parts of the packet the length byte includes per the custom RF framing.)
Output

I've tried most permutations of those, and the flowgraph is still unable to reliably demodulate the packets. Sometimes it misses packets that are there, and sometimes it finds packets when there are none. The ones it does catch often have several bit errors.

Any tips on how to improve this system would be much appreciated. We would really like to use gnuradio and gr-satellites for our actual satellite operations after launch, and I've started working on deframer and telemetry blocks in a branch of the gr-satellites repo, but they won't work if the demodulator can't even pass them correct packets.

Thanks so much!

[K4KDR]

Greetings. I'm sure Dani will have very valuable input, but in the meantime would it be possible to share an audio file, I/Q file, or both?

Thanks!

-Scott, K4KDR

[guutz]

I'm not completely sure if I'm allowed to share the recordings -- I'll find out and upload them if so :)

…

On Wed, Jul 27, 2022, 6:02 PM K4KDR ***@***.***> wrote: Greetings. I'm sure Dani will have very valuable input, but in the meantime would it be possible to share an audio file, I/Q file, or both? Thanks! -Scott, K4KDR — Reply to this email directly, view it on GitHub <#388 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGIRXUI5LKYKNR2DNUSFB7TVWGWVZANCNFSM543EBIUA> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[5ch4um1]

Hi Magpie! :)
If you are not sure about the bitrate, you could maybe first look at the recording with inspectrum and check it, and maybe see if you can decode a frame manually?

[daniestevez]

Hi,

Thanks for opening a discussion for the AERO-VISTA satellite.

I agree that having some recordings would be very useful. Perhaps there is something wrong with the signal or even with the recording method (could the recording be saturated?), and this is often difficult to find without looking at the recordings. I would say that by releasing the recordings you're not giving out more information than what people will be able to see when the satellite is transmitting in orbit (but now with enough time to get help from the community before launch). Maybe you can use this idea to convince people that publishing some recordings is harmless.

The idea of looking at the recording in Inspectrum to check if the signal looks like a proper FSK modulation, and has the baudrate and syncword that you expect is very good. This is probably the first thing I would do if I get my hands on a recording.

Regarding the Nanoavionics radio, it probably uses the CC1101 or a similar FSK transceiver chip. It is likely that some features of the framing will use the built-in packet handling of the chip. If you open one of the RF cans and look at the chip (or if you have the schematics), maybe you can get more information from the datasheet of the chip.

[guutz]

Thanks for your response!

To answer your questions, I am fairly certain the recordings aren't saturated based on playing them back in GR. I have looked at the recordings in tools like inspectrum and universal radio hacker, and the syncwords are definitely there, but for all my efforts there are still a lot of bit errors. And often times I can only get those to work if I set the baudrate to 1.2k, which is half of what it should be. Perhaps some weirdness with the sample rate of the recordings, even know I know for sure they were recorded at 48kHz.

I've found out that sharing recordings is fine, so I've attached two files. test_1.zip is a series of simple pings, which should be less than 20 bytes long, and should be nearly identical. test_2.zip is a mix of pings and some longer packets containing a few bytes of test payload. They use CC1200 framing, with preamble 0xAAAAAA and syncword 0x930B51DE. There shouldn't be any added scrambling, whitening, encryption, etc.

I'm walking on eggshells because the Nanoavionics NDA requires me to hold back an annoyingly specific amount of information. Here's a publicly available datasheet with more info on the satellite radio. The trouble is, we don't know which operation/modulation mode it is set to, because they have not responded to our repeated inquiries about the product they're providing us. Lovely customer support. It's definitely 2GFSK, most likely 2400bps, but it very well could be using AX.25/G3RUH modulation -- I've tried out all of these options, to no obvious success -- at least to my untrained eye ;-)

Thanks again for your help!

[K4KDR]

Thank you for the sample files!

Are these .c16 files audio at 48k? I would have expected .wav files for audio.

Or are the I/Q files in perhaps a raw (16-bit?) format?

Thanks!

[daniestevez]

I'm looking at the same!

The .c16 extension suggest complex 16-bit integers, but the file format is actually complex64 (i.e., what you read with the GNU Radio file source set to "Complex" data type).

Maybe a mix-up with the formats is the only problem in trying to process them?

[guutz]

Yes, they are raw IQ files - 16 bit complex numbers at 48kHz.

[guutz]

Actually you're definitely right, it's complex 64, standard gnuradio file sink output. Sorry for the confusion!

…

On Thu, Jul 28, 2022, 11:08 AM Daniel Estévez ***@***.***> wrote: I'm looking at the same! The .c16 extension suggest complex 16-bit integers, but the file format is actually complex64 (i.e., what you read with the GNU Radio file source set to "Complex" data type). Maybe a mix-up with the formats is the only problem in trying to process them? — Reply to this email directly, view it on GitHub <#388 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGIRXUMKPDCIDQABF7RYUU3VWKO5VANCNFSM543EBIUA> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[daniestevez]

This is an attempt at FM demodulation in Inspectrum.

The waveform looks quite distorted, which I guess explains your problems trying to demodulate it.

Are you recording this near the zero-IF of the SDR (i.e., close to DC at baseband)? Can you try recording at an offset in frequency? It might happen that you have the IQ image of the signal interfering with itself. Can you give more details about your recording set up and configuration?

[guutz]

Sure, it was recorded with an Ettus B210 radio. The transmitter center frequency is 437.7MHz and the Ettus was tuned to the same, with a yagi antenna placed on the opposite side of the room from the satellite. The satellite was set to minimum TX power.

[daniestevez]

I suggest you try tuning at an offset and perhaps reduce the gain of the USRP somewhat.

[K4KDR]

Yes, the distortion in the center of the I/Q recording really lowers your odds of decoding to near zero. When played & demodulated as FM audio, the ever-present center spike in Sample #2 is quite evident. As Dani said, you'll have much better results with a recording made under different circumstances.

[guutz]

I had noticed that, that makes sense that it would be causing problems actually. So would you recommend recording with the receiver tuned to a 1MHz offset or so?

[daniestevez]

If you tune to a 1 MHz offset then you'll need to use a sample rate higher than 2 Msps (because Nyquist) and use a Frequency Xlating FIR Filter block to downconvert and decimate to 48 ksps.

Since this signal is not too wide, you can maintain your 48 ksps sample rate (I'm assuming you're requesting 48 ksps from the USRP, but I might be wrong) and tune to an offset of 10 kHz.