locked WSJT-X Autogrid Feature Suggestion


Lawrence Dobranski
 

This is a future feature suggestion for JTAlert:

Support for WSJT-X Autogrid Feature

Provide the interface logic between a GPS NEMA position feed over RS-232 to set the transmitter GRID square via the WSJT-X Autogrid capability (on General Tab in WSJT-X).  

I am planning to do a lot of HF roving next summer, and not having to remember to reset my grid square would be fantastic.  I would also use it in VHF Rover contesting as well. 

I have found discussion on this feature from 2018 on the WSJT SourceForge wsjt-devel list.

Thanks for considering it.

Regards,

73 de VA3IQ

Lawrence


Joe Subich, W4TV
 

This belongs in WSJTX *not* JTAlert. Seek *full* support from the
developers of WSJTX.

73,

... Joe, W4TV

On 2021-10-01 11:42 AM, Lawrence Dobranski wrote:
This is a future feature suggestion for JTAlert:
*Support for WSJT-X Autogrid Feature*
Provide the interface logic between a GPS NEMA position feed over RS-232 to set the transmitter GRID square via the WSJT-X Autogrid capability (on General Tab in WSJT-X).
I am planning to do a lot of HF roving next summer, and not having to remember to reset my grid square would be fantastic.  I would also use it in VHF Rover contesting as well.
I have found discussion on this feature from 2018 on the WSJT SourceForge wsjt-devel list.
Thanks for considering it.
Regards,
73 de VA3IQ
Lawrence


Jim Brown
 

HamGPS (an Android app) displays a ten-digit Maidenhead locator, speed, and compass heading.


On Fri, Oct 1, 2021 at 1:45 PM Joe Subich, W4TV <lists@...> wrote:

This belongs in WSJTX *not* JTAlert.  Seek *full* support from the
developers of WSJTX.

73,

    ... Joe, W4TV


On 2021-10-01 11:42 AM, Lawrence Dobranski wrote:
> This is a future feature suggestion for JTAlert:
>
> *Support for WSJT-X Autogrid Feature*
>
> Provide the interface logic between a GPS NEMA position feed over RS-232 to set the transmitter GRID square via the WSJT-X Autogrid capability (on General Tab in WSJT-X).
>
> I am planning to do a lot of HF roving next summer, and not having to remember to reset my grid square would be fantastic.  I would also use it in VHF Rover contesting as well.
>
> I have found discussion on this feature from 2018 on the WSJT SourceForge wsjt-devel list.
>
> Thanks for considering it.
>
> Regards,
>
> 73 de VA3IQ
>
> Lawrence
>







Lawrence Dobranski
 

Some more details on how this is done are found here:  https://wsjtx.groups.io/g/main/message/28342.  In summary it uses a multicast IP group address in WSJT-X.

I am trying to avoid having to remember to re-set my Grid Square in WSJT-X as I rove in either a contest or when operating HF portable, for example when working something like the RAC Challenge "Coureur des bois" portable/field activity (like SOTA or POTA, etc.)  I try to minimize what I have to do at each rove location.  I have a checklist to follow, but I still miss things.  Hence wanting to automate it as much as possible.

Currently I set my system clock and get my grid square from  BktTimeSync:  https://www.maniaradio.it/en/bkttimesync.html

Since I have multiple consumers of my GPS data I am now looking at how to share the GPS data between platforms and devices and including the 1 PPS stream.  The GPSDO 10000 MHz stream gets routed to transverters and other devices.

I thought that JTAlert would be a good place for a basic method of taking the GPS stream and converting it to a format understood by WSJT-X.  If the consensus is no, that is fine.  My personal software is not designed to be portable or supportable.  I program in C and keep my code tight and specific.

73 de VA3IQ

Lawrence




Dave Garber
 

would you not be having the gps tell your pc the correct time, as wsjtx just gets it from the pc, not jtalert.  ( If I understand this )

Dave Garber
VE3WEJ / VE3IE


