Phoenix frames decoding

Thanks for let us know, we will keep watching. The objects are still close enough to allow to get signal even if we follow the wrong TLE set.

2 Likes

Sarah,
Could you probably make that frame publicly available (maybe just paste it in here)?

1 Like

This was the decoded message scott received using direwolf:

2020-02-25 16:10:36.130 UTC: from %$’‘e, to +%,’, via 000 > C0 00 57 4A 32 58 4F 59 00 4B 49 4F 4F 37 59 00 03 00 0B D7
020 > 09 40 6B 26 08 77 94 67 4A 1C 7D 6E D3 F6 F2 6E D5 B1 D2 39
040 > 15 52 55 19 85 C0

À.WJ2XOY.KIOO7Y…×.@k&.w”gJ.}nÓöònÕ±Ò9.RU.…À

2 Likes

Oh, well, I see: it should transmit ASCII healthbeacons, but seems to transmit something binary! The decoded frames that @fredy generated using direwolf do mostly also look like binary data!

Do you have some more docs on what it could transfer? probably in failsafe mode or maybe in a specific experiment mode?

1 Like

Found a file including a healthbeacon:

(.venv) pd@hexdump:~/software/satnogs-decoders$ cat ../sampledata/asu_phoenix/phoenix/99827_1721097.data 
Dire Wolf version 1.5
Includes optional support for:  gpsd hamlib
Setting such a small audio statistics interval will produce inaccurate sample rate display.
ERROR - Could not open config file /home/fredy/direwolf.conf
Try using -c command line option for alternate location.
Audio input device for receive: stdin  (channel 0)
Audio out device for transmit: default  (channel 0)
Channel 0: 9600 baud, K9NG/G3RUH, +, 48000 sample rate x 2.
The ratio of audio samples per sec (48000) to data rate in baud (9600) is 5.0
Increasing the sample rate should improve decoder performance.
Note: PTT not configured for channel 0. (Ignore this if using VOX.)
Bind failed with error: 98
Address already in use
Some other application is probably already using port 8000.
Try using a different port number with AGWPORT in the configuration file.
Bind failed with error: 98
Address already in use
Some other application is probably already using port 8001.
Try using a different port number with KISSPORT in the configuration file.

Audio input level is too high.  Reduce so most stations are around 50.
[0.4] (Not AX.25)WJ2XOY<0x00>KIOO7Y<0x00><0x03><0x00><0x84><0xa4><0xb6><0x00>hk:1,6,7.80,4.4M,3120360017,0.209,0.262,0.356,9.20,15,3,10,3,-93,2,0,0,1
------
 dest    +%,',  0 c/r=0 res=0 last=0
 source  %$''e,  0 c/r=0 res=0 last=0
  000:  57 4a 32 58 4f 59 00 4b 49 4f 4f 37 59 00 03 00  WJ2XOY.KIOO7Y...
  010:  84 a4 b6 00 68 6b 3a 31 2c 36 2c 37 2e 38 30 2c  ....hk:1,6,7.80,
  020:  34 2e 34 4d 2c 33 31 32 30 33 36 30 30 31 37 2c  4.4M,3120360017,
  030:  30 2e 32 30 39 2c 30 2e 32 36 32 2c 30 2e 33 35  0.209,0.262,0.35
  040:  36 2c 39 2e 32 30 2c 31 35 2c 33 2c 31 30 2c 33  6,9.20,15,3,10,3
  050:  2c 2d 39 33 2c 32 2c 30 2c 30 2c 31              ,-93,2,0,0,1
------

Let me know if I can help converting this output…

P.S.: just checked the rest of @fredy’s file: there are 115 healthbeacons!
P.P.S.: 5046 frames with unknown content from Phoenix (ASU)!

2 Likes

