EnduroSat in PIPE mode

[VinayakM123]

Hi,
I am currently working on setting up a ground station for our satellite but we are unable to demodulate and reframe the signal received from the communication module. We are using the EnduroSat UHF Transceiver, but we are working in the transparent PIPE mode . In this mode 2GFSK modulation is used with a data rate of 9600bps and deviation of 2400Hz and a modulation index of 0.5.

User Manual

It would be great if I receive help

[K4KDR]

Hello! I'm sure you will get very helpful information in answer to your questions.

In the meantime, do you have an I/Q recording of your signal so that others can investigate what is required to properly decode it?

Thanks!

[K4KDR]

Does the following decode appear to be valid?

***********************************
Endurosat
Packet number 0
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 14
contents = 
0000: 0d 45 53 2b 57 32 32 30 30 33 33 36 33 0d 
***********************************

... this was obtained after using Inspectrum to verify whether the packets in your I/Q file in fact were 9600 baud. However, as you can see below, the calculated baud rate of the packet being checked was approximately 3.73k, which is what I used in GNU radio's FSK demod block which in turn used the ENDUROSAT Deframer to output the payload above.

[VinayakM123]

I converted this data into ASCII and it looks valid.... In ASCII it is having ES+W.
I am little confused about the baud rate it is 9600bps, I am not sure how this baud rate is reduced.

Can you share the screenshot of the flow graph.. if possible please explain the mistakes I made while drawing the flow graph.

Thank you so much.

[K4KDR]

I am not aware of what is causing the difference between your TX settings and the packets being received. You are very welcome to my results; I'm sure there is much that can be improved.

The .GRC file is available at

https://www.qsl.net/k/k4kdr//grc/endurosat-iq-grc/

... and here is that flowgraph for reference here:

... there are several packets in your file, but only one decodes correctly for me.

You may have better results with a different SDR for your RX testing... the DC spike from the RTL-SDR, as well as it's frequency instability (compared to higher-grade SDR devices) can make testing more difficult. I get very nice results from an AirSpy-R2 w/ a 10 MHz GPSDO connected to it as a frequency reference.

[VinayakM123]

Thank you this flow graph has been a great help.

• From the flow graph I had a doubt regarding the use of RMS AGC. Why is it needed
• How was the sync world length selected in endurosat deframer.

[K4KDR]

The RMS AGC block is very probably not needed - I was experimenting with different settings to try to confirm that I was getting all possible decodes from the recording. I just tested and still get the one clean decode w/ the RMS AGC block disabled.

As for the Endurosat Deframer block, it may be helpful to you to review the code here in gr-satellites for information about how it works. I do not have any understanding of the design considerations for that deframer. It is located at

python/components/deframers/endurosat_deframer.py

[VinayakM123]

I am attaching the screen shot of flow graph I made for this.

[daniestevez]

Hi @VinayakM123, can you give more information about this satellite mission? Is it an upcoming amateur satellite?

[VinayakM123]

I don't have the organization permission to share more details regarding the satellite. Yes it is an upcoming mission.

[VinayakM123]

When I am trying to decode the signals IQ samples, the ESTTC instruction are being deframed and I am able to receive it as the output. But the data sent via the Endurosat is not being received. Could this be an issue due to PIPE mode of the Endurosat.

[VinayakM123]

@daniestevez @K4KDR

[K4KDR]

Please provide the bytes you are transmitting, the bytes you receive from your decoder, and the flowgraph used to produce your output. Those specific details will allow a much more helpful answer.

[VinayakM123]

@K4KDR
We are transmitting house keeping datas like temp, etc..
During the transmission a header H20 (48 32 30 in Hex) is added that is the method to verify if the received packet is correct.

0d 45 53 2b 57 32 32 30 30 33 33 36 33 0d this is a packet I am receiving which is ES+W22003363 that is a ESTTC command which I am able to accurately decode.

89 5d 84 15 26 7a 20 24 7c 22 dd 2a db 94 bb f0
e2 9b 27 4b ad 92 6b f2 cd f0 b3 89 5e 41 8a 53
17 d2 de 45 81 d5 32 03 dc d1 9e 42 09 66 d3 53
62 ad 36 da 89 6c ca 95 3e dc c0 57 0d bd 2f 5c
e3 1e c9 93 a0 d0 22 6a ca a3 12 6f 0e 8e e2 e0
15 16 47 dc 23 2b d4 43 8e a1 2c a4 21 27 c8
8a 07 79 fb 66 82 f6 64 69 68 6c 65 0a 29 9d 9e
24 da 5c 09 09 70 c7 54 ba 5a a9 3d a4 ab cd 6a
0a 55 64 61 62 6c 00 00 28 04
This is the 138 bytes I receive after which is not having the header H20 hence I dont think there is an accurate decoding to my understanding.

[K4KDR]

Sorry - I do not know enough about how your packets are being transmitted to give any suggestions to explain the unknown 138-byte packet you are receiving.

[VinayakM123]

gr_satellites GASPACS --wavfile ~/gr-satellites/satellite-recordings/GASPACS_48K_AF.wav --samp_rate 48e3 --disable_dc_block --hexdump
flowgraph ⚠️ Could not find port in in:
flowgraph ⚠️ in
Segmentation fault

What could be the solution to this error?