Date   

locked Re: JTAlert scan of DXKeeper log running forever #DXLAB

HamApps Support (VK3AMA)
 

On 17/03/2019 9:51 am, Joseph Barger wrote:
Running Win 10 Pro build 1809, JTAlertX 2.13.1, DXKeeper 14.8.5 and WSJT-X 2.0.1.  When I try to run a "scan log and rebuild" it just keeps reading records without end.  I have around 6000 QSOs and I stopped (i.e. killed the process) after it read 25,000 records and was still going.  Also, the homeQTH selections are empty even though according to DXKeeper they are all set to my call (N6KK).  Logging and upload to LotW seem to work fine.

Scanning worked fine a few versions ago (of both JTAlert and DXKeeper - sorry I don't remember which versions).  Perhaps DXKeeper has made a change to the log format?

Thanks and a great program!

Joe N6KK
Joe,

Something is not right, obviously ;)

The Scan function initially reads the number of records in the log database and uses that count to display the progress.

   

Some questions...
  • What is the count of the number Records shown in your DXKeeper import?
  • Does the Record count match the count of records in your Log (the ~6000)?
  • Does the first increasing number (the progress) go beyond the Total Records number?

Please post a screen-capture of the Scan Log window during the import process (similar to the above).

de Laurie VK3AMA


locked Re: Really struggling - can't get JT Alerts to work

HamApps Support (VK3AMA)
 

On 17/03/2019 9:04 am, Martin Blaise wrote:
This is the error I get. See attached file. Thanks. some kind of adif error


The clue is in the --in="" parameter. There is no adif file set to process.

This is set automatically by JTAlert, so very likely you have enabled ADIF logging without specifying an actual adif file to use.

de Laurie VK3AMA


locked JTAlert scan of DXKeeper log running forever #DXLAB

Joseph Barger
 

Running Win 10 Pro build 1809, JTAlertX 2.13.1, DXKeeper 14.8.5 and WSJT-X 2.0.1.  When I try to run a "scan log and rebuild" it just keeps reading records without end.  I have around 6000 QSOs and I stopped (i.e. killed the process) after it read 25,000 records and was still going.  Also, the homeQTH selections are empty even though according to DXKeeper they are all set to my call (N6KK).  Logging and upload to LotW seem to work fine.

Scanning worked fine a few versions ago (of both JTAlert and DXKeeper - sorry I don't remember which versions).  Perhaps DXKeeper has made a change to the log format?

Thanks and a great program!

Joe N6KK


locked Re: Really struggling - can't get JT Alerts to work

Martin Blaise
 

This is the error I get. See attached file. Thanks. some kind of adif error

On Wed, Mar 13, 2019 at 7:24 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 14/03/2019 11:03 am:
> I want to use the information from my WSJT-X log adi file but the
> program says that will make an error. So I tried selecting ADIF as log
> file and everything crashed and said command line database?? errors. I
> am not a programmer so I can't understand how to fix that. Please help
> I am lost.........................................................

OM,

Its hard to know what your experiencing without knowing the source
application of the error and the exact message.
Post a screen-capture of the error window, that will help greatly with
diagnosis.

Please DON'T post an image of your entire desktop, just the error window.

de Laurie VK3AMA





locked Re: Problem with Marathon - DEFECT Confirmed

HamApps Support (VK3AMA)
 

On 16/03/2019 1:08 pm, Jim N6VH wrote:
I worked RM0F, Asiatic Russia, zone 19, on March 1, 2019. and the QSO is logged with the correct country and zone in LOG4OM. I have done the Scan and Rebuild routine several times since then. However, the Marathon alert still shows I need Asiatic Russia and Zone 19. They are both listed in the Wanted category.

I have Wanted CQ Marathon set for Any Band and Any Mode. I have Scan Log and Rebuild enabled and set for No QSL Confirmation for the Marathon.

I am using JTAlertX 2.13.1, with the Callsign Database version 2019.03.09.

I have checked the Help file, and checked all the settings that might be involved, and I don't see anything that could be affecting this.

73,

Jim N6VH

I can confirm that this behaviour is due to a defect in the Log import process undertaken as part of the Scan Log routine. QSOs that contained State/Prefecture data that contained a single quote were not being imported and subsequently not used in the scan.

In this specific case, it was a single quote in the Oblast recorded for RM0F, "SL // Sakhalinskaya oblast' (Sakhalin Oblast)".

de Laurie VK3AMA

 


locked Re: decodes history problem - DEFECT Confirmed

on5po
 

the problem when have click on 5v1ei it's ja5nln which is called


ON5PO, Janny


De : Support@HamApps.groups.io <Support@HamApps.groups.io> de la part de Peter Butler <capecod.wireless@...>
Envoyé : samedi 16 mars 2019 11:59
À : Support@HamApps.groups.io
Objet : Re: [HamApps] decodes history problem - DEFECT Confirmed
 

This “defect” is a GOOD THING!

PETER W1UU

 

Sent from Mail for Windows 10

 

From: on5po
Sent: Saturday, March 16, 2019 4:32 AM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] decodes history problem - DEFECT Confirmed

 

