Date   

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


locked Re: Losing connection to 2.2.0-rc1

Dany VE2EBK
 

Same observation here. Everything seems to stop after a first QSO.

73
Dany VE2EBK


locked Re: Zones Problem

WB8ASI Herb
 

OK Joe. Consistency is good for me, but atleast you have a reason.

On May 11, 2020 at 10:11 PM "Joe Subich, W4TV" <lists@subich.com> wrote:



So maybe switch the order of the ITU and CQ postions on the JTA Fields Window......
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


On 2020-05-11 9:29 PM, WB8ASI Herb wrote:
Happy to report that Terry responded in the Log4OM forum that the Zone problem should be fixed in the next release.  Now my SUGGESTION BOX item for JTALERT is that since I've been focused on zone problems, I'm used to reading them ITU then CQ.  The only place they are reversed is on the JTA Log Fields Window.  Not a big deal, but just a cosmetic item for when you are comparing screens from different sources reading left to right it's a quick stumble for an old brain.   So maybe switch the order of the ITU and CQ postions on the JTA Fields Window......unless I've stumbled upon another US vs Metric thing, or Month/Day switcheroo, or what side of the road to drive on kinda custom. LOL.  Thanks. 73 Herb WB8ASI




locked Re: Zones Problem

Joe Subich, W4TV
 

So maybe switch the order of the ITU and CQ postions on the JTA Fields Window......
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


On 2020-05-11 9:29 PM, WB8ASI Herb wrote:
Happy to report that Terry responded in the Log4OM forum that the Zone problem should be fixed in the next release.  Now my SUGGESTION BOX item for JTALERT is that since I've been focused on zone problems, I'm used to reading them ITU then CQ.  The only place they are reversed is on the JTA Log Fields Window.  Not a big deal, but just a cosmetic item for when you are comparing screens from different sources reading left to right it's a quick stumble for an old brain.   So maybe switch the order of the ITU and CQ postions on the JTA Fields Window......unless I've stumbled upon another US vs Metric thing, or Month/Day switcheroo, or what side of the road to drive on kinda custom. LOL.  Thanks. 73 Herb WB8ASI


locked Re: Zones Problem

WB8ASI Herb
 

Happy to report that Terry responded in the Log4OM forum that the Zone problem should be fixed in the next release.  Now my SUGGESTION BOX item for JTALERT is that since I've been focused on zone problems, I'm used to reading them ITU then CQ.  The only place they are reversed is on the JTA Log Fields Window.  Not a big deal, but just a cosmetic item for when you are comparing screens from different sources reading left to right it's a quick stumble for an old brain.   So maybe switch the order of the ITU and CQ postions on the JTA Fields Window......unless I've stumbled upon another US vs Metric thing, or Month/Day switcheroo, or what side of the road to drive on kinda custom. LOL.  Thanks. 73 Herb WB8ASI


locked Re: Km vs Miles

Dave <kc3am@...>
 

Hello all, Nubie here, KC3AM

Can someone tell me just what the purpose of JTAlert is.

I am old school and can control the radio and computer just fine. I am not a contester.

With JTAlert being a popular software item I am curious.

Thanks much, Dave KC3AM

On 05/11/2020 15:14, Mark W2OR via groups.io wrote:
Thank you, Jim.  That did the trick.  Two years with JTAlert, and I had never seen that page of settings before.  Nice.

The km/miles option that had referred to earlier is on another tab. And that other tab is what was referred to in those old posts, for changing between km and miles.  Why there are two such settings is beyond me, but there's surely good reasons ... which I really don't need to know.  

Again - tks mucho.
// Mark
--
73, Dave KC3AM


locked WSJT-X WSPR with JTAlert

Niek
 
Edited

Hi,

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.

Edit: I just installed WSJT-X v. 2.2.0-rc1, but it didn't make a difference.


locked Re: Km vs Miles

Mark W2OR
 

Thank you, Jim.  That did the trick.  Two years with JTAlert, and I had never seen that page of settings before.  Nice.

The km/miles option that had referred to earlier is on another tab. And that other tab is what was referred to in those old posts, for changing between km and miles.  Why there are two such settings is beyond me, but there's surely good reasons ... which I really don't need to know.  

Again - tks mucho.
// Mark


locked Re: Km vs Miles

Jim Cooper
 

Indeed, it IS hidden in plain sight !!!

graphic

On 11 May 2020 at 11:10, Mark W2OR via groups.io wrote:

