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 <g4...@classdesign.com <mailto:g4...@classdesign.com>> 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 <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
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to