SAL-E 5-04-2026
5 Likes
Got strong signals for the first time today, uploaded 20 packets between 13:55 and 13:59 UTC and of course filled out the form for a QSL card.
I’ve noticed that the PID of the AX.25 packets is always 0xcc (ARPA Internet Protocol).
Since the decoder (cp16.ksy) discards the 29 bytes of IPv4 and UDP information, is the implementation of a layer 3 protocol by any purpose?
Daniel
2 Likes
Hi Daniel,
Yes, as you noticed, we use the IP stack. All of our packets, both for uplink and downlink, use IPv4 and UDP. For downlink, this information is used for our ground segment to determine where to send responses (based on the ip and port). Our communication processes (both onboard and on the ground) are built around the IP stack, so we use the same for the beacons for commonality.
In the case of beacons, we know it is a beacon if the destination IP is 224.0.0.1 and we also verify that satellite (source IP) is correct (the same as the satellite our ground station is tracking). I discarded the bytes since there is no need to actually store them, but I could modify the decoder to also verify those two IPs. Let me know if that would be beneficial.
Alex
5 Likes
Hi everyone,
I’ve finished making a dashboard for SAL-E and I’m excited to share it here! Huge thanks to @deckbsd for merging the decoder, @Fredy and @dl7ndr for helping with dashboard access, and everyone here for their continued observations and support!
https://dashboard.satnogs.org/d/afjyxg3eck64gc
I’m happy to take any questions or suggestions on the dashboard or mission
Alex
8 Likes
Hello, I am the co-lead of the Ground Station and Operations team at Cal Poly. To provide the wonderful SatNogs community with the data we downlink from SAL-E, we upload all received beacons to the SatNogs DB under our ground station’s callsign N6CP. However, due to an oversight in our script which collects packets to upload to SatNogs, we have unintentionally uploaded data from our engineering test unit which we keep in our lab, on the ground, for testing. The issue has since been corrected, but we are hoping a SatNogs DB administrator would be able to remove these packets from the database for SAL-E, as the data in them did not come from the actual flight unit on orbit.
Not sure who the right person to contact is about this, @fredy , we’ve appreciated all your help and SAL-E observations over the past month, would you be able to help us with deleting the bad packets?
These are the time stamps for the packets inadvertently uploaded by N6CP:
4/29/2026 22:56
4/29/2026 22:56
4/29/2026 22:56
4/29/2026 22:56
4/29/2026 22:56
4/29/2026 22:55
4/29/2026 22:55
4/29/2026 22:55
4/29/2026 22:54
4/29/2026 22:54
4/29/2026 22:54
4/29/2026 22:54
4/29/2026 22:53
4/29/2026 22:53
4/29/2026 22:53
4/29/2026 22:53
4/29/2026 22:53
4/29/2026 22:52
4/29/2026 22:52
4/29/2026 22:52
4/29/2026 22:52
4/29/2026 22:52
4/29/2026 22:52
4/29/2026 22:52
4/29/2026 22:51
4/29/2026 22:51
4/29/2026 22:51
4/29/2026 22:51
4/29/2026 22:51
4/29/2026 22:51
4/29/2026 22:50
4/29/2026 22:50
4/29/2026 22:50
4/29/2026 22:50
4/29/2026 22:49
4/29/2026 22:48
4/29/2026 22:48
4/29/2026 22:48
4/29/2026 22:48
4/29/2026 22:47
4/29/2026 22:47
4/29/2026 22:47
4/29/2026 22:47
4/29/2026 22:47
4/29/2026 22:46
4/29/2026 22:46
4/29/2026 22:46
4/29/2026 22:46
4/29/2026 22:46
4/29/2026 22:46
4/29/2026 22:46
4/29/2026 22:45
4/29/2026 22:45
4/29/2026 22:45
4/29/2026 22:45
4/29/2026 22:45
4 Likes
Sure, thank you for letting us know. I’ll check it in the next hours and remove all these frames.
2 Likes
All the 56 frames are now removed from DB and from influxdb (the database that Grafana uses for dashboards).
Let me know if you notice anything strange.
2 Likes