Date   

locked Re: Logging failures do not update worked before information

David De Coons
 

It is not misinformation about the RAM. I did not know at the time his CPU was at 100%. He had 4 GB ram running Windows 10 with SmartSDR (for Flex Radio), SSDR CAT, SSDR DAX, JTALERT, WSJT-C, HRD and HRD Logbook running. As I stated his ram usage was over 70%. The poor laptop was swapping stuff back and forth to the swap file on the hard drive. RAM upgrade was the easiest thing to try first. Again 4 GB is NOT enough. 

The video adapter was the cause of CPU @ 100%. Once he changed the cable and used the native display port VPU came down to a very reasonable level. 

I too have been working with PCs since the 8086 days. 

73
Dave wo2x

Sent from my waxed string and tin cans. 

On May 12, 2020, at 9:10 AM, Dev Null <aptget@...> wrote:


Upgraded to 12 GB. CPU still at 100% but memory better.
I am sorry,  I can't help it, but misinformation in public forums really bothers me. Especially in a great group like this one.

(This is not directed at you personally, I am just using your post as an example.) It is unfortunately true that folks in general think that increasing RAM will make computers faster. In 90% of cases, it will make no difference whatsoever. The only time it does is when the computer is actually deficient, which never happens any more, since all have come with at least 8GB for many years now.

This is not to say that I personally don't load them up with RAM too. But it is only for "insurance."

I take care of hundreds of Windows machines, been doing it for decades, and I regularly check their actual RAM usage. You can do this yourself by just hitting ctl-alt-del and looking at task manager. You will find that in most cases, even with multiple programs running, usage will be below 4GB. The reason people add RAM is simple: because they can. 

I commend you for pointing out the single biggest improvement anyone can make to a computer today, which is to switch from a mechanical hard disk to a SSD (solid state drive.) Doing this will give you more improvement by far than anything else you can do, short of replacing the computer. It is truly dramatic.

As you mentioned, the street price of a 256 SSD is down below $50 US, so this is a no-brainer. Finally, I would suggest a clean install to the new SSD, rather than a clone, but I do understand that many are not up to that. In the words of Adrian Monk, "you will thank me later."


locked Re: Logging failures do not update worked before information

Dev Null
 

Upgraded to 12 GB. CPU still at 100% but memory better.
I am sorry,  I can't help it, but misinformation in public forums really bothers me. Especially in a great group like this one.

(This is not directed at you personally, I am just using your post as an example.) It is unfortunately true that folks in general think that increasing RAM will make computers faster. In 90% of cases, it will make no difference whatsoever. The only time it does is when the computer is actually deficient, which never happens any more, since all have come with at least 8GB for many years now.

This is not to say that I personally don't load them up with RAM too. But it is only for "insurance."

I take care of hundreds of Windows machines, been doing it for decades, and I regularly check their actual RAM usage. You can do this yourself by just hitting ctl-alt-del and looking at task manager. You will find that in most cases, even with multiple programs running, usage will be below 4GB. The reason people add RAM is simple: because they can. 

I commend you for pointing out the single biggest improvement anyone can make to a computer today, which is to switch from a mechanical hard disk to a SSD (solid state drive.) Doing this will give you more improvement by far than anything else you can do, short of replacing the computer. It is truly dramatic.

As you mentioned, the street price of a 256 SSD is down below $50 US, so this is a no-brainer. Finally, I would suggest a clean install to the new SSD, rather than a clone, but I do understand that many are not up to that. In the words of Adrian Monk, "you will thank me later."


locked Re: Logging failures do not update worked before information

David De Coons
 

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.

73
Dave wo2x


On May 12, 2020, at 6:37 AM, g4wjs <bill.8@...> wrote:


On 12/05/2020 07:22, HamApps Support (VK3AMA) wrote:
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.

73
Bill
G4WJS

Bill,

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

Hi Laurie,

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.

73
Bill
G4WJS.


--
73
Bill
G4WJS.


locked Re: WSJT-X WSPR with JTAlert

Joe Subich, W4TV
 

Why? WSPR is a *broadcast* (SWL) protocol - not a QSO based protocol.
There is no QSO data exchanged/acknowledged only two stations hearing
each other.

73,

... Joe, W4TV

On 2020-05-12 3:44 AM, Niek wrote:
Thanks Laurie, that's a shame.


