Grid Square logging

[k1io]

Now we're getting into the real meat of the issue, poor communications including in the documentation. It uses terms that are unclear. It shows "QRZ" and other data sources and it uses the term "external source". It appeared, and I asked this before that "external source" could mean a program like WSJT-X or JTDX. But now you seem to be clarifying that "external source" means a data source, where you pull the grid square and zone data from.

In that case there is no defined term for programs like WSJT-X (which use the API, which uses a UDP port for communications) that provide input to the input stream so that the human user doesn't have to touch it. If that is not the "external source" what do we call it? What does the documentation call it? I don't think the manual pays enough attention to it to even give it a name. So for this thread only, let's call that source Joe. I do my DXing using Joe and Joe uses a UDP port to send messages to Log4OM. Joe sends data to Log4OM at least twice. The first time is when I try to begin the contact. At that point it knows the grid square if I am answering a CQ or if Joe already knows it. But in some cases Joe does not know so the grid square should remain blank. Log4OM could guess at that point but it should treat that as only tentative. (I wouldn't bother if it were up to me. I'm looking at Joe's user interface, not Log4OM.)

Now at the end of the contact, Joe has a logging function. That's when it sends the complete message to Log4OM, including grid square, which Joe can look up if it doesn't come from the QSO. (Joe has its own sources.) That is the grid square that should go into the Log4OM database, not the one that Log4OM would have pulled out of somewhere if this were a CW or SSB contact. The problem is that Log4OM overwrites what Joe sends it and saves the value that Log4OM looks up. And yes, that does show up in the normal input window but Joe users are looking at Joe, not Log4OM, so that normal input window is minimized down in the taskbar.

Does that make it any clearer? Again, I'm on the latest beta 2.26-03.

[G4POP]

Now we're getting into the real meat of the issue, poor communications including in the documentation.

I am sorry that you feel agrieved but we try our best, unfortunately its not always good enough for the user, however this is the first complaint of this kind that I can recall in the 11 years I have been writing the user guide and producing the video tutorials for Log4OM and prior to that writing user guides for other ham software, also on a voluntary basis.


The introduction by Joe Taylor of WSJT and all of the subsequent derivitives has inflicted on logging software developers a huge workload in supporting this 3rd party software. The level of user support required has increased at leat 10 fold, just check the forums and social media sites to see the support demanded by users! The result is we sometimes have a missfire but lets face it we do this for a hobby to support the International amateur radio fraternity which is not easy when you dont have the staff of Microsoft or Intel, its just the two of us supported by a hanfull of dedicated users.

It uses terms that are unclear. It shows "QRZ" and other data sources and it uses the term "external source". It appeared, and I asked this before that "external source" could mean a program like WSJT-X or JTDX. But now you seem to be clarifying that "external source" means a data source, where you pull the grid square and zone data from.

When discussing information providers we assume the user is familiar with the terms refering to on line call lookup systems and usually qualify it by adding (QRZ etc)

In that case there is no defined term for programs like WSJT-X (which use the API, which uses a UDP port for communications) that provide input to the input stream so that the human user doesn't have to touch it. If that is not the "external source" what do we call it? What does the documentation call it? I don't think the manual pays enough attention to it to even give it a name. So for this thread only, let's call that source Joe.

Deciding on a generic name is always fun! probably 3rd Party software would suffice? but suggestions from expert instruction manual authors is always welcome.

I do my DXing using Joe and Joe uses a UDP port to send messages to Log4OM. Joe sends data to Log4OM at least twice. The first time is when I try to begin the contact. At that point it knows the grid square if I am answering a CQ or if Joe already knows it. But in some cases Joe does not know so the grid square should remain blank. Log4OM could guess at that point but it should treat that as only tentative. (I wouldn't bother if it were up to me. I'm looking at Joe's user interface, not Log4OM.)

As I stated earlier in the next release you will be able to decide what happens to such incoming UDP data

The problem is that Log4OM overwrites what Joe sends it and saves the value that Log4OM looks up.

I mentioned earlier that this has now changed, it was a temporary issue because a change in another input routine also affected the 3rd Party Software UDP input.

I hope the foregoing addresses your dissapointment with our software, user guide and support and I also hope that to some extent has reassured you that we do listen and we try to get it right, however sometimes we fail and for that we appologise.

[k1io]

Okay, thanks for the reply. Third-party software does complicate things, but there's an awful lot of it out there, and digital modes are already more popular than the older ones, in terms of QSO count. If there is a well-defined standard input (and there may be; I don't know if anyone does it differently from WSJT-X) that makes it easier to support. If not, yeah, it gets bad (look at CAT, for instance).

