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?
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 <g4...@classdesign.com
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
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
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 <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.
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.
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