locked Re: Logging failures do not update worked before information

g4wjs
 

On 12/05/2020 07:22, HamApps Support (VK3AMA) wrote:
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.

73
Bill
G4WJS

Bill,

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

Hi Laurie,

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.

73
Bill
G4WJS.


--
73
Bill
G4WJS.


locked Re: Losing connection to 2.2.0-rc1

Dany VE2EBK
 

Hi Laurie

In my case. WSJT-X 64bit.

73 Dany VE2EBK


locked Re: WSJT-X WSPR with JTAlert

Niek
 

Thanks Laurie, that's a shame.


locked Re: Logging failures do not update worked before information

WB8ASI Herb
 

Laurie,  I don't know about a Retry, but seems it might be possible.  There is the Last QSO Log that it tells us it's there.  I have stumbled around in the past and somehow got it to get it back in the log.  Usually it's easier for me to just enter the info into the log from the still visible screen, but I can't remember how to retrieve it from the Last QSO Log, but that's gotta be a clue for a Retry.  Thanks again. 73 Herb WB8ASI  Can't sleep.

On May 12, 2020 at 2:22 AM "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...> wrote:

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.

73
Bill
G4WJS

Bill,

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


 


locked Re: Logging failures do not update worked before information

HamApps Support (VK3AMA)
 

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.

73
Bill
G4WJS

Bill,

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


locked Re: The call database shows that I operate from MN, I have never had an address there #FT8

HamApps Support (VK3AMA)
 

On 11/05/2020 1:16 pm, aa7g.gert@... wrote:
The JTAlert Call database shows that I operate from MN but the thing is I have never had an address in that state. I don´t know why I have been associated with that state in the call database. There are no official sources that lists me in MN whatsoever and there never have been. Someone must have added AA7G in MN to the call database so can that someone please correct my call to show ME instead since I do all my FT8 operating from Maine. Thank you in advance,

Gert, AA7G with FCC address in Oregon but operating from Maine

Gert,

Your in the database as "MN" because there is an override for your callsign in the code, overriding the FCC reported State. Your Callsign and several other US hams have overrides being applied. These are only done when I have been contacted personally requesting an FCC listed State override.

My guess is that I mistakenly wrote "MN" instead of "ME" when you first requested the override (I no longer have that email to confirm the request details).
That change has now been made.
This is a direct copy of the relevant hard-coded SQL instruction that will get run every time the database is built...
"UPDATE [data] SET [state] = 'ME' WHERE [call] = 'AA7G';"
 
FWIW, you should consider updating your QRZ data as it lists you as in "OR" and JTAlert users will log you as in "OR" if they are using the QRZ XML service. That's is your QRZ data is also wrong and needs correcting. The same goes for your HamQTH listing as it is also wrong.

de Laurie VK3AMA


locked Re: New Marathon visual alert fault \ It's about priority

HamApps Support (VK3AMA)
 

On 11/05/2020 3:24 pm, asobel@... wrote:
It is
apparent that verbal alerts enjoy different priority then visual alerts.

Amos 4X4MF
That's true, if a Callsign generates several alerts, the sound files for all alerts are played, but only one color can be applied to the Callsign, and that will be of the highest priority alert. That is, there are no priories applied to Alert sounds, only Callsign colors. JTAlert has always done this.

de Laurie VK3AMA


locked Re: Failure to log to HRD LB after updates

HamApps Support (VK3AMA)
 

On 12/05/2020 1:00 am, WB5JJJ - George wrote:
I updated to 2.16.5 a few days ago and all was good with WSJTx v2.1.2 configurations.  

Today I updated to WSJTx v2.2.0-rc1 today and noticed that some contacts were not displayed in the JTA grid and if worked, ultimately not logged to HRD LB.  However, if the call was displayed, it logged.   Rolled back to WSJTx v2.1.2 and all returned to normal display and logging.  
--
73's
George - WB5JJJ

Which build of WSJT-X, 32bit or 64bit?

de Laurie VK3AMA


locked Re: JTDX AND JTALERT

HamApps Support (VK3AMA)
 

On 12/05/2020 1:49 am, F6HRP Alain wrote:
hello I use JTDX and JTALert and I have a question:
in the window of jtalert when i click on a callsign how done so that enabletx of jtdx not in red (TX)
73 de alain F6HRP/TM22P
JTDX does not respond to all Callsign clicks in JTAlert. it only works for CQ decodes. WSJT-X doesn't have this problem.