On Sun, Oct 3, 2021 at 6:50 PM Lawrence Dobranski <ldobranski@...> wrote:
Some more details on how this is done are found here:  https://wsjtx.groups.io/g/main/message/28342.  In summary it uses a multicast IP group address in WSJT-X.

I am trying to avoid having to remember to re-set my Grid Square in WSJT-X as I rove in either a contest or when operating HF portable, for example when working something like the RAC Challenge "Coureur des bois" portable/field activity (like SOTA or POTA, etc.)  I try to minimize what I have to do at each rove location.  I have a checklist to follow, but I still miss things.  Hence wanting to automate it as much as possible.

Currently I set my system clock and get my grid square from  BktTimeSync:  https://www.maniaradio.it/en/bkttimesync.html

Since I have multiple consumers of my GPS data I am now looking at how to share the GPS data between platforms and devices and including the 1 PPS stream.  The GPSDO 10000 MHz stream gets routed to transverters and other devices.

I thought that JTAlert would be a good place for a basic method of taking the GPS stream and converting it to a format understood by WSJT-X.  If the consensus is no, that is fine.  My personal software is not designed to be portable or supportable.  I program in C and keep my code tight and specific.

73 de VA3IQ

Lawrence




Jim Cooper
 

On 3 Oct 2021 at 15:50, Lawrence Dobranski wrote:

I thought that JTAlert would be a good place for a basic method of
taking the GPS stream and converting it to a format understood by
WSJT-X. 
Aren't you begging at the wrong tree?
My understanding is that JTalert cannot tell
WSJT-X to change any of it's basic information;
the grid setting in WSJT-X is set in the Settings,
and thus I presume in the .ini file ... which JTalert
can read, but not change.

Seems like you should be begging the WSJT-X
team to let your GPS stuff change the grid setting
IN wsjt-x ...

w2jc


HamApps Support (VK3AMA)
 

On 4/10/2021 11:06 am, Jim Cooper wrote:
Aren't you begging at the wrong tree?
My understanding is that JTalert cannot tell
WSJT-X to change any of it's basic information;
the grid setting in WSJT-X is set in the Settings,
and thus I presume in the  .ini  file ... which JTalert
can read, but not change.

Seems like you should be begging the WSJT-X
team to let your GPS stuff change the grid setting
IN wsjt-x ...

w2jc

Jim,

Not exactly correct.

WSJTX does provide a programmatic option, part of the UDP protocol, to temporarily change the Grid in WSJTX. This is to allow 3rd party apps to initiate a grid change. It has its own dedicated message number in the API. Given the narrow focus of this functionality I presume that this was added to the API in the past after a request by someone. I don't know the history of the feature or who requested it, I find it unusual given the history of WSJTX UDP API changes and requests that got knocked on the head as being too narrowly focused.

I note that any changes made via the API are temporary in nature, they last for the WSJTX session only and are reverted when WSJTX is next started.

de Laurie VK3AMA


Lawrence Dobranski
 

First for Dave Garber,

As I stated in my previous post "Currently I set my system clock and get my grid square from  BktTimeSync:  https://www.maniaradio.it/en/bkttimesync.html".   BktTimeSync acts as a Stratum 1 time source and provides a network time source for my PC to set its internal clock -- exactly as you propose.

Second for Jim Cooper,

Already done!  WSJT-X supports "AutoGrid".  It is enabled under Settings->General.  There is a check box right beside where you enter your grid.  AutoGrid causes WSJT-X to listen on the multicast address and port for a properly formatted grid square.  All any application that wants to cause WSJT-X to change its home Grid Square just needs to broadcast it to the multicast IP addresses and the associated port.  No modification required to WSJT-X -- it is already implemented!  The source code to see how this can be done (in Python) case be viewed here:  https://github.com/bmo/py-wsjtx  py-wsjtx are a collection of Python modules that talk to WSJT-X

Thanks for the feedback/ideas.

73 de VA3IQ

Lawrence



