NEUDOSE CubeSat (McMaster University, Canada)

[Danieltajik]

Hello Dr. Daniel Estévez

My name is Daniel Tajik and I am the Communications team lead for the McMaster University NEUDOSE CubeSat mission (https://mcmasterneudose.ca/). This is the Canadian university's first-ever satellite mission that we (hope) to launch sometime in 2022. It is being developed by a student-run team comprised of over 100 undergraduate and graduate students. The project is apart of the new Canadian CubeSat Project launched by the federal government in 2017 (https://www.asc-csa.gc.ca/eng/satellites/cubesat/what-is-the-canadian-cubesat-project.asp).

We are going to be launched in a LEO orbit from the ISS, and will be utilizing two Texas Instruments CC1125 transceivers on a custom communications board. The communications board is connected to an ISISpace UHF/VHF CubeSat Dipole Antenna Module, with VHF providing the uplink and UHF with the downlink. We have submitted some of our licensing paperwork with our IARU submission complete and are currently preparing the Canadian CPC-2-6-02 — Licensing of Space Stations application.

The satellite will be operating on 2-GFSK at 9600 bps for both the uplink and downlink channels, and will support the CC1125 framing protocol with CSP networking support. The expectation for FEC is to use an LDPC code developed based on the DVB-S2 standard.

There is also a ground station being built at McMaster University, consisting of two 5.5 meter-long RHCP Yagi-Uda antennas which will operate on an antenna rotor to track the satellite as it passes overhead. This ground station is currently in the design phase and we expect it to be completed sometime in the first half of this year. Linked into this ground station will be our ground station server running our GNURadio flowgraphs for handling the communication link. This is achieved with an Ettus Research B210 transceiver.

There are two major things we would like to state here. First is that the inclusion of our satellite into the gr-satellites repo would be massively beneficial for us, especially since we are expecting to have to send CC1125 packets that are not readily accessible by the amateur community. Secondly, we would love to begin testing out our ground station before our satellite launches with other teams that have recently launched.

There is a lot of information we do not know as of yet, and if you have any suggestions for us upon reading this proposal please feel free to let us know.

Thank you for your consideration!

Daniel

[daniestevez]

Hi Daniel,

Thanks for writing this detailed presentation.

The most interesting aspect that you mention is the use of LDCP codes coming from DVB-S2. I think this is a novel idea (for small satellite communications, this is), and also a pretty good idea. gr-satellites doesn't currently have an LDPC decoder (and I think that GNU Radio doesn't either, since the DVB-S2 blocks implement just the transmitter), but this is something that doesn't worry me, because there is the very good leandvb open source DVB-S/-S2 software decoder, which uses this DVB-S2 LDPC decoder library, so potentially we would just need to take some code from there.

What interests me at this early stage is the interplay between the CC1125 and the LDCP code. I'm assuming that you'll use the short (16200 bit) codewords. Using the normal code words (64800 bits) doesn't seem advisable, because these take too long to transmit at 9.6 kbaud (6.75 seconds) and too much data will be lost if a FEC frame didn't sync or is lost to deep fading. Still, short codewords are much longer than the CC1125 transmit FIFO, so I'm assuming that you'll use the "infinite length packet mode", where the MCU is responsible for refilling the FIFO before it underflows to allow the transmission of packets longer than the FIFO.

An interesting question is synchronization. Will you be relying on the syncword that the CC1125 inserts at the beginning of the packet? This doesn't seem too bad, but it might be possible that with such a good FEC the synchronization becomes the "weakest link in the chain", and as we reduce the SNR packets can no longer be decoded not because of bit errors, but rather because of failure to synchronize.

Finally, DVB-S2 uses a BCH outer code. Are you planning to include that as well, or only the LDPC? LDPC codes tend to leave a few uncorrected errors, so that's the reason why DVB-S2 (and many other protocols) include an outer code to fix those. However, depending on the probability of uncorrected errors, you may not care about using an outer code.

For the uplink, are you planning to use the same LDPC code or a simpler scheme? Take in mind that the CC1125 will only give you hard-decission bits, so the LDPC decoder won't be as advantageous, and you'll probably have limited processing power onboard the satellite to decode FEC. The uplink has the advantage that you can put much more transmit power at the groundstation than at the satellite, so often a simpler FEC is used for the uplink.

[Danieltajik]

Thanks for the quick response!

In terms of DVB-S2, I actually created a custom parity check matrix based off of their technique in order to utilizes the default 256 byte FIFO limit on the CC1125 chip. I've tested it with simple MATLAB codes and it seems to be working successfully with low BER, (it at least avoids girth-4 Tanner graphs). Right now I have it as a r =3/4, column weight 2, row weight 8 block.

Our plan was to utilize the synchronization codeword from the CC1125 for simplicities sake, but I hadn't considered that it could be a rate limiting component. Do you have any other recommendations? Right now one issue we are dealing with is the amount of payload data that we will be needing to downlink during each pass, and we are finding ourselves very tight on bandwidth. Adding too much overhead in the packet headers is a little concerning so if there is anything that can manage it without more it could be beneficial.

I should also note that our link budget margin at this current point is fairly comfortable (approximately 10 dB) even in the uncoded case. We are transmitting about 2W on downlink and have pretty high gain Rx antenna (18 dBic) which is definitely a big help, but are considering dropping it down to better conserve power, especially during our beacon windows.

I wasn't aware of the BCH outer code. Does it add a lot of complexity or overhead to the packets? Again with our margins it may not be necessary but it is worth considering.

Yes this was one consideration to conserve complexity on the uplink. We can absolutely transition to an RS/CC code or equivalent for simplicities sake. Do you have any recommendations?

I do have one question that I was hoping you would be able to answer. I have been working with the symbol sync block in GNURadio and have been having a lot of difficulty optimizing the synchronization. Is there any literature or examples beyond what GNURadio provides that you have seen that could help us develop this a bit more accurately? My background is not in signal processing so this optimization is a bit perplexing to me.

Thank you and looking forward to working with you further! I think an LDPC code for CubeSats would be an awesome think to include into your library if we can get it running well.

[daniestevez]

How does your custom LDCP code perform? Do you have a BER vs. Eb/N0 in AWGN plot? The CCSDS synchronization and coding blue book gives LDPC codes for an information block size k = 1024. At a rate of r = 1/2, this fits in the 256 byte FIFO. Detailed performance of these codes can be found in the green book. Maybe there's no need to reinvent the wheel with a custom code.

Capacity achieving codes typically work much better for a large block size, and I have the impression that for smaller block sizes Turbo codes outperform LDPCs (that's the reason why Turbo instead of LDPC was chosen for the Longjiang-2 Amateur payload). Nevertheless, the AR4JA code given in CCSDS for k = 1024 and r = 1/2 is not a bad performer and it outperforms by some 0.5 or 1 dB the typical concatenated code (k = 7, r = 1/2 convolutional + (255,223) Reed Solomon) for the range of BERs that you would typically care about in this application.

Thinking again about the outer code, I don't think you need near errorless copy as in the typical DVB-S2 use case, so it's not so important that the BER curve of the LDPC code is not so steep and it's probably a good idea not to include an outer code.

How long is the CC1125 syncword? Is it 32 bits? Can you set it freely to a syncword having good autocorrelation properties? CCSDS uses a 64 bit syncword for LDPC codes.

For the uplink, I think that you don't even need the convolutional code. This saves you from the need to do Viterbi decoding in the satellite. A Reed-Solomon code works well if it fits your frame size, or if not you can use BCH (which is similar to Reed-Solomon, but comes in more block sizes). The TC synchronization and channel coding blue book gives a short BCH code to be used by blocks in telecommands (so that it can fit different telecommand lengths).

Regarding the symbol sync block, have you seen Andy Walls' talk about it?

[Danieltajik]

I wrote the code using Matlab's built-in LDPC (based on DVB-S2) encoder/decoder. All I needed to do was construct a parity check matrix that was considered valid (I believe the requirements were high sparsity and that the parity portion of the parity check matrix was invertible). I have attached an image from a report that should clarify the BER performance (note that there are some fitting errors related to the CC code).

The CC1125 sync word is 32 bits. I believe we have complete control over the sync word and can set it to whatever would provide the most optimal synchronization. Also note that the CC1125 packet contains any length preamble which assists with this process.

In this plot I also created a Reed Solomon r=3/4 code and it performed reasonably, reducing the BER by several dB. It can definitely be an option for uplink. Thank you for the bluebook, I will take a look and try to better determine what will work for our uplink connection.

I have not seen this talk and will take a look, thank you!

[daniestevez]

In any case I suggest you do a BER simulation with you particular choice of LDPC parity check matrix. Not all the LDPC codes for a fixed size perform equally well, so there is a lot of art to generating and choosing better performing codes, even though there are some algorithms to generate parity check matrices pseudorandomly.

Another question that will become important in the future is to use your LDPC code in GNU Radio. There are "LDPC encoder/decoder definition" blocks, so I guess those could be used, but they need an AList to specify the code.

[Danieltajik]

Thanks Daniel,

The previous post including the graph depicting the performance is the particular LDPC Parity check matrix we have created, in a 2-FSK format. I ran the simulation to about 10^9 transmissions, stopping when I detected 10^3 errors. However, I should take a look at other PCM that could be an improvement, I will look around.

I haven't attempted to use the LDPC code blocks in GNURadio as of yet. If they utilize the same approach as DVB-S2 I may be able to easily transfer over my implementation from Matlab. Thanks for your help! I will update you on our progress as we reach new developments.

[daniestevez]

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