Date   

locked Re: WSJT-X Audio Output Reduces

Michael Black
 

Also...wrong email group...that's a wsjt-x question.

Mike W9MDB





On Thursday, February 18, 2021, 11:34:44 PM CST, Mark via groups.io <m.weiss@...> wrote:


My WSJT-X audio level starts out at the desired level, but it declines substantially during the 15 second cycle.  That, of course, reduces the RF power out of the transceiver.

 

Does anyone also have that experience?  If so, what is the fix?

 

Tnx & 73,

 

Mark, K6FG


locked Re: WSJT-X Audio Output Reduces

Michael Black
 

What rig?
What power level?

Could be thermal control?

Mike W9MDB




On Thursday, February 18, 2021, 11:34:44 PM CST, Mark via groups.io <m.weiss@...> wrote:


My WSJT-X audio level starts out at the desired level, but it declines substantially during the 15 second cycle.  That, of course, reduces the RF power out of the transceiver.

 

Does anyone also have that experience?  If so, what is the fix?

 

Tnx & 73,

 

Mark, K6FG


locked WSJT-X Audio Output Reduces

Mark
 

My WSJT-X audio level starts out at the desired level, but it declines substantially during the 15 second cycle.  That, of course, reduces the RF power out of the transceiver.

 

Does anyone also have that experience?  If so, what is the fix?

 

Tnx & 73,

 

Mark, K6FG


locked Re: New Computer Hookup Problem

W7JHR@...
 

Thanks Laurie that did the trick. I knew it was a matter of pressing the right button, but I just couldn’t find it. 

Thanks,
Jim W7JHR


locked Re: Slow path to logging

Radio K0HB
 

 

From: Laurie, VK3AMA
Sent: Thursday, February 18, 2021 06:40
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Slow path to logging

 



Your problem is that your JTAlert settings do not match the Log4OM settings.

  • You have the JTAlert inbound connection set to port 2235 in Log4OM.
  • You have the ADIF_Message port set to port 2335 in JTAlert.

The ports need to match. Set Log4OM to use port 2335 and turn off the port 1240 inbound connection.

How does that work now?

de Laurie VK3AMA

 

That was it Laurie!  A bloody typo!

I can’t count how many times I examined those port numbers and didn’t catch it.

I sincerely apologize for wasting hours of your time, chasing a TYPO!

Again, I apologize, but appreciate your persistence.

 

73, de Hans, K0HB

 

 

 


locked Re: JTAlert error alert

w4lde
 

Mike,

The folder I was referring to is:  C:/users/"name"/AppData/Local/HamApps/W4LDE/logs/JTAlert

Normally there's 3 files, however, after using the ADIF Master or some other program deposit, I had five additional files, two from ADIF master and three with no name with the typical ahdcxz-----, used I guess by temps.

I did review the error file left there by ADIF Master and found that every mode "FT4" was I.D. as a bad mode.  So now I'm thinking that the Master program I was using was old, very old.

Anyway the issue is behind me and all is working OK.

Good to see your call and offer of help once again, thank you..

Stay Safe
73 de Ron W4LDE


locked Re: Help setting up B4

Mark
 

Thank you Laurie.  That did the trick.

73,

Mark, K6FG


locked Re: JTAlert error alert

Michael Black
 

What "log sub" folder are you referring to?  And how many files were in there?

Mike W9MDB




On Thursday, February 18, 2021, 06:45:33 AM CST, w4lde <w4lde.ron@...> wrote:


Issue with the error I reported fixed.
A few days earlier I had used ADI Master program to review the JTAlert log.  It showed one problem and I corrected it an saved it.  I don’t think it caused the issue either since it’s help me in the past.
Yesterday the issue was caused by the crap/temp files left in the log sub folder.  I ran my incremental backup program and replaced that folder.
I had not lost anything since I do a incremental backup of all my critical files when I shut down every evening.
I’m 99.9% sure the issue was not caused by JTAlert, thanks for a great program
Stay safe 73 de
Ron W4LDE






locked Re: JTAlert error alert

w4lde
 

Issue with the error I reported fixed.
A few days earlier I had used ADI Master program to review the JTAlert log. It showed one problem and I corrected it an saved it. I don’t think it caused the issue either since it’s help me in the past.
Yesterday the issue was caused by the crap/temp files left in the log sub folder. I ran my incremental backup program and replaced that folder.
I had not lost anything since I do a incremental backup of all my critical files when I shut down every evening.
I’m 99.9% sure the issue was not caused by JTAlert, thanks for a great program
Stay safe 73 de
Ron W4LDE


locked Re: Slow path to logging

Laurie, VK3AMA
 



On 18/02/2021 5:16 pm, Radio K0HB wrote:

Thanks for “hanging with me” on this Lauri.

Notice on the Log4OM “Configuration screen” I have an additional inbound at port 1240, not seen on your example.  I have unchecked that, and then nothing arrives at Log4OM.  So I’ve left it checked.


