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