Date   

locked Re: DT Alerts in 2.15.9

Ron W3RJW
 

But that now works only in the decodes window ?   I thought it was a useful feature in the WSJT-X window.
--
73
Ron, W3RJW


locked Re: DT Alerts in 2.15.9

HamApps Support (VK3AMA)
 

On 8/02/2020 9:29 pm, Carlo - IK2RPE wrote:
Sorry I do not find the "Decodes Settings" of your image

Carlo  IK2RPE
On the Decodes window, use the "File -> Settings" menu.

de Laurie VK3AMA


locked Re: DT Alerts in 2.15.9

Carlo - IK2RPE
 

Sorry I do not find the "Decodes Settings" of your image

Carlo  IK2RPE


locked Re: Worked B4 with HRD

Gavin Bennett
 

Thanks Laurie

 

I am using the latest version of HRD 6.7.0.262 with Maria SQL database 10.4.10, with the MySQL ODBC connector.

 

I have tried working QSO’s with and without the unchecked “Ignore Grid”  status with fresh restarts of WSJTX/JT Alert, and it still does no show the B4 status in JT Alert in the current session.  The right-click on “show QSO history” does show the QSO as worked.  If I restart the applications, the QSO  shows  the correct status of the QSO.

 

If I revert to 2.15.8 the B4 status works correctly.

 

Regards

 

 

Gavin

de ZL3GAV

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Saturday, 8 February 2020 20:00
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Worked B4 with HRD

 

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: Double entries on JTAlert Decodes window with instances / Clue

asobel@...
 

Laurie

 

The problem is still there with JTAlert 2.15.9

 

 

Amos 4X4MF

 

========================================================================================

Laurie

 

Mistake See below

 

Laurie

 

I am using 4 instances

My filter is using "Show only alerts" and "JTAlerts enabled Alerts only" What is the difference?

Maximum records is 2000

Slice B 60m does now duplicate

Slice A 80m does not duplicate

Slice C and D are not active this morning. No alerts.

Did change to 100 records and restart.

Slice B 60m does not duplicate most of the time (one duplication)/ Mistake:  All activity moved to slice A 80m.

Slice A 80m does not duplicate

 

Amos 4X4MF

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: יום ד 05 פברואר 2020 05:47
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Double entries on JTAlert Decodes window with instances / Clue

 

On 5/02/2020 8:58 am, asobel@... wrote:

It shows:

 

DH Filter Status

Active Filters

Show only Alerts

Hide worked B4

Hide Ignored

 

Amos 4X4MF

OK,

That didn't help. Using the same filtering settings I am not seeing any duplication of records.

How many JTAlert instances are you running?
What is the size of the Decodes database as shown in the status bar, number of records and size in brackets?

de Laurie VK3AMA


locked Re: JTAlert does give some false "Not Wanted" DXCC report.

asobel@...
 

Laurie

 

I did manage to repair this situation.

The problem did affect only few hundred records of Log4OM QSOs. Probably of my misdoing.

Using the Log4OM tools, I did manually repair those records.

Scanning with JTAlert 2.15.8 did not repair the situation.

Scanning with JTAlert 2.15.9 did repair the situation.

 

For your attention.

 

Amos 4X4MF

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: יום ד 05 פברואר 2020 22:22
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JTAlert does give some false "Not Wanted" DXCC report.

 

On 6/02/2020 2:50 am, asobel@... wrote:

This morning I did work VK9NK on Norfolk Is. 17m. This was my first QSO. I did upload it to LoTW and download LoTW  on Log4OMV2. I did later Scan the log on JTAlert and was surprised to find that Norfolk Is. Is reported as "Not wanted" on DXCC 17m. I did later find that Log4OMV2 does report all entries as LoTW confirmation Received as "Yes" and Received Date of some entries, not including VK9NK 17m of today, with the reporting received date.

So why did my JTAlert report 17m Norfolk Is. as "not wanted" and how does JTAlert find "Not Wanted" DXCC/LoTW in general?

 

Amos 4X4MF


If Log4OM2 is showing VK9NK as Lotw Received = "Yes" than JTAlert will consider that as LoTW confirmed. JTAlert doesn't look at the Date entry, only the Received entry.

de Laurie VK3AMA


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