Provide tracking data thorugh other interfaces

[csete]

Often, users request support for making tracking data avaialble through a more versatile interface than what is currently available through the rigctld and rotctld interface. We could use the EasyComm II standard to provide such data through TCP and UDP, see attached specification.

easycomm.txt

[mdblack98]

I can think of a way to do this via hamlib. Perhaps allow apps to set "tags" that could be read by clients. So do something like a format of "tag=val\tunits" \set_tag az=180.00\tdegrees \get tag az az=180.00\tdegrees \set_tag uplink=145000000\tHz \get_tag uplink uplink=145000000\tHz \set_tag downlink=455000000\tHz \set_tag doppler=5\tHz \get_tag doppler doppler=5\tHz uplink=145000000\tHz Function to get all tags that have been set -- pipe delimited answer \get_tags az=180.0\tdegrees|uplink=145000000\tHz|downlink=455000000\tHz

And a tag for gpredict mode too

Using \t as the field separator on the tag will also allow for strings to be set

Mike W9MDB

[magicbug]

Often, users request support for making tracking data avaialble through a more versatile interface than what is currently available through the rigctld and rotctld interface. We could use the EasyComm II standard to provide such data through TCP and UDP, see attached specification.

easycomm.txt

Pleased to see this as I was about to ask so I can populate data from Gpredict into my Cloudlog Project easycomm via UDP would suit me!

[mdblack98]

What data items are you looking to get? Mike W9MDB

On Saturday, January 30, 2021, 11:20:36 AM CST, Peter Goodhall <notifications@github.com> wrote:  

Often, users request support for making tracking data avaialble through a more versatile interface than what is currently available through the rigctld and rotctld interface. We could use the EasyComm II standard to provide such data through TCP and UDP, see attached specification.

easycomm.txt

Pleased to see this as I was about to ask so I can populate data from Gpredict into my Cloudlog Project easycomm via UDP would suit me!

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe.

[magicbug]

Mike nothing too exciting

Uplink Freq, Mode, Downlink Freq Mode Satellite Name

I just use it to repopulate log fields saves manually doing it, for SatPC32 I grab the DDE feed and rip it out of that.

[mdblack98]

So if I provide a generic tag field in hamlib, and we can get gpredict to set them, then can you pull them via hamlib and do whatever you want with them? e.g. broadcast via UDP or just pull them from rigctcld.

Mike W9MDB

[magicbug]

I can work with that Mike

[mudhwk]

HI Mike, I was the originator of this request. My preference would be an easycomm string via UDP (Similar to what WSJT-x does with UDP). I'm looking to insert an application in between gpredict and hamlib to make some other more advanced, but qth specific decisions around rig control and antenna configuration. If this is implemented via hamlib, I would need to impersonate Hamlib (as I currently do for rotctld). A UDP solution would allow multiple clients (including hamlib) to see and act on the data.

Specifically, I'm looking for:

Uplink Freq, Mode, Downlink Freq Mode Satellite Name azimuth elevation Doppler shift at a reference (beacon?) frequency (Extra credit: CTCSS uplink and downlink tones, although I can derive these myself based on the SAT Name.)

The old easycomm string that WISP used to send would be perfect!

In any case, if the implementation is not easycomm, please send ALL the data at once each time, rather than sending radio specific commands with just the changes.
Thanks! -al WB1BQE

[mdblack98]

OK...so here's the plan Gpredict can send these 5 easycomm commands and any time one of these commands is received by hamlib will send out a UDP packet containing them all...UDP data will be simple ASCII in easycomm format. It will be UDP on port 4532 (the same port as hamlib uses for TCP). Will be able to support multicast. AZ EL UP DN UM DM

[csete]

I mentioned the Easycomm protocol because that is what people often mention and there seems to be a lot of hardware and software that readily supports it. My current thought is to add it as a new option where users can select which data to export and how to make it available (TCP, UDP, multicast), and keep the existing radio and rotator interfaces as they are.

[mudhwk]

Morning Everybody!

From my perspective, I would prefer to be an unworthy peer of Hamlib, rather than a client, but I'll happily consume data from anybody who can put it on a port for me.

I could minimally live with the list Mike outlined above (although I think he inadvertently omitted the uplink mode), but I REALLY would like the satellite name, as well as some means of knowing the current doppler shift value at 100 MHz, or some other frequency (Beacon?) that I could proportionally scale as needed. (Gpredict has both of these pieces of information in the UI, but from looking at the interface protocol, I don't think they get passed to hamlib.)

Knowing the satellite name allows me to cover the following important use cases:

1) I can make intelligent decisions on when to do a full setup (including a potential mode B<>Mode J band switch. 2) I can automate other non-rig/non-rotor tasks such as turning on preamps, and choosing the desired antennas for each type of satellite. . (I have computer driven antenna switches that "do the right thing" based on operating frequency/mode for both satellites and repeater use.) 3) I can decide to listen to a satellite or not based on its name 4) I can launch an appropriate telemetry copying/logging application and/or switch between beacon and voice modes 5) I can automate CTCSS Entry Tone needs for some of the FM Satellites.

Knowing the Doppler shift at 100 mhz, I can ignore the tuning frequencies from gpredict (if I choose to) and apply my own corrections for use with receive converters and possibly drive an external SDR alongside the radio etc. It would also make it much easier to switch between beacon and general operating modes during a pass.

I'm pretty excited to see this getting some interest!

Thanks! :)

--al WB1BQE

[mdblack98]

Modified the list to include uplink mode. See the hamlib issue I've created here https://github.com/Hamlib/Hamlib/issues/517 We would have to extend the easycomm API to add more items. hamlib doesn't anything about doppler as there no rigs that provide that info and we are rig-centric. Perhaps SN -- satellite name D1 -- doppler#1 -- or some appropriate name here... D2 -- doppler#2 Can you attach a screen snapshot of the doppler items that you mention?

Mike W9MDB

[mdblack98]

Adding it to gpredict makes more sense...and more generic...hamlib could be a client then on multicast if I wanted to utilize that data in hamlib.

[mudhwk]

HI Mike,

Thanks so much for adding the satellite name - that's huge!

The "reference doppler" is something I picked up from Gpredict. It appears on the UI as "Doppler @100M". Winorbit had something similar that I used back in the day, and I used to trick Wisp into supplying this for analog satellites when needed by configuring for the beacon frequency, and just adding/subtracting what wisp gave me from the known value. (I kept my own satellite config files, so I could look up additional information based on the satellite name.) I could certainly do this again based on the satellite name and be fine, if that's easier. (This is 25 year old software that's long past its prime, so I really want to frame my asks in terms of stuff that other more modern users can leverage.)

The exact use case here is an FT-736r with a mode J uplink and a mode S downlink (via a receive converter with a 2 meter output.) In this case, presumably, I would be essentially configuring the software to transmit on 435.xxx mhz and receive on 145.xxx mhz, although the doppler correction value for 2.3 ghz would be far bigger than what what one would normally apply to a 2 meter signal.)