I think the CCSDS scrambling is correct. The first frame you decoded from the flatsat data using this setting has the correct structure of a SpacePacket in a SpaceDataLink frame.
Specifically, the 14th byte (0x03) indicates that the service is ‘Housekeeping’ and the next byte (0x19) is the ‘Housekeeping Parameter Report’ sub-service.
I think you’ll see the same service and sub-service if you try the CCSDS descrambler on your live-captured data.
Unfortunately, the contents of a housekeeping parameter report isn’t standardised, so we’ll need the HERMES team to interpret that part.
Thank you for the analysis! I do not have any familiarity with any of the standardized (‘expected’) bytes in a SpaceDataLink frame, so that is extremely helpful.
As a reminder, my live capture appeared at first glance to be a single packet but when looked at more closely in Inspectrum, each downlink was actually a PAIR of packets:
Bits 3 to 12 are the Spacecraft ID (SCID). These frames are both from a satellite with the SCID set to 36 (decimal).
To the HERMES team: Did you set the SCID different on the different CubeSats? Can you tell if this is H1 or H2 from the SCID of 36 (0x24 in hex)?
Bits 13-15 are the Virtual Channel ID and in this case have a value of 3. The third byte in the frame is the ‘Master Channel Frame Count’. The fourth byte is the ‘Virtual Channel Frame Count’. It’s really common for CubeSats to only use one virtual channel so both counts will always match exactly.
Since you got got 0x11 for the frame counts in the first frame and 0x12 for the next, it indicates that these are definitely consecutive frames. That’s probably really obvious from how close together they were anyway.
It is with great pleasure that I confirm that the two packets decoded by @K4KDRbelong to HERMES H2!!!
The satellite is alive and kicking with all its major subsystems in nominal conditions.
We hence confirm to look for our beacons using CCSDS scrabler and NASA-DSN convolutional coding. We are still looking to achieve contact with our ground stations, may I ask you the G/T of your ground station?
I an using an omni antenna, so was not tracking with any exact TLE. However, for observation timing, I was using what has been provided in this thread:
Thanks for sharing the location, it is useful for us to correlate the TLEs.
Just to be clear, I was just wondering how to compare the performance of our ground station with yours. The first figure of merit I was able to think of is the gain over noise temperature (G/T). Please let me know if you have any other idea or number you can share.
By the way, I am not able to decode these packets from your IQ file using the ground station modem (which is proprietary and I have not too much visibility into) due to low SNR. I have tried to built a GNUradio flowgraph on my own, but even using the deframer settings you suggested no packets are printed. I think I could be missing something in the GSFK demodulator. Would you mind sharing your flowgraph?
I hope that my GRC file is self-explanatory… there are comment blocks to label the purpose of each input option. (I/Q file, audio file, or ‘live’ audio from GQRX)
Regarding the use of an I/Q file as input, please note the use of an adjustable ‘BFO’ so that the observed signal can be centered at the zero point of the spectrum for proper decoding. This is particularly useful if you set the ‘Repeat’ option to ‘Yes’ when using an isolated packet as the input.
Updated TLE for TEVEL2 first group, which is now split in two groups too, for avoiding confusion I will refer to these as g11 (1-3), g12 (4-6), g2 (7-9):
Note: g11 and g12 groups are based on the deployment order and on some decodings, however the satellite that are in each group on those two may change with newer more accurate observations
Note 2: The TLE are again an approximation and don’t fit very well but will give better observations that will allow us better separation in the future
