thanks for the post_write_delay tip. I do have that setup and while it has slowed down the updates, it seems to keep sending them after the satellite pass. I’m wondering if all the commands are buffered and this just drags out how long it takes to send them versus skipping updates when they aren’t necessary. Thoughts on how this works or what your experience is?
I’ll add that my rtl dongle issue seemed to be related to the usb/port or RPI power supply i was using. I unplugged the rotor control and it sprang to life, then when i re-added the rotor it still worked. I changed usb ports was about all i did. Odd, but it seems to be working now. Let’s try an observation…
Nope… it tracked it, but something went wrong with post-processing it or uploading.
The log has stuff like this…
redis.exceptions.ConnectionError: Error 111 connecting to None:6379
2017-07-16 00:41:16,329 - apscheduler.executors.default - ERROR - Job “post_data (trigger: interval[0:02:00], next run at: 2017-07-16 00:43:16 UTC)” raised an exception
Traceback (most recent call last):
File “/usr/lib/python2.7/site-packages/apscheduler/executors/base.py”, line 125, in run_job
retval = job.func(*job.args, **job.kwargs)
File “/usr/lib/python2.7/site-packages/satnogsclient/scheduler/tasks.py”, line 102, in post_data
for f in os.walk(settings.SATNOGS_OUTPUT_PATH).next()[2]:
StopIteration
Well I will need to let the SatNOGS developers help with the data issues. I had to get help to get my station working. I did have a problem with power early on. Seems the Raspberry Pi3 and the RTL Dongle were a little too much for the power supply I was using. The RTL dongle gets warm just sitting on desk. After upgrading the PS the system is very reliable.
Regarding the SatNOGS client implementation of the rotor control function. It is a little strange when compaired to applications like SatPC32 or PSTRotator and initially it would crash my rotor system interface controller. I had to do a few things in the controller code to work around the SatNOGS implementation. Because the client system continually sends move commands through rotctld, even to the current location, rapid fire, over-and-over again, and it never issues a get position command, it caused problems in my controller design.
I had not noticed that at the end of a tracking operation, that the client was still sending move commands, I would assume the commands are to the same and final location of that tracking pass. I do now that once a tracking operation was finished, that the client leaves the antenna at what ever position it was at when the satellite tracking was over. I added to the rotor controller the intelligence to re-home it’s self after one minute of no communication from the host. this way the rotor system can re-calibrate for tracking errors between passes. Being the developer of the Rotor System I am using for my SatNOGS ground station, I can change the code in the Rotor Controller as needed.
The rotor system was developed for portable ham satellite tracking but also fits well into the SatNOGS environment.
Cheers!