I’m working on integrating the satnogs client with the existing software I’ve written for the Bobcat-1 ground station, and I have a question. I intend on running the satnogs client on a Pi and having it interface with rotctld and a USRP over the network. My hope is that when Bobcat-1 is not overhead (or about to be overhead), SatNOGS has control over the ground station rotator and access to the radio. However, when Bobcat-1 is or is about to be overhead, I need to be sure that the satnogs client could not interfere with our operations. Can I somehow tell SatNOGS Network that our ground station is unavailable for scheduling during Bobcat-1 passes? I don’t want to simply change the rotctld port and deny it access to the radio at risk of frustrating other users and raising the failure rate.
Thanks for bringing this up. There was a discussion almost 1.5 years ago about it. Unfortunately it remained a discussion with some issues opened. But I think we can give some more priority to these issue to be implemented/fixed. Here is the suggestion I had written, any feedback/comments are more than welcome:
Hello everyone!
I’ve started to check and implement fixes and features for station status and availability in network.
My plan is to have one status and two different properties:
Status: online or offline , this will be automatically changed to online when client requests jobs from network and to offline when client hasn’t requested jobs from network for X time.
Properties:
Testing: true of false , this will be manually changed by the station owner in the station settings and will show if the station is under development/testing or ready for being fully utilized.
If the status of the testing station is online, then the owner will be able to schedule observations. Access for scheduling will be also available to admin for test/debugging reasons or in case of special events (new deployments, scheduled contacts, requests for helping receiving a satellite etc).
Availability: true or false , this will be also manually changed by the station owner. However owner will be able to schedule availability (or better downtime), in this case network will automatically change the availability when the time comes. True means that observations can be scheduled for this station, False means that no observations can be scheduled for the station and that if there were any scheduled ones will be removed.
When a change happens in one of the above then it will be logged in the station log with details, in order to keep track.
Please let me know if you have any objections/ideas/feedback on my plan.
Finally, as a workaround until this is implemented, you can stop locally the satnogs-client by running: sudo systemctl stop satnogs-client
Then you will need to remove the future observations that are scheduled for the period that the station will be offline. If there is any removal it would be great if you can communicate this removal to the observers that have scheduled the observations if this is possible.
For restarting the satnogs-client just run: sudo systemctl start satnogs-client
Thanks Fredy! Good to hear this was previously discussed – hopefully we can bring these features to fruition now.
Adding availability as a property is a great solution. Ideally this is exposed via an API somewhere and I can tell the system a couple days in advanced when our ground station is going to be unavailable. It would be nice for it to be configurable to “default available” or “default unavailable”.
Bobcat-1 will not launch till early August, and until then I can devote nearly all of the ground station time to SatNOGS.
Just wondering if any more progress has been made on this topic. As you saw in the chatroom yesterday, our ground station is almost ready to go back on the SatNOGs network, hopefully within the next day or two. My involvement with the cubesat and groundstation will be ending within the next couple months when I graduate so I am hoping to have the SatNOGs integration done soon so the rest of the team can just leave it running without much thought.