There is a problem how CQRlog logs QSOs that start prior to midnight GMT and end after midnight GMT.
If you start a QSO prior to midnight GMT (23:55 example) and end the QSO after midnight GMT (00:05 example) CQRlog will take log the entry as 23:55 with tomorrows date. Then for the next 24 hours all logged QSOs will be logged PRIOR to the example above.
How long has this been going on and no one has noticed?
This means the date will be tomorrow's date but will have a time of say 23:55.
I am using CQRlog in conjunction with fldigi when this happens. I am NOT using xmlrpc in this example but I am using "remote mode for fldigi". When using xmlrpc, the mode gets populated with an invalid mode name so I am not using xmlrpc at this time.
It looks like CQRLog only has one date titled qsodate. That date is the current machine date in GMT.
If you look at the "New QSO" page, it shows qsodate but shows time_on. At 00:01 the qsodate goes to the next day but the time_on indicates 23:56 which is the previous day.
Hope I'm making myself clear. This is hard to explain.
Is the general practice of logging a QSO based upon the date and time of when the QSO started or when it ends? When reporting to eQSL or LoTW, is the time_start or time_end sent? If its time_start and the only date I see in CQRLog is just the time_end date, then there is a problem.
Hi!
This is interesting bug.
Cqrlog has been in use over 10 years and this is not reported before (I have been around about 6-7 years)
"Remote mode for fldigi" is the original remote that uses IPC to read latest log entry from fldigi's log.
This bug should affect to all qsos, not just fldigi remote, I think. Do you say that it happens only with fldigi remote, not with manual qsos?
Testing this needs special arrangement as linux tends to keep system time in sync with ntp. The whole system must be disabled to be able to adjust system clock manually to repeat testing. Testing in real life here means no sleep ;-( (local summer time UTC+3)
That is why I see that if we just assign qso date at starting time it should be ok. There is no qso end date in log database, only date,start time, and time.
We have to accept the ending time with past date is not correct pair in case of date crossing time. Does that make problems with LoTW/eQSL?
Other that could be done easily is to clear end time completely if it is smaller than start time. How about that ?
--
Saku
OH1KH
fldigi has separate date_start and date_end. That keeps things quite clear.
If CQRlog doesn't keep track of both dates in the future releases than I think what should happen is when entering manually, it should populate the date and start time when a call sign is entered into the call field. Then when the save QSL button is pressed, it should populate the time_end. The date should not change when the save QSL is pressed or when time_end is updated.
When populating from fldigi, bring the date_start over and populate CQRlog date, bring time_start and time_end over and populate those two fields. Don't read the machine date or you'll overwrite the correct date coming from fldigi.
My "Edit QSO" window originally only had the column time_on. I must have changed something somewhere because it now includes both time_on and time_off. The entries are sorted by default using date/time_on and this is what was throwing everything out of wack because that date was getting updated to match time_end. The primary key must be qsodate/time_on? Is that correct? If that's the case, then the qsodate should always be the date that the qso started and should not change to match the time_end.
I don't think clearing the time_end if smaller than time_start is a good idea. Looks like the QSO never ended.
This issue happens quite a bit for me because I'm in Arizona where midnight GMT occurs at 5:00 p.m. local time. If I'm on the air, this is a pretty typical time for me.
I just wanted to also take a moment to thank you very much for being so patient with me and looking into this issue. I came from a MS Windows environment and since switching to Linux, its been one steep learning curve. Just finding applications to replace the ones I used in Windows was quite an adventure. When I came across CQRlog, I couldn't believe all of the features it had and how well it seemed to behave. I was able to bring all of my Ham Radio Deluxe logs over, including the ones from my previous call signs. It forced me to clean up some issues I had in my logbook and now everything is nice and orderly. If we can get the date/time issue figured out and get the proper mode to come over from fldigi when using XmlRpc the program will be perfect.
Once again, thank you very much for your help and patience....
Hi!
I have started rewriting of fldigi remote. I will change both the "classic" remote and xmlrpc remote.
The problem with "classic" remote comes because Cqlog is watching fldig log to see if there is any new entries.
New entry comes after qso is logged to fldigi and if it has started before midnight the date gets wrong as it is taken from system clock at the moment Cqrlog notices a new qso in fldigi's log.
I will change this as fldigi offers a date, time, and endtime. I will use them for cqrlog as it's log have just same columns (one date and start and end times)
At same go I can add also some other items offered by fldigi like name, power and serial numbers rx/tx(contest) that are not taken now to Cqrlog.
After it works I will fix the xmlrpc side. Take also date and times from there and now Dave has fixed new fldigi to give right formatted mode and submode.
When that is done I check also wsjt-x remote do work same way if it is not already done so. I can't remember what I did.
Because it is easy for you to test could you start a manual qso from NewQSO just before UTC midnight, please?
Just enter a fake call and move cursor to rst received column so that "QSO takes" counter starts to count at left side below Offline checkbox.
What happens to counter result when UTC date changes? (I guess it goes wrong)
Perhaps you could also test fldigi remote after it is fixed. I do not work other digimodes than FT very often. And, as said, have some difficulties to test UTC day change.
--
Saku
OH1KH
I will test in a few minutes.
fldigi records 2 dates. date_on and date_off along with time_on and time_off.
When a call is entered in the call field, fldigi does a lookup and locks in the date_on and time_on.
when the qso is logged, it then adds date_off and time_off. I believe all uploads to eqsl and LoTw use the date_on and time_on fields.
See attached png file.
The last 2 entries (at bottom of list) were the latest one's I added.
NL7UE was added directly from CQRlog New QSO. The timer below the date seemed to be just fine.
AA7MF was added via "remote mode for fldigi" without using XmlRpc. You can see that the date is based on whatever date was current at the time the save qso was initiated which is basically the time_end. This is WRONG. The window I have to work with 23:xx to 00:01 is pretty short. I wish I could do more testing. Hope this helps...
It still doesn't make much sense to me yet. I don't know why the NL7UE entry appears to be fine.
Norm - W7CK
File:
HI Norm!
Yesterday I finished rewriting of "remote mode for fldigi" (not xmlrpc).
What we can get from fldigi with this remote is as follows:
There is only one date and I think it is the start date. Also fldigi's log view shows only one date.
Only ADIF record of qso has also the ending date added.
But that is ok, as Cqrlog log database has only one date for qso record and it is the start date.
Before rewriting this fldigi date (in example as "31 Mar 2022") was not used at all. Date for qso was added from PC system clock at the time (+ one second) qso were logged to fldigi. So if qso started on day 30 at 23:59 and ended day 01 at 00:01 qso record date became as day 01.
After rewriting qso is logged now to Cqrlog with date that fldigi gives, in case above it will be day 30.
Also mode "OLIVIA" with submode "OLIVIA 8/500" is received and Cqrlog will save it as "OLIVIA 8/500" as there is only one column for mode in log database.
When eporting this qso to ADIF (also LoTW and eQSL uses same ADIF) Cqrlog will convert it back to Mode OLIVIA and submode OLIVIA 8/500.
That will make everybody happy.
Today I am starting to rewrite fldigi xmlrpc remote.
With the latest test version of fldigi I received from David it can send separate mode and submode via xmlrpc. So that will fix the mode problem.
I also check that date comes from fldigi and not from Cqrlog afterwards.
After that I will also check that wsjt-x remote does not have same date prolem.
--
Saku
OH1KH
Ok!
I am so far that both fldigi remotes are fixed.
Now I need testing. Could you do that, please?
If you can compile you find source from https://github.com/OH1KH/cqrlog/tree/remote_on_top
If you can not do that I can compile binary file for you (send link to my Google drive). It is just a change of /usr/bin/cqrlog to new one.
Fixes:
"classic" fldigi remote:
- whole processing of qso rewritten
- take qso time from fldigi
- set submode as mode if it exists. Should be now ADIF compatible
xmlrpc fldigi:
- take qso time from fldigi
- set submode as mode if it exists. Should be now ADIF compatible. But only with very latest test version of fldigi. WIth older versions works as before
- fldigi xmlrpc window has small changes in layout
wsjt-x remote
- qso time from wsjt-x (just checked, it was already so)
All remote modes:
- some fixes to keep better Cqrlog on background when remote modes are active
--
Saku
OH1KH
I'm not very good with Linux yet. Still struggling. I used the ppa:ok2cqr/ppa repository.
If you gave me some instructions on how to deal with binary file, I could give that one a try. I'd need some instructions though.
Norm
HI Norm!
I sent an email to your qrz.com address
--
Saku
OH1KH
I followed the directions in your email but it didn't work. I sent the message I got back to you via email.
I couldn't test. The program wouldn't run.
Actually the ok2cqr/ppa/.... was disabled on last focal update. Maybe its time for me to learn a different way to do this install?
Update running Cqrlog is not very difficult. You just need to open command console. It usually opens to your home directory ( /home/your_username ). Type just these five console commands (while cqrlog is closed):
sudo apt-get install lazarus git
git clone https://github.com/ok2cqr/cqrlog.git
cd cqrlog
make
sudo make install
Of course your did backup your ~/.config/cqrlog folder before doing this!
Either with your file browser (you must set "show hidden" to find ".config" folder.
or console command:
cp -a ~/.config/cqrlog ~/.config/cqrlogback
After that first time update you can do further updates after that by opening command console and type these (while cqrlog is closed):
git pull
cd cqrlog
make
sudo make install
If command "git pull" says "Already up to date" you do not have to issue rest three commands as there is nothing new happened with cqrlog source. Otherwise issuing them will install latest version of Cqrlog. You can do this as often as you wish, but the information of updates can also be found here: https://github.com/ok2cqr/cqrlog/commits/master and after that decide do you need update.
As additional information you can read these message chains:
Raspberry PI 4 and cqrlog https://www.cqrlog.com/node/3124
New Ubuntu and latest cqrlog https://www.cqrlog.com/node/2984
Mint 20 Cinnamon and new cqrlog https://www.cqrlog.com/node/2998
--
Saku
OH1KH
SORRY!
Here is the right order of commands after the first update is done (the one having "git clone")
cd cqrlog
git pull
make
sudo make install
--
Saku
OH1KH
Has this issue been fixed?
HI!
If I remember right it was fixed along with these submode issues:
https://github.com/ok2cqr/cqrlog/commit/9384102e8c24b2d89640a8a878887dc9...
The pull request date fits against your message date. Sorry that it is not mentioned in text. The fix grow so big because the submode handling was totally changed that some parts were not documented.
David did also some changes in fldigi for dates and modes and in latest fldigi they should be ok so that fldigi sends start time with IPC (the classic cqrlog fldigi remote) instead of end time and xml side was fixed fixed to send proper ADIF standard mode an submode pairs.
So if fldigi can do it right (is new enough) Cqrlog should have it ok in the log either with IPC or XML remotes.
If you look at https://github.com/ok2cqr/cqrlog/commits/master you can see that lots of other fixes have been added too since May 7.
Click the "..." (three dots icon) to see the explanations of commits.
--
Saku
OH1KH
I think the BIN would be easier for me. I have no idea how to compile.