> Yes. And "Hidden in plain sight"  still applies here, as well.
>
> Here, I attempted to change the
> distance column today from 'km' to
> miles, using the instructions
> outlined in below messages, but that
> column still reappears as km.  So, I
> restarted JTA twice, to possibly help
> with a reset.  Each time it returns
> as 'km'.  And each time, in checking
> the "Decoded Callsign Data Tooltip"
> tab, the option "show distance in
> miles" was, in fact, already enabled
> for miles.  Yet the Distance column
> label and the distance numbers, are
> still in km.  Hmm.  The solution is
> hiding in front of my nose
> somewhere.

  


locked Re: Km vs Miles

Mark W2OR
 

Yes. And "Hidden in plain sight"  still applies here, as well. 

Here, I attempted to change the distance column today from 'km' to miles, using the instructions outlined in below messages, but that column still reappears as km.  So, I restarted JTA twice, to possibly help with a reset.  Each time it returns as 'km'.  And each time, in checking the "Decoded Callsign Data Tooltip" tab, the option "show distance in miles" was, in fact, already enabled for miles.  Yet the Distance column label and the distance numbers, are still in km.  Hmm.  The solution is hiding in front of my nose somewhere. 


locked JTAlert 2.16.5 working with WSJT-X 2.2.0.rc1

Jim AF5FH
 

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


locked JTDX AND JTALERT

F6HRP Alain <f6hrp@...>
 

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
 
What do you want to do ?
New mailCopy
 
What do you want to do ?
New mailCopy


locked Re: Zones Problem

Jim N6VH
 


On 5/10/2020 6:20 PM, WB8ASI Herb wrote:
...and Log4OM also has the correct zones in its Main UI window, however something goes wrong upon the logging of the QSO.  It happens over and over again.  Guess we need more chatter on the Log4OM forum to get some attention.  Jim, I switched to HamQTH per your suggestion.  73 Herb WB8ASI

Herb,

Testing with the call N3BNA, Log4OM has the zones as CQ 5 and ITU 6, and it gets logged that way. ITU should be 8. This happens whether I have Log4OM set to do no lookups, lookups from QRZ, or from HamQTH. It seems that if Log4OM doesn't know the correct zone, it enters either a "5" or "0" for the CQ zone and "6" for ITU. The odd thingis, HamQTH does have the correct zones, but they apparently weren't used, even when I had lookups set for HamQTH.

You're right - we should put this discussion on the Log4OM forum, since the problem is clearly not on the JTAlert end, and there is really nothing that can be done about it in JTAlert.

73,

Jim N6VH


locked Re: Losing connection to 2.2.0-rc1

WB5JJJ - George
 

Similar events here as posted below.
--
73's
George - WB5JJJ


locked Losing connection to 2.2.0-rc1

Jon KM8V
 

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. 


locked Failure to log to HRD LB after updates

WB5JJJ - George
 

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


locked Re: Logging failures do not update worked before information

Michael Black
 

Bill...how many QSOs do you have and how big is your database?

I ran into a couple of users there their mdb file had grown way too big and we had to backup/restore/compact and their update rates improved considerably.
There's a 2GB limit on MDB files too.

de Mike W9MDB




On Monday, May 11, 2020, 06:37:38 AM CDT, g4wjs <bill.8@...> wrote:


On 10/05/2020 23:22, HamApps Support (VK3AMA) wrote:
On 10/05/2020 6:22 am, g4wjs wrote:
Hi Laurie,

it seems that when JTAlert cannot confirm logging of a QSO in the configured logging application it does not update its internal worked before database. Often these logging failures are due to slow updates to the logging application even though the log is eventually updated. Restarting JTAlert does sort it out but until then it is easy to mistakenly work the same station twice.



-- 
73
Bill
G4WJS.
Hi Bill,

Your correct, the internal B4 cache (held in memory) does not get updated if JTAlert is unable to confirm a QSO was logged.

What Logger are you using that is experiencing the delays?

If your logger is consistently slow in writing the QSO to the log file/database and your happy that QSOs are reliably getting logged, there is the option is to turn on the "Do not check or report logging success/failure" serring, under the Logging section of the Settings (scroll the checkbox display down). With that set, JTAlert will set the B4 status regardless and not perform any code-blocking checks.

There is the option to increase the QSO check time, but that can be problematic, especially with the short period FT4, as the delay QSO check delay, which is blocking the UI thread, can extend into the new decode period and JTAlert may miss the period. The main JTAlert code is single-threaded and synchronous (no async functionality) so any additional delay added to the QSO logged check function blocks there entire code.

Rather than restarting JTAlert you can use the "Alerts -> Clear B4 cache" menu (2nd from the top).

de Laurie VK3AMA

Hi Laurie,

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.


--
73
Bill
G4WJS.

3781 - 3800 of 33231