locked WSJT-X Autogrid Feature Suggestion
Lawrence (VA3IQ)
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.
|
|
Joe Subich, W4TV
This belongs in WSJTX *not* JTAlert. Seek *full* support from the
toggle quoted messageShow quoted text
developers of WSJTX. 73, ... Joe, W4TV
On 2021-10-01 11:42 AM, Lawrence Dobranski wrote:
This is a future feature suggestion for JTAlert:
|
|
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:
|
|
Lawrence (VA3IQ)
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.
|
|
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 ofAren'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
|
|
JTAlert 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 (VA3IQ)
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:
|
|
JTAlert 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. 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
|
|
JTAlert Support (VK3AMA)
On 4/10/2021 11:28 am, Lawrence
Dobranski wrote:
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.
|
|
g4wjs
On 04/10/2021 01:28, Lawrence Dobranski
wrote:
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 -- 73 Bill G4WJS.
|
|
Lawrence (VA3IQ)
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:
|
|
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:
|
|