ZONES 18, 19, 3, 4 INSERTION ON LOG

General discussions V2
User avatar
KI5IO
Log4OM Alpha Team
Posts: 1798
Joined: 16 Aug 2015, 16:30
Location: Plano, TX

Re: ZONES 18, 19, 3, 4 INSERTION ON LOG

Post by KI5IO »

F6FLU wrote: 19 Jun 2021, 16:43 Hello
Yes Nolan
I confirm that the tests carried out here were done by manually typing the call, I did not test by validating this same callsign from an FTxx digital mode interface, but if necessary I can give it a try…
73
Dan ( also for Laurent and other OMs),

As y'all have seen and experienced when operating FTxx APPs (WSJTx and JTDX "direct" connection to Log4OM V2 AND running WSJTx via JTAlert) once a spot is selected in the FTxx APP it will appear in the Log4OM Main UI with a certain set of values the Log4OM V2 brings to the screen from it's internal databases.

In most cases we see certain ITU and CQ zone values in the Log4OM Main UI.

Then, once the QSO is completed and saved the data is then sent via UDP from the FTxx APP to the Log4OM V2 database (SQLITE or MYSQL) and saved in that file and finally visible in our Recent QSO's (F7) grid.

This is where we will often now see a difference in either the ITU or CQ zone (or both) for that QSO.

Terry and I have gone over my findings (yet again) this morning and the bottom line is that Log4OM V2 is merely taking the data (via UDP generally) from the FTxx APP and saving it to the database file. The assumption is that the FTxx APP has made certain choices to ID the ITU & CQ zone values to include with their data packet.

Terry shared this comment with me today: "if data comes from an external source it would be wrong for us to change it even if it's wrong because we must assume that is the data the user wants recorded "

Also ... if it is determined that certain data is continually wrong from the FTxx APP developer then the OM should reach out to them to make corrections in the data they provide with a completed QSO.

Hope this helps a tad.
73 - Nolan Kienitz - KI5IO
Plano, TX
F6FLU
Old Man
Posts: 435
Joined: 03 Aug 2015, 15:33
Location: Near Paris
Contact:

Re: ZONES 18, 19, 3, 4 INSERTION ON LOG

Post by F6FLU »

Hello
thank you Nolan for these very clear explanations and I agree with you ...

but in this case (difference between the CQ / ITU zones between the FTxx and Log4OM app) could we not automatically have a warning?
that would be a real plus for the user

thank you in any case for all these explanations ...
73
Dan - F6FLU
Log4OM V2.32.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wired dipole 40-30M
https://F6FLU.org
User avatar
KI5IO
Log4OM Alpha Team
Posts: 1798
Joined: 16 Aug 2015, 16:30
Location: Plano, TX

Re: ZONES 18, 19, 3, 4 INSERTION ON LOG

Post by KI5IO »

F6FLU wrote: 20 Jun 2021, 09:47 Hello
thank you Nolan for these very clear explanations and I agree with you ...

but in this case (difference between the CQ / ITU zones between the FTxx and Log4OM app) could we not automatically have a warning?
that would be a real plus for the user

thank you in any case for all these explanations ...
73
Dan,

