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.
@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.
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.
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 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.
@fredy@DL4PD@Kevin 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?
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.
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…
