Date   

locked Re: QSO Not Logged! Log4OM v2

neil_zampella
 

Try downloading the final release of v2.15.8, which is the latest with all the Log4OM updates.  Then see if this still occurs.

 

Neil, KN3ILZ


locked Re: JTAlert error messages

neil_zampella
 

Um .. you do realize that you're having WSJT-X  >>> AND <<< JT-Alert try to use the SAME port to send the SAME UDP packet, right?

Turn off the WSJT-X rebroadcast as that setting is 'deprecated' which means it will probably go away in the next version of WSJT-X.  it was only added for N1MM+ before they created a different method of connecting to WSJT-X, and is no longer used by it.

Just keep the JT-Alert rebroadcast if you have to.    In reality, all you should need is to use the HRD V5/V6 logging setup and no rebroadcast is needed.

 

Neil, KN3ILZ


locked Re: jtalerts shortcut

HamApps Support (VK3AMA)
 

On 25/01/2020 12:35 pm, richard clare wrote:
When I attempt to start jtalerts along with wsjtx I get a message: [JTAlert started directly (without using a shortcut) or with an incorrect shortcut target parameter. Select the jt mode application that jtalert will use.]  I have set up in settings; applications;autostart the location of wsjtx. Is there something I'm missing? Thanks, Richard wb6ewm
You need to start JTAlert using one of the shortcuts created during the software installation. They may be on your desktop if you enabled that, but they are always created in the "HamApps JTAlert" group of the Windows start menu.

de Laurie VK3AMA


locked jtalerts shortcut

richard clare
 

When I attempt to start jtalerts along with wsjtx I get a message: [JTAlert started directly (without using a shortcut) or with an incorrect shortcut target parameter. Select the jt mode application that jtalert will use.]  I have set up in settings; applications;autostart the location of wsjtx. Is there something I'm missing? Thanks, Richard wb6ewm


locked Re: QSO Not Logged! Log4OM v2

HamApps Support (VK3AMA)
 

On 25/01/2020 10:56 am, g4iua.uk@... wrote:
I've also noticed that using Beta version 1.15.7 Build 0003 under Manage Settings/Logging both Log4OM V1 and V2 are shown.  V1 is BOLD and V2 is not and cannot be selected.
OM,

You are way behind if your running Beta build 0003. The builds, each with Log4OM V2 specific fixes/changes went up to 0006.
All those build are now superseded by the new non-Beta public release, 2.15.8, which you should install else in approx 3 weeks, the Beta expires and becomes non-functional.

V1 showing Bold while V2 doesn't indicates that you have enabled V1 as your logger with JTAlert. If you want to use Log4OM V2 with JTAlert, select the "Log4OM V2" line in the left-hand tree-view and then tick the enable checkbox on the settings view for V2, the entry will then become bold.

JTAlert treat Log4OM V1 and Log4OM V2 as two separate logger applications due to the significant differences in the Log file schemas and config files of the two versions.

de Laurie VK3AMA




locked Re: QSO Not Logged! Log4OM v2

g4iua.uk@...
 
Edited

I've also noticed that using Beta version 1.15.7 Build 0003 under Manage Settings/Logging both Log4OM V1 and V2 are shown.  V1 is BOLD and V2 is not and cannot be selected.


locked Re: Interesting sound issue - Update

John Petrocelli
 

Hello again,

  Here is a screen shot of when this happened just a bit earlier.
  Note the order of 2 particular callsigns in the JTAlert window (5T5PA and then W9TMW which was a reply to me)
  The 5T5PA generated the "CQ" alert sound but the "WA2HIP W9TMW R-09" did not trigger the "Own Call" alert tone.

   Maybe this will help.
   I COMPLETELY understand that the other issue with Log4OM took priority.

73
John - WA2HIP


John R. Petrocelli - WA2HIP
¶¶¶¶¶¶¶¶¶¶
Primary Home Page:
   http://wa2hip.com
On 1/24/2020 10:57 PM, HamApps Support (VK3AMA) wrote:

On 24/01/2020 1:35 pm, John Petrocelli via Groups.Io wrote:
I have been much more vigilant as to the anomaly happening.

I am getting an  even stronger sense that it will happen if "Own Call" is decoded after a "CQ".  The result is, as I stated, that the "CQ" alert sounds but the "Own Call" does not.

