Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Error reading from Callbook databases
24-07-2021, 10:27 PM, (This post was last modified: 24-07-2021, 10:42 PM by EI4KF.)
#1
Photo  Error reading from Callbook databases
Starting with version 5.102b, I have the error seen in the picture below:

   

I have Swisslog set to read from qrz.com and is doing so on every contact but in this version the name being pulled for the latest QSO is not sent to the Operator field and instead I get a sequence of the last name being transferred into the new QSOs. The QTH for all QSOs is pulled and transferred correctly. After a certain number of QSOs, a correct name is put in the Operator field but soon the duplicates start to happen again.

At the time of the QSOs, when Swisslog fetches the data, the correct name is seen in the Entry of QSO window; example 7L2CDG who is Yasunori but was logged with the name transferred from a previous QSO:

   


Which then leads to another problem that has started which is that I can no longer correct Operator and QTH errors with the Update QSO Data from Callbook CD and Internet databases. The function appears to work, it accesses qrz.com, but the data in the Fields I ask it to fetch and overwrite existing data is not changed.

Erik.
Reply
25-07-2021, 02:24 AM,
#2
RE: Error reading from Callbook databases
Hello Erik,

I'm not able to reproduce your first issue. I work many QSOs every day and all names are set properly and I'm also reading from QRZ. Please send me a screenshot of the Field Copy instruction tab of your Callbook settings. This way I could try to reproduce this issue. I haven't changed anything on this (remember I restored the original code in 5.102b) but I need to see your settings to try to find out something.

Regarding the second issue, Walter programmed this in a weird way: it replaced the name in the Callbook table, but the Operator field in the QSO was only replaced if it was empty. So the name in the Callbook table was always replaced but the operator name not (normally is filled out). I think, if user set this option to overwrite operator, both operator names must be overwritten either in the QSO and Callbook table.

QTH is replaced (if overwrite option is checked) only if it's the HomeQTH and not portable (logical). This works as expected.

I have uploaded a new beta fixing this:

www.swisslogforwindows.com/Beta/SwisslV5.exe

I have also made a fix restoring a line from version 5.8 which I changed it in version 5.9 which may has something to do with first issue. However I fixed this 7 years ago with no reports from any user and myself. Please test and let me know.

Best 73


I have uploaded a beta fixing this.
Jordi, EA3GCV
Current developer of Swisslog
Reply
25-07-2021, 09:10 AM, (This post was last modified: 25-07-2021, 11:21 AM by EI4KF.)
#3
RE: Error reading from Callbook databases
(25-07-2021, 02:24 AM)EA3GCV Wrote: Hello Erik,

I'm not able to reproduce your first issue. I work many QSOs every day and all names are set properly and I'm also reading from QRZ. Please send me a screenshot of the Field Copy instruction tab of your Callbook settings. This way I could try to reproduce this issue. I haven't changed anything on this (remember I restored the original code in 5.102b) but I need to see your settings to try to find out something.

Regarding the second issue, Walter programmed this in a weird way: it replaced the name in the Callbook table, but the Operator field in the QSO was only replaced if it was empty. So the name in the Callbook table was always replaced but the operator name not (normally is filled out). I think, if user set this option to overwrite operator, both operator names must be overwritten either in the QSO and Callbook table.

QTH is replaced (if overwrite option is checked) only if it's the HomeQTH and not portable (logical). This works as expected.

I have uploaded a new beta fixing this:

www.swisslogforwindows.com/Beta/SwisslV5.exe

I have also made a fix restoring a line from version 5.8 which I changed it in version 5.9 which may has something to do with first issue. However I fixed this 7 years ago with no reports from any user and myself. Please test and let me know.

Best 73


I have uploaded a beta fixing this.
Hello Jordi

1st issue: my Field copy instruction tab is set thus:

   

I will need to test later to see if restoring the line from 5.8 has had any effect. It takes a string of QSOs as per my log extract for the issue to occur. So I will try on a run of JAs later this morning. I will update the thread with the result.

2nd issue: FIXED!! Well done, thank you. At least now I can correct problems caused by the 1st issue and I already did so for that portion of my log that I posted yesterday.

Erik.
Reply
25-07-2021, 10:34 PM, (This post was last modified: 25-07-2021, 11:23 PM by EA3GCV.)
#4
RE: Error reading from Callbook databases
Hello Erik,

I have had to delete again the line restored from 5.8. Other beta tester have found that in latest beta QTH locator was not passed on the QSO. I have revised the code carefully and this line has direct relation for Region field (such US State) and geo coordinates. It has nothing to do with other fields such name, QTH etc. I did this fix in 5.9 and I didn't recall why I did it but it was obvious it was needed! I have updated the beta restoring this line and leaving it as it was before.