On Sun, Oct 3, 2021 at 8:06 PM Jim Cooper <jim.w2jc@...> wrote:
On 3 Oct 2021 at 15:50, Lawrence Dobranski wrote:

> I thought that JTAlert would be a good place for a basic method of
> taking the GPS stream and converting it to a format understood by
> WSJT-X. 

Aren't you begging at the wrong tree?
My understanding is that JTalert cannot tell
WSJT-X to change any of it's basic information;
the grid setting in WSJT-X is set in the Settings,
and thus I presume in the  .ini  file ... which JTalert
can read, but not change.

Seems like you should be begging the WSJT-X
team to let your GPS stuff change the grid setting
IN wsjt-x ...     

w2jc


HamApps Support (VK3AMA)
 

On 4/10/2021 9:50 am, Lawrence Dobranski wrote:
I thought that JTAlert would be a good place for a basic method of taking the GPS stream and converting it to a format understood by WSJT-X.  If the consensus is no, that is fine.  My personal software is not designed to be portable or supportable.  I program in C and keep my code tight and specific.

73 de VA3IQ

Lawrence

It is very unlikely I will implement a GPS-based update of the WSJTX grid via the WSJTX API. I don't have access to a GPS device to test with and what little research I have done indicates that not all GPS devices are suitable. I note many comments in docs of GPS software advise which devices work, which don't and which behave inconsistently.

Supporting GPS hardware in JTAlert would likely to be a maintenance nightmare. There is always that one individual who, to save a couple of dollars or to stand out in the crowd, will go against the mainstream recommendations and choose a device that is relatively unknown, lacking documentation or badly supported by the vendor, who will complain loudly that JTAlert will not work with their device.

Sorry, I  don't want to go down that path of supporting GPS hardware. Its bad enough now with the differences with JTDX and WSJTX.

Please note that if there is any future  implementation of the auto-grid feature within JTAlert it will only work with WSJTX as this is another component (out of many) of the UDP API that the JTDX people removed.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 4/10/2021 11:28 am, Lawrence Dobranski wrote:
Already done!  WSJT-X supports "AutoGrid".  It is enabled under Settings->General.  There is a check box right beside where you enter your grid.  AutoGrid causes WSJT-X to listen on the multicast address and port for a properly formatted grid square.  All any application that wants to cause WSJT-X to change its home Grid Square just needs to broadcast it to the multicast IP addresses and the associated port.  No modification required to WSJT-X -- it is already implemented!  The source code to see how this can be done (in Python) case be viewed here:  https://github.com/bmo/py-wsjtx  py-wsjtx are a collection of Python modules that talk to WSJT-X

Thanks for the feedback/ideas.

73 de VA3IQ

Lawrence

If there is Python code that already does the auto-grid update, that's you answer. Run the Python code. Make sure that all three components, WSJT_X, JTAlert and the Python code are set to use Multicast UDP and they will happily operate concurrently.

de Laurie VK3AMA


Willi Passmann
 

Here is a help page that explains the procedure:
http://kd2iff.com/node/21

vy 73,
Willi, DJ6JZ

Am 04.10.2021 um 03:10 schrieb HamApps Support (VK3AMA):

If there is Python code that already does the auto-grid update, that's you answer. Run the Python code. Make sure that all three components, WSJT_X, JTAlert and the Python code are set to use Multicast UDP and they will happily operate concurrently.

de Laurie VK3AMA



g4wjs
 

On 04/10/2021 01:28, Lawrence Dobranski wrote:
Second for Jim Cooper,

Already done!  WSJT-X supports "AutoGrid".  It is enabled under Settings->General.  There is a check box right beside where you enter your grid.  AutoGrid causes WSJT-X to listen on the multicast address and port for a properly formatted grid square.  All any application that wants to cause WSJT-X to change its home Grid Square just needs to broadcast it to the multicast IP addresses and the associated port.  No modification required to WSJT-X -- it is already implemented!  The source code to see how this can be done (in Python) case be viewed here:  https://github.com/bmo/py-wsjtx  py-wsjtx are a collection of Python modules that talk to WSJT-X

