Phoenix frames decoding

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

Wonderful! What you are looking at is the system configuration for the AX100. We blasted packets at Phoenix yesterday to collect this table, as we were afraid that our routing table was reset, which would have prevented our OBC from communicating with the AX100. We didn’t receive these packets, but I am glad that someone did!

@fredy Could you please post this demodulated data in the observation? The observation just shows the waterfall and audio file for now. It just helps me to keep track of when Phoenix is heard from.

1 Like

@DL4PD Out of curiosity, have you ever worked with/programmed the AX100 personally, or have you mainly worked with other teams who have used it? We want to send a few CSP packets to Phoenix’s AX100 to change the routing tables, since these were reset.

We are hoping that changing these back to what they were will allow us to regain control and resume operations. However, we are having a bit of trouble with the fletcher16 checksum, so I’m trying to reach out to others who might be able to help us better understand how to structure this CSP packet. Even if not, I could post the portion of the Ax100 user manual which discusses this here and we can see what sense we can make of it.

2 Likes

I have never had access to one yet! From experience I would like to say that it would be possible to help you out. A manual is mandatory for this. If it is in some case of NDA, we might be able to talk about that via PM.

2 Likes

Hi Sarah,

I have a GS100 (2x AX100s) as well as the AX100 in the Bobcat-1 cubesat (mostly assembled, currently working on the OBSW development) accessible to me. Unfortunately our ground station is currently out of commission while we replace the coax and rotator so I can’t help track/transmit, but I can still capture IQ recordings from our AX100s if that would be helpful to you. Or, let me know if I can help in some other way.

Kevin

4 Likes

@phasewrap we have an EM AX100 unit that we are testing with. We are trying to understand how to change the routing tables using a CSP command. Specifically, we want to send a ‘RPARAM_SET’ command to change the routing settings in table 0. If you have any experience with this, we would be happy to hear your advice on how to develop the command with the proper checksum.

1 Like

@fredy @DL4PD @phasewrap we used the magic checksum to try and reset the routing tables on our ax100. we weren’t able to receive a response at our ground station, but that doesn’t mean it didn’t work. if you guys observe any packets from Phoenix, please let me know.

4 Likes

@fredy @DL4PD updated on Phoenix: we have tried resetting the system configuration for Phoenix in hopes of regaining control. However, this didn’t appear to set things back to normal. Over the next week or so, we are going to take a more systematic approach to figuring out what conditions allow us to establish consistent 2 way communications with Phoenix. Our transceiver has its own health beacon that we are going to try to turn on so that Phoenix is easier to track. After that, we plan to try changing things further once we have a better understanding of what’s going on.

We still aren’t 100% sure which TLE belongs to Phoenix. It’s difficult to confirm whether it is ID 45258 or 45257, since both TLEs are very close to one another. As observations of Phoenix are scheduled over the next week, I was thinking that it might be best to alternate between both TLEs to see if one is better at picking up the health beacon compared to the other. Could we do this?

2 Likes

I would like to suggest that you might try to make any transmissions more frequent, no matter what is transmitted. Ikhnos will be able to help identify the correct norad ID once we can see more packets in a pass!

Did you, btw, get an answer from your engineers how they were able to make the ax.25 header that faulty?

2 Likes

If we are able to get the automatic health beacon to start, the plan would be to have this go off in intervals of 30 seconds so that the conditions are similar to how Phoenix would normally operate (power-wise), considering that we have no way of knowing the battery’s power level. Do you think that interval would be alright?

I haven’t been able to look into the AX.25 header yet, but I’ll try to get that done today.

3 Likes

That interval would be perfect! What I wanted to suggest is: if you can’t make the health beacon work, just pick any other beacon and set it to that interval - if possible! :slight_smile:

I don’t really know how the rf routing is working in the GomSpace chain and if there are any health checks on the ax.25 encapsulation in any case. If so: that might be one of your problems. I doubt the flight hardware really cares about that, it’s just an idea that came up…

2 Likes

@sarah_srogers I’ve noticed some signals above Australia stations that are fitting some TLE (different from the ones we track for Phoenix) and have an interval of 40s. Could it be possible that the interval is not 30s but 40s?

More details on those observations will come after finishing my analysis.

3 Likes

That seems unlikely, though if we got a few bit flips while changing the table settings, then perhaps. These are monitoring our frequency at 437.35 MHz?

2 Likes

https://network.satnogs.org/observations/1818921/ here is visible in waterfall around 80s but more visible in audio waveform where more signals are visible.

Also noticed in audio waveform of this one https://network.satnogs.org/observations/1818686/.

For checking audio waveforms I’ve used audacity.

The signal on the first observations fits better on objects 45260 and 45261.

2 Likes

There is also another report for an unknown object on almost the same frequency with QARMAN from JA0CAW which maybe is Phoenix:

Note: the time in the images is local… the UTC time is 23:00UTC

2 Likes