Date   

locked Re: Worked B4 with HRD

HamApps Support (VK3AMA)
 

On 8/02/2020 5:46 pm, HamApps Support (VK3AMA) via Groups.Io wrote:
Did you uncheck the new "Ignore Grid" option for the B4 alert?

If you did unckeck that option, try with it checked as that will produce the same sql queries as the earlier versions of JTAlert (I am thinking the sql may be broken).
Let me know.

de Laurie VK3AMA


locked Re: B4 bug or feature?

HamApps Support (VK3AMA)
 

On 7/02/2020 4:20 pm, Marc VK3OHM wrote:

I have just worked C21PF. He does not do LOTW or eQSL. I have my flags set to not display calls unless they do either LOTW or eQSL. He did not display in JTAlert (correct), but nevertheless, I decided to work him.

When I see his decode (in WSJT-X) in subsequent cycles, he is not greyed out, i.e. there is no B4 indication in WSJT-X. Now, I can understand why this might be - because he's not displaying in JTAlert, he is not being color coded in WSJT-X. Whilst I can understand how this could happen, is it really correct behavior?

I have worked him B4, therefore I expect to see him color coded in WSJT-X. Whether he does LOTW or eQSL is an unrelated issue.


Not a Bug, but a design decision. If a callsign doesn't pass your filters so is not shown (and colored) then the same applies to the color-coding in WSJT-X.

You can always have the JTAlert Decodes window open, it follows the main window Callsign coloring but its filtering is independent of the main window filtering so you could have the B4s shown.

While a case could be made to color WSJT-X callsigns when the JTAlert callsign is not shown due to filtering, especially for the higher importance Alerts, like DXCC, doing so for lowly B4's is unlikely compared to new Countries. I'll think on this some more and may implement a Filter override for WSJT-X coloring, no promises and no guarantee if implemented B4's will make the list of Alert exceptions to which the override would apply.

de Laurie VK3AMA


locked Re: Worked B4 with HRD

HamApps Support (VK3AMA)
 

On 8/02/2020 8:04 am, Gavin Bennett wrote:
Since updating to v2.15.9 l, when I work a new station, it does not show in JTAlert as worked B4 status. I am using HRD6+ for logging.

However, if I close WSJTx/JTAlert, and restart both applications the correct status of the worked B4 stations are indicated with B4 correctly in JTAlert when subsequently decoded.

On reverting to prior version the problem goes away, reappears on the reinstallation of v2.15.9.1

Thanks

Gavin

de ZL3GAV
Gavin,

What version of HRD?
What database type for the HRD log, MSAccess, MSSQL or MySQL?
Did you uncheck the new "Ignore Grid" option for the B4 alert?

de Laurie VK3AMA



locked Re: Performance with big AC Log

Shel KF0UR
 

Keith,

Are you referring to AC Log's List / Last xx setting?  if so, it's set to a few hundred, and doesn't seem to affect this issue (same time whether 50 or 500).

Tnx,

Shel KF0UR


locked Re: Performance with big AC Log

Keith Ennis
 

 
Shel
 
Also make sure your "Recent Contact" list does not contain all of your logs.  Set it to something like 50-100.
 
 
Keith, KV5J
 
 

On Friday, February 7, 2020, 01:57:36 PM EST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
 
 
On 8/02/2020 5:24 am, Shel KF0UR wrote:
I've got a rather large number of QSOs in my AC Log (111K), 21K of which are FT8 and FT4 QSOs.   For FT8 and FT4, I'm using JTAlert as the conduit to get the QSO data into AC Log from WSJT-X.  I have any other JTAlert features turned on at this time.

It's been working fine, but as my log grows the time to get the the call into AC Log has grown. On my Microsoft Surface 3, it takes almost 30 seconds.  That's longer than an FT4 QSO.

I did some testing by reducing the log size significantly and the time shrinks significantly as well.  Interesting.

I'm looking for information on the process that's taking place, and if there are any options to speed things up.  It behaves as though a scan of the whole log is being done, when all that is needed is to send the call there.  AC Log will take care of alerting me of prior QSOs.

So...
- is there an explanation of the process taking place when a new call appears in WSJT-X?
- has anyone else experienced this, and is there a solution?

Tnx in advance.

73,

Shel KF0UR
Sheil,

