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