@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.
@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?
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?
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.
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!
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…
@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.
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?
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.
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
It’s really difficult to say whether the unknown object is Phoenix. The transceiver should have reset its system configuration automatically today, as this occurs every 2 days. When it does this, it transmits out a packet to indicate the watchdog has been reset. That could be what that packet was, but without seeing anything decoded I cannot be certain. I don’t think 2 packets should be transmitted for that though, but I could inquire with Gomspace about that.
Regarding the AX.25 header getting messed up, we don’t currently understand what caused this to happen. We don’t set the AX.25 header in the flight code. We transmit our message in ascii format using csp_send. If the AX100 is supposed to create its own ax.25 header, I don’t know how it’s appended to this. I might have to open a conversation with Gomspace to understand this further.
in general, regarding the TLE for Phoenix, we have established very limited two-way communications with the cubesat by tracking TLEs 45257 and 45258, but we aren’t sure which one is the right one. That’s why I find it a bit difficult to believe that 45260 or 45261 is Phoenix’s TLE.
We tracked 45258 for the most recent pass over ASU, but did not receive anything back. We will try tracking 45257 next to see if that produces anything different.
Oops I missed to answer the two questions bellow:
Unfortunately I can not add any demodulated frame from direwolf in the data of an observation, as direwolf doesn’t give any timestamp on when the frame was demodulated. However I can add here a list of all the observations that have demodulated frames and keep it updated, does this work for you?
For now choosing any of those two object doesn’t make any significant difference, especially for receiving as they are close enough to be visible at the same time from a station. Check the Gpredict screenshot bellow and see how close are RA and RB OBJECTS:
Yeah, but you somehow must have set the source and destination callsigns. I think that the GomSpace radio supports this correctly, because we can see a lot of satellites where this is not an issue…
Sarah, can you please confirm if you are operating the AX100 in mode 6 or another mode?
We are operating in mode 6.
I see. Just having a thread of which observations have demodulated frames would work just fine! It’s just difficult to tell from the waterfalls sometimes. A lot of the waterfalls look to me like they are displaying QARMAN packets at an interval of 2 minutes.
Thank you for the object clarification as well. We don’t have a qualitative value on what the spacing between cubesats needs to be before the Doppler shift starts to affect the success of establishing two-way communication with Phoenix.
PHOENIX RAW Telemetry, Interval 30 sec:
2020-03-29 12:56:19.260 UTC: [78 Bytes KISS Frame (without CRC)]
1 > C0 00 57 4A 32 58 4F 59 00 4B 49 4F 4F 37 59 00 03 00 CA A7
21 > DB DC 00 FF E0 FF E1 00 00 00 00 00 00 00 04 00 00 00 16 00
41 > 00 00 E8 00 00 01 46 02 C3 21 00 00 00 01 B9 FC BB D2 FF 8C
61 > 00 00 01 C5 FC 00 04 EE B6 00 35 75 B0 00 55 B6 85 C0
@sarah_srogers this is a KISS frame - remember to “unkiss” before interpreting!
Thanks so much for alerting us of this, Vlad! I’ve decoded the packet, and it appears that we have managed to turn on the AX100’s auto hk beacon. I’ve posted this below
Removing the AX.25 header and the KISS wrapping, this packet is decoded as follows:
CSP Header: CA A7 DB DC 00 --> actually CA A7 C0 00 due to KISS framing protocol
Decoding the CSP header tells us this packet comes from node 5, port 0 - ax100 control port, which is also used for sending out telemetry packets.
FF E0 - board temp = 65504 --> 65.504 degC (note: at our AFT range, expected from models max allowable temp = 85C)
FF E1 - PA temp = 65504 --> 65.505 degC
00 00 - last rssi = 0 (common value)
00 00 - last rferr = 0 (common value)
00 00 00 04 - tx_count = 4 (count since reboot)
00 00 00 16 - rx_count = 22
00 00 00 E8 - tx_bytes = 232
00 00 01 46 - rx_bytes = 326
02 - active_conf = 2
C3 21 - boot_count = 49953 (lol)
00 00 00 01 - boot cause = 1
B9 FC BB D2 - last_contact = 3120348114 (timestamp of last valid packet)
FF 8C = bgnd_rssi = -116 (using 2’s complement, common value)
00 = tx_duty = 0 (total tx duty time since reboot, common)
00 01 C5 FC - tot_tx_count = 116220 (expect to be high)
00 04 EE B6 - tot_rx_count = 323254
00 35 75 B0 - tot_tx_bytes = 3503536
00 55 B6 85 - tot_rx_bytes = 5617285
This is an excellent first step for us. We haven’t managed to establish contact with our OBC yet, but hopefully this is a step in the right direction.