The JTAlert logging to ACLog mechanism is quite simple, very fast, and is independent of the ACLog file size. It is the sending of a single TCP data packet to ACLog. What ACLog does with that data and how long it takes to physically get into the ACLog log file is all handled withing the ACLog realm. Any ACLog post logging operations it is performing on the data (like xml lookups, qrz bio lookup and photo display, award analysis, etc) are not controllable by JTAlert.

If your happy that JTAlert is successfully logging the QSOs you can turn off the Log Check performed by JTAlert which avoids the JTAlert hang at the end of logging, because it is a single threaded executable, as it waits for the timeout before rechecking the log. Logging Section of the Settings, very last option checkbox (scroll down). This option will allow JTAlert to return immediately to processing decodes after the TCP instruction for ACLog has been sent, within milliseconds of the WSJT-X logging event.
   

de Laurie VK3AMA


 


locked Re: Performance with big AC Log

Shel KF0UR
 

Hi Laurie,

Tnx for the fast reply.

I checked the "Do not check or report logging success/failure", but it didn't change anything.  But if I understand the checkbox correctly, I'm not surprised, as the issue is when the call first appears in WSJT-X and is passed to AC Log so the AC Log History and QRZ.com lookup is done and call data populated.  The last step of logging the QSO when the QSO is finished works well, and quickly.

I've pinged Scott N3FJP, the AC Log author on this as well, but he didn't see anything on his side.  The interesting thing is that if I type the call into AC Log directly (instead of JTAlert passing it), the data in AC log is populated immediately, even with a QRZ.com lookup.  So there's something different happening somewhere!

Still befuddled...

Tnx,

Shel KF0UR




locked Worked B4 with HRD

Gavin Bennett
 
Edited

Hello

Since updating to v2.15.9 l, when I work a new station, it does not show in JTAlert as worked B4 status. I am using HRD6+ for logging.

However, if I close WSJTx/JTAlert, and restart both applications the correct status of the worked B4 stations are indicated with B4 correctly in JTAlert when subsequently decoded.

On reverting to prior version the problem goes away, reappears on the reinstallation of v2.15.9.1

Thanks

Gavin

de ZL3GAV


locked Re: 2.15.9 Trojan virus warning

Hasan Schiers N0AN
 

Create an exclusion in every piece of anti-virus or malware software you run. Exclude the directory (folder)  that the *.exe file resides in.

I run Defender and have no issues.

Then you don't have to wait for anyone else to do something.

73, N0AN


Hasan


locked Thank you so much, Laurie!! You do great work!

HamApps Support (VK3AMA)
 

Laurie, I have been running JT alert since the beginning, or at least since JT65 and have been running FT8 since the 'demise' of JT 65.  I REALLY APPRECIATE the fine work you have done and your resulting product.  I love FT8 but doubt that I would still be into it if it weren't for JT Alert adding great amounts of pleasure to the mode.  This is especially true since you increased the decoded stations display time to two 15 second segments from the original one.  This has helped a lot.  Keep up the good work.  I upgrade everytime you issue a new one..

73 de Ron WA4HWN, Dothan, Alabama, USA.


locked Re: DT Alerts in 2.15.9

HamApps Support (VK3AMA)
 

On 8/02/2020 4:21 am, gary.sewell@... wrote:
Highlighting DT values is still available
       in the JTAlert Decodes window."

If it is still available where is it?

Gary

Look in the Decodes window Settings, its not hard to find.



de Laurie VK3AMA


locked Re: Performance with big AC Log

HamApps Support (VK3AMA)
 

On 8/02/2020 5:24 am, Shel KF0UR wrote:
I've got a rather large number of QSOs in my AC Log (111K), 21K of which are FT8 and FT4 QSOs.   For FT8 and FT4, I'm using JTAlert as the conduit to get the QSO data into AC Log from WSJT-X.  I have any other JTAlert features turned on at this time.

It's been working fine, but as my log grows the time to get the the call into AC Log has grown. On my Microsoft Surface 3, it takes almost 30 seconds.  That's longer than an FT4 QSO.

I did some testing by reducing the log size significantly and the time shrinks significantly as well.  Interesting.

I'm looking for information on the process that's taking place, and if there are any options to speed things up.  It behaves as though a scan of the whole log is being done, when all that is needed is to send the call there.  AC Log will take care of alerting me of prior QSOs.

