Support for BeliefSat-1

[rnbokade]

Students of K.J.Somaiya Institute of Engineering and Information Technology, Sion, Mumbai are building a student satellite called "BeliefSat-1". This is the institute's first satellite and one of its core goals includes inspiring students around India towards amateur radio and SDRs by enabling them to receive the satellite with minimal setup, while also allowing STEM educators to make tracking the satellite as an educational activity to teach concepts of RF, Orbits, Doppler effect, FEC, Modulations etc. We believe that having gr-satellite based decoder will be a good starting point. Right now the satellite is in prototyping stage but we are optimistic about getting chance to launch as a part of ISRO's PS4-Orbital platform program. Apart from general telemetry which will consist of 58-byte data from onboard magnetometer, gyrosensor, ambient light sensors, solar panel current sensors, battery voltage & state of charge and other flags along with 32 Reed-Solomon parity bytes; there will also be SSDV downlink that would either start after being triggered by an uplink or automatically when the satellite is put in automatic imagery mode. The sync word byte of standard SSDV packet won't be sent owing to FIFO size of onboard radio is limited to 255 bytes. However, the radio will auto add 64-bit preamble and 4-byte CCSDS sync word before all the packets using the builtin packet generator capabilities. Both the downlink is supposed to be on 435-438 Mhz Ham band, exact downlink frequency will be notified as soon as co-ordination process is completed. While telemetry will be transmitted at 1200bps GMSK with 0.5 as a shaping factor, the ssdv downlink will be 9600bps GMSK. Before SSDV downlink is started, a special telemetry frame will be sent with one of the flags set to indicate that the sensor values contained in that frame are the ones taken at the moment of capturing the upcoming image to be sent over SSDV. SSDV downlink will start after 5-second delay after sending this special frame to allow the receivers to switch the mode. More detailed information about sensor values, flags and sequence will be published soon in an official downlink format document which will be added in this issue as soon as it is available. We request you to please help us add support for our satellite in gr-satellite. Although it is still quite early before launch if the support is added early, this will help us to thoroughly test our satellite end to end with the ground support to ensure it's proper working once in orbit. And when we say end to end, we are also interested in hosting SIDS server and having Live Dashboard. We have read something on the lines that there may be some kind of dashboard-like support within gr-satellite being developed too, so we are interested in making our project compatible with that too. thank you in advance.

[rnbokade]

The 58 bytes of data also consists of 2 bytes of 16bit CRC CCITT calculated on remaining 56 bytes.

[daniestevez]

Thanks for writing! I'm glad that you are planning to use gr-satellites for your groundstation.

A few comments regarding support for BeliefSat-1. It seems to me that probably everything that is needed for decoding is already in place in gr-satellites v3.0.0, so supporting BeliefSat-1 could be as easy as adding an appropriate SatYAML file. When you release the detailed documentation we can check if this is the case, but if your Reed-Solomon frames are CCSDS compliant, then the CCSDS Reed-Solomon Deframer should be able to process the frames.

CRC-16 CCITT checking is already implemented in gr-satellites and used for a few satellites, but there's not a good way to specify a CRC check in gr-satellites v3 (the best solution would be to have a general CRC infrastructure and the ability to specify CRCs in the SatYAML file, but maybe that's an overkill). CRC checking for BeliefSat-1 might be implemented as part of a custom deframer that consists just of the CCSDS Reed-Solomon Deframer plus the CRC check, or as a transport. I should think about what is best for the future.

SSDV decoding using an external fork of ssdv for JY1SAT is already supported in gr-satellites, so the same could be done for BeliefSat-1. We also have used a modified version of ssdv together with GNU Radio (but not gr-satellites) extensively for Longjiang-2 (DSLWP-B).

Regarding the 56 byte telemetry frames, it is good that you start familiarizing with construct so that eventually you can write a telemetry definition for the Telemetry parser such as the ones already in python/telemetry/ .

Another thing that is important to test that the decoder is working are sample recordings from the engineering model, so you can record those as soon as your radio protocols design is fixed.

Finally,

We have read something on the lines that there may be some kind of dashboard-like support within gr-satellite being developed too

I don't know exactly where you've read this, but I'm currently not planning to implement anything like that. I'm afraid that I simply lack the time for such a dashboard-like thing. However, gr-satellites can be interfaced to external dashboard applications.

[rnbokade]