Your first issue is really weird, I'm unabled to reproduce it here and nobody has report me anything similar (even other very active beta testers). I haven't changed anything on this. I don't understand why it sets the same name in new QSOs from previous callsigns. Did you check if you had previous QSOs with such callsigns? in such case, could you please see what operator name is set in previous QSOs for such call? Remember that the saved name in previous QSO prevail over the QRZ name.  Maybe it was a big coincidence for these callsigns and the operator name was wrong.

By the way, I have implemented S-Meter reading from TCI. Could please give it a try to see if it works?

Best 73
Jordi, EA3GCV
Current developer of Swisslog
Reply
26-07-2021, 08:46 AM,
#5
RE: Error reading from Callbook databases
(25-07-2021, 10:34 PM)EA3GCV Wrote: Hello Erik,

I have had to delete again the line restored from 5.8. Other beta tester have found that in latest beta QTH locator was not passed on the QSO. I have revised the code carefully and this line has direct relation for Region field (such US State) and geo coordinates. It has nothing to do with other fields such name, QTH etc. I did this fix in 5.9 and I didn't recall why I did it but it was obvious it was needed! I have updated the beta restoring this line and leaving it as it was before.

Your first issue is really weird, I'm unabled to reproduce it here and nobody has report me anything similar (even other very active beta testers). I haven't changed anything on this. I don't understand why it sets the same name in new QSOs from previous callsigns. Did you check if you had previous QSOs with such callsigns? in such case, could you please see what operator name is set in previous QSOs for such call? Remember that the saved name in previous QSO prevail over the QRZ name.  Maybe it was a big coincidence for these callsigns and the operator name was wrong.

By the way, I have implemented S-Meter reading from TCI. Could please give it a try to see if it works?

Best 73

Hello Jordi,

I do have previous QSOs with most of the affected contacts. In those the Operator name is correct. All my logbook Operator names are correct for Swisslog versions before 5.102b. I am still testing the beta with the line change and so far it has not happened but I have not made that many QSOs yet. I will continue to test and then change to the newest beta and see if there is any difference. 

Regarding the S-Meter in TCI, as I am now on the Flex I will need to update Swisslog on the Expert Electronics MB1 and test it. In next days I will do it and send you an email with the result.

Erik.
Reply
01-08-2021, 10:56 AM,
#6
RE: Error reading from Callbook databases
(26-07-2021, 08:46 AM)EI4KF Wrote:
(25-07-2021, 10:34 PM)EA3GCV Wrote: Hello Erik,

I have had to delete again the line restored from 5.8. Other beta tester have found that in latest beta QTH locator was not passed on the QSO. I have revised the code carefully and this line has direct relation for Region field (such US State) and geo coordinates. It has nothing to do with other fields such name, QTH etc. I did this fix in 5.9 and I didn't recall why I did it but it was obvious it was needed! I have updated the beta restoring this line and leaving it as it was before.

Your first issue is really weird, I'm unabled to reproduce it here and nobody has report me anything similar (even other very active beta testers). I haven't changed anything on this. I don't understand why it sets the same name in new QSOs from previous callsigns. Did you check if you had previous QSOs with such callsigns? in such case, could you please see what operator name is set in previous QSOs for such call? Remember that the saved name in previous QSO prevail over the QRZ name.  Maybe it was a big coincidence for these callsigns and the operator name was wrong.

By the way, I have implemented S-Meter reading from TCI. Could please give it a try to see if it works?

Best 73

Hello Jordi,

I do have previous QSOs with most of the affected contacts. In those the Operator name is correct. All my logbook Operator names are correct for Swisslog versions before 5.102b. I am still testing the beta with the line change and so far it has not happened but I have not made that many QSOs yet. I will continue to test and then change to the newest beta and see if there is any difference. 

Regarding the S-Meter in TCI, as I am now on the Flex I will need to update Swisslog on the Expert Electronics MB1 and test it. In next days I will do it and send you an email with the result.

Erik.

This error in Swisslog continues.

   

It seems to start happening when there is a very short delay between logging stations. For example, I see it mostly when on a run of JAs in FT8. These guys often start with TX2 and hence each QSO takes 45 seconds. Then Swisslog copies the previous name into the Operator Field instead of the correct name as seen in the Entry Of QSOs window as obtained from qrz.com

The ways in which I have seen the sequence of repeated Operator Name stop is either a gap in logging occurs (for example if the run is broken by a CQ) or if I close and reopen Swisslog. All is then normal until there is a rush of loggings in a short period, say 2 in a minute or 3 in 2 minutes. 

From a layman's user perspective, the QTH Field is not affected by the quick input from the online database but the Operator Field is not ready, maybe the new data has not passed to it in a timely fashion, and hence it takes the last data when the QSO is saved. 

Erik.
Reply
01-08-2021, 02:01 PM,
#7
RE: Error reading from Callbook databases
Hello Erik,

This is a very weird issue really... I haven't received any similar report but it's obvious it's happening... Because I'm not able to reproduce it, I need to know when callsign is passed into the QSO Entry window if the Operator field is filled out with the right name. I need to know at which point the Operator field remains from the last QSO. The Operator name should be filled out properly in the QSO Entry. I have revised the code, and when retrieving data from Callbook database, the Operator field is always cleared.

