Hi, everyone,
My team and I have a CubeSat which is scheduled to deploy from the ISS come mid-Feb. We would love as much help as possible with tracking our spacecraft post-deployment to verify that it is alive and well. I figure this forum would be one place to share any information that people would need to hear from our CubeSat, but does anyone know of any other resources that would allow me to spread the word about this? Any advice would be greatly appreciated!
Cheers,
Sarah
Hello Sarah,
Welcome to the community!
Some of the initial information would be:
The first one will be used for adding the satellite in DB. From 2 to 4 will be used to add transmitters on the DB entry and will allow us to schedule observations and demodulate frames. The last one will help to create a decoder and a dashboard in our grafana instance like this one.
I think, there are some basic info:
http://phxcubesat.asu.edu/subsystems/communications
t.janos
Hi, all,
Thanks for the replies! The link @tjanos posted is, in fact, our project.
To answer your questions,
1: Satellite name: Phoenix CubeSat (website: phxcubesat.asu.edu)
2. 1 transceiver (UHF amateur frequencies). We are using the AX100 from Gomspace
3. Frequency: 437.35 MHz
4. baud: 9600
other information: packets follow the KISS and AX.25 protocols
Regarding decoding instructions, we have been using a Kantronics TNC and an ICOM 9100 radio to receive our data and our ground station code to decode the packets. We are posting our ground station code to our website soon to give this info to others. So far it appears that the best way to decode our packets is to use hardware and our ground station code.
We have tried using an RTL-SDR and software TNCs which use the sound card to decode the packets, but we haven’t had success with this yet. The SDR can pick up the signal fine, but the software TNC is unable to decode it. We’ve tried HS Soundmodem, AGWPE, and Direwolf without luck. I know 9600 baud packets are difficult to decode, however. Our plan so far is for people with SDRs to send us their recorded signal, and we can decode it to see if it is our spacecraft. I’m not sure if you might have additional advice there based on your experience.
IARU Coordination info is here: http://www.amsatuk.me.uk/iaru/finished_detail.php?serialnum=594
I am very sorry but your information is not 100% correct. Most probably you will be running the GomSpace Modem in “Mode 6”, which encapsulates a CCSDS RS encoded payload into AX.25 to meet HAM Bands requirements. For efficiency this is totally irrelevant. KISS is also not “supported” by that modem, because KISS is a protocol between TNC and PC. If you really run a decoder after demodulating AX.25 frames: you are wasting a huge amount of frames!
Please consider getting in touch with us to improve both sides: yours for improving data amount and also ours by of improving the network capabilities! Let’s combine forces also with the ESA team running OPS-SAT!
All the best,
Patrick
Hi, Patrick (@DL4PD) ,
Sorry for the late response here. To ensure that other amateur operators can monitor Phoenix in orbit, we have also been working on a way to decode packets from our engineering model of our AX100 radio using an SDR and other software based platforms. I have been able to configure gqrx and direwolf to display the incoming packets. The packets appear as just hex at the moment, but Direwolf displays the SRC and DST callsigns from the AX.25 header, so an operator can at least interpret that they are receiving packets from Phoenix with that information.
This is a start for users to decode our packets with a software-based setup, and I am working on taking this the rest of the way, as well as linking our ground software with this, which will not only allow amateur operators to see our packets, but also send basic “ping” commands to the spacecraft if they wish to interact with it. We’ve been moving our ground station to a new location over the past few weeks, though, so i’m not entirely finished with this however. In this regard, I believe I have mainly resolved the issues discussed in my previous post. It just took us a while to find the right software platform.
I have updated our website to include information on Phoenix’s transmitter as well as the decoding methods discussed above. You can see that here: http://phxcubesat.asu.edu/content/amateur-operations
If you have any suggestions to improve this setup, I would be happy to hear your thoughts. In addition, how would you recommend we proceed in combining forces with ESA?
Finally, @fredy does the content on our website provide enough information to get Phoenix registered in the SatNOGS database? If I can be more specific with an of the information provided, I would be happy to explain anything further.
If you could provide sample recordings I am sure we can help out a lot!
A telemetry structure description inside the ax.25 frames would also be neccessary.
We just uploaded a few sample I/Q recordings of a housekeeping packet and a simple “ping command” that amateur operators can send to our public GitHub repo. Hopefully these are able to help!
https://github.com/ASU-cubesat/phxsat-gsw-public/tree/master/Recordings
We have also included supporting documentation in this folder to describe the structure of each recording so you know what you should expect to see.
I should note that the a housekeeping packet recording just includes data from our EM AX100 transceiver, and is not the exact same hk packet that the satellite will usually transmit. We didn’t get the chance to record the spacecraft’s typical health beacon before delivery. We would need our OBC to recreate the satellite’s health beacon, and our only module flew with the spacecraft.