I'm running CQRlog v2.5.2, fldigi v4.1.20 along with fldigi xmlrpc.
I currently have CQRlog setup to start fldigi as remote.
The problem I'm having is the way the mode gets logged. As an example. When operating the digital mode Olivia, it will log as Olivia-8/500 or Olivia-32-1k.
At the end of the day when I upload my new QSOs to eQSL and LoTW, I get errors telling me that the mode is invalid. I then have to go into each and every log entry and change the mode to a valid entry such as: Changed Olivia-8/500 to OLIVIA, changed THOR8 to THOR.
I'm not sure what to do to fix this issue and I can't believe I'm the only one experiencing this
Hi!
Did your read my replies from linuxham.groups.io (2pcs) ?
Problem is that while fldigi is logging Olivia ok to its own log (without "-" between) it sends it with "-" via xmlrpc to Cqrlog that then accepts it as mode. How ever eQSL does not accept Olivia with "-" as it is not by ADIF standard.
My opinion is that fldigi should send mode in same format via xmlrpc as it logs it to it's own log.
It is not matter of Cqrlog to fix non standard expression of fldigi. (I have asked to fix this, no reply)
--
Saku
OH1KH
Here I made a test qso with fldigi (4.1.20.36) xmlrpc with my xyl's call and mode Olivia-8/500 and then tried to upload it to eQSL. Got error . Then removed "-" from mode. It went through.
If you look NewQSO worked before list you see fixed mode without "-". If you look NewQSO/mode there is still mode with "-" as it comes from xmlrpc remote.
Below is failed upload to eQSL and then succeeded when "-" was removed from mode.
The problem is that fldigi sends Olivia with dash "-" that is not standard ADIF, while it logs it to it's own log without "-"
--
Saku
OH1KH
Another thing I've noticed
Another thing I've noticed but will have to try to verify further; When I log a QSO that takes place after 00:01 am GMT which should be tomorrow's date, it doesn't get the date right. It seems to use the local date. I believe its because xmlrpc isn't passing the date to CQRlog?
Is that happening to anyone else?
Yep!
xmlrpc passes only timeon and timeoff.
Date comes from Cqrlog.
But I do not understand why this fails. Specially if fldigi and Cqrlog are runnig in same PC.
They should use same PC's RTC to get date and time. Cqrlog uses UTC (if your PC's system clock is set to UTC as it should).
Local time is always derived from UTC by Linux system.
I have local time in my displays LXDE statusbar. And still fldigi and cqrlog will log qso using UTC (what my PC's system RTC is using)
Have you installed linux using local time for system (RTC) clock?
--
Saku
OH1KH
I have no idea why but the date has been correct for the past 24 hours. Scratching my head. I wish I knew what changed but glad the date is now working as it should. I made no changes that I can think of since the last time the date did not work correctly.
Hi!
Ok.
This may be related to errors I have seen for long. They are so random that I have not been able to catch them.
First one is that sometimes you can get an error splash saying:
"'2022-03-29' is not valid date" Abort/OK
The date is usually current date and this error happens when saving qso. There is no way to pass it with OK, it needs Abort and restart of Cqrlog. After restart everything works ok again.
The second problem is that when you have started Cqrlog and open QSO list, or see already worked qsos on top of NewQSO they do not have date at all. The column is completely empty for all qsos.
If that happens, then also saving a new qso leads to error splash. But "not valid date" error splash appears also when QSO list has dates.
This is very nasty and reason needs to be found, but no luck so far.
--
Saku
OH1KH
Dig Olivia from standard:
https://adif.org/312/ADIF_312.htm#Mode_Enumeration
--
Saku
OH1KH