Are you saying that the issue I raised is a bug in this version (2.25, 2.26-03) and will be fixed? If so, is that planned for the final 2.26 or would it be a later release? Thanks.

[G4POP]

I said in my last post "As I stated earlier in the next release you will be able to decide what happens to such incoming UDP data"

If you study page 55 of the latest user giuide you will see this screen shot.

Picture1.png (85.79 KiB) Viewed 1610 times

The port number and name shown in the screen shot above are fictional and just used to illustrate the process they should not be emulated


With this statement


"PLEASE NOTE
When a QSO is in progress in an external program like WSJT etc the Log4OM lookup is only displayed it is not what is saved when the QSO is completed by the WSJT software sending the QSO via UDP
UNLESS the user elects to update the data received in the QSO sent from the external program in the Program Configuration menu."

You will notice that while setting up an inbound UDP as you would for and FT4/8 external software ther are check boxes located under the 'UDP Inbound Parameters' heading where the user can define what Log4OM does to the incoming QSO data.

Our release notes for the BETA 2.26.0.4 release state: (This will not be the Beta release that you see for download it will have a later release number because development is ongoing)

• [NEW] UDP inbound connections.
Added support for user parameters INBOUND CONNECTIONS.

ADIF IMPORT, allow user to choose from some update options. Existing connections only work with default values (so the USER needs to recreate them to apply these customized settings)

JT CONNECTION allows user to choose if the QSO should be saved when JT message 12 arrives. This will provide a complete JT integration without need of receiving ADIF messages from JTDX/WSJT-X (Message 12 parameter has been removed from the separate option page in settings).

PLEASE NOTE: To add/remove a parameter from a connection you should REMOVE the connection and create it again, as a complete reboot of the connection layer is required.

[k1io]

Okay, so your post clarifies that the picture in the instruction book, which shows those inbound parameters, is NOT YET implemented as of 2.26-03 but will be in 2.26 final. In that case the check box should allow the selection of the value provided by JTDX/WSJT-X. The existing checkbox for message 12, which goes away, doesn't do that now. I will happily test that out when the next beta with it arrives. Thanks.

[ei3grb]

"The grid shown in the normal input window of Log4OM is retrieved from the external source selected by the user (QRZ, HamQTH etc) NOT what is received from the FT software (JTDX, WSJT, Gridtracker etc) its purely a visual display and not saved with the incoming FT QSO

Regardless of what is displayed in the input window its the grid received from the FT software that is/should be logged.

That said there was an earlier release of Log4OM that logged the grid found from the external source (QRZ etc) as shown in the normal input window - Thats why we are so insistant on asking for the version number being used!
"



went through all the settings and latest user manual and I find it's now picking grids that are not in input window or in the ft software

any how I'm out of here , I really like the logger , but I have little radio time and like to spend it on the radio rather
trying to sort through pages of manual without success

73

[k1io]

For what it's worth, the weirdest part it that it sometimes works right. Yes, the initial lookup in the window is often wrong, but sometimes it logs the wrong (visible) value and sometimes it logs the right (caller-provided) value. It is usually correct on US calls, for instance. But some calls logged wrong, like D2UY. If I answered an RR and there was no grid square given, then JTDX logs a blank (since it doesn't really know) while Log4OM logs the guess. That's tolerable if not quite right (it should be logged as a predicted value, not a given one). The problem is when, sometimes, the predicted value is logged in place of the given one.

[N6VH]

I have been having similar problems, which I posted about in the Error Reports section of the forum. As I said there, the problem I was having was in the beta version, 2.26.0.3, I reverted back to 2.26.0.0, and have not had that problem. Something seems to have changed in the beta version.

73,

Jim N6VH

[vu3tbu]

Hi

For me the grid still not fetching. Done all settings mentioned and changed to many other sources. Is it possible to fetch grid from QRZ.COM?
NOW ON LATEST BETA 2.26.0.3

Thank You
73
vu3tbu
Rajesh A.