EIRSAT-1 (University College Dublin)

[Fergal95]

Hi Daniel,

EIRSAT-1 is Ireland's first satellite that is being developed by postgraduate students in University College Dublin. EIRSAT-1 is a 2U cubesat and was chosen as part of ESA's Fly Your Satellite! programme, that will fly with three scientific payloads.

We are likely to be launched into an LEO orbit from the ISS but there is a possibility that we are launched into a yet to be determined SSO orbit. We are developing our own ground station on campus at UCD and will obtain between 4 to 7 minute communication windows for each pass.The communications will use a VHF uplink and UHF downlink. Frequency coordination had been completed by IARU. http://www.amsatuk.me.uk/iaru/finished_detail.php?serialnum=639 Our downlink frequency is 437.1MHz. 1k2 AFSK modulation scheme will be implemented for the uplink that will use the AX.25 protocol.

For downlink we are using 9k6 GMSK. Two FEC schemes will be used at different stages of our mission. Nominally, we will use dual basis RS(255, 223) codes with an interleaving depth of 4 with a CCSDS scrambler. The data is formatted in PUS packets with CCSDS framing. Each frame is 1020 bytes long and is prepended with the standard 0x1ACFFC1D ASM. At the beginning of the mission and when the satellite has entered safe mode, convolutional encoding will be used making it a concatenated scheme. The convolutional encoding is applied in hardware by our comms board which is a CPUT CMC (also sold by Clyde Space as "Pulsar TMTC"). The polynomials that are used are (109, 79) with neither polynomial being inverted.

The ground station solution is using standard GNURadio blocks for the signal processing and demodulation stage with gr-satellite blocks being implemented for parts of the decoding process. The solution works well and we are able to route our decoded data to our mission control software. An SDR receiver that will be used for deployment has not been chosen yet but we are currently using the FunCube Pro+ for developing our ground solution.

We'd love to get official support for EIRSAT-1 in gr-satellites. One current difficulty to simply writing a satyaml file is the non-standard convolutional encoding polynomials used by the CMC hardware. In our solution we just made a hierarchical block similar to that in older versions of gr-satellites but with the correct polynomials for our board. I noticed that NASA-DSN polynomial support was recently added to gr-satellites alongside the NASA-GSFC polynomials. Maybe our (really CPUT's) polynomials could be added in a similar way? We can upload some short recordings of both purely RS encoded frames and also frames encoded with the concatenated scheme.

Thanks,
Fergal

[daniestevez]

Hi Fergal,

Thanks for reaching out. I've been "keeping an eye" on your satellite since a while ago, but I don't think I've seen any of your presentations.

I see two possible ways to proceed here:

1. Add a specific deframer for EIRSAT-1. The only other satellite that is using interleaved Reed-Solomon is Astrocast 0.1, which uses an interleaving depth of 5 and no convolutional code. It has its own custom deframer. I see that this specific deframer is basically what there is already in david-j-murphy@d686ce6. The only modification I would do to that is to include the Viterbi decoder in eirsat_concatenated_deframer.py instead of in a separate hierarchical block.

2. Rethink a little the CCSDS concatenated and Reed-Solomon deframers and how to specify different polynomials for the convolutional code and interleaving depth for Reed-Solomon. Theses deframers would then support Astrocast 0.1 and EIRSAT-1. Here I see the opportunity to reduce duplicated code:

• The Reed-Solomon C++ decoder blocks could be merged together. Currently there are decode_rs, decode_rs_general and decode_rs_interleave. These would be reduced to just one block.

• How to specify variants of CCSDS codes in SatYAML needs to be rethought. Currently there is an unmanageable explosion of combinations of the words "dual", "dual", "no-scrambler", "differential" and "NASA-DSN". I am more inclined to adding more fields to the framing section (we already have the frame size field) to represent all these options.

I think that 2 is the best solution, since it tackles several points where gr-satellites can be improved. However, I'm not sure if I'll be able to implement everything needed in 2 very quickly. This depends on your time frame. If you need something merged to gr-satellites in the next month, then it might be better to do 1 as a temporary solution.

[Fergal95]

Hi Daniel,

Thanks for your response, it is great that you have been keeping up with what we are doing! We have a talk next Tuesday on our ground station solution and communications with the amateur radio community here in Dublin that myself and David will be giving. If you are interested in listening in we would be delighted to send you a link to the zoom call.