Thus it would seem that in this situation, the "CQ" sound preempts the "Own Call" sound.

Note that I also have WSJT-X set to decode at the deepest level, although I doubt that this is a contributing factor.

Thanks again
John - WA2HIP
John,

In all honesty, I have not yet looked at the code, I have been thinking about the issue, but the unexpected release of Log4OM V2 diverted all my energies to getting it supported asap.

Very likely there are a couple of bits to the puzzle, the recent JTAlert changes to improve the speedup of Callsign alerting/displaying which required a change in how quickly JTAlert handles the incoming UDP decodes feed from WSJT-X and the multi-pass decoding performed by WSJT-X, especially since your running with Deep decoding.

Question: When you see this behavior is the Station Calling you on your TX frequency? Is there difference in the alerting depending on where the Calling Station is Tx?

de Laurie, VK3AMA




locked Re: Interesting sound issue - Update

HamApps Support (VK3AMA)
 

On 24/01/2020 1:35 pm, John Petrocelli via Groups.Io wrote:
I have been much more vigilant as to the anomaly happening.

I am getting an  even stronger sense that it will happen if "Own Call" is decoded after a "CQ".  The result is, as I stated, that the "CQ" alert sounds but the "Own Call" does not.

Thus it would seem that in this situation, the "CQ" sound preempts the "Own Call" sound.

Note that I also have WSJT-X set to decode at the deepest level, although I doubt that this is a contributing factor.

Thanks again
John - WA2HIP
John,

In all honesty, I have not yet looked at the code, I have been thinking about the issue, but the unexpected release of Log4OM V2 diverted all my energies to getting it supported asap.

Very likely there are a couple of bits to the puzzle, the recent JTAlert changes to improve the speedup of Callsign alerting/displaying which required a change in how quickly JTAlert handles the incoming UDP decodes feed from WSJT-X and the multi-pass decoding performed by WSJT-X, especially since your running with Deep decoding.

Question: When you see this behavior is the Station Calling you on your TX frequency? Is there difference in the alerting depending on where the Calling Station is Tx?

de Laurie, VK3AMA



locked Re: Double click on spot - with JTDX

HamApps Support (VK3AMA)
 

On 25/01/2020 9:00 am, Doug Munday wrote:
Single click on decode does forward the call to JTDX, IF the decode is a CQ
This is what I am seeing in testing. The JTAlert code to send the appropriate instruction to JTDX or WSJT-X doesn't change with the decode type. WSJT-X accepts the JTAlert commands regardless, JTDX only actions the command if it is for a CQ decode.

This is not a JTAlert defect, but either a feature/defect within JTDX. This has been like this for quite some time (many months I believe). I don't know which JTDX version first introduced this behavior

de Laurie VK3AMA


locked Re: Double click on spot - with JTDX

Doug Munday
 

I've partially solved this question.  Single click on decode does forward the call to JTDX, IF the decode is a CQ.  I seem to remember that JTDX has more rigorous filters on when to go into TX mode, so as not to spam the DX if they are not CQ'ing.  Wonder if there is a work around for this, as I would still like to have the call forwarded to JTDX, just not go into TX mode, which it does not at this time. 

Thanks for any clarifications!

Doug - W7DRM


locked Double click on spot - with JTDX

Doug Munday
 

New to JTDX, and testing with latest JTAlert for JTDX (2.15.8), the double click on a spot in JTAlert is not forwarding the call to JTDX.  It does when using WSJTx and JTAlert.  Is this a limitation of JTDX, or something amiss in my settings? 

Thanks,
Doug - W7DRM


locked Re: JTAlert error messages

HamApps Support (VK3AMA)
 

On 25/01/2020 4:57 am, Michael Black via Groups.Io wrote:
Turns out Webroot was blocking JTAlert.exe.  However JTAlert_AL.exe was allowed to run so Bill is up and running now.

I've help other people with Webroot blocking stuff like this.  It's a bit too aggressive and in this case we found the option that affected this was "silent and automatic" with no way to make exceptions.  It was blocking JTAlert from getting process data.  Don't know why the alternate version works though...should be doing the same thing.

de Mike W9MDB
Mike, Tnx very much for sorting this out, your help is appreciated!