This might be a better question for Gomspace, but I’m not sure if they would have thoughts on what could have been transmitted. When the AX100 transmits messages, it includes a CSP header which indicates where data is going to and coming from. The satellite will normally transmit out the ascii health beacon, but if it does not receive or transmit anything for a certain length of time, the AX100 has its own health beacon that it will transmit, which only includes information on that component. If the AX100 transmits out its own health beacon, the CSP header looks different than when the spacecraft is transmitting its ascii beacon.

We decoded the CSP header and got the following:

Scott’s Packet CSP Header
0B D7 09 40 00 - 0 Prio
00101 - 5 Source Node
11101 - 29 Destination Node
011100 - 28 - Destination Port
001001 - 9 - Source Port
0100 - 4 - Reserved
0000 - Flags

A source node of 5 indicates that data is coming from the AX100, rather than a message that was generated by our OBC and then transmitted out via the radio. However, if the AX100 were transmitting out its own health beacon, the CSP header should include a source port of 7 rather than 9, and the message would look very different. From what I understand, the hardware’s health beacon is the only message that the AX100 would transmit on its own.

Port 9 usually handles the AX100’s ground WDT, which acts to reset the transceiver’s stored configuration and save it as the alternate boot file after 48 hours. This shouldn’t result in a transmission, and it shouldn’t change our settings to be different than the way things were configured prior to launch. However, I will pick the vendor’s brain on this.

Given this, we aren’t sure what this beacon means. Scott hasn’t observed anything else from the spacecraft since Tuesday, but continues to keep an eye out for us.

3 Likes

Is it possible to decode the audio file that @fredy posted above from the time of Scott’s observation to see if you get the same hex values that Scott did?

3 Likes

The frame was exactly the same, all hex values were the same.

3 Likes

I’m just curious: are those 4 bytes in front of the hk: of a healthbeacon also that CSP Header?

I’ve just checked a few thousand frames with that content from @fredy’s file: the data is always exactly the same as in Scott’s frame! Probably kind of an emergency heartbeat?

Here’s the file. Probably this link works (please confirm or decline):

@fredy: could we probably split this discussion off of this thread?

1 Like

What I am also surprised of:

The GomSpace Modem supports AX.25 directly in one of its modes. How did you manage to “malform” the header?

1 Like

I’ve split the topic, let me know if I need to change the topic to something better.

2 Likes

The link you provided works just fine. These packets are not the same as what Scott obtained, however. When we programmed the satellite, we programmed it to transmit error packets if something went wrong with processing a command, or to tell us things that would let us know if operations were successful such as “schedule file uploaded” and “image captured.” The packets that were decoded from the 19th are error packets that we programmed it to transmit. What Scott got was not something we recognize.

1 Like

Hm, I am decoding the exact same…

Could you probably show where the difference is?

1 Like

One more frame captured between 2020-02-28 04:03:30 UTC - 2020-02-28 04:13:33. Still trying to find the exact time and perform TLE analysis, I’ll post my results on the other thread.

[0.4] (Not AX.25)WJ2XOY<0x00>KIOO7Y<0x00><0x03><0x00><0xcb>uC0<0x00><0x00><0x01><0xe8>
------
 dest    +%,',  0 c/r=0 res=0 last=0
 source  %$'' c/r=0 res=0 last=0
  000:  57 4a 32 58 4f 59 00 4b 49 4f 4f 37 59 00 03 00  WJ2XOY.KIOO7Y...
  010:  cb 75 43 30 00 00 01 e8                          .uC0....
------
1 Like

This is indeed different!

Screenshot_2020-02-28_22-49-54

1 Like

From our understanding of the hardware, the AX100 shouldn’t be transmitting anything from a source port of 9 or 3. We aren’t sure what either of these packets mean. I’ll have to speak to GOMSpace more about this. One thing we are going to try on the next pass is just sending CSP packets to the AX100 to see if it responds to us. If that’s the case, the transceiver may be active, but perhaps some of the settings were messed up due to an unknown error.

2 Likes

To show you the difference between these packets and what we would expect to get, I’ve broken up the CSP headers below.