Laurie,

other problem, 2.13.1

in the window "Message" the dxcc which are signaled in alert, are privileged on the left side, even when two same station are announced on the right

 

ON5PO, janny

De : Support@HamApps.groups.io <Support@HamApps.groups.io> de la part de HamApps Support (VK3AMA) <vk3ama.ham.apps@...>
Envoyé : samedi 16 mars 2019 02:39
À : Support@HamApps.groups.io
Objet : Re: [HamApps] decodes history problem - DEFECT Confirmed

 

On 15/03/2019 6:17 pm, Hartmut Luedtke via Groups.Io wrote:

"Decodes History" is a nice function in JTAlert. But I think the display of the DT value is wrong. It is too high on my system by a factor of 10.
If JTDX displays a DT of 0.1, 1 is logged in "Decodes History", if the DT value in JTDX is 1.4, "Decodes History" logs the value 14....
Please ignore my text if the error is already known. I didn't find it in the search.

vy73 Ham, DB6LL


I can confirm this defect. It affects those running Windows with a language culture that uses the period "." as a number group separator, typically a thousands separator.

For the curious, the problem was with how the .NET Double.TryParse function was being used without consideration of the default behaviour using the current culture of the users Window installation. JTAlert is Culture invariant, it passes all numbers to the Decodes History, regardless of culture, using a period as a decimal point. The new Decodes history was not using the "Double.TryParse" correctly, I had neglected to force its operation to be culture invariant.

de Laurie VK3AMA

 


locked Re: decodes history problem - DEFECT Confirmed

Peter Butler
 

This “defect” is a GOOD THING!

PETER W1UU

 

Sent from Mail for Windows 10

 

From: on5po
Sent: Saturday, March 16, 2019 4:32 AM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] decodes history problem - DEFECT Confirmed

 

Laurie,

other problem, 2.13.1

in the window "Message" the dxcc which are signaled in alert, are privileged on the left side, even when two same station are announced on the right

 

ON5PO, janny

De : Support@HamApps.groups.io <Support@HamApps.groups.io> de la part de HamApps Support (VK3AMA) <vk3ama.ham.apps@...>
Envoyé : samedi 16 mars 2019 02:39
À : Support@HamApps.groups.io
Objet : Re: [HamApps] decodes history problem - DEFECT Confirmed

 

On 15/03/2019 6:17 pm, Hartmut Luedtke via Groups.Io wrote:

"Decodes History" is a nice function in JTAlert. But I think the display of the DT value is wrong. It is too high on my system by a factor of 10.
If JTDX displays a DT of 0.1, 1 is logged in "Decodes History", if the DT value in JTDX is 1.4, "Decodes History" logs the value 14....
Please ignore my text if the error is already known. I didn't find it in the search.

vy73 Ham, DB6LL


I can confirm this defect. It affects those running Windows with a language culture that uses the period "." as a number group separator, typically a thousands separator.

For the curious, the problem was with how the .NET Double.TryParse function was being used without consideration of the default behaviour using the current culture of the users Window installation. JTAlert is Culture invariant, it passes all numbers to the Decodes History, regardless of culture, using a period as a decimal point. The new Decodes history was not using the "Double.TryParse" correctly, I had neglected to force its operation to be culture invariant.

de Laurie VK3AMA

 


locked Re: decodes history problem - DEFECT Confirmed

on5po
 

Laurie,
other problem, 2.13.1
in the window "Message" the dxcc which are signaled in alert, are privileged on the left side, even when two same station are announced on the right


ON5PO, janny


De : Support@HamApps.groups.io <Support@HamApps.groups.io> de la part de HamApps Support (VK3AMA) <vk3ama.ham.apps@...>
Envoyé : samedi 16 mars 2019 02:39
À : Support@HamApps.groups.io
Objet : Re: [HamApps] decodes history problem - DEFECT Confirmed
 