This is not a JTAlert limitation, it is how the JTDX developers chose to change the WSJT-X UDP protocol.

de Laurie VK3AMA


locked Re: JTAlert 2.16.5 working with WSJT-X 2.2.0.rc1

HamApps Support (VK3AMA)
 

On 12/05/2020 2:31 am, Jim AF5FH wrote:
Downloaded WSJT-X 2.2.0.rc1 and installed. So far have made multiple contacts using FT8 on several bands. No issues with JTAlert. Contacts are being logged to DXKeeper and uploaded to eQSL and LoTW.

Thanks!

73,
Jim AF5FH
Tnx Jim, good to hear.

de Laurie VK3AMA


locked Re: WSJT-X WSPR with JTAlert

HamApps Support (VK3AMA)
 

On 12/05/2020 5:28 am, Niek wrote:
New user of JTAlert (v. 2.16.5).
It works nice with WSJT-X (v. 2.1.2) in for example FT8 mode, everything gets picked up by JTAlert.
However in WSPR mode, nothing arrives in JTAlert.
The titlebar of JTAlert updates and shows WSPR, but none of the decodes seem to be picked up.
Am I missing a setting?

I searched the forum and read the help file, sorry if I missed something.

Short answer, JTAlert doesn't support processing and alerting on WSPR decodes. Sorry that is unlikely to change.

de Laurie VK3AMA


locked Re: Km vs Miles

HamApps Support (VK3AMA)
 

On 12/05/2020 5:14 am, Mark W2OR via groups.io wrote:
Why there are two such settings is beyond me, but there's surely good reasons ... which I really don't need to know.  
There are two different settings because the Decodes window, part of the JTAlertV3 project is written in a language different from the base JTAlert code and uses a different mechanism for settings storage.

I chose not to try and integrate the Decodes Settings into the JTAlert Settings because of the fundamental differences in how the settings are managed. In JTAlert, opening the Settings window stops all decodes alerting and any changes are not applied until the Settings window is closed, you cannot run JTAlert while leaving its Settings window open. With the Decodes window (and the future JTAlertV3), its Settings window can remain open and any changes are applied in real-time (try adjusting the row height and  see what I mean).

de Laurie VK3AMA


locked Re: Zones Problem

HamApps Support (VK3AMA)
 

On 12/05/2020 12:11 pm, Joe Subich, W4TV wrote:

Please don't!  CQ is the only one that is associated with a useful award
and should always come first.  I would not even mind if ITU zone were
not displayed at all.

73,

   ... Joe, W4TV

Don't worry Joe there will be no changes.

I have always referred to zone pairs as CQ first ITU second. To me it feels more natural because "C" comes before "I" in the alphabet I am guessing.
 
Referring to the Gold-Standard, DXLab, I note DXView is CQ first, same for DXKeeper and the Capture window. A qucik look at ACLog it is the same. I don't bother checking any other loggers.

de Laurie VK3AMA


locked Re: Losing connection to 2.2.0-rc1

HamApps Support (VK3AMA)
 

On 12/05/2020 2:36 pm, Jim Brown wrote:
Same here. And logging seems not to work.
What build type of WSJT-X 32bit or 64bit?

de Laurie VK3AMA


locked Re: Losing connection to 2.2.0-rc1

HamApps Support (VK3AMA)
 

On 12/05/2020 1:31 am, Jon KM8V wrote:
I seems like 2.16.5 is losing it's connection to WSJT-X 2.2.0-rc1. After a few minutes, it stops highlighting, logging, etc and needs to be restarted to establish the connection. 
What build of WSJT-X 2.2.0-rc1, 32bit or 64bit?
Are you by any chance running 2.2.0-rc1 with elevated privileges (set to run as administrator)?

None of the JTAlert Test Team have reported an issue like this.

de Laurie VK3AMA


locked Re: Losing connection to 2.2.0-rc1

Jim Brown
 

Same here. And logging seems not to work.

On Mon, May 11, 2020 at 7:30 PM Dany VE2EBK <ve2ebk@...> wrote:
Same observation here. Everything seems to stop after a first QSO.

73
Dany VE2EBK