This is an example of a CSP header for a health beacon coming from the AX100
ca a7 c0 00
in binary: 11001010101001111100000000000000
Decoded:
11 - priority: 3
00101 - source node: 5 (AX100 node)
01010 - dest. node: 10 (ground station node)
011111 - dest port: 31 (arbitrary port)
000000 - source port: 0 (control port)
0000 - reserved: 0
0000 - flags: 0

This is an example of a CSP header that is generated when the satellite is sending out its own health beacon (the one that starts with hk:…)
CSP header: 4A A7 D3 00
Decoded:
01 - priority: 1
00101 - source node: 5 (AX100 node)
01010 - dest. node: 10 (ground station node)
011111 - dest port: 31 (arbitrary port)
010011- source port: 19 (arbitrary port)
0000 - reserved: 0
0000 - flags: 0

source port will be something arbitrary for these packets because this data is coming form the OBC and being passed into the AX100. The AX100 has certain ports that are reserved for specific functions, and all other ports are free game. The specific ports are described more in the image below. Thus, the satellite’s health data will always be packets that have a source port above 9, and these will also increment with each transmission.

image

2 Likes

Regarding the error packets that were received throughout the evening on Feb 19th, I am asking gomspace about this to see if they have any idea on what this could be, since these packets don’t appear to be the result of anything that we wrote.

[0.3] (Not AX.25)WJ2XOY<0x00>KIOO7Y<0x00><0x03><0x00>E<0xbc><0x98><0x82><0x04><0x17><0x9b><0x82><0xd1>

dest +%,’, 0 c/r=0 res=0 last=0
source %$’'e, 0 c/r=0 res=0 last=0
000: 57 4a 32 58 4f 59 00 4b 49 4f 4f 37 59 00 03 00 WJ2XOY.KIOO7Y…
010: 45 bc 98 82 04 17 9b 82 d1 E…

If I try to decode the CSP header, I get the following, which doesn’t make sense, so I’m not sure what to do with this information either.

45 bc 98 82
10 - priority: 2
00101 - source node: 5
10111 - dest. node: 23
100100 - dest. port: 36
110001 - source port: 49
0000 - reserved: 0
010 - ??

2 Likes

Sarah,

thanks for all that informations, it will really help!
First of all: I told you about the KISS format which indeed is misleading your interpretations. Scott’s frame actually is forwarded in KISS format! You need to “un”-KISS it prior to decoding. Scott’s frame after unKISSing contains the following AX.25 frame:

00000000  57 4a 32 58 4f 59 00 4b  49 4f 4f 37 59 00 03 00  |WJ2XOY.KIOO7Y...|
00000010  0b d7 09 40 6b 26 08 77  94 67 4a 1c 7d 6e d3 f6  |...@k&.w.gJ.}n..|
00000020  f2 6e d5 b1 d2 39 15 52  55 19 85                 |.n...9.RU..|
0000002b

or, to use it directly as hexlified array:

574A32584F59004B494F4F37590003000BD709406B26087794674A1C7D6ED3F6F26ED5B1D2391552551985

Decoded CSP Header:

Screenshot_2020-03-01_09-24-18

Now one of the frames that were demodulated by @fredy:

00000000  57 4a 32 58 4f 59 00 4b  49 4f 4f 37 59 00 03 00  |WJ2XOY.KIOO7Y...|
00000010  45 bc 98 82 04 17 9b 82  d1                       |E........|
00000019

or hexlified:

574A32584F59004B494F4F375900030045BC988204179B82D1

Decoded CSP Header:

Screenshot_2020-03-01_09-22-19
So they are indeed different. There is a third (or fourth including the normal hk: healthbeacon) which is even shorter!

00000000  57 4a 32 58 4f 59 00 4b  49 4f 4f 37 59 00 03 00  |WJ2XOY.KIOO7Y...|
00000010  cb 75 43 30 00 00 01 e8                           |.uC0....|
00000018

or hexlified:

