Move-II Decoding

[K4KDR]

The beaconparser executable has been added to

https://www.qsl.net/k/k4kdr//grc/move-ii/

… in typical linux fashion, you can run it w/ –help for syntax.

To parse the .bin file output from the GRC flowgraph, I would typically run something like:

./beaconparser -7 -8 -r -i80 /tmp/move-ii.bin | more

… where a result with complete & valid telem data would then say:

{“MATCH”: “VALID v200 at #### with 100% integrity”},

Output not showing ‘VALID’ or with less than 100% integrity at least lets you know if you’re close

[K4KDR]

This morning’s MOVE-II pass had plenty of elevation here, so the signals were nice & strong:

… however, while a perfectly fine .BIN file was created to be fed to the BEACONPARSER utility, my flowgraph did not produce hex decodes for upload to SatNogs, etc.

In the past, the only frames I ever decoded were of type ‘V200’. Today’s .BIN file produced a good number of decodes in the BEACONPARSER utility, but the -3- that were 100% VALID were of type ‘V7’. So, perhaps my flowgraph does not handle those correctly (perhaps frame size or checksum?) to generate raw hex output.

Regardless, the -3- clean decodes produced by the BEASONPARSER utility appear to be good data:

I’ll attach that text file here if anyone would like to review it in more detail:

VALID_beaconparser_output.txt (7.5 KB)

[K4KDR]

Sometimes you just guess right. Taking another look at the .BIN file that the flowgraph produces as a stream of all the decoded hex bytes, sure enough these were frames of a different size than I had seen in the past. In a hex editor, it was easy enough to visually mark a couple of frames to confirm that the new size was 0x174 hex = 372 decimal:

… so, the new expected frame size was put into the GNU Radio flowgraph:

… I also bypassed the CRC check just to eliminate another variable. With the new frame size in place, we get human-readable frames again:

(the 2 example frames shown may or may not be valid - there may be more fine-tuning required. All I was trying to do was find out why I was getting NO output… and at least part of that answer turned out to be frame size from these ‘v7’ packets that I had not seen previously)

[dl7ndr]

I pushed this observation with one 100% integrity beacon through the decoder, but nothing.
Using my own recordings, beaconparser goes up to 89%.

[dl7ndr]

EA4GPZ’s article about decoding MOVE-II.

[K4KDR]

@dl7ndr

I pushed this observation with one 100% integrity beacon through the decoder, but nothing.
Using my own recordings, beaconparser goes up to 89%.

In the past I’ve always found that it took a very strong, very clean packet to get a 100% valid decode. Many times a packet would look strong in the waterfall but when run through the BEACONPARSER, was not “perfect”.

But, the good news is that often you do get some that reach that 100% valid threshold!

[dl7ndr]

Got one 100% beacon from today’s pass and confirm that the appended CRC is wrong.
Instead of b69c or 9cb6 it should be b972 (CRC16-CCITT-ZERO).

0000: fa f3 20 00 16 e0 58 9b 35 99 07 34 2e 36 31 34
0010: 2e 32 32 32 2e 36 34 ff b9 30 66 23 03 00 00 00
0020: 00 00 00 00 d0 d4 00 01 01 02 00 00 00 64 4d 64
0030: 64 64 64 64 64 03 10 00 18 00 00 0f 00 10 00 00
0040: 00 40 00 00 00 00 00 04 00 00 00 00 20 00 10 00
0050: 00 04 00 00 00 04 00 00 00 00 00 00 81 10 00 00
0060: 01 81 00 00 10 00 00 08 40 11 00 00 00 08 00 82
0070: 80 84 10 30 4c 00 08 00 10 01 00 04 80 00 08 23
0080: 00 80 04 40 09 40 02 62 82 00 23 a6 cf ab 3f fb
0090: bd df d6 5f 69 73 8e ed fc ff 77 f7 af fb 3d 7d
00a0: fd 77 45 97 d6 00 00 00 80 00 00 00 00 00 00 00
00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00c0: 10 00 00 01 00 00 00 00 00 00 00 00 00 00 10 00
00d0: 00 00 87 ff 7d ff 81 ff 00 00 71 ff 3b fe ed fd
00e0: 63 fe 7a fe 00 00 00 00 00 00 a0 fa 00 00 c0 fb
00f0: 4b 01 00 44 00 7e 00 05 00 02 00 02 00 01 00 02
0100: 00 01 00 02 00 01 00 02 00 bb 00 4f 00 c0 00 33
0110: 00 18 00 08 8d 55 7f cb 1c 13 27 51 27 45 11 00
0120: 00 00 00 00 00 00 00 40 00 80 4e 7d 7c 13 00 77
0130: 00 c0 04 00 7b 00 00 00 00 00 00 00 00 00 00 00
0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0150: 00 2b 00 00 00 2b 00 40 00 00 00 00 00 00 00 00
0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c9 26
0170: d0 57 b6 9c

[
{“MATCH”: “BROKEN v7 at 4187 with 100% integrity”},
{
“HEADER”: {“ASM”:“0xFAF320”,“SEQ”:0,“ARQ”:0,“EXT”:0,“LEN”:366,“VC”:0,“RSV”:0},
“CDH”: {“beaconId”:-1724540072,“beaconVersion”:7,“loadAvg1Min”:4.61,“loadAvg5Min”:4.22,“loadAvg15Min”:2.64,“realtimeClock”:1714469375,“uptime”:803,“freeSpaceOnDataImage”:0,“maxMemoryUsage”:13946880,“runningOsImageId”:1,“lastBootedOsImageId”:1,“bootCounter”:2,“uptimeImage”:[100,77,100,100,100,100,100,100]},
“HORST”: {“safemodeState”:3,“manualmodeState”:16,“maneuvermodeState”:0,“batteryLevel”:24,“thermalState”:0,“adcsPointingState”:15,“adcsRequestedState”:0,“payloadState”:16,“leopState”:0},
“ADCS”: {“timestamp”:4194304,“status”:0,“magneticFieldXYZ”:[0,0,0],“gyroscopeXYZ”:[0,0,0],“estimatedStateRIJK”:[0,0,0,0],“estimatedVelocityXYZ”:[0,0,0],“sunXYZ”:[0,0,2.07],“error”:1644314633,“svdAttitudeRIJK”:[0,-9.95213e+35,3.09666e+19,-5.5108e+27],“controlDipoleMomentXYZ”:[-5.03004e+33,1.57832e+37,0]},
“THM”: {“payloadTempOw”:[2.1,0,1.3,0,0,0],“adcsSidepanelXPosTempBmx”:23,“adcsSidepanelXPosTempOw”:[0,0,0],“adcsSidepanelXNegTempBmx”:23,“adcsSidepanelXNegTempOw”:[0,0,0],“adcsSidepanelYPosTempBmx”:31,“adcsSidepanelYPosTempOw”:[16,0,0],“adcsSidepanelYNegTempBmx”:23,“adcsSidepanelYNegTempOw”:[0,0,1],“adcsMainpanelZPosTempBmx”:23,“adcsMainpanelZPosTempOw”:[-7.6,-8.2,-7.9],“adcsPayloadZNegTempBmx”:23,“adcsPayloadZNegTempOw”:[-8.9],“epsBoardTemp”:-4.5,“epsBatteryBoardTemp”:-5.3,“epsBatteryTemp”:[-4.1,-3.9],“comSbandTemp1”:0,“comSbandTemp2”:0,“comSbandTemp3”:0,“comUhfVhfTemp1”:-5.4,“comUhfVhfTemp2”:-30,“comUhfVhfTemp3”:-4.2,“cdhTemp”:3.3,“thmSystemState”:0},
“EPS”: {“busCurrentBatV”:68,“busCurrent5V”:126,“pdmCurrentSBand”:5,“pdmCurrent2Smard”:[2,2],“pdmCurrentPl5V”:1,“pdmCurrentAdcs5V”:[2,1],“pdmCurrentPl33V”:2,“pdmCurrentAdcs33V”:[1,2],“batteryCurrent”:187,“bcrCurrent”:[79,192,51,24],“manualResetCounter”:8,“softwareResetCounter”:141,“brownOutResetCounter”:85,“watchdogResetCounter”:127,“batteryVoltage”:7371,“bcrVoltage”:[10003,10065,4421]},
“COM”: {“ukwTxCounter”:0,“ukwRxCounter”:0,“ukwPaCurrent”:64,“ukwPaVoltage”:20096,“ukwRssi”:31869,“ukwMcs”:19,“ukwRxFrequency”:79691895,“ukwRxQueueCounter”:0,“ukwSpiTransfersProcessed”:123,“ukwSpiTransfersFailed”:0,“sbandTxCounter”:0,“sbandRxCounter”:0,“sbandPaCurrent”:0,“sbandPaVoltage”:0,“sbandRssi”:0,“sbandAccelerometerXYZ”:[0,0,0],“sbandRxQueueCounter”:0,“sbandSpiTransfersProcessed”:43,“passedAuthCounter”:0,“failedAuthCounter”:0},
“PL”: {“timeOfLastMeasurement”:0,“exitCodeOfLastMeasurement”:0,“Sc6VocNewestValue”:0,“Sc6IscNewestValue”:0,“Sc6MppVoltageNewestValue”:0,“Sc6MppCurrentNewestValue”:0},
“CHECK”: {“hmac”:“0xC926D057”,“crc”:“0x9CB6”}

Seems that also DK3WN noticed invalid CRCs already in 2019.

[pyBlob]

The semantics of the integrity field is a bit confusing. It tells how many of the bits used to search for a beacon message match. So 100% integrity means that the search pattern matches exactly. However there may still be decoding errors in the remaining message. In this particular example, you can see that there are few bit-errors in the ADCS section (e.g. adcsSidepanelYPosTempOW[0] has 16 instead of 0 and some of the RIJK/XYZ state vectors way too big).

A correctly decoded message will also contain a matching CRC and is labeled as “VALID” instead of “BROKEN”.