On 15/03/2019 6:17 pm, Hartmut Luedtke via Groups.Io wrote:
"Decodes History" is a nice function in JTAlert. But I think the display of the DT value is wrong. It is too high on my system by a factor of 10.
If JTDX displays a DT of 0.1, 1 is logged in "Decodes History", if the DT value in JTDX is 1.4, "Decodes History" logs the value 14....
Please ignore my text if the error is already known. I didn't find it in the search.

vy73 Ham, DB6LL

I can confirm this defect. It affects those running Windows with a language culture that uses the period "." as a number group separator, typically a thousands separator.

For the curious, the problem was with how the .NET Double.TryParse function was being used without consideration of the default behaviour using the current culture of the users Window installation. JTAlert is Culture invariant, it passes all numbers to the Decodes History, regardless of culture, using a period as a decimal point. The new Decodes history was not using the "Double.TryParse" correctly, I had neglected to force its operation to be culture invariant.

de Laurie VK3AMA



locked Re: decodes history problem - DEFECT Confirmed

Hartmut Luedtke
 

Hello group :-)

What a big difference such a small punctuation mark can make. I was allowed to test the bugfixed version already and can say it works now. I'm pleased how quickly Laurie responded.

Thanks to Laurie and greetings to the group.


73 Ham, DB6LL

---------------------

HamApps Support (VK3AMA) <vk3ama.ham.apps@...>
An:Support@HamApps.groups.io
16. März um 02:40
On 15/03/2019 6:17 pm, Hartmut Luedtke via Groups.Io wrote:
"Decodes History" is a nice function in JTAlert. But I think the display of the DT value is wrong. It is too high on my system by a factor of 10.
If JTDX displays a DT of 0.1, 1 is logged in "Decodes History", if the DT value in JTDX is 1.4, "Decodes History" logs the value 14....
Please ignore my text if the error is already known. I didn't find it in the search.

vy73 Ham, DB6LL

I can confirm this defect. It affects those running Windows with a language culture that uses the period "." as a number group separator, typically a thousands separator.

For the curious, the problem was with how the .NET Double.TryParse function was being used without consideration of the default behaviour using the current culture of the users Window installation. JTAlert is Culture invariant, it passes all numbers to the Decodes History, regardless of culture, using a period as a decimal point. The new Decodes history was not using the "Double.TryParse" correctly, I had neglected to force its operation to be culture invariant.

de Laurie VK3AMA


locked Re: Problem with Marathon

HamApps Support (VK3AMA)
 

On 16/03/2019 1:08 pm, Jim N6VH wrote:
I worked RM0F, Asiatic Russia, zone 19, on March 1, 2019. and the QSO is logged with the correct country and zone in LOG4OM. I have done the Scan and Rebuild routine several times since then. However, the Marathon alert still shows I need Asiatic Russia and Zone 19. They are both listed in the Wanted category.

I have Wanted CQ Marathon set for Any Band and Any Mode. I have Scan Log and Rebuild enabled and set for No QSL Confirmation for the Marathon.

I am using JTAlertX 2.13.1, with the Callsign Database version 2019.03.09.

I have checked the Help file, and checked all the settings that might be involved, and I don't see anything that could be affecting this.

73,

Jim N6VH
Jim,

I can't fault JTAlert with respect to RM0F.

As a test, I created a new empty log, ran a Marathon Scan Log and confirmed that all Zones and Countries are listed as still needed for the Marathon alert. Set WSJT-X DX Call to RM0F and JTAlert correctly identified him as AS Russia in Zone19 in the log fields area. Logged the QSO. Restarted JTAlert, than ran the Scan Log and AS Russia & Zone19  were correctly identified as no longer needed with the Marathon Alert list showing both as not needed.

Are you sure your log correctly has RM0F as AS Russia and Zone19? If so, than double-check that the Scan Log setting for the Marathon alert is set to no QSL confirmation. These are the only way I can explain what your observing.