574A32584F59004B494F4F3759000300CB754330000001E8

Decoded CSP header:

Screenshot_2020-02-28_22-49-54

Now there are at least four known frames to deal with.
I’ll try to dig a bit deeper with new frames dropping in!

Let me know if you need more explanations on the KISS format or the decoding - whatever help is needed!

3 Likes

Three more frames by direwolf from observation 1778625:

[0.3] (Not AX.25)WJ2XOY<0x00>KIOO7Y<0x00><0x03><0x00><0x0a><0xa3><0xc7><0x11><0x00><0x00><0x04><0x01><0x00><0x00>rssi_offset<0x00><0x00><0x00><0x00><0x02><0x05><0x02><0x00><0x00>max_temp<0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x04><0x0d><0x04><0x00><0x00>bgndrssi_ema<0x00><0x00><0x00><0x08><0x00><0x01><0x00><0x00>csp_node<0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x09><0x10><0x01><0x00><0x00>i2c_en<0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x0b><0x10><0x01><0x00><0x00>can_en<0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x0c><0x10><0x01><0x00><0x00>extptt_en<0x00><0x00><0x00><0x00><0x00><0x00><0x0d><0x10><0x01><0x00><0x00>led_en<0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x0e><0x04><0x01><0x00><0x00>kiss_usart<0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x01><0xb8><0x16><0x04>p<0xa3>
------
 dest    +%,',  0 c/r=0 res=0 last=0
 source  %$'' c/r=0 res=0 last=0
  000:  57 4a 32 58 4f 59 00 4b 49 4f 4f 37 59 00 03 00  WJ2XOY.KIOO7Y...
  010:  0a a3 c7 11 00 00 04 01 00 00 72 73 73 69 5f 6f  ..........rssi_o
  020:  66 66 73 65 74 00 00 00 00 02 05 02 00 00 6d 61  ffset.........ma
  030:  78 5f 74 65 6d 70 00 00 00 00 00 00 00 04 0d 04  x_temp..........
  040:  00 00 62 67 6e 64 72 73 73 69 5f 65 6d 61 00 00  ..bgndrssi_ema..
  050:  00 08 00 01 00 00 63 73 70 5f 6e 6f 64 65 00 00  ......csp_node..
  060:  00 00 00 00 00 09 10 01 00 00 69 32 63 5f 65 6e  ..........i2c_en
  070:  00 00 00 00 00 00 00 00 00 0b 10 01 00 00 63 61  ..............ca
  080:  6e 5f 65 6e 00 00 00 00 00 00 00 00 00 0c 10 01  n_en............
  090:  00 00 65 78 74 70 74 74 5f 65 6e 00 00 00 00 00  ..extptt_en.....
  0a0:  00 0d 10 01 00 00 6c 65 64 5f 65 6e 00 00 00 00  ......led_en....
  0b0:  00 00 00 00 00 0e 04 01 00 00 6b 69 73 73 5f 75  ..........kiss_u
  0c0:  73 61 72 74 00 00 00 00 00 00 00 00 00 00 01 b8  sart............
  0d0:  16 04 70 a3                                      ..p.
------


