Observation 449332: Delphini-1 (99990)


#1

Regarding Observation 449332

This could be Delphini-1?


#2

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.


#3

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


#4

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


#5

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…


#6

Stuffing! OK, that explains it, thanks.
– jesper


#7

You can find these snippets here :wink: