So the first SatNOGs controlled tracking operation at Ground Station N7IPY failed badly.
Rotor system started tracking and was going smoothly but once the highest part of the pass was approaching things failed. The system looked to be overloading the Rotor Controller with excessive movement commands. My assumption was that the serial buffer was being overrun with move commands. I will attach the Pi-3 / RTL SDR to my development Rotor system so I can see what’s happening with a protocol analyzers, First guess, as I am the developer is that rotctl is pounding the serial port with small move commands at a very fast rate. I will know more in a while when I have a chance to set up, capture and analyze the data…
Maybe someone can provide an answers to the way SatNOGs operates so I can better diagnose the issue:.
How does the network control frequency and rotor movement. is there a constant stream of data sent via the WAN to the ground station, or is it batched out to the ground station prior to a tracking session for autonomous operations?
Likewise is the raw data captured and uploaded to the SatNOGs network after a tracking session, or is it streamed live?
After a tracking session, how soon is the captured ‘data’ made available for processing?
Sorry for the questions and issues to be solved. Thanks - Will - N7IPY
Once a job is issued on the network, the client periodically fetches this “job” from the network and updates local schedule. When the time comes, it starts observing (i.e. controlling rotator through rigctl and spawning the gnuaradio to capture the audio/wf/data). The frequencies and pointing locations are calculated on the fly, locally in satnogs-client. Admittedly at a rate of more than 2Hz. That might be overloading your controller but there is always the option to add the argument write_delay on rigctld.
Data is captured and stored locally throughout the observation and then they are posted (through a periodic task) back to Network
Depends on the timing of the observation (within the posting intervals) and the upload bandwidth of your connection
Let me know if we can help you more debugging this!
I spent some time this afternoon capturing a few tracking operations with the instrumented Rotor System test bed here in the shop. Using your suggestion, I found that rotctl has a post command delay called ‘post_write_delay’ which seems to add a defined delay after each command sent out of the USB/Serial port. This worked to slow down the commands being issued, currently using 500ms.
What I found by looking at the trace data is:
rotctld never (at least I never found an instance) requests rotor position data, never sends a 'C2’command as defined in the GS232 protocol (rotctl ‘p’ command) so it looks like the client operates the antenna system blind.
rotctld sends the same move commands continuously until the next position change is needed, then starts the cycle of sending the same command over and over again.
Movement commands are in 1 degree increments. 1 degree moves while tracking an overhead pass are difficult at best. Pretty hard to start/stop the mechanical system at a 1 degrees increment fast enough to keep up with the satellite.
The Amateur Radio Satellite tracking applications like SatPC32, PSTRotator, Ham Radio Deluxe, etc., do not operate in this way. PSTRotator and HRD, continuously pole a Controller at a user defined interval, 0.5 to 2 seconds is common. Most use 1 second interval as default, SatPC32 poles antenna position only during a move operation. A move command is only issued once, where the programs seem to track the motion and of course display the antenna position to the user. Most folks run at 4 or 5 degree movement increments as the smaller antennas used just have that tight of a pattern that 1 degree is needed.
More analysis at my end is needed to see if I can get the system to operate in the SatNOGs environment.
Latest code changes worked last night as the system was able to simulate a tracking operation with a scheduled Satellite pass. The pass had an elevation of about 45 degrees so it was not as stressful as an overhead pass but the test stand tracked as expected. Our tracker design uses a return to home (turn to 000Az/000El) operation to re-calibrate its Azimuth and Elevation after every tracking operation to minimize drift errors in the mechanical system as we use small DC gear motors and not steppers. When the SatNOGS Client finishes with a tracking operation, it leaves the antenna where it was last moved to and lets the next operation turn it to the new heading and pitch. Because of this I added an auto return to home operation after 60 seconds of no commands received from the host. That and other functions have been modified to support the differences in the SatNOGS Client operation versus other Amateur Radio commercial satellite tracking applications.
More testing today and if all goes well, I will load the code up to the outside test system for some live testing; weather permitting.
Great update @N7IPY ! Thanks for sharing it. It would be great to check those additions to see how we can amend the satnogs-client to make it easier to work for amateur radio / manual passes.
