Transferring Rotor and Radio data to another program?

Hi,
I am currently writing code that automatically downlinks data from noaa through an sdr, then processes the data through wxtoimg. I was hoping to use gpredict to do all the calculations for the rotor and radio dopler shift however I want to control the rotor and radio through the code im writing (in c++). I was wondering if there is a way to transfer the data gpredict would send to the radio and rotor to my program instead. My only thought as to how would to run it through a port on my local machine, but I have ran into alot of issues with that. I was wondering if I was missing something that would make this process alot easier.

Could you write a hamlib drive for your specific program (ie, instead of selecting a rotator to send antenna commands to, it goes to your software, and instead of sending tuning commands to a rig, it goes to your software).

Another layer of complexity, I guess. Just a thought from a guy who’s last proficient programming language was Fortran 77…

I’d echo the above and suggest that implementing a subset of the rotctld and rigctld protocols would probably be the best option.

These protocols really are simple. For rotctld:
p\n - Request position from rotator (rotator returns: \n \n )
P \n - Set rotator position

For rigctld:
f\n - Request frequency from radio (Radio returns <freq_hz>\n)
F <freq_Hz>\n - Set radio frequency

1 Like

I actually have a similar question/situation (an FT-736r which is poorly served by hamlib, and a switched array rather than turnable antennas.)

I’m sure lots of homebrewers probably have similar one-off needs that probably aren’t really worth including in hamlib.

Would it be possible instead for gpredict to have a general purpose UDP broadcast interface (Similar to wsjt-x) which simply sends the current satellite Name/Az/EL/Up_freq / Dl_freq, Up_Mode, Dl_Mode, Doppler (and frequency information if it is known) via an Easycomm compliant string, or something similar?

This essentially lets gpredict be the tracking engine it excels at without having to tie itself tightly to other automation needs.

Thanks for any consideration

–al
WB1BQE

I have this setup too (running on a raspberry pi). I also have an FT-736r which has other challenges (see my comments further down the thread.)

For the antena piece, I wrote a little python hack to impersonate rotorctld and capture az/el data to drive my “rotor” (really a switched array). It was really easy to grab the az/el data, and the protocol to keep gpredict happy was only 4 commands. (It sends a "get position, then a series of set positions followed by a stop and quit.)

Less easy is getting the frequency data from what I have seen so far, since I think it comes out in dribs and drabs, not as a full data block. In particular, I don’t think the satellite NAME gets sent anywhere to hamlib, which could be the key to an intermediate program adding lots of value to the radio communication interface.

–al
WB1BQE