If unchecking the port 1240 setting stops logging that indicates that the logging is happening via that port and not via the configured JTAlert port 2335.

You have port 1240 listening to the JTAlert UDP resend (I guess that is it, 1240 is an unusual number, the default is 2334) of the WSJT-X UDP traffic. That is how Log4OM is picking up on the logging event. It also means that any additional log data you have entered in the JTAlert Log Fields area will not be getting logged. You can quickly check that by entering some unique string for the QSO partners name in the Log Fields of JTAlert and observing if that unique string gets logged. Based on your screen-captures and my interpretation of the problem it will not get logged.

There is never any need to have Log4OM listening to the JTAlert UDP resend traffic. Turn it off.

Your problem is that your JTAlert settings do not match the Log4OM settings.
  • You have the JTAlert inbound connection set to port 2235 in Log4OM.
  • You have the ADIF_Message port set to port 2335 in JTAlert.
The ports need to match. Set Log4OM to use port 2335 and turn off the port 1240 inbound connection.

How does that work now?

de Laurie VK3AMA


locked Re: Slow path to logging

Radio K0HB
 

Thanks for “hanging with me” on this Lauri.

 

Here are those screen shots.

 

 

 

Notice on the Log4OM “Configuration screen” I have an additional inbound at port 1240, not seen on your example.  I have unchecked that, and then nothing arrives at Log4OM.  So I’ve left it checked.

 

So here is where I’m at.

 

If I check the “Do not check or logging success/failure”, then I get acceptable transfer to Log4om, with about 6-9 seconds transit time.  This condition is acceptable to me.

 

If I uncheck that box, I get increased delay, and that delay can be influenced by increasing the “Check QSO Log Record” delay time.  At the lowest setting (5 seconds) the transit time is around 20 seconds.  At the 20 second setting the transit time is nearly a minute.

 

Since the “Do not check…..” option gives me acceptable performance, I’m willing to “drop the case” as some quirk at my end,  or continue to work with you if you would like.

 

73, Hans, K0HB

 

 

From: HamApps Support (VK3AMA)
Sent: Thursday, February 18, 2021 03:45
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Slow path to logging

 

On 18/02/2021 12:31 pm, Radio K0HB wrote:

Forgot to include:

 

Using SQLite, and my log size is about 98,000 QSO’s.


98K records should not be a problem. I routinely run multi-million record sqlite files for testing purposes.

I wonder if there is something unusual within your Log4OM comms setup for receiving logging instructions from JTAlert. Is it setup correctly, per the JTAlert Help file,

"Settings -> Logging -> Log4OM V2" section.

Can you provide a screen-capture of your Log4OM settings? It should look something like this...


And the correct JTAlert setup like this...


de Laurie VK3AMA

 


locked Re: Help setting up B4

HamApps Support (VK3AMA)
 

On 18/02/2021 2:13 pm, Mark via groups.io wrote:

I have WSJT-X (Version 2.3.0) and JTAlert (Version 2.16.17) installed on my Windows 10 computer.

 

Both applications seem to run properly.

 

But I can’t get the B4 to appear for prior QSOs.  Precisely what steps (and settings) do I need to get the B4 indication enables?

 

Tnx & 73,

 

Mark, K6FG


All JTAlert B4 checks are done against the logger you have enabled in JTAlert. Note: B4 checks do not utilize the WSJT-X log file.

If you are not using a logger with JTAlert ("NO Log" shown in titlebar text), than JTAlert will use a special file just for B4 checks. However, this file starts off empty and only adds entries  when you log a QSO in WSJT-X. You can pre-populate this "B4 database" with old QSOs by doing an import from an adif file. See the "Logging -> Log B4 Database" section of the JTAlert Settings window if you want to do an import.

de Laurie VK3AMA



locked Re: Slow path to logging

HamApps Support (VK3AMA)
 

On 18/02/2021 12:31 pm, Radio K0HB wrote:

Forgot to include:

 

Using SQLite, and my log size is about 98,000 QSO’s.


98K records should not be a problem. I routinely run multi-million record sqlite files for testing purposes.

I wonder if there is something unusual within your Log4OM comms setup for receiving logging instructions from JTAlert. Is it setup correctly, per the JTAlert Help file,

"Settings -> Logging -> Log4OM V2" section.

Can you provide a screen-capture of your Log4OM settings? It should look something like this...


And the correct JTAlert setup like this...


de Laurie VK3AMA


locked Re: Slow path to logging

HamApps Support (VK3AMA)
 

On 18/02/2021 12:29 pm, Radio K0HB wrote:
File enroute.
Files received.

All looks perfectly normal. A total of 88 ms between when JTAlert receives the QSO logged UDP message from WSJT-X and when JTAlert has vinished sending the logging instruction to Log4OM. Note the 3 highlighted entries from the debug file.

