Log4OM

Hi,

Tracking down some minor integration issues with the ADIF Monitor function. Read trough the manual and I think the problem is mostly on the other end, but wanted to double-check that I am not misunderstanding.

I run multiple concurrent instances of FLDigi and use Log4OM ADIF Monitor to track the logbook.adi files and automatically import QSOs. On some modes like OLIVIA, I often end up with duplicate QSO's after syncing with online logbooks due to the Mode getting changed. What I think is happening:

1) The FLDigi adif file has an entry with "<MODE:12>OLIVIA 8/250". That is not ADIF 3.x compliant -- the MODE should be "OLIVIA" and there should be a "<SUBMODE:12>OLIVIA 8/250" that isn't presented in the FLDigi log file.

2) Log4OM notices the file change and imports the QSO. Log4OM does NOT alter the non-compliant MODE field so any ADIF export from Log4OM is non-compliant.

3) At least one of the online logs "fixes" the non-compliant MODE, and after some syncing I often end up with two entries for the same QSO (one ADIF compliant, one ADIF non-compliant)

Fix appears to be manually editing the QSO in Log4OM and selecting the "OLIVIA8/250" mode from the dropdown, which provide a displayed mode of OLIVIA8/250 but exports compliant ADIF with <MODE:6>OLIVIA <SUBMODE:12>OLIVIA 8/500.

As far as I could find, there's no setting in Log4OM that will automatically correct QSO's imported via the ADIF Monitor, nor is there a search function to find non-compliant QSO modes. In fact Log4OM doesn't even appear to display submodes --- when I add the Sub Mode field to the recent QSO's table, it is always blank and the Mode field continues to display the Log4OM mode (combination of Mode+Submode) not the ADIF mode.

Dale,
No there is not an auto correction setting in Log4OM when monitoring an ADIF file.

Seems the issue lies with the FLDigi developers so probably best to ask them to conform to the ADIF format

In fact Log4OM doesn't even appear to display submodes --- when I add the Sub Mode field to the recent QSO's table, it is always blank and the Mode field continues to display the Log4OM mode (combination of Mode+Submode) not the ADIF mode.

This may be an issue we will look into that

Hi Terry,

Thanks for the quick response and agree with tracking things down with FLDigi folks. I suspect it will be a big ask since they are using ADIF as their native storage format, so this is akin to changing the database schema.

For completeness on the displayed Sub Mode issue, here's the truth table:

If the ADIF file has invalid MODE and no SUBMODE:
- Log4OM creates QSO with bad MODE, no SUBMODE, and will export non-compliant ADIF
If the ADIF file has invalid MODE and correct SUBMODE:
- Log4OM creates QSO with bad MODE, no SUBMODE, and will export non-compliant ADIF
If the ADIF file has no MODE and correct SUBMODE:
- Log4OM does not create a QSO
if the ADIF file has correct MODE and correct SUBMODE
- Log4OM creates a QSO with good mode, exports compliant ADIF, but does not populate Sub Mode column in table.

For ease of use, Log4OM never displays MODE / SUBMODE in your QSO Data. It's purely matter of ADIF, and ADIF is an interchange format, nothing else.
Instead, Log4OM use an internal set of modes, each mode is then described also as MODE/SUBMODE in ADIF concept, to be able to export and import back data.

Read mode from Log4OM is parsed using ADIF values, and if a valid ADIF value (couple) is identified, the right mode is loaded into Log4OM.
On some situations a bad mode can be read from the ADIF file.
We then have 3 choices here:
1) discard the QSO (i don't like that)
2) load the QSO creating a fictional mode. That will create "troubles" on output
3) load the QSO and try to fix the mode. And that's the most complex part because in some cases the "solution" is a mix of different strings.

About writing the SUBMODE in database, that field is left unused as the mode saved is the internal log4om mode, that "contains" both mode and submode information.

You can try playing with MODELIST.CSV file in the settings folder (from help menu) making a modelist_user.csv file from base and try adding/patching the file to check if it matches with your needs.
Later on i will investigate on that and i'll try to make a more robust import

Thanks for digging into

Hi Daniele,

Thanks for the response. Looking at modelist now, but I don't think that's a safe way to get where I need to go.

But it did make a couple of options spring to mind that I'll explore further:

1) Though FLDigi uses a non-standard ADIF file as it's on-disk format, it also has an ADIF export function that generates standard ADIF. Quick hack would be to call that at every log event and generate an ADIF compliant file that Log4OM would track instead of the default file.

2) expanding on the above, rather than stuffing the ADIF into a file, it may be more flexible to generate a WSJT message 12 and send that by UDP. Then add some appropriate listener ports on Log4OM and things should "just work".

As a quick update....

FLDigi does generate a full ADIF 3.x compliant file entry for each logged QSO, but does so in a temporary file at ...\fldigi.files\temp\log.adif. This file is volatile and only valid for the current run of FLDigi, but might be sufficient for what I would like to accomplish with Log4OM. Testing now....

Closing the loop after some testing....

Using the Log4OM ADIF Function to monitor the "...\flDigi.files\temp\log.adif" files seems to address all the problems. Those temporary files are ADIF v3 compliant and pressing the log button in FLDigi transfers all the data to Log4OM correctly including modes, submodes, transmit power etc. Transfer happens correctly when monitoring multiple concurrent instances of FLDigi (usually 2-4) and with or without using Log4OM's built-in FLDigi connection.

User experience is much better than when monitoring FLDigi logs\logbook.adi which uses some non-standard modes specific to flLog's schema which then required correcting in Log4OM.