If you confident that all is correct with your Log and the Scan settings, than I will need to see your JTAlert files and a copy of your Log4OM log file. Do the following...
  • Run a Marathon Scan Log.
  • After the Scan, use the "? -> Contact Support" menu, on the JTAlert title-bar, to send me your JTAlert files for analysis.
  • Send me direct, NOT via this group, your Log4OM log file zipped up, or put it into DropBox or similar and send me the link (don't post the link to the group either).

de Laurie VK3AMA


locked Problem with Marathon

Jim N6VH
 

Laurie,

I worked RM0F, Asiatic Russia, zone 19, on March 1, 2019. and the QSO is logged with the correct country and zone in LOG4OM. I have done the Scan and Rebuild routine several times since then. However, the Marathon alert still shows I need Asiatic Russia and Zone 19. They are both listed in the Wanted category.

I have Wanted CQ Marathon set for Any Band and Any Mode. I have Scan Log and Rebuild enabled and set for No QSL Confirmation for the Marathon.

I am using JTAlertX 2.13.1, with the Callsign Database version 2019.03.09.

I have checked the Help file, and checked all the settings that might be involved, and I don't see anything that could be affecting this.

73,

Jim N6VH


locked Re: decodes history problem - DEFECT Confirmed

HamApps Support (VK3AMA)
 

On 15/03/2019 6:17 pm, Hartmut Luedtke via Groups.Io wrote:
"Decodes History" is a nice function in JTAlert. But I think the display of the DT value is wrong. It is too high on my system by a factor of 10.
If JTDX displays a DT of 0.1, 1 is logged in "Decodes History", if the DT value in JTDX is 1.4, "Decodes History" logs the value 14....
Please ignore my text if the error is already known. I didn't find it in the search.

vy73 Ham, DB6LL

I can confirm this defect. It affects those running Windows with a language culture that uses the period "." as a number group separator, typically a thousands separator.

For the curious, the problem was with how the .NET Double.TryParse function was being used without consideration of the default behaviour using the current culture of the users Window installation. JTAlert is Culture invariant, it passes all numbers to the Decodes History, regardless of culture, using a period as a decimal point. The new Decodes history was not using the "Double.TryParse" correctly, I had neglected to force its operation to be culture invariant.

de Laurie VK3AMA



locked Re: JTAlert text messages

Richard Robbins
 

If I get a message.  I will see a pop up.  If I don’t see the pop up.  No further notification 

Richard Robbins

WA8RR


On Mar 15, 2019, at 4:07 PM, Jim N7US via Groups.Io <jim@...> wrote:

I understand HOW to do it.  I was curious how it worked.

I guess it's similar to any other instant messaging program, in that a user ID, in this case a callsign, apparently logs in to a central server, and that's how messages are received and can be sent.  Other programs, such as loggers, don't communicate with a central server when they're launched.

It seems a bit like Alexa, in that launching it authorizes it to establish communication with a server somewhere.

Jim N7US
Sent from Outlook on my Samsung Galaxy Tab S3



From: Richard Robbins
Sent: Friday, March 15, 3:00 PM
Subject: Re: [HamApps] JTAlert text messages
Right click on call sign shown in JTAlertX…bottom of list is “Send text message to callsign”.
 
 
 
Richard Robbins
 
WA8RR
 
 
From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Jim N7US via Groups.Io
Sent: Friday, March 15, 2019 10:58 AM
Subject: [HamApps] JTAlert text messages
 
How do the text messages work?  I looked in the old reflector messages and read they are sent via the internet, not RF, but I don’t understand how they are sent or delivered.
 
Jim N7US
 




locked Re: JTAlert text messages

Frank Kirschner
 



On Fri, Mar 15, 2019 at 4:07 PM Jim N7US <jim@...> wrote:
I understand HOW to do it.  I was curious how it worked.

I guess it's similar to any other instant messaging program,

I think that's what I said.

73,
Frank
KF6E


locked Re: JTAlert text messages

Jim N7US
 

I understand HOW to do it.  I was curious how it worked.

I guess it's similar to any other instant messaging program, in that a user ID, in this case a callsign, apparently logs in to a central server, and that's how messages are received and can be sent.  Other programs, such as loggers, don't communicate with a central server when they're launched.

It seems a bit like Alexa, in that launching it authorizes it to establish communication with a server somewhere.

Jim N7US
Sent from Outlook on my Samsung Galaxy Tab S3



From: Richard Robbins
Sent: Friday, March 15, 3:00 PM
Subject: Re: [HamApps] JTAlert text messages
To: support@hamapps.groups.io, hamapps@groups.io


Right click on call sign shown in JTAlertX…bottom of list is “Send text message to callsign”.
 
 
 
Richard Robbins
 
WA8RR
 
Richard@...
 
From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Jim N7US via Groups.Io
Sent: Friday, March 15, 2019 10:58 AM
To: HamApps@Groups.io
Subject: [HamApps] JTAlert text messages
 
How do the text messages work?  I looked in the old reflector messages and read they are sent via the internet, not RF, but I don’t understand how they are sent or delivered.
 
Jim N7US
 




locked Re: JTAlert text messages

Richard Robbins
 

Right click on call sign shown in JTAlertX…bottom of list is “Send text message to callsign”.

 

 

 

Richard Robbins

 

WA8RR

 

Richard@...

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Jim N7US via Groups.Io
Sent: Friday, March 15, 2019 10:58 AM
To: HamApps@Groups.io
Subject: [HamApps] JTAlert text messages

 

How do the text messages work?  I looked in the old reflector messages and read they are sent via the internet, not RF, but I don’t understand how they are sent or delivered.

 

Jim N7US

 


--

Jim N7US


locked Re: decodes history problem

Hartmut Luedtke
 

Laurie, thank you very much for your quick answer. I did it the way you asked.
For everyone else I'll send a screenshot (1920 x 1172 pixel )to the group. I marked two extremes. Only because of these high values I noticed it at all.

Many thanks for reading.

vy73 Ham, DB6LL

------------------

HamApps Support (VK3AMA) <vk3ama.ham.apps@...>
An:Support@HamApps.groups.io
15. März um 08:29
On 15/03/2019 6:17 pm, Hartmut Luedtke via Groups.Io wrote:
Hi, Laurie,

"Decodes History" is a nice function in JTAlert. But I think the display of the DT value is wrong. It is too high on my system by a factor of 10.
If JTDX displays a DT of 0.1, 1 is logged in "Decodes History", if the DT value in JTDX is 1.4, "Decodes History" logs the value 14....
Please ignore my text if the error is already known. I didn't find it in the search.

vy73 Ham, DB6LL
Ham,

Thanks for the report, yours is the first.
Please use the "? -> Contact Support" menu, on the JTAlert title-bar, to send me your JTAlert files for analysis.

de Laurie VK3AMA


locked Re: JTAlert text messages

James Shaver (N2ADV)
 

Right click on the callsign and click the option to send a text message or press F5 and the window will pop up to send a text message. 

On Mar 15, 2019, at 12:55 PM, Frank Kirschner <frank.kirschner@...> wrote:

As I understand it, the text message function is an instant messaging application built into JTAlert. If you are using JTAlert and are connected to the Internet, you can send IMs to, and receive IMs from, anyone else who is similarly set up. It's a convenience when you're trying to work someone through QRM, so you can negotiate a frequency, or just to say, "TNX FER QSO."

73,
Frank
KF6E

On Fri, Mar 15, 2019 at 10:57 AM Jim N7US <jim@...> wrote:

How do the text messages work?  I looked in the old reflector messages and read they are sent via the internet, not RF, but I don’t understand how they are sent or delivered.

 

Jim N7US

 


--

Jim N7US


locked JTAlert/Raspberry Pi Compatibility #POLL

Barrett WØASB
 

I found an older thread ( that was locked that showed interest in being able to communicate through the network to a remote computer; at first glance, this might seem like an odd/corner case request, but I would probably make a case that this is not as unusual as it sounds. I don't have a dedicated shack PC, but I use a Raspberry Pi that I stick in my shack and can remote into that runs WSJTX for all my QSOs. Reading through further threads, it appears that a Linux/Raspbian port would be out of the question for this software, so running JTAlert directly on the Pi is not likely.

There is a rumored-to-be-similar app that runs on Linux (AlarmeJT), but there appears to be little support for this and I have not seen evidence of a successful installation and execution of this program since a blog that was created around 2016. 

For this reason, I would like to gauge the interest in WSJT-X to JTAlert communication across a local network using UDP in remote computer/raspberry pi; Is there a desire for an implementation of this feature, or are there few people that are looking for this type of support? Are there other solutions that are being used for WSJTX & Raspberry Pi that I am not aware of?

Thanks,
Barrett W0ASB


locked Re: JTAlert text messages

Frank Kirschner
 

As I understand it, the text message function is an instant messaging application built into JTAlert. If you are using JTAlert and are connected to the Internet, you can send IMs to, and receive IMs from, anyone else who is similarly set up. It's a convenience when you're trying to work someone through QRM, so you can negotiate a frequency, or just to say, "TNX FER QSO."

73,
Frank
KF6E

On Fri, Mar 15, 2019 at 10:57 AM Jim N7US <jim@...> wrote:

How do the text messages work?  I looked in the old reflector messages and read they are sent via the internet, not RF, but I don’t understand how they are sent or delivered.

 

Jim N7US

 


--

Jim N7US

9621 - 9640 of 33195