I think it will be a hard bone to solve but please let me know this to see if I can find the exact point when things are starting to go wrong...

Best 73
Jordi, EA3GCV
Current developer of Swisslog
Reply
01-08-2021, 02:55 PM, (This post was last modified: 01-08-2021, 02:57 PM by EI4KF.)
#8
RE: Error reading from Callbook databases
(01-08-2021, 02:01 PM)EA3GCV Wrote: Hello Erik,

This is a very weird issue really... I haven't received any similar report but it's obvious it's happening... Because I'm not able to reproduce it, I need to know when callsign is passed into the QSO Entry window if the Operator field is filled out with the right name. I need to know at which point the Operator field remains from the last QSO. The Operator name should be filled out properly in the QSO Entry. I have revised the code, and when retrieving data from Callbook database, the Operator field is always cleared.

I think it will be a hard bone to solve but please let me know this to see if I can find the exact point when things are starting to go wrong...

Best 73

Hello Jordi, I am not sure much how more information I can give you that you do not already know. When a FT8 QSO is started, Swisslog retrieves the Operator Name and QTH from the callsign database - in my case qrz.com. I get this data quickly, almost instantly as I no longer have slow internet here. So 30 seconds on from the Callsign going into the Entry of QSOs window I am seeing the Log QSO window in JTDX. About 5 seconds later, while I am sending the '73', I log it. When this logging has closely followed the previous one, the correct Operator Name does not appear in the logbook - all the other Fields are filled in correctly. The timings are the same when it works correctly, which it does when QSOs are not coming in rapidly. 

If you have a beta exe to test later, please let me have the link. It will be some time before there is another scenario in which this can happen but I will test it as soon as practical. I tried with a run of USA stations but they invariably send their Grid first and hence the QSO takes 60 seconds in which case the issue does not occur. I also tried on a run in CW but I am too slow in that mode to complete even 599/599 QSOs in less than a minute  Blush  So it has to be tested on a run of JAs sending TX2 to start.

Erik.
Reply
01-08-2021, 04:59 PM, (This post was last modified: 01-08-2021, 06:25 PM by EA3GCV.)
#9
RE: Error reading from Callbook databases
Hello Erik,

I don't think the JTDX sequence has nothing to do on this. Swisslog retrieves info as soon as a callsign is in the DX Call field from JTDX regardless the sequence. What is important to me to know is if the operator name is OK in the QSO Entry window when the QSO is started but is changed when logged. Excuse me if you told me this before but this matter it's not clear to me yet.

VERY IMPORTANT: The operator field of JTDX prevails over the info set in Swisslog! so if Swisslog retrieves the info well but you have a different name in the Log QSO window, this name will be saved in Swisslog. Review carefully this because it could be the reason of this issue. If you have a wrong name saved in the JTDX Logbook, this will always be set in the Log QSO window. I suggest you to export your logbook into JTDX by using the Tools / Export log to WSJT-X to ensure your JTDX logbook contains the same info as the Swisslog logbook.

Best 73
Jordi, EA3GCV
Current developer of Swisslog
Reply
01-08-2021, 06:44 PM,
#10
RE: Error reading from Callbook databases
(01-08-2021, 04:59 PM)EA3GCV Wrote: Hello Erik,

I don't think the JTDX sequence has nothing to do on this. Swisslog retrieves info as soon as a callsign is in the DX Call field from JTDX regardless the sequence. What is important to me to know is if the operator name is OK in the QSO Entry window when the QSO is started but is changed when logged. Excuse me if you told me this before but this matter it's not clear to me yet.

VERY IMPORTANT: The operator field of JTDX prevails over the info set in Swisslog! so if Swisslog retrieves the info well but you have a different name in the Log QSO window, this name will be saved in Swisslog. Review carefully this because it could be the reason of this issue. If you have a wrong name saved in the JTDX Logbook, this will always be set in the Log QSO window. I suggest you to export your logbook into JTDX by using the Tools / Export log to WSJT-X to ensure your JTDX logbook contains the same info as the Swisslog logbook.

Best 73

Hello Jordi

JTDX log book was created from Swisslog. It is identical. This is not the reason for the issue. I did say before but I understand how things get lost in a long discussion: I see the correct Operator Name in QSO Entry but for these QSOs it is not saved to the Operator Field in the log. The JTDX sequence is irrelevant, I was answering about timings but misunderstood your question. Essentially: the data is retrieved from qrz.com and is displayed correctly in Entry QSOs. If the QSO save is only a short time since the last save, the correct Operator Name does not go to the logbook which somehow fills the Field with data from the previous QSO. This continues unabated until there is a longer delay between QSOs or I stop and restart Swisslog.

How to fix it is another matter!! At least when this happens now, as it did today again, updating affected QSOs from online databases now works so I can put it right. 

Erik.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)