The code differences between JTAlert.exe and JTAlert_AL.exe are minimal, they share ~99% the same code. I am starting to suspect that some of these problematic Protection Software products are also triggering simply because of the executable name, JTAlert.exe, with JTAlert_AL.exe getting a pass because it is a relatively new file name.

IMO, any protection software product that causes application operation interference, deletes files or blocks access without notifying the end-user that action has been taken and/or doesn't provide a mechanism to override these unwanted actions is not much better than the malicious applications it is try to protect us from.

de Laurie VK3AMA


locked JTAlert 2.15.8 is available. Full Log4OMV2 support. #Announcement #NewRelease

HamApps Support (VK3AMA)
 

The Latest JTAlert version 2.15.8 is now available @ https://hamapps.com/JTAlert/

This release has support for the newly released Log4OM V2. Both SQLite & MySQL logs are supported.
Log4OM V2 users should view the Help file for proper setup instructions (they are very simple).
See the "Settings -> Logging -> Log4OM V2" topic in the help file. Using the Help button when on the Log4OM V2 section of the JTAlert Settings window will take you to the relevant help topic.

de Laurie VK3AMA

The Release Notes...

2.15.8 (24-JAN-2020)

  *** Includes Callsign database file version 2020-01-24 (2020-January-24)

  New Features:

    - Log4OM V2: Full support for Log4OM V2, both SQLite and MySQL logs.

    - Log4OM V1/V2 SQLite logs: "Test" button to check log file selected is
       a valid SQLite file for the Log4OM version and contains QSO records.
       See Settings window, "Logging -> Log4OM..." sections.

    - Logging option: New "Do not check or report logging success/failure".
       This option when ticked (off by default) instructs JTAlert to not try
       and confirm that a QSO was logged by reading the Loggers log directly.
       Once the logging instruction has been sent, JTAlert goes back to normal
       operation, there are no delays or hangs as JTAlert is stuck waiting to
       confirm the QSO was logged. JTAlert will however still report a logging
       failure when it could not initially establish the TCP or UDP connection
       to the target logger.

  Changes:

    - MySQL support: libmysql.dll file updated to v6.1.10 (previously v5.1.37)

  Fixes:

    - ADIF logging: Excessive time to confirm QSO logged successfully when using
       large adif files. 200,000 record check now takes ~1 sec (previous ~45 secs)



locked Re: JTAlert error messages

Michael Black
 

Turns out Webroot was blocking JTAlert.exe.  However JTAlert_AL.exe was allowed to run so Bill is up and running now.

I've help other people with Webroot blocking stuff like this.  It's a bit too aggressive and in this case we found the option that affected this was "silent and automatic" with no way to make exceptions.  It was blocking JTAlert from getting process data.  Don't know why the alternate version works though...should be doing the same thing.

de Mike W9MDB




On Friday, January 24, 2020, 10:29:59 AM CST, Bill-KC8WSM 070-1191 <kc8wsm@...> wrote:


Good morning.  I was able to get my HRD fixed and now JTAlert opens but I am getting error messages.  These are the two I have received.  I checked the boxes as instructed in the first message then I start receiving the second one.  I'm sure It's a simple fix but I can figure it out.  Any ideas?

image.png

image.png

ReplyForward


locked Re: JTAlert error messages

Michael Ernst
 

Bill KC8WSM,

 

Here are my settings and they work on HRD First of all in WSJT-X, also check the Secondary UDP Server, as seen here (note that this one uses port 2333 in my setup, I think that is the default):

 

 

Then in JTAlert, change the port to use the one above, as shown here:

 

 

This works on mine.

 

73,

Mike, AE8U

 

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Bill-KC8WSM 070-1191
Sent: Friday, January 24, 2020 11:30 AM
To: Support@hamapps.groups.io
Subject: [HamApps] JTAlert error messages

 

Good morning.  I was able to get my HRD fixed and now JTAlert opens but I am getting error messages.  These are the two I have received.  I checked the boxes as instructed in the first message then I start receiving the second one.  I'm sure It's a simple fix but I can figure it out.  Any ideas?

 

image.png

 

image.png

 

ReplyForward

 


locked JTAlert error messages

Bill-N7RI
 