About the dashboard :- I read it in your post dated May,31,2020 that you are storing data in Influx db 2.0 and using Grafana to plot and explore the data. About Reed-Solomon codes :- We are using same routines that are used for SSDV code from Philip Heron (@fsphil), those are in turn based on portable implementation by Phil Karn. I have compared the polynomial array in the code with that in one of the CCSDS RS routine, they were same so I think this is CCSDS compatible. Before using them I had asked fsphil on how to encode smaller byte array with the rs routine, he ahe suggested we use pad argument and pass it as (223-length of byte array) i.e. 165 in our case. He said on decoder side use same pad length to make decoder work properly.

[daniestevez]

About the dashboard :- I read it in your post dated May,31,2020 that you are storing data in Influx db 2.0 and using Grafana to plot and explore the data.

This was specifically for LES-5, which is kind of another side project, and not supported in gr-satellites. For Amateur satellites there is already SatNOGS Dashboard so perhaps your best option is to arrange for telemetry to end up in SatNOGS DB and build a SatNOGS Dashboard for your satellite.

Regarding Reed-Solomon, it is good that at some point you actually check if your understanding is correct by using the "CCSDS Reed-Solomon Decoder" block to try to decode a packet encoded with your software. If it turns that it is not exactly the same Reed-Solomon code, then the "Reed-Solomon Decoder (libfec)" block can be used. This allows one to specify any Reed-Solomon code by entering all the RS code parameters in the same manner as in Phil Karn's libfec.

[rnbokade]

Hello. We recently had some discussion and are wondering about ditching ssdv format and sending a raw image 640x480 instead with following format at 38.4kbps :- Preamble(8)+Sync-Word(4)+Packet-type(1)+ Base-40 encoded callsign(4)+Image no.(1)+ Packet no. of image (2) + Image Raw bytes (128) + Rs parity bytes (32) The nos. In "( )" are no. of bytes. Now that this is just a Raw image with each pixel made of 8-bit RGB bytes, I think a very simple real time image display can be easily made in python. Question is can gr-satellite FSK decoder be made for 38.4 kbps? Also can such image decoder program be made to integrate with gr-satellite and if is how?

[daniestevez]

Ok. Why would you use raw image files instead of using the JPEG compression provided by SSDV escapes me, but this is your design decision, so go ahead if you feel it's appropriate. Beware that such a raw image is 900kiB large, so even at 38.4kbps with the 40% overhead given by your protocol it would take 4.5 minutes to transmit. Also beware your link budget at 38.4kbps. You need 6dB more than for 9k6.

The gr-satellites FSK demodulator component can use any baudrate and sample rate (as long as the combination makes sense), so it's not a problem to use it with 38.4 kbps. We support ÑuSat, which transmits 40 kbaud FSK, so 38.4 kbps wouldn't be something completely unheard of. However note that using 48ksps for 38 kbps FSK is a bit far-fetched, so most likely you would need to use a higher sample rate.

The simple protocol that you describe to transfer image chunks can be used with the gr-satellites File Receiver component. You will need to write an file definition class for your protocol. See the documentation and the classes that are already implemented. Your protocol can even be make use of the real time Image Receiver if you manage to write your image into a file that feh can read. I think that there are image formats which are basically a raw image as you describe plus a header. The header could be written in an ad-hoc manner in the file definition class.

[rnbokade]

Hello. We studied more as per your guidance regarding how the alternative image sending method will compromise the link margin and indeed we will be better off with SSDV only. Meanwhile, we were finally able to bring home some of our radios from the campus and were able to write a code to transmit a few static packets in our packet format. We have recorded the IQ in SDR# for the same. Although we are not able to figure out how to open that recording in GNU radio to do any further processing. https://drive.google.com/file/d/1KypnJ3wLth1Z48QymdzSxMTu988iji7h/view?usp=sharing This is the link for the IQ recording file from SDR#.

[daniestevez]

That recording is an IQ WAV file, so it can be (not surprisingly) used in GNU Radio with the Wav File Source block.

From my side, I'm still waiting for your final RF protocol specifications document, so until then I probably won't look at any recordings.

[NewLeapKjsieit]

https://github.com/NewLeapKjsieit/BeliefSat Please find all the required info in the readme. If anything else is required let me know

[NewLeapKjsieit]

https://github.com/NewLeapKjsieit/BeliefSat/tree/master/Recordings Recordings are available here. These recordings were done using SDR#. Baseband and Audio were recorded in 16-bit PCM. The recorded packets are dummy telemetry packets from our prototype.

[daniestevez]

I'm taking a look at the SDRSharp_20200630_062032Z_435912500Hz_IQ.wav and I'm not obtaining correct decodes by following your protocol description.

Could you please clarify the following about that file:

