- Use fldigi for general logging serial numbers#
- Use fldigi for general logging manual#
- Use fldigi for general logging Offline#
Perhaps you could also test fldigi remote after it is fixed. What happens to counter result when UTC date changes? (I guess it goes wrong)
Use fldigi for general logging Offline#
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.
Use fldigi for general logging manual#
I can't remember what I did.īecause it is easy for you to test could you start a manual qso from NewQSO just before UTC midnight, please? When that is done I check also wsjt-x remote do work same way if it is not already done so. Take also date and times from there and now Dave has fixed new fldigi to give right formatted mode and submode.
Use fldigi for general logging serial numbers#
I will use them for cqrlog as it's log have just same columns (one date and start and end times)Īt 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.Īfter it works I will fix the xmlrpc side. I will change this as fldigi offers a date, time, and endtime. 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. The problem with "classic" remote comes because Cqlog is watching fldig log to see if there is any new entries. I will change both the "classic" remote and xmlrpc remote. I have started rewriting of fldigi remote. I don't think clearing the time_end if smaller than time_start is a good idea. 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. 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. I must have changed something somewhere because it now includes both time_on and time_off.
My "Edit QSO" window originally only had the column time_on. Don't read the machine date or you'll overwrite the correct date coming from fldigi. 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. The date should not change when the save QSL is pressed or when time_end is updated. Then when the save QSL button is pressed, it should populate the time_end. 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. How about that ?įldigi has separate date_start and date_end. Other that could be done easily is to clear end time completely if it is smaller than start time. We have to accept the ending time with past date is not correct pair in case of date crossing time. There is no qso end date in log database, only date,start time, and time. That is why I see that if we just assign qso date at starting time it should be ok.
Testing in real life here means no sleep -( (local summer time UTC+3) The whole system must be disabled to be able to adjust system clock manually to repeat testing. Testing this needs special arrangement as linux tends to keep system time in sync with ntp. Do you say that it happens only with fldigi remote, not with manual qsos? This bug should affect to all qsos, not just fldigi remote, I think. "Remote mode for fldigi" is the original remote that uses IPC to read latest log entry from fldigi's log. Cqrlog has been in use over 10 years and this is not reported before (I have been around about 6-7 years)
0 kommentar(er)
