Regarding Observation 449332 …
This could be Delphini-1?
The TLEs are the correct ones, so it could be that. But I’m not sure as there isn’t any other source that delphini is received.
We are now quite certain that it was three 4k8 bursts since it looks very similar to subsequent recetions from today: https://network.satnogs.org/observations/?future=0&good=1&bad=0&unvetted=0&failed=0&norad=44030
3 Likes
Delphini-1 is based on GomSpace HW so maybe is Delphini-1 reusing the transceiver and setup from other GomSpace sats. According to Daniel Estevez’s overview (https://github.com/daniestevez/gr-satellites) use LUME-1 and 1KUNS-PF this setup for GMSK:
Gomspace NanoCom AX100 modem, CCDS scrambler, (255,223) Reed Solomon code.
So I downloaded the audio files and gave it a try with these modems/decoders:
- MSWin: UZ7HO’s modem for 1KUNS-PF @4800 and DK3WN’s “Online Kiss Decoder”
- Linux: Daniel’s modem for LUME-1 from gr-satellites with a modified flowgraph:
– Enabled “Message debug” and disabled telemetry forwarding and decoding (unknown format)
– Low pass filter changed to “Cutoff Freq = 2500, Transition Width = 3000” (that gave the best results with LUME-1 @4800)
And bingo, the two decoders got exactly same number of frames, nice:
Satnogs obs 449332: 3 frames decoded
Satnogs obs 449336: 58 frames decoded
Satnogs obs 451430: 12 frames decoded
Satnogs obs 451461: 15 frames decoded
But if I compare the 18th frame in obs 449336 from the two decoders they are not quite the same (ignoring header)…
_Below 18the frame from “Online Kiss Decoder”
2019-02-06 21:22:29.750 UTC: [201 Bytes KISS Frame (without CRC)]
1 > C0 00 00 07 DA 4B 55 13 00 B3 21 1F 00 16 00 16 00 00 F5 00
21 > 02 00 3C 00 04 3F 00 00 00 00 08 05 00 09 01 00 0B 01 00 0C
41 > 01 00 0D 01 00 0E 04 00 0F 02 00 10 05 00 12 01 90 00 14 03
61 > E8 00 18 00 00 00 1C 00 00 00 00 00 20 00 00 21 00 00 24 00
81 > 00 00 0A 00 28 00 00 12 DB DC 00 2C 00 0A 00 2E 0E 10 00 30
101 > 32 2F 35 20 49 32 43 2C 20 30 2F 32 20 43 41 4E 2C 20 30 2F
121 > 30 20 41 58 31 30 30 2C 20 38 2F 35 20 4B 49 53 53 00 00 00
141 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
161 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
181 > 3D 00 00 00 0A 00 00 00 03 70 61 72 61 6D 20 6D 53 AD DD D1
201 > C0
À…ÚKU…³!..õ…<…?..è…
…!..$…(…ÛÜ.,…02/5 I2C, 0/2 CAN, 0/0 AX100, 8/5 KISS…
…=…param mSÝÑÀ
Below same frame from “gr-satellites” LUME-1 decoder:
2019-02-06 22:08:03
Packet number 17
MESSAGE DEBUG PRINT PDU VERBOSE
()
pdu_length = 197
contents =
0000: 00 07 da 4b 55 13 00 b3 21 1f 00 16 00 16 00 00
0010: f5 00 02 00 3c 00 04 3f 00 00 00 00 08 05 00 09
0020: 01 00 0b 01 00 0c 01 00 0d 01 00 0e 04 00 0f 02
0030: 00 10 05 00 12 01 90 00 14 03 e8 00 18 00 00 00
0040: 1c 00 00 00 00 00 20 00 00 21 00 00 24 00 00 00
0050: 0a 00 28 00 00 12 c0 00 2c 00 0a 00 2e 0e 10 00
0060: 30 32 2f 35 20 49 32 43 2c 20 30 2f 32 20 43 41
0070: 4e 2c 20 30 2f 30 20 41 58 31 30 30 2c 20 38 2f
0080: 35 20 4b 49 53 53 00 00 00 00 00 00 00 00 00 00
0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00b0: 00 3d 00 00 00 0a 00 00 00 03 70 61 72 61 6d 20
00c0: 6d 53 ad dd d1
What is going on here, should’nt they be the same…?
– jesper
The first one is a KISS format data stream, the second is not! As C0 00 [escaped data] C0 is used to encapsulate the data stream, an occurance of C0 as value inside that stream has to be replaced by DB DC, which is the escape sequence for it.
Edit: you can find a short python script snippet in the satnogs-decoders gitlab repository to convert KISS frames back to raw binary, and another one that writes them into a file in ‘hexlified’ format.
Sorry for lacking links, but I’m on my mobile only…
Stuffing! OK, that explains it, thanks.
– jesper
1 Like
