D-STAR One are a series of Amateur satellites with an on-board D-STAR digital voice repeater. The first satellite of the series, called D-STAR One, was launched on November 2017 but was lost due to a problem with the upper stage of the rocket. The second satellite, called D-STAR One v1.1 Phoenix, was launched in February 2018 but never worked. On 27 December 2018, a Soyuz rocket launched the next two satellites in the series: D-STAR One Sparrow and D-STAR One iSat. I hear that, unfortunately, these two newer satellites haven’t been coordinated by IARU.
Besides using the D-STAR protocol, these two satellites also transmit telemetry in the 70cm Amateur satellite band using the Mobitex protocol, as described in the CMX990 modem datasheet. They use GFSK at 4800 baud.
In the past, I have talked about the Mobitex protocol in the context of the BEESAT satellites by TU Berlin. I described some notes about the Mobitex-NX variant used in these satellites, and contributed to the beesat-sdr GNU Radio decoder for the Mobitex-NX protocol.
Now, I have adapted the Mobitex-NX decoder to work also with the D-STAR One satellites, and added a decoder to gr-satellites. The decoder requires my fork of beesat-sdr to be installed.
The differences between the Mobitex-NX used in the BEESATs and the Mobitex used by D-STAR One are the following. First, the frame sync marker is different. BEESAT uses 0x0ef0, while D-STAR One uses 0x5765. Second, the format of the control bytes is different. I haven’t found any documentation about the format used by D-STAR One, but it always uses 0x7106 as control bytes. Since the frames sent by D-STAR One always have 6 blocks, I guess that the 0x06 byte is the number of blocks, but I don’t know what does 0x71 mean. Third, D-STAR One omits the callsign field (and its CRC-16), since this was a add-on to the Mobitex-NX protocol done by the BEESATs. The remaining details about the protocol seem to be the same.
Using a sample recording that Mike Rupprecht DK3WN has sent me, I have been able to decode the following packets.
pdu_length = 116
contents =
0000: 71 06 6c a3 90 41 02 00 02 00 00 00 81 85 15 85
0010: 00 0c 00 c1 09 5a 0c 62 0a a0 06 0e 00 05 00 14
0020: 00 0b 00 01 00 0c 00 27 02 59 00 06 00 00 00 09
0030: 00 0b 00 1a 00 b2 00 06 00 07 00 03 00 0a 00 07
0040: 00 05 00 03 00 03 00 00 00 08 00 ef 08 43 00 07
0050: c0 10 03 00 30 f0 00 00 00 00 10 10 00 ff 00 00
0060: 00 02 ff ff ff ff ff ff ff ff ff ff 3f 90 aa 00
0070: 00 00 00 bb
pdu_length = 116
contents =
0000: 71 06 6c a3 ae 41 02 00 02 00 00 00 81 85 15 85
0010: 00 10 00 c0 09 5d 0c 9f 0a a0 05 19 00 05 00 15
0020: 00 0d 00 01 00 0c 00 28 02 58 00 08 00 00 00 0a
0030: 00 0b 00 1a 00 b0 00 06 00 07 00 05 00 09 00 08
0040: 00 06 00 03 00 02 00 00 00 07 00 ef 08 43 00 08
0050: c0 10 03 00 30 f0 00 00 00 00 10 10 00 ff 00 00
0060: 00 02 ff ff ff ff ff ff ff ff ff ff 56 90 aa 00
0070: 00 00 00 bb
pdu_length = 116
contents =
0000: 71 06 6c a3 cb 41 02 00 02 00 00 00 81 85 15 85
0010: 00 0f 00 53 09 70 0c a4 0a a0 05 3d 00 05 00 14
0020: 00 0d 00 01 00 0c 00 28 02 59 00 08 00 00 00 0a
0030: 00 0b 00 1b 00 14 00 05 00 07 00 05 00 0a 00 08
0040: 00 05 00 03 00 02 00 01 00 07 00 ef 08 5b 00 08
0050: c0 10 03 00 30 f0 00 00 00 00 10 10 00 ff 00 00
0060: 00 02 ff ff ff ff ff ff ff ff ff ff 3c 37 aa 00
0070: 00 00 00 bb
See the Mobitex-NX notes for the meaning of the errorcode bytes between the 0xaa and 0xbb at the end of the packet.
We already have the information about the format of the beacon packets, so a telemetry parser will be released soon.
Update 2018-12-29: The telemetry parser is now included in gr-satellites. The parsed output of the packets shown above can be seen in this gist.
Thanks for putting that together so quickly! Since we have two satellites near each other & transmitting with the same protocol on the same frequency, is there (yet) a way to identify which spacecraft a telemetry packet is actually coming from? Looking at my decodes, I don’t see anything obvious unless I’m simply overlooking it.
Hi Scott,
I think you’re right. I don’t see any way to identify the satellite from the information in the Mobitex beacons. The BEESATs had the callsign embedded in the Mobitex-NX protocol, but D-STAR One doesn’t.
However, in the D-STAR beacons there are callsigns embedded, so it might be possible to use those. Mike DK3WN already had some decodes using dsd.
Thanks for the reply! I have not seen any D-STAR beacons remotely strong enough to decode yet, but am excited to see what happens when I do. Word from the Project Team is that the D-STAR capability is in “test mode”, so apparently will not be transmitting at all times on all orbits. Hopefully that will change to full-time in the near future!
Dear Dr. Estevez
I want to measure the exact time of IQ-recording and write it in the filename of the recorded file in GNURadio using ettus B210 devices. Do you know how I should do this?
Hi John,
If you don’t need very exact timing, you can use a variable in the GRC flowgraph that contains Python code to get the current timestamp and format it as text. Then this variable can be used as part of the filename.
If you need precise timing, my advise is that you use GNU Radio meta files, which can embed timing information from the B210 on-board GPSDO.
Dear Dr. Estevez
Thank you for your worthy reply. I need the time for cross-correlation measurement between two distant located receivers similar to the one you done in your post: “DSLWP-B Moonbounce cross-correlation analysis”. Hence, I think the precise timing is critical.
Do you know how should I do this? Do you know any .grc in GNURadio?
Best Regards
Hi John,
We’re using the GNU Radio file metadata sink in our DSLWP-B VLBI experiments. I don’t have an example flowgraph at hand, but you can start by looking at
examples/metadata/file_metadata_sink.grcin your GNU Radio installation.