Regarding the next steps forward, we are in no rush to get merged into gr-satellites and agree that approach 2 would be best, especially if it helps with the improvement of gr-satellites. We have a working solution locally that we are going to continue to use for testing. We would love to make it possible for the community to receive data from EIRSAT-1 but as we are not going to be launching for a while yet, we can afford to wait a while before merging EIRSAT-1 into gr-satellites.

[daniestevez]

I've made some progress with this over the last days. I have now finished refactoring the Reed-Solomon C++ blocks so that a single block is used for decoding (or for encoding) regardless of the code properties or the interleave depth.

This still leaves me with the task of implementing different CCSDS variants with parameters in SatYAML rather than using different framing names.

The work in progress is in the ccsds branch.

[janvgils]

I am also following this development and would like to do some tests if possible.

During the really great online lecture (https://youtu.be/jrwyb2rDYBs) I already asked for some example data that could be used to test decoders, is there any news on this, are there examples available?

[daniestevez]

I have pushed 48dd969 to the ccsds branch. This removes most of the variants of the CCSDS framings in the SatYAML files and only leaves "CCSDS concatenated" and "CCSDS Reed-Solomon". The variants are specified via extra parameters, so that the SatYAML for EIRSAT-1 would look like

framing: CCSDS Concatenated
RS basis: dual
RS interleaving: 4
frame size: 892
convolutional: NASA-DSN uninverted

I still need to add documentation for this, but it would be great to have feedback before the ccsds branch gets merge into master.

[daniestevez]

I have just merged the ccsds branch into master, so the refactored Reed-Solomon decoder C++ blocks and all the SatYAML changes needed to support EIRSAT-1 are now in master and will be available in v3.6.0.

[daniestevez]

Hi @Fergal95, I saw that EIRSAT-1's launch is coming up some day in April. Have you tested whether the features in the last versions of gr-satellites have all you will need for EIRSAT-1?

[janvgils]

I am also following this development and would like to do some tests if possible.

During the really great online lecture (https://youtu.be/jrwyb2rDYBs) I already asked for some example data that could be used to test decoders, is there any news on this, are there examples available?

Is there already some test data made available?

[daniestevez]

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

[david-j-murphy]

Hi @daniestevez, @janvgils,

I'm picking this thread up after a very long break! Fergal has since graduated but work on our ground station has continued. It really wouldn't have been possible without gr-satellites, so thank you!

I would like to direct your attention to https://github.com/ucd-eirsat-1/beacon. I have made a SatYAML file for EIRSAT-1 which works perfectly. I can create a pull request here with the SatYAML if you like? Is there a particular temporary NORAD ID I should use? The repository also contains some recordings of the satellite beacons. I would be happy to contribute the recordings or edited, shorter versions to your satellite-recordings repository if it's useful. In any case, they are released without licence, so do with them as you please!

Thanks again for all your hard work!

[daniestevez]

Hi David,

Thanks for this. A PR with the SatYAML file is mostly welcome. I've been looking at the beacon repository and it looks fantastic. Regarding the temporary NORAD ID, I suggest that you get in touch with the SatNOGS community at the librespace formus to get EIRSAT-1 added to SatNOGS DB. We could use any temporary ID, but we try to coordinate with SatNOGS DB and use the same so that the frames that people submit to SatNOGS end up associated to the right satellite.

Regarding the recordings, yes, sending a PR with some short sample recordings to satellite-recordings would be good. These are 48ksps WAV and tend to be rather short (a couple frames in general) to save space. I've looked at Recordings_failsafe_conv_enabled.wav and I think something like that would be good, but I suggest to cut out most of the 25 seconds of noise between the two packets (leaving only a couple of seconds).

[david-j-murphy]

Hi Daniel,

Thanks! Using a temporary ID from SatNOGS makes a lot of sense. I've made a post on the Libre Space forums, but it's currently pending as while I've had a SatNOGS account for a long time now, I haven't posted to the forum before.

[janvgils]

Hi David,

I have created a EIRSAT-1 entry in the SatNOGS db and this only needs moderation.

https://db.satnogs.org/satellite/HKNJ-5808-9467-1239-6592

After that it will receive a temporary NoradID that we can use in the yml file.

Sorry if I missed it, a question will you be hosting a solution to receive decoded frames by yourself ?

[janvgils]

EIRSAT-1 now has temporary NoradID 99320 https://db.satnogs.org/satellite/HKNJ-5808-9467-1239-6592.So we can configure that value in the EIRSAT-1.yml file.

With the latest gr_satellites master build we no have the --satcfg option, this will use parameters from the file ${HOME}/.gr_satellites/sat.cfg. Below an example included the EIRSAT-1.yml where 99320 is used as temporary NoradID.

46276 --disable_dc_block  --deviation 500 --clk_bw 0.15
48900 --disable_dc_block
37855 --clk_bw 0.1
35933 --clk_bw 0.3
99320 --input_gain -1

[david-j-murphy]

Thanks Jan! That's much appreciated!

It's not something that we've put any work into yet, but it might be a good idea for us to look at setting up a SiDS server.

[K4KDR]

Thanks for the updates!

FYI, the first recording tested (primary_no_conv.wav) decodes perfectly in GNU Radio 3.8 (gr-satellties branch "maint-3.8) but please follow the instruction provided in the README (https://github.com/ucd-eirsat-1/beacon/blob/main/README.md) to invert the provided audio files on playback:

Note: these recordings do need to be played back with a gain of -1 in gr-satellites.
.

[daniestevez]

If you could bypass the framing of the transmitter, then by transmitting a sequence that is all 1's (or mostly 1's), you could observe the spectrum and check if the transmitter is transmitting the high tone or the low tone. Even if you can't bypass the framing, you could exploit this technique by transmitting a frame that contains the scrambling sequence, so that when it's scrambled yields all 0's or all 1's.

However, from the results you have I am already quite confident that the it's the transmitter. If on the QT GUI Waterfall Sink you can see the spectrum correctly (rather than mirrored; to test this you can inject a signal at some other known frequency), then you're sure that there are no spectral inversions caused by the SDR receiver. In the flowgraph there are no spectral inversions either (no complex conjugates, and the gain of the quadrature demod is positive), so you can be certain that you're recording to WAV exactly what the transmitter is sending.

Another alternative is to record IQ data and look at it with inspectrum. Set the waterfall resolution so that you can see the tones, and check if the syncword is inverted. While doing this, inject a signal at another known frequency to be absolutely sure that the IQ recording hasn't ended up with a frequency inversion somehow.

[david-j-murphy]

I think you may be correct correct about the transmitter. We see the spectrum correctly on the Waterfall plot (signals at a higher frequency appear to the right as expected).

I will check this with the vendor of the transceiver and I'll see if it's possible to schedule some time with our test bench to run some tests with the scrambler disabled, but both of those activities could take some time.

I've tried setting deviation: -2400 and it works well with an IQ input. Is there a way that we can specify to invert the signal by default if people are using an already FM demodulated input?

Thanks!

[daniestevez]

Indeed I hadn't thought that setting a negative deviation will not work with an FM demodulated input. The fix is simple, so I'll implement it today.

I am wondering if SatYAML should actually have a field to indicate that the polarity of the bits is inverted. In a certain sense, using a negative deviation seems like a hack, but in another way it also makes sense, and we have used this with AFSK for long. It's also relevant to point out that the polarity of the bits inversion only makes sense for FSK and AFSK, since with BPSK we always have a 180º phase ambiguity. In principle I'm happy to keep using a negative deviation to imply that the polarity of the bits is inverted, both in FSK and AFSK, but I'm happy to hear feedback from the community about whether this is a good idea or not.

[daniestevez]

I have now fixed the problem with the FM demodulated input in 730ad51.

[david-j-murphy]

Thanks Daniel! This solution seems good!

[K4KDR]

How is the transmitted signal being generated? Is it from your flight-model satellite, a bench-test duplicate, or by some type of simulation?

If from a 'real' radio (i.e., on the satellite), details on the hardware/software might be helpful if not held privately.

[david-j-murphy]

The recordings were made using a bench-test duplicate (the same components we used in the qualification model of the spacecraft but in a flat sat configuration). I'm going to upload some more recordings made of our flight model over the past few days in our ongoing mission test.

The radio is a CPUT CMC also known as a Pulsar_VUTRX sold by AAC Clyde Space. We're using it in 'transparent' mode so all the framing and scrambling is performed by the flight-software on the On-Board Computer. The radio itself handles convolutional encoding when that is enabled though.

Unfortunately, the copy of the user manual that we received with the radio was under NDA. I thought I'd found it posted freely online before but I've had no luck tracking it down again. So I'd prefer not to post it here publicly, but if you'd like to take a look at it, I'm sure we can work something out! :)