I have tried over the past several days to have an "eye open" to see which ITU / CQ zones will be coming from the the FTxx APP (in my recent efforts I was using WSJTx (direct and also latest 'RC" version) and WSJTx via JTAlert (latest verion).

There is no visual when the QSO ends and a prompt appears asking me to save (my option is to see as best as possible what is being saved) the event. Only thing I typically always do is add the last two characters for the Grid as all of the FTxx APPs only supply the first 4 characters and I 'try' to always have 6.

Ergo ... I don't see which ITU & CQ zones will be coming via the UDP feed to my database until it is saved and appears in my Recent QSO list.

I'm sure Lele could devise some code to interrogate that final feed, but at what cost in time and delay?

Also ... as related to what Claus shared above there is not a consistent and precise database for the ITU / CQ zones.

Case in point ... yesterday I was changing the order of Info Providers (Clublog, CTY, External) and was simply putting in my own callsign to see the results in the Main UI. They were not consistent. One of the Providers had my own location incorrect, but the other were OK. That really took me by surprise as my QTH is not on a border of any of the zones, yet it wasn't consistent. How does one correct for that unless you take the time/effort to enter in a 6-digit grid to another service that also shows the ITU/CQ zones and (hopefully) they are correct as well ... but who knows for sure?

So which one do I choose to be comfortable with?

I figured (at least for me) I'll choose the Info Provider that gives me the correct ITU / CQ zones for my QTH and I'm going to stop worrying about tweaking the saved FTxx APP QSOs. Rather just let the data be saved as it comes from those APPs and move forward.

My head was spinning last night after all those tests and I was just not able to make good sense of it. Far more to be concerned about so I've decided it will be one less headache for me. ;)

.
73 - Nolan Kienitz - KI5IO
Plano, TX
F6FLU
Old Man
Posts: 435
Joined: 03 Aug 2015, 15:33
Location: Near Paris
Contact:

Re: ZONES 18, 19, 3, 4 INSERTION ON LOG

Post by F6FLU »

Hello

I did some tests with JTDX and what is surprising is that obviously (unless I am mistaken of course) JTDX does not transmit the CQ zone or the ITU zone

here is an example of a trace :

2021-06-20 16:46:06.4900 TRACE: [#=zEd6Pycg8mE6od5iB8ueLHC8=][MoveNext] :
<adif_ver:5>3.1.0
<programid:4>JTDX
<EOH>
<BAND:2>6m <CALL:6>EA7IQT <FREQ:9>50.313644 <MODE:3>FT8 <QSO_DATE:8>20210620 <TIME_ON:6>164448 <QSO_DATE_OFF:8>20210620 <TIME_OFF:6>164559 <RST_SENT:3>-07 <RST_RCVD:3>-12 <GRIDSQUARE:6>IM66vk <COMMENT:41>FTdx5000 / Hexbeam / 40M-30M Wired Dipole <EOR>
2021-06-20 16:46:06.4900 DEBUG: [#=zEd6Pycg8mE6od5iB8ueLHC8=][MoveNext] :
<adif_ver:5>3.1.0
<programid:4>JTDX
<EOH>
<BAND:2>6m <CALL:6>EA7IQT <FREQ:9>50.313644 <MODE:3>FT8 <QSO_DATE:8>20210620 <TIME_ON:6>164448 <QSO_DATE_OFF:8>20210620 <TIME_OFF:6>164559 <RST_SENT:3>-07 <RST_RCVD:3>-12 <GRIDSQUARE:6>IM66vk <COMMENT:41>FTdx5000 / Hexbeam / 40M-30M Wired Dipole <EOR>


73
Dan - F6FLU
Log4OM V2.32.1.0 - Windows 11 - i9-11900K - SSD 512Go - 32 Go
FTdx101D - Hexbeam - Wired dipole 40-30M
https://F6FLU.org
N6VH
Old Man
Posts: 186
Joined: 07 Nov 2015, 15:41

Re: ZONES 18, 19, 3, 4 INSERTION ON LOG

Post by N6VH »

If the WJT-X (and possibly JTDX) QSO is logged by JTAlert, the USA CQ zone will probably be correct, based on the database Laurie uses for JTAlert. Also, In the USA, CQ zones can be determined if the state is known. Not so for ITU zones, however. Non-USA QSOs might be a different issue. Of course, if the station is operating at a location other than his home location, the zone might not be correct.

73,

Jim N6VH
F1TRF
Advanced Class
Posts: 60
Joined: 13 Aug 2015, 20:30
Location: JN39CC

Re: ZONES 18, 19, 3, 4 INSERTION ON LOG

Post by F1TRF »

Good morning all
the problem is not that for the United States, it is on all DXCCs that have multiple ITUs or CQs. (eu russia, asia russia, indonesia, china, brazil ..... etc
I suspect that it must be very complicated to manage for the designers of the software. But why not validate the contact with the info in the main window for contacts arriving from outside? (wsjt, jtdx, mmsstv, fldigi .... etc).
If we register a contact directly on Log4om, it takes this data into account, so regardless of the database (qrz.com, hamqth, clublog .... etc). This will greatly reduce the number of errors.
sorry if not everyone understands, it's translated with google.
73
User avatar
KI5IO
Log4OM Alpha Team
Posts: 1798
Joined: 16 Aug 2015, 16:30
Location: Plano, TX

Re: ZONES 18, 19, 3, 4 INSERTION ON LOG

Post by KI5IO »

Laurent,

Good suggestions and "yes" ... trying to confirm the "most correct" CQ & ITU zones in certain countries is most difficult.

Log4OM-2 uses a pretty extensive routine to try and minimize the differences. Yet the results still can change.

As for the data coming from outside (IE: WSJTx, JTDX, JTAlert, etc.) ... many or most of those APPs are often using the same databases / sources that we use. So how do we get to the bottom line to minimize the differences? Difficult question to answer.

Even when I test with my own callsign the ITU & CQ zones will change depending upon how I select the Info Providers for priority in the Log4OM-2 configuration. And, I am not located on any border between any zone where it should be any chance of being one zone or another.

BTW - your Google translate was / is FB. I use similar as well. ;)
73 - Nolan Kienitz - KI5IO
Plano, TX
F1TRF
Advanced Class
Posts: 60
Joined: 13 Aug 2015, 20:30
Location: JN39CC

Re: ZONES 18, 19, 3, 4 INSERTION ON LOG

Post by F1TRF »

what I cannot explain is the difference with version 2.08.00.
I tested an import of .ADI file with my last 200 contacts
after checking the file with version 2.09 or higher, I found 39 errors in ITU or CQ.
I redid the same operation with version 2.08 and there I only have 2 errors, 1 of which is due to a locator near a border. (solved by metering the six character GRID)
73
User avatar
IW3HMH
Site Admin
Posts: 2925
Joined: 21 Jan 2013, 14:20
Location: Quarto d'Altino - Venezia (ITA)
Contact:

Re: ZONES 18, 19, 3, 4 INSERTION ON LOG

Post by IW3HMH »

can you send me some samples of those callsigns that behaves not correctly on import?
An ADIF will be also appreciated.
I've added a flag on routine that imports ADIF from UDP messages to make a check of the CQ/ITU zone on import (was not enabled before for what we said above)
Currently under alpha testing team view
Daniele Pistollato - IW3HMH
K0AY
Old Man
Posts: 142
Joined: 22 Jan 2013, 16:58
Location: Sarasota, fl

Re: ZONES 18, 19, 3, 4 INSERTION ON LOG

Post by K0AY »

I hAVE A related problem. When uploading to LOTW, I get an error message stating that my IYU zone is wrongly set at 3. but when I look at the QSO that was cited, the IITU zone is not set at 3. Any clues?
Post Reply