• Frame length. I'm guessing 90 bytes from your description of the Telemetry packets, but the frames seems shorter.
• Expected frame contents. I'm demodulating frames that look like

  pdu_length = 90
  contents = 
  0000: 54 d1 ed 6a f8 e8 9e 21 57 79 4b 9c 0e f8 fa 5f 
  0010: aa 41 4b 1c b6 48 6e f2 49 6f e3 bd 5e 3f 4c 18 
  0020: 0d cb d9 fb b6 88 f8 b9 fb c4 30 61 ab 73 08 84 
  0030: fd 9c 3e ba 99 53 e3 12 75 d6 f3 14 b7 9c 19 f4 
  0040: bd 95 57 59 e5 7a 27 89 db e2 9b fb 50 85 1f 8f 
  0050: be 75 6b 3b 7c 11 78 b9 2c 28 

  but I'm not sure if these looks at all like dummy packets.

[nvshinde]

Hello, the following program was used to generate the dummy packets. The files are available in the following directory. Please find packetGen.ino for your reference. https://github.com/NewLeapKjsieit/BeliefSat/tree/master/temp

[daniestevez]

I'm sorry, but the data your engineering model is transmitting doesn't match what you expect or describe in the documents.

Here are the FSK symbols for one of the packets in the recording:

You can see the alternating 0101 preamble, then the CCSDS syncword, then 0x54 0xd1 as indicated by GNU Radio in my comment above. According to the code you mentioned the payload should start by 0xAB.

[rnbokade]

New recordings of iq uploaded with changes suggested by @jgromes . The problem was with the Radiolib library we were using, which by default keeps on-chip builtin scrambler on. I hope problem is solved now and we should be able to decode

[daniestevez]

I have tested the new IQ recording and it works. I have added a preliminary SatYAML file for BeliefSat-1 in be1c64574f62b3a443d4d9c9ab18b4cac32260c5 in the beliefsat branch.

[rnbokade]

Btw I am wondering if we can do something to make digipeater on board accessible using fm rigs... Say a general uv-5r or something... As in we generate a audio signal that when fed to these radios will result in 1.2kbps gmsk... On receive side I guess the normal decoder should work though I am not sure.. Is this possible... If so how to go ahead?

[daniestevez]

Probably you can't receive or transmit 1k2 GMSK correctly on an FM radio due to the AC coupling (high pass filtering) of the audio input/output, although with scrambled data it might even work. This needs to be tested. It will probably depend on the FM radio. If discriminator tap / packet interface is available, then it's recommended.

On the other hand, a 1k2 GMSK signal is narrow enough to fit in 2.7kHz bandwidth, so an SSB tranceiver can be used.

[rnbokade]

RDA1864, around which Hamshield and Baofeng UV-5R both are based have a setting to turn of filters. If the filters are off, it it possible?

[daniestevez]

Only one way to be sure: go to the lab and measure.

[rnbokade]

Question is how do we do it? I mean we have spectrum analyser, the said radio module, pc with gnu radio, audio cable at our hand... Now how to generate sound tones that should therotically result in gmsk? Once we have that, is should be easy to test which radio will support in what settings which won't 😂

[daniestevez]

I think you need to do two separate tests for each FM radio you want to consider: one where the FM radio is used as RX, the other where the FM radio is used as TX. The other end of the test can be an SDR. I would roughly organize the tests as follows:

• Computer soundcard -> FM radio (TX) -> SDR (RX). In this test you need an FSK transmit flowgraph that uses the computer soundcard to transmit FSK through the FM radio. Then you use an SDR and an FSK demodulator flowgraph to receive the FSK signal and study things such as BER, eye diagram, frequency response (this may be done in postprocessing, so in the lab it's enough if you record the IQ data). Note that the frequency response of the computer soundcard may play a role here, so before using the FM radio it is perhaps a good idea to connect the computer soundcard to the oscilloscope to check the waveform integrity.

• SDR (TX) -> FM radio (RX) -> computer soundcard. This is basically the reverse of the previous test. You need a flowgraph to transmit FSK through the SDR, then a flowgraph that receives FSK through the computer soundcard and study BER, eye diagram, etc. As before, the frequency response of the soundcard might be a concern, so it would be good to measure it with a signal generator.

Instead of the soundcard you may use an ADC/DAC to interface to the FM radio, but this complicates the setup and I guess the intended application would use a soundcard. So maybe it's a good idea to study the response of the soundcard + FM radio as a whole.

[daniestevez]

Hi, since gr-satellites is starting to use discussions, I'm moving this thread to a discussion, as it seems more appropriate.