So...
- is there an explanation of the process taking place when a new call appears in WSJT-X?
- has anyone else experienced this, and is there a solution?

Tnx in advance.

73,

Shel KF0UR
Sheil,

The JTAlert logging to ACLog mechanism is quite simple, very fast, and is independent of the ACLog file size. It is the sending of a single TCP data packet to ACLog. What ACLog does with that data and how long it takes to physically get into the ACLog log file is all handled withing the ACLog realm. Any ACLog post logging operations it is performing on the data (like xml lookups, qrz bio lookup and photo display, award analysis, etc) are not controllable by JTAlert.

If your happy that JTAlert is successfully logging the QSOs you can turn off the Log Check performed by JTAlert which avoids the JTAlert hang at the end of logging, because it is a single threaded executable, as it waits for the timeout before rechecking the log. Logging Section of the Settings, very last option checkbox (scroll down). This option will allow JTAlert to return immediately to processing decodes after the TCP instruction for ACLog has been sent, within milliseconds of the WSJT-X logging event.
   

de Laurie VK3AMA



locked Performance with big AC Log

Shel KF0UR
 

Hi,

I've got a rather large number of QSOs in my AC Log (111K), 21K of which are FT8 and FT4 QSOs.   For FT8 and FT4, I'm using JTAlert as the conduit to get the QSO data into AC Log from WSJT-X.  I have any other JTAlert features turned on at this time.

It's been working fine, but as my log grows the time to get the the call into AC Log has grown. On my Microsoft Surface 3, it takes almost 30 seconds.  That's longer than an FT4 QSO.

I did some testing by reducing the log size significantly and the time shrinks significantly as well.  Interesting.

I'm looking for information on the process that's taking place, and if there are any options to speed things up.  It behaves as though a scan of the whole log is being done, when all that is needed is to send the call there.  AC Log will take care of alerting me of prior QSOs.

So...
- is there an explanation of the process taking place when a new call appears in WSJT-X?
- has anyone else experienced this, and is there a solution?

Tnx in advance.

73,

Shel KF0UR


locked DT Alerts in 2.15.9

gary.sewell@...
 

I thought that this was a great tool, but I understand that it has been removed in 2.15.9. In the release not it states: "
The option "Highlight Band Activity DT values that
       exceed threshold" has been removed. Highlighting DT values is still available
       in the JTAlert Decodes window."

If it is still available where is it?

Gary


locked Re: audio

Michael Black
 

You need to explain what you are trying to do.  Don't understand what you are asking about.

de Mike W9MDB




On Friday, February 7, 2020, 10:43:55 AM CST, lozere15@... <lozere15@...> wrote:


Hello
how to get 2 audio on pc with windows 10 * thank you
73 friends


locked audio

lozere15@...
 

Hello
how to get 2 audio on pc with windows 10 * thank you
73 friends


locked Re: 2.15.9 Trojan virus warning

Stephen Mitchell
 

I get the same thing daily from Malwarebytes.

K7CB

On Friday, February 7, 2020, 07:47:31 AM MST, Lou Laderman W0FK <lladerman@...> wrote:


I’ve downloaded 2.15.9 but my antivirus program (Windows Defender) has quarantined it with a Trojan virus warning. I downloaded it on a second PC running Norton and no warning was given. Suggestions how to address this other than waiting for the next release and seeing if the issue manifests itself again?

73

Lou, W0FK 


locked Re: 2.15.9

rogich@...
 

Thanks for the help. Appreciate the app and super support.


locked Re: 2.15.9 Trojan virus warning

Lou Laderman W0FK
 

Thanks for the link. Although it advises sending the info to my malware provider for advice, since the warning came from Microsoft software, I’ll pass on that because I’m too old to wait for an answer from the company that never gives a straight answer to anything.

73, Lou W0FK 


locked Re: 2.15.9 Trojan virus warning

m_scot_alex
 
Edited


locked 2.15.9 Trojan virus warning

Lou Laderman W0FK
 

I’ve downloaded 2.15.9 but my antivirus program (Windows Defender) has quarantined it with a Trojan virus warning. I downloaded it on a second PC running Norton and no warning was given. Suggestions how to address this other than waiting for the next release and seeing if the issue manifests itself again?

73

Lou, W0FK 

5761 - 5780 of 33325