Good morning.  I was able to get my HRD fixed and now JTAlert opens but I am getting error messages.  These are the two I have received.  I checked the boxes as instructed in the first message then I start receiving the second one.  I'm sure It's a simple fix but I can figure it out.  Any ideas?

image.png

image.png

ReplyForward


locked Re: JTAlert won't open

HamApps Support (VK3AMA)
 

On 24/01/2020 2:02 pm, Bill-KC8WSM 070-1191 wrote:
Does this help?

Yes it helps. I was starting to suspect that you may have been running a non-standard WSJT-X build, but your image dispels that thought.

Regarding the JTAlert waiting for WSJT-X message, does it include any mention of an instance, like "[2nd Instance]"?
If so that indicates that JTAlert is already running, but not visible, and starting JTAlert starts a 2nd JTAlert instance and it is waiting for a 2nd instance of WSJT-X to be started. In this situation you could try and kill off the already running JTAlert using TaskManager, but that risks still leaving some parts of JTAlert running, the better solution is a PC restart to ensure all zombie processes are killed and file-locks removed.

If it is not an instance issue, then I am back to suspecting WSJT-X is running elevated. Are you sure the properties of BOTH wsjtx.exe and the shortcut used to start WSJT-X are not set to run as Administrator. You have to check both.

If your certain that WSJT-X is not running elevated and JTAlert is not trying to start a second instance, then you will need to find someone who is familiar with the programs to remote access your PC and check what is happening. Sorry, I cannot provide that sort of support, but there are some members of this Group who can, hopefully one of them will make contact.

Let me know how you get on, especially if it gets resolved, as I am curious as to what might be the cause.

de Laurie VK3AMA


locked Re: JTAlert won't open

Bill-N7RI
 

Does this help?

image.png

On Thu, Jan 23, 2020 at 5:01 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 24/01/2020 9:01 am, Bill-KC8WSM 070-1191 wrote:
I think I have the screen shot thing figured out.  Here is a shot of my panel.

Please post an image of your running WSJT-X window. There may be something there that will help identify why JTAlert is not detecting WSJT-X running.

de Laurie VK3AMA


locked Re: Interesting sound issue - Update

John Petrocelli
 

I have been much more vigilant as to the anomaly happening.

I am getting an  even stronger sense that it will happen if "Own Call" is decoded after a "CQ".  The result is, as I stated, that the "CQ" alert sounds but the "Own Call" does not.

Thus it would seem that in this situation, the "CQ" sound preempts the "Own Call" sound.

Note that I also have WSJT-X set to decode at the deepest level, although I doubt that this is a contributing factor.

Thanks again
John - WA2HIP

John R. Petrocelli - WA2HIP
¶¶¶¶¶¶¶¶¶¶
Primary Home Page:
   http://wa2hip.com
On 1/21/2020 3:40 AM, HamApps Support (VK3AMA) wrote:

On 21/01/2020 2:19 pm, John Petrocelli via Groups.Io wrote:
All sounds are working very well in the newest version.

Yet, I have seen recently (past several weeks) that

Sometimes when there is a simultaneous "CQ" audio alert and "Own Call" audio alert the "Own Call" alert will not play.
However the "CQ" alert will play.

I am sensing that if the "CQ" decode hits JTAlert before the "Own Call" that this may happen.

I have checked the "Alerts Priority" and I do see that:
   1) there is no way to flag the "Own Call" as top priority
   2) "CQ" is shown as the top priority

Note that I have not experimented with making the "CQ" alert a lower priority, but that will be next in my efforts.

Has anyone else observed this behavior ??
-- 


John R. Petrocelli - WA2HIP

John,

I'll investigate and see if I can reproduce this behavior.

Regarding setting the "Own Call" as top priority, that is already the case and cannot be changed.
Did you miss this from the "Alerts -> Alerts Priority" section of the Settings?
 

de Laurie VK3AMA



locked Re: JTAlert won't open

HamApps Support (VK3AMA)
 

On 24/01/2020 9:01 am, Bill-KC8WSM 070-1191 wrote:
I think I have the screen shot thing figured out.  Here is a shot of my panel.

Please post an image of your running WSJT-X window. There may be something there that will help identify why JTAlert is not detecting WSJT-X running.

de Laurie VK3AMA