it's under working in 2.8.0.0

Yes, no automatic re-import made yet.

Yes, we monitor and check everything, but we need a bit of time to make our checks. According to our info we export PROP_MODE correctly with the correct code (SAT) if the user set this while logging his QSO (that's automatic selected starting from 2.6.1.0) It seems EQSL expects "SATELLITE" in the PR...

Hi, the only thing that changed is a DTREnable command sent during initialization phase to raise DTR pin and support serial winkeyers giving them the power they expect through the DTR pin.
That should not change anything i suppose...

I'm checking that. It's probably an issue related to checks order. Dxcc is one of the most important fields imho and v1 exports it from first release, as well as all other fields (ADIF is the backup method for Log4OM 1 and 2 so we necessarily export everything). About response timings we read everyt...

Hi Wojtek,
that's the original file not passed through excel or other application?
Because the code clearly states that the format should be dd/MM/yyyy so it's very strange and i need to try reproducing...
Let me know, thanks

Version 2.6.0 ⦁ [NEW] Serial winkeyer devices are now supported (added DTR pin HIGH on WK initialization) ⦁ [NEW] Added ADIF import checks for missing BAND/MODE. Log4OM tries to recover band from frequency if available. If found and MODE is missing, the mode will be retrieved from the bandplan as be...

can you write here the ADIF row for this QSO as originally imported?

phew... seems really strange as there are no data writers to this field in the whole code but...
i'm investigating

Ciao, abbiamo identificato un problema in talune situazioni con HRDLog.
Sarà risolto con la versione 2.6 che uscirà a breve