Thanks for the feedback/ideas.

73 de VA3IQ

Lawrence

Hi Laurence,

although you are basically correct, there are a number of errors in your description above. Firstly multicast is not broadcast, multicast was developed to avoid the inherent network flooding issues of wide area broadcast.

Secondly, WSJT-X instances are clients in the topology of the WSJT-X UDP Message Protocol. It is the cooperating applications like JTAlert that have the server role. That means that WSJT-X instances do not listen for multicast traffic on a well know port (by default 2237 is used by servers to do that), WSJT-X instances send to that port and servers discover them because of that. It is the responsibility of the server(s) to record the and sender IP address and ephemeral port number that each WSJT-X client sends to them from, *replies* like the dynamic grid locator update are conveyed to individual WSJT-X instances (on a one-to-one basis) by the server using that recorded addressing information, using a simple UDP datagram. The net effect is that rather than any "broadcasting" the server must establish a one-to-one relationship (I won't call it a connection as there is no formal connection with UDP communications) with each WSJT-X client it discovers and is interested in.

This may sound complicated, but in reality is no different from the way most Internet services work, e.g. email, http(s), etc. The main difference being that many other Internet services use point-to-point TCP/IP connections, WSJT-X uses UDP which, when combined with multicast group addressing, allows a many-to-many topology where all servers can share the same well known listening port number and interact with the same set of WSJT-X clients if they wish.

73
Bill
G4WJS.


--
73
Bill
G4WJS.


Lawrence Dobranski
 

I want to thank everyone for their comments and feedback.  Laurie's, VK3AMA,  position is understandable.  

I was proposing this for ham's that like my implementation but my implementation is not suitable for general consumption for similar reasons as Laurie gave.  I am experimenting with a version of an enterprise service bus to allow multiple services to be made available to multiple clients.  I may publish an article on it for QEX, like I did for ham radio API's back in 1999: The Need for Standard Application-Programming Interfaces (APIs) in Amateur Radio (arrl.org)

And Bill, G4WJS, sorry for using "broadcast" and keeping me honest -- I am intimately familiar with IETF RFC 1112, RFC 4604, and RFC 5771. 

73 de VA3IQ

Lawrence

On Mon, Oct 4, 2021 at 5:40 AM g4wjs <bill.8@...> wrote:
On 04/10/2021 01:28, Lawrence Dobranski wrote:
Second for Jim Cooper,

Already done!  WSJT-X supports "AutoGrid".  It is enabled under Settings->General.  There is a check box right beside where you enter your grid.  AutoGrid causes WSJT-X to listen on the multicast address and port for a properly formatted grid square.  All any application that wants to cause WSJT-X to change its home Grid Square just needs to broadcast it to the multicast IP addresses and the associated port.  No modification required to WSJT-X -- it is already implemented!  The source code to see how this can be done (in Python) case be viewed here:  https://github.com/bmo/py-wsjtx  py-wsjtx are a collection of Python modules that talk to WSJT-X

Thanks for the feedback/ideas.

73 de VA3IQ

Lawrence

Hi Laurence,

although you are basically correct, there are a number of errors in your description above. Firstly multicast is not broadcast, multicast was developed to avoid the inherent network flooding issues of wide area broadcast.

Secondly, WSJT-X instances are clients in the topology of the WSJT-X UDP Message Protocol. It is the cooperating applications like JTAlert that have the server role. That means that WSJT-X instances do not listen for multicast traffic on a well know port (by default 2237 is used by servers to do that), WSJT-X instances send to that port and servers discover them because of that. It is the responsibility of the server(s) to record the and sender IP address and ephemeral port number that each WSJT-X client sends to them from, *replies* like the dynamic grid locator update are conveyed to individual WSJT-X instances (on a one-to-one basis) by the server using that recorded addressing information, using a simple UDP datagram. The net effect is that rather than any "broadcasting" the server must establish a one-to-one relationship (I won't call it a connection as there is no formal connection with UDP communications) with each WSJT-X client it discovers and is interested in.

This may sound complicated, but in reality is no different from the way most Internet services work, e.g. email, http(s), etc. The main difference being that many other Internet services use point-to-point TCP/IP connections, WSJT-X uses UDP which, when combined with multicast group addressing, allows a many-to-many topology where all servers can share the same well known listening port number and interact with the same set of WSJT-X clients if they wish.

73
Bill
G4WJS.


--
73
Bill
G4WJS.


Michael Black
 

I decided to start writing my own grid tracker in C# Net 6.0 with portability in mind to cover Windows, Linux, and MacOS.  I've got the grid stuff working now and working on getting it to WSJTX.

First goal would be getting the grid to WSJT-X, second goal would be multicast of the gps sentence to multicast clients which could then put the gps data on one or more virtual serial ports.  Then make a generic serial multicast client/server capability.  There is a commercial product that does this but it's not that hard to do.

Mike W9MDB

On Monday, October 4, 2021, 09:39:24 AM CDT, Lawrence Dobranski <ldobranski@...> wrote:


I want to thank everyone for their comments and feedback.  Laurie's, VK3AMA,  position is understandable.  

I was proposing this for ham's that like my implementation but my implementation is not suitable for general consumption for similar reasons as Laurie gave.  I am experimenting with a version of an enterprise service bus to allow multiple services to be made available to multiple clients.  I may publish an article on it for QEX, like I did for ham radio API's back in 1999: The Need for Standard Application-Programming Interfaces (APIs) in Amateur Radio (arrl.org)

And Bill, G4WJS, sorry for using "broadcast" and keeping me honest -- I am intimately familiar with IETF RFC 1112, RFC 4604, and RFC 5771. 

73 de VA3IQ

Lawrence

On Mon, Oct 4, 2021 at 5:40 AM g4wjs <bill.8@...> wrote:
On 04/10/2021 01:28, Lawrence Dobranski wrote:
Second for Jim Cooper,

Already done!  WSJT-X supports "AutoGrid".  It is enabled under Settings->General.  There is a check box right beside where you enter your grid.  AutoGrid causes WSJT-X to listen on the multicast address and port for a properly formatted grid square.  All any application that wants to cause WSJT-X to change its home Grid Square just needs to broadcast it to the multicast IP addresses and the associated port.  No modification required to WSJT-X -- it is already implemented!  The source code to see how this can be done (in Python) case be viewed here:  https://github.com/bmo/py-wsjtx  py-wsjtx are a collection of Python modules that talk to WSJT-X

Thanks for the feedback/ideas.

73 de VA3IQ

Lawrence

Hi Laurence,

although you are basically correct, there are a number of errors in your description above. Firstly multicast is not broadcast, multicast was developed to avoid the inherent network flooding issues of wide area broadcast.

Secondly, WSJT-X instances are clients in the topology of the WSJT-X UDP Message Protocol. It is the cooperating applications like JTAlert that have the server role. That means that WSJT-X instances do not listen for multicast traffic on a well know port (by default 2237 is used by servers to do that), WSJT-X instances send to that port and servers discover them because of that. It is the responsibility of the server(s) to record the and sender IP address and ephemeral port number that each WSJT-X client sends to them from, *replies* like the dynamic grid locator update are conveyed to individual WSJT-X instances (on a one-to-one basis) by the server using that recorded addressing information, using a simple UDP datagram. The net effect is that rather than any "broadcasting" the server must establish a one-to-one relationship (I won't call it a connection as there is no formal connection with UDP communications) with each WSJT-X client it discovers and is interested in.

This may sound complicated, but in reality is no different from the way most Internet services work, e.g. email, http(s), etc. The main difference being that many other Internet services use point-to-point TCP/IP connections, WSJT-X uses UDP which, when combined with multicast group addressing, allows a many-to-many topology where all servers can share the same well known listening port number and interact with the same set of WSJT-X clients if they wish.

73
Bill
G4WJS.


--
73
Bill
G4WJS.