[0.4] (Not AX.25)WJ2XOY<0x00>KIOO7Y<0x00><0x03><0x00><0x0a><0xa3><0xc7><0x11><0x00><0x0f><0x04><0x01><0x00><0x00>gosh_usart<0x00><0x00><0x00><0x00><0x00><0x10><0x00><0x01><0x00><0x00>i2c_addr<0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x12><0x01><0x02><0x00><0x00>i2c_khz<0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x14><0x01><0x02><0x00><0x00>can_khz<0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x18><0x01><0x02><0x00><0x00>reboot_in<0x00><0x00><0x00><0x00><0x00><0x00><0x1c><0x02><0x04><0x00><0x01>tx_inhibit<0x00><0x00><0x00><0x00><0x00><0x20><0x00><0x01><0x00><0x00>log_store<0x00><0x00><0x00><0x00><0x00><0x00>!<0x00><0x01><0x00><0x00>tx_pwr<0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x00><0x00>$<0x02><0x04><0x00><0x00>bcn_interval<0x00><0x00><0x00><0x00><0x00><0xb4><0x00><0x00><0x01><0xb8><0xa3>9(<0xee>
------
 dest    +%,',  0 c/r=0 res=0 last=0
 source  %$'' c/r=0 res=0 last=0
  000:  57 4a 32 58 4f 59 00 4b 49 4f 4f 37 59 00 03 00  WJ2XOY.KIOO7Y...
  010:  0a a3 c7 11 00 0f 04 01 00 00 67 6f 73 68 5f 75  ..........gosh_u
  020:  73 61 72 74 00 00 00 00 00 10 00 01 00 00 69 32  sart..........i2
  030:  63 5f 61 64 64 72 00 00 00 00 00 00 00 12 01 02  c_addr..........
  040:  00 00 69 32 63 5f 6b 68 7a 00 00 00 00 00 00 00  ..i2c_khz.......
  050:  00 14 01 02 00 00 63 61 6e 5f 6b 68 7a 00 00 00  ......can_khz...
  060:  00 00 00 00 00 18 01 02 00 00 72 65 62 6f 6f 74  ..........reboot
  070:  5f 69 6e 00 00 00 00 00 00 1c 02 04 00 01 74 78  _in...........tx
  080:  5f 69 6e 68 69 62 69 74 00 00 00 00 00 20 00 01  _inhibit..... ..
  090:  00 00 6c 6f 67 5f 73 74 6f 72 65 00 00 00 00 00  ..log_store.....
  0a0:  00 21 00 01 00 00 74 78 5f 70 77 72 00 00 00 00  .!....tx_pwr....
  0b0:  00 00 00 00 00 24 02 04 00 00 62 63 6e 5f 69 6e  .....$....bcn_in
  0c0:  74 65 72 76 61 6c 00 00 00 00 00 b4 00 00 01 b8  terval..........
  0d0:  a3 39 28 ee                                      .9(.
------


[0.4] (Not AX.25)WJ2XOY<0x00>KIOO7Y<0x00><0x03><0x00><0x0a><0xa3><0xc7><0x11><0x00>(<0x02><0x04><0x00><0x00>bcn_holdoff<0x00><0x00><0x00><0x00>,<0x01><0x02><0x00><0x00>max_tx_time<0x00><0x00><0x00><0x00>.<0x01><0x02><0x00><0x00>max_idle_time<0x00><0x00>0<0x0e>`<0x00><0x00>csp_rtable<0x00><0x00><0x00><0x00><0x00><0x00><0x01>h<0x00><0x00><0x01><0xb8><0x98><0xde><0xd1>J
------
 dest    +%,',  0 c/r=0 res=0 last=0
 source  %$'' c/r=0 res=0 last=0
  000:  57 4a 32 58 4f 59 00 4b 49 4f 4f 37 59 00 03 00  WJ2XOY.KIOO7Y...
  010:  0a a3 c7 11 00 28 02 04 00 00 62 63 6e 5f 68 6f  .....(....bcn_ho
  020:  6c 64 6f 66 66 00 00 00 00 2c 01 02 00 00 6d 61  ldoff....,....ma
  030:  78 5f 74 78 5f 74 69 6d 65 00 00 00 00 2e 01 02  x_tx_time.......
  040:  00 00 6d 61 78 5f 69 64 6c 65 5f 74 69 6d 65 00  ..max_idle_time.
  050:  00 30 0e 60 00 00 63 73 70 5f 72 74 61 62 6c 65  .0.`..csp_rtable
  060:  00 00 00 00 00 00 01 68 00 00 01 b8 98 de d1 4a  .......h.......J
------

The signal is visible in a couple of observations of Phoenix and QARMAN, TLE analysis will follow on the other thread.

3 Likes