I'll have to take my 1.8.0 diff and get it fixed up for the dev branch.
There's one slight UI suggested change, and that is in the configuration
UI, an 'autogrid' (didn't think about this name much, it popped in while
working on it) checkbox next to the grid entry field in the dialog that
will allow updates via UDP.
The operation is as follows:
The grid is configured in the configuration dialog as normal. At startup of
wsjtx, *or when autogrid checkbox is turned off* the grid in the
configuration dialog is used.
If the 'autogrid' checkbox is checked, then the grid *can* be changed by a
valid grid being received by wsjt-x. This change will *not* be saved at
program end.
Regarding the python server stuff, yes, I listen for the heartbeat packet
before trying to listen for status packets and examining the currently
configured grid. I only have unicast support in my current implementation.
In a multicast scenario where there were more than one wsjt-x instance, it
might be hard to divine the geographic topology of the instances, so that
exercise would be left to the reader.
I'll go look at the message aggregator -- I originally got it tested with
UDP_daemon, but the edit-compile-feedback loop is a bit long on my i5
machine, so wrote a little python library so my turnaround would be quicker.
I've thought about the 'inconvenient grid changing' occuring during a QSO
(and inadvertently tested that a few times myself):
- Someone could change the grid in the configuration dialog at any time
already
- The grid is only used in tx1 and tx6
I think the impact of changing a grid during a QSO is minimal, and the grid
that is handed out is the one that was reflective of the beginning of the
QSO.
On grid change detected, one could configure the grid server program to
ALSO set the Free Text message (TX5) to be something like "73 <CALL>
<GRID>" ) to inform subsequent callers of a grid change if they have a
five-character-or-fewer-in-length callsign to stay under the 13 character
limit of the free text message. The downside is the autoseq detection
mechanism would not recognize the 73 message in that case.
The next CQ would send the new grid. Enhancement: Perhaps TX1 gets a color
change until CQ is sent again, which hopefully would draw the attention of
the operator.
For the IGC purposes, I would make sense to be the case that the own-grid
squares of each station are used if provided (since they don't need to be
in a QSO as part of the IGC rules), but I've not tested that.
On Sat, Feb 3, 2018 at 10:00 AM, Bill Somerville <g4...@classdesign.com>
wrote:
> On 03/02/2018 17:48, Brian Moran wrote:
>
>> Hi Folks, when we were on the boat on the way to Mellish Reef we operated
>> /MM. Adding the appropriate grid square was just something we had to
>> remember to do, and didn't require checking too often as we were only
>> proceeding at 8 kt.
>>
>> In a vehicle, grid might need to be updated more frequenty, like those
>> that used wsjt-x in the January VHF contest as rovers.
>>
>> I've been experimenting with adding support for a new NetworkMessage type
>> ChangeLocation that accepts grid square from the UDP packet, runs it
>> through the usual checks the same as manually typing into the configuration
>> dialog, and sets the messages appropriately.
>>
>> I also have a small program that also provides the 'other end' -- takes
>> my u-blox usb dongle, reads the GPGLL message, and generates this message
>> to WSJT-X if it detects the grid squares are not the same. This one is in
>> python, and I'll just put it on github.
>>
>> Should I submit a diff for the wsjt-x part against 1.8.0 or the
>> development branch?
>>
>> -Brian N9ADG
>>
>> Hi Brian,
>
> thanks for working on that enhancement. A patch against the development
> branch is easiest to handle. A couple of requests that will save time
> integrating:
>
> As this is an unsolicited input message it is preferable that the server
> (your external application) is capable of joining a multicast UDP group
> address so that it is compatible with other such servers that might wish
> interoperate with WSJT-X. I assume you have to bind to the WSJT-X port and
> complete a heartbeat exchange to discover the protocol schema number and
> ephemeral port each WSJT-X instance is listening on so you can send
> unsolicited messages to them.
>
> Have you restricted grid updates to just one WSJT-X instance or will any
> WSJT-X instance joining the network get a grid update?
>
> As with all UDP messaging cases, relevant implementations of the
> message_aggregator reference application is preferred, for example in this
> case you might have a grid input line edit in it that updates all WSJT-X
> instances, thereby exercising the new message.
>
> How are you proposing to handle a grid update mid-QSO?
>
> 73
> Bill
> G4WJS.
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
