IOTA and V2

[DF5WW]

Hi Michel,

in the Layout table IOTA isn´t implemented yet. There will be more possibilities in future
updates of Log4OM.

[G4POP]

Enter the other stations IOTA ref in the input UI F3 Awards ref tab

Enter your IOTA ref in the Settings/Program Configuration/My References tab

View Award statistics and select IOTA to see IOTA worked information

IOTA.JPG (69.9 KiB) Viewed 5034 times

[IW3HMH]

I'm taking advantage of this discussion to talk about this topic, which I knew would come up.

Log4OM v1 was based, in structure and data, on the information in the ADIF file, and showed that information. The ADIF protocol, however, has, in my opinion, some big problems of consistency that have grown over the years. For example, it introduces some fields related to some specific awards (DOK, IOTA, SOTA) in an explicit way, forgetting completely some awards that, over the years, have assumed the same size, the same follow up and the same importance.

For this reason Log4OM V2, which adopts an award management engine completely guided by configuration and without a single line of specific code, could not favour one or two awards not giving the same importance to all the others.

In Log4OM V2 we "detached" ourselves from the logic of the ADIF protocol (which we use and fully support) in the user interface design.

If we had not taken this step, a large amount of information that we collect, export and manage would still be linked to the concept of the "ADIF" fields. Log4OM is perfectly capable of reading and exporting the required ADIF fields, including SOTA and IOTA (although we will propose to include dynamic fields for the management of all awards without distinction and deprecation of the IOTA and SOTA fields in a future version).

Log4OM through the function of the FILTERS is however able to extract and show, in grid, all the QSOs that result to have references of the type selected by the user, not limited to IOTA or SOTA, but extended to all the awards that today and in the future we will support.

I know it's a "big impact" on who were habit to have this field at a glance, but it's a design choice made to correct a previous error

[IW3HMH]

Hi Michael,
we have a lot of capabilities in Log4OM but we cannot change other applications.
JTAlert is not supporting (actually) our version 2, and it's not an issue of Log4OM 2 but simply Laurie didn't had enough time to make JTAlert compatible.

We're talking with each other, but in case of JTAlert, is that software that comes into our database searching for data. Our system is open, but we can't update other applications.
By the way i'm using JTDX perfectly with JTAlert and Log4OM.
I simply configured JTAlert to broadcast ADIF via UDP and configured a listener here (it's a generic JTAlert function i'm using), so i'm receiving QSO from JTDX through JTAlert flawlessy.
More, i configured JTAlert to rebroadcast JT messages so i'm also able to read JT Messages coming from JTDX and show the callsign on Log4OM lookup.
I'm missing JTAlert statistics but, again, is something they must update, if they want.