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.
Sarah,
Could you probably make that frame publicly available (maybe just paste it in here)?
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.ā¦Ć
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?
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)!
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.
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?
The frame was exactly the same, all hex values were the same.
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?
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?
Iāve split the topic, let me know if I need to change the topic to something better.
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.
Hm, I am decoding the exact sameā¦
Could you probably show where the difference is?
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....
------
This is indeed different!
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.
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.
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 - ??
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:
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:
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:
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!
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.