@ 01:26:26:915 the RR73 decode from KS4OT received.
@ 01:26:31:650 the Logged QSO UDP message received from WSJT-X
@ 01:26:31:738 The Log4OM log TCP instruction had finished (662 bytes sent).

In the 88ms between when JTAlert received the logged QSO message from WSJT-X and when JTAlert has finished sending the TCP message to Log4OM JTAlert gathers the log field data (_Read_Log_Data instruction), combines that data with what came from WSJT-X (_Set_Log_Data instruction) clears & sets the B4 Cache for K4SOT and writes the single adif entry record to disk (_write_singleqso_log entry).



de Laurie VK3AMA


locked Help setting up B4

Mark
 

Hello all,

 

I have WSJT-X (Version 2.3.0) and JTAlert (Version 2.16.17) installed on my Windows 10 computer.

 

Both applications seem to run properly.

 

But I can’t get the B4 to appear for prior QSOs.  Precisely what steps (and settings) do I need to get the B4 indication enables?

 

Tnx & 73,

 

Mark, K6FG

 


locked Re: Slow path to logging

Micky Corrow
 

Nice call Mike on the exclusions.
That worked miracles on my older slow system.

Micky K1XH


locked Re: Slow path to logging

Radio K0HB
 

Forgot to include:

 

Using SQLite, and my log size is about 98,000 QSO’s.

 

 

Sent from Mail for Windows 10

 

From: HamApps Support (VK3AMA)
Sent: Thursday, February 18, 2021 00:14
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Slow path to logging

 

On 18/02/2021 10:28 am, Radio K0HB wrote:

I ran some experiments, Laurie, and it appears that JTAlert is involved.

 

First, as a benchmark, I took JTAlert offline and logged directly from WSJT-X to Log3OM.

 

From the time I pressed “Log it” until the QSO arrived in Log4OM took a second or two.  This result is consistent.

 

Then I put JTAlert back in the app lineup (with appropriate UDP settings).

 

Then I did 4 experiments, each one twice to check consistency.

 

  1. I turned off the check as per your message below.  Two QSO’s each took about 10 seconds to arrive.
  2. I turned the check back on, with a wait of 5.  Two QSO’s each took about 25 seconds.
  3. Increased the wait to 10.  30 seconds elapsed.
  4. Increased the wait to 20.  About 50 seconds elapsed.

 

So it seems that JTAlert, even without the check, adds some (tolerable) delay.

 

Then, increasing the “time before check” also increases the travel time to Log4OM.

 

For now, I will turn off the check as you recommend, as the delay in that condition is tolerable.

 

73, de Hans, K0HB

 


Hans,

Your comparing Apples to Oranges. WSJT-X -> Log4 direct logging compared to WSJT-X -> JTAlert -> Log4 logging via the Log4OM TCP logging interface which I assume uses a different pipe-line through the Log4 code.

What Log type are you using in Log4OM V2? SQLite or MySQL? How many records does it contain?

If you have JTAlert logging confirmation checks turned off and your getting 10 second delays before the QSO gets written to the log, those delays are coming from Log4OM. Perhaps it is delayed while it does its post logging processing for QSOs logged via its TCP interface only. I don't know, that is speculation.

I would like to see some of the timings that JTAlert records in its debug file to reassure myself that JTAlert is not introducing delays. Please do the following...

  • Enable debug recording via the JTAlert "Settings -> Enable Debug Recording" menu.
  • Restart JTAlert.
  • With the "Do not check or report logging success/failure" checkbox ticked, log a QSO.
  • After the QSO has been logged and appeared in the Log4OM log you can turn off the debug recording.
  • Then use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis. Pleas include a note of the Callsign logged.

de Laurie VK3AMA

 

 


locked Re: Slow path to logging

Radio K0HB
 

File enroute.


locked Re: JTAlert error alert

HamApps Support (VK3AMA)
 

On 18/02/2021 11:23 am, w4lde wrote:
Yesterday I ran version 2.16.17 without any problems.  This evening I started JTAlert and its set to auto start WSJT-x and after thing seems loaded correctly
I got the following popup and an alert to a specific line number.  I uninstalled 2.16.17 and reinstalled 2.16.16 and the same error alert poped up.
I dont think its an alert issue but Im lost wee to start to trouble shoot.  Any help is appreciated.  The opoup is:




Thanks for help
73 de Ron W4LDE
Ron,

If JTAlert is not throwing this error immediately, Please use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis.

If your unable to send a support request let me know.

de Laurie VK3AMA


locked JTAlert error alert

w4lde
 

Yesterday I ran version 2.16.17 without any problems.  This evening I started JTAlert and its set to auto start WSJT-x and after thing seems loaded correctly
I got the following popup and an alert to a specific line number.  I uninstalled 2.16.17 and reinstalled 2.16.16 and the same error alert poped up.
I dont think its an alert issue but Im lost wee to start to trouble shoot.  Any help is appreciated.  The opoup is:




Thanks for help
73 de Ron W4LDE

3341 - 3360 of 36454