Re: [wsjt-devel] Automatic WSJT-X Grid Updating from GPS via UDP Message

[Brian Moran]

Thanks for adding that, Bill. Regarding the UDP message, are you saying
that you'd like N1MM to accept the ADIF blob as it's being generated now
(which it might already, haven't tested it, but will try to do in the next
couple of days), or that N1MM should implement the 'server' side of the
wsjt-x udp dance (which I perceive as being not very likely whatsoever,
heck, I can't even see if issues I've reported in N1MM are bugs.)?

"fewer moving parts" is always desirable  -- we could have used JTAlert to
get Q's into N1MM, but it's another thing to remember, another thing to
configure... etc.
-Brian N9ADG


On Sun, Feb 4, 2018 at 2:52 PM, Bill Somerville 
wrote:

> Hi Brian,
>
> thanks fro the patch. I have applied a somewhat modified version along
> some documentation updates and further udp_daemon and message_aggregator
> reference application example updates.
>
> I am not 100% sure the "Auto grid" check box in settings is really
> necessary but I have left it in. It seems to me that simply allowing
> incoming "Location" UDP messages to update the temporary grid locator with
> minimal validation is all that is needed.
>
> I have also added a new logging UDP message that is valid ADIF format. I
> would like to switch to using this to update the N1MM+ log if we can find a
> way for it to accept these messages within the WSJT-X UDP protocol. All
> that should be needed is to join the multicast group and filter messages
> for these "Logged ADIF" type messages. The whole message or just the "ADIF"
> field are conforming and valid ADIF files containing a single record of
> logged fields. Worst case, a simple bridging application could be written
> to map between WSJT-X "Logging ADIF" messages and N1MM+ UDP log messages.
> Your Python script for NMEA geo-location could perhaps serve double duty?
>
> 73
> Bill
> G4WJS.
>
>
> On 04/02/2018 06:33, Brian Moran wrote:
>
> When clean-before-build is off, rebuilding only takes a few 10's of
> seconds. Just impatient, I guess.
>
> I used a hidden 'dynamic grid' variable that is set from the UDP message,
> but is only used if the checkbox is selected.
>
> For the MessageAggregator test bed for it, the grid field is implemented
> similarly to the free text entry -- when editing is deemed 'finished', the
> message to change the grid is sent.
>
> Attached is a diff.
>
>
>
> On Sat, Feb 3, 2018 at 3:31 PM, Bill Somerville 
> wrote:
>
>> Hi Brian,
>>
>> some comments in line below.
>>
>> On 03/02/2018 21:30, Brian Moran wrote:
>>
>>> I'll have to take my 1.8.0 diff and get it fixed up for the dev branch.
>>>
>> I can't help much with that, in theory you can simply switch your svn
>> workspace to the development branch and it will merge your changes but YMMV.
>>
>>>
>>> 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.
>>>
>> I'm not certain that is really necessary but add it if you feel so
>> inclined.
>>
>>>
>>> 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.
>>>
>> Ok, that is consistent with an excursion across grids and the default of
>> returning "home" on a restart makes sense. I'm not sure how you intend to
>> implement that, I suppose all references to Configuration::my_grid() will
>> need replacing or are you using a temporary grid cache in he Configuration
>> class instance. Either way, how will that interact with normal usage of the
>> settings dialog?
>>
>>>
>>> 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.
>>>
>> Multicast and multiple instances of WSJT-X are unrelated issues.
>> Multicast UDP only comes into play when there are multiple servers, e.g.
>> your application and JTAlert (with the caveat that JTAlert is a bad example
>> as it doesn't do multicast UDP).
>>
>>>
>>> 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 am happy to help with message_aggregator, it is somewhat more complex
>> as it has a UI and exercise 

Re: [wsjt-devel] Automatic WSJT-X Grid Updating from GPS via UDP Message

[Claude Frantz]

On 02/03/2018 07:00 PM, Bill Somerville wrote:

Hi Bill & all,

> 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.
In simple words, we need a bridge software between the gpsd and the
WSJT-X software.

Best wishes,
Claude (DJ0OT)

--
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

Re: [wsjt-devel] Automatic WSJT-X Grid Updating from GPS via UDP Message

[Brian Moran]

When clean-before-build is off, rebuilding only takes a few 10's of
seconds. Just impatient, I guess.

I used a hidden 'dynamic grid' variable that is set from the UDP message,
but is only used if the checkbox is selected.

For the MessageAggregator test bed for it, the grid field is implemented
similarly to the free text entry -- when editing is deemed 'finished', the
message to change the grid is sent.

Attached is a diff.



On Sat, Feb 3, 2018 at 3:31 PM, Bill Somerville 
wrote:

> Hi Brian,
>
> some comments in line below.
>
> On 03/02/2018 21:30, Brian Moran wrote:
>
>> I'll have to take my 1.8.0 diff and get it fixed up for the dev branch.
>>
> I can't help much with that, in theory you can simply switch your svn
> workspace to the development branch and it will merge your changes but YMMV.
>
>>
>> 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.
>>
> I'm not certain that is really necessary but add it if you feel so
> inclined.
>
>>
>> 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.
>>
> Ok, that is consistent with an excursion across grids and the default of
> returning "home" on a restart makes sense. I'm not sure how you intend to
> implement that, I suppose all references to Configuration::my_grid() will
> need replacing or are you using a temporary grid cache in he Configuration
> class instance. Either way, how will that interact with normal usage of the
> settings dialog?
>
>>
>> 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.
>>
> Multicast and multiple instances of WSJT-X are unrelated issues. Multicast
> UDP only comes into play when there are multiple servers, e.g. your
> application and JTAlert (with the caveat that JTAlert is a bad example as
> it doesn't do multicast UDP).
>
>>
>> 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 am happy to help with message_aggregator, it is somewhat more complex as
> it has a UI and exercise all UDP capabilities.
>
> You should not be having and edit-compile-test loop time issues on
> something as powerful as a Core i5 CPU. I suspect you are using the JTSDK
> and have not turn off the, developer unfriendly, option to do a make clean
> every build.
>
>>
>> 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
>>
> Entering the settings dialog and changing something should be disabling
> "Enable Tx" so going into settings during a QSO should be effectively
> quitting the QSO. I am not 100% sure that is always correctly implemented
> but it is the intention. I would recommend a grid change being in line with
> that intent.
>
>>
>> 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.
>>
> Thinking about it I think that is simple and effective.
>
>>
>> On grid change detected, one could configure the grid server program to
>> ALSO set the Free Text message (TX5) to be something like "73 
>> " ) 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.
>>
> Any message with the word "73" should be processed identically to a
> standard format "dx-call de-call 73" message. I would suggest simply
> calling CQ or QRZ with a new grid is sufficient, I can't imagine a station
> moving across a grid boundary is too concerned about an extra 30 seconds
> (in FT8 mode) to announce  anew location using existing standard messages.
>
>>
>> The next CQ would send the new grid. Enhancement: Perhaps TX1 gets a
>> color change until CQ is sent again, which 

Re: [wsjt-devel] Automatic WSJT-X Grid Updating from GPS via UDP Message

[Bill Somerville]

Hi Brian,

some comments in line below.

On 03/02/2018 21:30, Brian Moran wrote:

I'll have to take my 1.8.0 diff and get it fixed up for the dev branch.
I can't help much with that, in theory you can simply switch your svn 
workspace to the development branch and it will merge your changes but YMMV.


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.

I'm not certain that is really necessary but add it if you feel so inclined.


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.
Ok, that is consistent with an excursion across grids and the default of 
returning "home" on a restart makes sense. I'm not sure how you intend 
to implement that, I suppose all references to Configuration::my_grid() 
will need replacing or are you using a temporary grid cache in he 
Configuration class instance. Either way, how will that interact with 
normal usage of the settings dialog?


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.
Multicast and multiple instances of WSJT-X are unrelated issues. 
Multicast UDP only comes into play when there are multiple servers, e.g. 
your application and JTAlert (with the caveat that JTAlert is a bad 
example as it doesn't do multicast UDP).


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 am happy to help with message_aggregator, it is somewhat more complex 
as it has a UI and exercise all UDP capabilities.


You should not be having and edit-compile-test loop time issues on 
something as powerful as a Core i5 CPU. I suspect you are using the 
JTSDK and have not turn off the, developer unfriendly, option to do a 
make clean every build.


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
Entering the settings dialog and changing something should be disabling 
"Enable Tx" so going into settings during a QSO should be effectively 
quitting the QSO. I am not 100% sure that is always correctly 
implemented but it is the intention. I would recommend a grid change 
being in line with that intent.


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.

Thinking about it I think that is simple and effective.


On grid change detected, one could configure the grid server program 
to ALSO set the Free Text message (TX5) to be something like "73 
 " ) 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.
Any message with the word "73" should be processed identically to a 
standard format "dx-call de-call 73" message. I would suggest simply 
calling CQ or QRZ with a new grid is sufficient, I can't imagine a 
station moving across a grid boundary is too concerned about an extra 30 
seconds (in FT8 mode) to announce  anew location using existing standard 
messages.


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.
I'm not sure what a colour change helps with or which end of the QSO 
shows it?


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.



One thing that must be solid is that the roving station must record 
their own grid correctly with each QSO, this is where the behaviour of 
grid change part way through a QSO will cause issues. Keeping it simple, 
the operator must at least push the "Log QSO" button after competing a 
QSO and before moving on.


73
Bill
G4WJS.

Re: [wsjt-devel] Automatic WSJT-X Grid Updating from GPS via UDP Message

[Brian Moran]

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 
" ) 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 
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, 

Re: [wsjt-devel] Automatic WSJT-X Grid Updating from GPS via UDP Message

[Bill Somerville]

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