0
$\begingroup$

we are trying to develop a flowgraph for cubesat operation. Our flowgraph for includes both downlink and uplink parts in one flowgraph. It uses SoapySDR as a driver of an SDR. Most of the used blocks are included in the core of GNURadio. Few blocks from gr-satellites by Daniel Estévez are used. Data input and output is provided via TCP servers (sink and source blocks).

Our flowgraph for GFSK mod/demod

Uplink part takes binary data from TCP port and provides KISS deframing. Deframed data is packed to the HDLC frame. Output of the HDLC framer block are bytes that represent individual bits of stream (0x00 and 0x01 bytes). For KISS deframing and HDLC framing blocks from gr-satellites are used. Afterwards G3RUH scrambling and NRZI Encoding are done. Used Scrambler block comes from GNURadio core, NRZI Encoder is from gr-satellites. Resulting bitstream needs to be repacked to bytes again which are subsequently sent to the GFSK modulator. Repack Bits block is used for this operation. It packs incoming 8 bytes (representing 8 bits of 1 byte) into one outcoming byte. End of the bitstream is cut if the bit stuffing and NRZI Encoding cause that the overall bit count is not divisible by 8. Bytes are then GFSK modulated and sent over air via SDR using the SoapySDR sink block.

The GFSK Mod parameters are:

  • Samples per symbol: 40
  • Sensitivity: (0.625*pi)/40 (deviation 3kHz, 9600bd -> mod. index 0.625)
  • BT: 0.5

In this part we are dealing with one problem we are not able to solve. While using 2 postambles to be sure that at least one is repacked correctly in Repack Bits block data seems not to be sent completely. We have tried several receivers (Downlink part of flowgraph, our cubesat TRX module, UZ7HO hs-soundmodem with a second SDR) but none of them were able to receive packets correctly.

We started to send packets quickly in a row. Some of them passed through the receivers. It seemed that the first preamble byte from (N+1)th packet served as a postamble byte of the Nth packet.

After this we tried to increase postamble byte count. With this the success rate increased. Interesting fact is that certain packets were received correctly with all of the used receivers. We end up with the conclusion that 20 postamble bytes are enough to pass almost 100% of packets. This seems to be working but is definitely not the correct solution to this problem. In correct operation only one postamble byte should be needed. Increasing the number of postamble bytes affects the overall data throughput.

After checking the encoding blocks we also saved the output from the GFSK Mod block. It is a 32bit float IQ file that is normally sent directly to the SDR. We created a small and simple flowgraph to demodulate and decode this data saved in a file.

Flowgraph for IQ demod and decode

As the first demodulating method we have used the FSK Demodulator block from the gr-satellites package. After demodulating we also did the decoding procedure and saved the output to the file.

Here is the demodulated and decoded data in binary form:

x1111111 11111000 00111111 11111111 11111111 11111111 11111111 11111111 10101011 11111111 01101010 01011101 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 001011

We can see 150 bytes of preamble (bold) followed by an incomplete byte of data. This incomplete part of data seems to be correct as the first expected byte is B4 → LSB 00101101 MSB

Second method we have tried is by using the GFSK Demod block from GNURadio core. We used the same input file as in the first method.

Here is the demodulated and decoded data in binary form:

xxxxx011 00000000 00110001 11111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 01111110 00101101 00001111 11000110 00000000 00000000 01001010 10111110 11001010 10001010 00111010 00

Here we can see only 149 preamble bytes instead of encoded 150. After that we can see an incomplete data packet. Bit destuffing was performed and analysis shows the data bytes are correct.

The “digital” part of the flowgraph seems to be correct during the whole process of data encoding. No errors are observed and the data packet changes in a manner that is expected.

We can see that two demodulators demodulated data differently. In both outputs the end of the packet is missing. If we set postambles to 5, the second method is able to demodulate the packet correctly observing two postambles. When using the first method, postambles are still missing. Transmitting packets over air with only 5 postambles has a very poor success rate.

Sending and demodulating data over air ended up with a similar problems. End of the packet is simply missing. Have anybody some idea where can be the problem?

$\endgroup$
1

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.