toggle quoted messageShow quoted text
Here’s something to check.
Myfriend was having intermittent issues using a Lenovo i5 laptop. We found his CPU running @ 100% and memory around 70%. A little digging found he had two hardware issues.
1) he was running Win 10 woth only 4 GB ram. Upgraded to 12 GB. CPU still at 100% but memory better.
2) he was using a USB to HDMI adapter plugged into a USB 2.0 port for an external 36” TV as a monitor. This was the bottleneck. The laptop has a mini display port so he replaced the adapter with a mini display port to HDMI cable. CPU now around 30% and memory around 30%.
Last, yesterday he cloned the laptop drive to a solid state drive (they are cheap now here in U.S.). He put the SDD drive in the laptop in place of the original drive. Now everything is running MUCH faster.
For HRD Logbook we converted his log from Access to SQL Lite using MariaDB. With larger logs (mine has 20,000 contacts) it speeds logbook database queries up.
And last comment. For the reply on failed to log QSOs you can click on log QSO in WSJT-X as long as you haven’t started the next QSO. Just remember to check the start time.
Some of the intermittent logging issues may be due to CPU or memory bottlenecks in the PC. Not saying al are due to this but worth checking.
On May 12, 2020, at 6:37 AM, g4wjs <bill.8@...> wrote:
On 12/05/2020 07:22, HamApps Support
On 11/05/2020 9:37 pm, g4wjs wrote:
I am using DXKeeper for logging. My delay before checking is
set to 8 seconds which is perfectly adequate 99% or more of
the time, but occasionally when my machine is particularly
busy it trips up. Thanks for the tip on clearing the B4 cache.
How about my suggestion of a "Retry" button alongside the "Ok"
button on the error message about not confirming the logging
success, in my case that would cover all the cases as far as I
know, assuming a successful retry that finds the logged QSO
goes on to update the worked B4 cache in JTAlert.
Do you have DXKeeper set to auto-upload new QSOs to one or more
online-logbooks? If so, that is a likely cause of the occasional
extended logging times. That has been experience by
JTAlert/DXKeeper users in the past.
Regarding a "Retry" button, that would seem to be the most
sensible if it wasn't' for the code I have to work with. All the
logging code is in the main JTAlert executable and runs on the
UI thread. A Retry will involve a database access and a timeout
value (if the lookup was unsuccessful), both of which will block
the main thread. I am hesitant to add further blocking code. I
will give it some thought.
de Laurie VK3AMA
thanks for that, the online lookups are most probably the issue
as I have a WiFi connection in the shack which is a bit QRP. No
problem on the issues with implementing a "Retry" button, I had
assumed that as the failure message doesn't time out that the
required code to retry the logbook lookup was easily accessible,
but if that is not the case I fully understand the issues. Since
no one else has chipped in with similar requests, I am fine with
just clearing the B4 cache when this happens. Normally it is
pretty obvious where a station is running a frequency and
continues to call after a QSO, I have to be pretty distracted not
to notice that I have just worked them.