Date   

locked Re: Multiple instances #JTDX #FT8

HamApps Support (VK3AMA)
 

On 30/01/2021 9:19 am, John Holmes W9ILY wrote:
My previous post didn't appear so I am repeating.
I have two issues. First, the 4th instance of JTAlert does not decode anything. The first 3 are OK but not #4.
Secondly, does JTAlert function with multiple instances of JTDX? The first instance is fine but not any other ones.
Thanks for your help.
John W9iLY

Check the UDP server settings for your 4th instance. How do you have the UDP server settings set, are you using a multicast IP or "127.0.0.1" with unique UDP port for each instance technique? If the latter, you will likely find your 4th instance is using the same port as one of your other instances.

Send me a support request. Bring up your 4 instances, it doesn't matter that one is failing, wait 5 minutes to give JTAlert sufficient time to capture a snapshot of your running processes, before sending the support request.

There is no limit to the number of JTDX instances (expect the max 16 that JTAlert also applies to WSJT-X). Don't try an mix and match WSJT-X and JTDX instances, use one or the other.

de Laurie VK3AMA


locked Re: JTAlert locks up if too many QSO's in HRD logbook #HRD

Michael Black
 

Ensure you have your database file/folder excluded from anti virus programs.

Mike W9MDB




On Friday, January 29, 2021, 05:13:14 PM CST, Jim - N4ST <newsgroup@...> wrote:


Barry,

 

Something else is causing your problem.  4,700 QSOs are not a lot for HRD Logbook.

 

_____________

73,

Jim – N4ST

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Barry Mcdonald via groups.io
Sent: Friday, January 29, 2021 09:01
To: Support@HamApps.groups.io
Subject: [HamApps] JTAlert locks up if too many QSO's in HRD logbook #HRD

 

I have JTAlert sending to HRD logbook.  Use to work great but started locking up for a few minutes after QSO sent or clicking on anything to transmit.  Kept getting worse.  Trouble shot to JTAlert not able to get existing info from logbook such as B4.  After finally narrowing it down to this I created a new DB in HRD and this worked great.  Unfortunately This has no B4 info.  I currently have 4700 entries in HRD.  Is there a limit or solution?  If I remove about half of these it is fine.  All software is current.
Thanks,
Barry
W5CJ 


--
____________________
73,
Jim - N4ST


locked Re: JTAlert locks up if too many QSO's in HRD logbook #HRD

Jim - N4ST
 

Barry,

 

Something else is causing your problem.  4,700 QSOs are not a lot for HRD Logbook.

 

_____________

73,

Jim – N4ST

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Barry Mcdonald via groups.io
Sent: Friday, January 29, 2021 09:01
To: Support@HamApps.groups.io
Subject: [HamApps] JTAlert locks up if too many QSO's in HRD logbook #HRD

 

I have JTAlert sending to HRD logbook.  Use to work great but started locking up for a few minutes after QSO sent or clicking on anything to transmit.  Kept getting worse.  Trouble shot to JTAlert not able to get existing info from logbook such as B4.  After finally narrowing it down to this I created a new DB in HRD and this worked great.  Unfortunately This has no B4 info.  I currently have 4700 entries in HRD.  Is there a limit or solution?  If I remove about half of these it is fine.  All software is current.
Thanks,
Barry
W5CJ 


--
____________________
73,
Jim - N4ST


locked Re: JTAlert locks up if too many QSO's in HRD logbook #HRD

Dick Bingham
 

Hello all

I am experiencing a similar 'lock-up' that takes up to 1-minute and 45-seconds
for the DXKeeper logging operation to release WSJT-X FT8 to begin decoding again.

Almost seems like it it tied to the 15-second RX/TX cycles of FT8.

73  Dick/w7wkr



On Fri, Jan 29, 2021 at 11:30 AM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 30/01/2021 1:00 am, Barry Mcdonald via groups.io wrote:
I have JTAlert sending to HRD logbook.  Use to work great but started locking up for a few minutes after QSO sent or clicking on anything to transmit.  Kept getting worse.  Trouble shot to JTAlert not able to get existing info from logbook such as B4.  After finally narrowing it down to this I created a new DB in HRD and this worked great.  Unfortunately This has no B4 info.  I currently have 4700 entries in HRD.  Is there a limit or solution?  If I remove about half of these it is fine.  All software is current.
Thanks,
Barry
W5CJ 

Barry,

Let me guess, you're using an Access type Log in HRD, is that correct?

4700 entries is small and is not the cause of your problems. In the past I have tested with Access logs of over 100,000 entries without issue.

In recent months there have been a not insignificant number of JTAlert/HRD users who have experienced a range of issues, the most common being increasing slowdowns. The solution in all cases was to create a new logbook in HRDLogbook, import your old QSOs into that new Log and then set JTAlert to use that new Log.

You have already created the new log, but have not performed the import of your old QSOs and that is why the B4's are not working. Your old QSO and the number of are not the problem so it is safe to import them into your new Log.

The root cause of the HRD Access log problem is unknown, I suspect something gets broken within the ODBC DSN that all HRD logs use, possibly due to Windows updates. Creating a new Log creates a new DSN after which the problems disappear.

Let us no how you get on.

de Laurie VK3AMA


locked Multiple instances #JTDX #FT8

John Holmes W9ILY
 

Laurie,
My previous post didn't appear so I am repeating.
I have two issues. First, the 4th instance of JTAlert does not decode anything. The first 3 are OK but not #4.
Secondly, does JTAlert function with multiple instances of JTDX? The first instance is fine but not any other ones.
Thanks for your help.
John W9iLY


locked Re: JTAlert locks up if too many QSO's in HRD logbook #HRD

Barry Mcdonald <bmcdon9085@...>
 

I had put 1200 QSO's back in by copy and paste to give me some of the B4's and it worked good.  I deleted them all out of the new database and did an import to do it proper.  It worked perfect for about 10 minutes but when I made a contact it messed up again for about 10 minutes.  Workes great until I give it a comand like freq. change, mode change or try to make a contact.  Any other ideas?
Barry
W5CJ


locked Re: JTAlert locks up if too many QSO's in HRD logbook #HRD

HamApps Support (VK3AMA)
 

On 30/01/2021 1:00 am, Barry Mcdonald via groups.io wrote:
I have JTAlert sending to HRD logbook.  Use to work great but started locking up for a few minutes after QSO sent or clicking on anything to transmit.  Kept getting worse.  Trouble shot to JTAlert not able to get existing info from logbook such as B4.  After finally narrowing it down to this I created a new DB in HRD and this worked great.  Unfortunately This has no B4 info.  I currently have 4700 entries in HRD.  Is there a limit or solution?  If I remove about half of these it is fine.  All software is current.
Thanks,
Barry
W5CJ 

Barry,

Let me guess, you're using an Access type Log in HRD, is that correct?

4700 entries is small and is not the cause of your problems. In the past I have tested with Access logs of over 100,000 entries without issue.

In recent months there have been a not insignificant number of JTAlert/HRD users who have experienced a range of issues, the most common being increasing slowdowns. The solution in all cases was to create a new logbook in HRDLogbook, import your old QSOs into that new Log and then set JTAlert to use that new Log.

You have already created the new log, but have not performed the import of your old QSOs and that is why the B4's are not working. Your old QSO and the number of are not the problem so it is safe to import them into your new Log.

The root cause of the HRD Access log problem is unknown, I suspect something gets broken within the ODBC DSN that all HRD logs use, possibly due to Windows updates. Creating a new Log creates a new DSN after which the problems disappear.

Let us no how you get on.

de Laurie VK3AMA


locked JTAlert locks up if too many QSO's in HRD logbook #HRD

Barry Mcdonald <bmcdon9085@...>
 

I have JTAlert sending to HRD logbook.  Use to work great but started locking up for a few minutes after QSO sent or clicking on anything to transmit.  Kept getting worse.  Trouble shot to JTAlert not able to get existing info from logbook such as B4.  After finally narrowing it down to this I created a new DB in HRD and this worked great.  Unfortunately This has no B4 info.  I currently have 4700 entries in HRD.  Is there a limit or solution?  If I remove about half of these it is fine.  All software is current.
Thanks,
Barry
W5CJ 


locked Re: Request for Call Sign alert feature

WarrenG KC0GU
 

That would be called JTALERT, it does all that and more, check it out!

Warren KC0GU


locked Re: Request for Call Sign alert feature

James N7ELL
 

Unfortunately that function is only for stations decoded by your station and not other stations calling a “rare one” or some DX.

 

Cheers,

James

N7ELL

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Dave Garber
Sent: Wednesday, January 27, 2021 4:32 PM
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Request for Call Sign alert feature

 

is this what you seek

 

 

Dave Garber

VE3WEJ / VE3IE

 

 

On Wed, Jan 27, 2021 at 5:15 PM Mark W2OR via groups.io <reston2010mm-orders=yahoo.com@groups.io> wrote:

This is a request for a call sign alert feature - - an audible/visual alert when a desired call sign (or a desired DX Entity) is called by other stations, though not yet decoded at one's own QTH.

The idea here is probably obvious.  It'd be great to have advance "warning" (also known as a "heads up") when a needed entity or rare call sign has shown up on the band and is seen being called by others, but not being decoded (yet) at our own QTH. Advance notice would give an operator a chance to better set up his station for a possible contact, attending to the antenna, making appropriate preparations, halting QSO's with other stations, checking PSK-Reporter for exact frequency, and otherwise turning away from other distracting tasks at hand.  Such an alert would be especially helpful for when potential contact with rare DX stations depends on a small 'window' of opportunity, sometimes lasting only for 10-15 minutes or so, such as during certain Grey Line conditions.  Thank you!  

  


locked Re: Request for Call Sign alert feature

Dave Garber
 



yes, just add that call to the alert box

no??


Dave Garber
VE3WEJ / VE3IE


On Wed, Jan 27, 2021 at 7:17 PM KL7NW <john.kl7nw@...> wrote:

He wants to get alerted for a callsign that is being called by others.  What the Wanted Callsign does is this:

 

 

While this might be useful some of the time, the DXCluster alerts might be just as useful, but I have not found it easy to setup!

 

John KL7NW

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Dave Garber
Sent: Wednesday, January 27, 2021 17:32
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Request for Call Sign alert feature

 

is this what you seek

 

 

Dave Garber

VE3WEJ / VE3IE

 

 

On Wed, Jan 27, 2021 at 5:15 PM Mark W2OR via groups.io <reston2010mm-orders=yahoo.com@groups.io> wrote:

This is a request for a call sign alert feature - - an audible/visual alert when a desired call sign (or a desired DX Entity) is called by other stations, though not yet decoded at one's own QTH.

The idea here is probably obvious.  It'd be great to have advance "warning" (also known as a "heads up") when a needed entity or rare call sign has shown up on the band and is seen being called by others, but not being decoded (yet) at our own QTH. Advance notice would give an operator a chance to better set up his station for a possible contact, attending to the antenna, making appropriate preparations, halting QSO's with other stations, checking PSK-Reporter for exact frequency, and otherwise turning away from other distracting tasks at hand.  Such an alert would be especially helpful for when potential contact with rare DX stations depends on a small 'window' of opportunity, sometimes lasting only for 10-15 minutes or so, such as during certain Grey Line conditions.  Thank you!  

  


locked Re: Request for Call Sign alert feature

Jim Cooper
 

No, he specifically said "not decoded at my station yet"

BUT ...  what Mark is asking for is already amply and
excellently provided by the SPOTTING servers, clusters, the Reverse Beacon Networks, etc. such as N1MM+ provides
in their Telnet window.   There are many of them.

https://dxwatch.com/
https://hamspots.net/
http://www.dxsummit.fi/
https://www.dxmaps.com/
http://k7ar.net/ft8web/Default.aspx
https://dxheat.com/dxc/

All of the above are highly refined and expert
at doing just what Mark is asking for, without
adding any further overhead to JTalert ...

And most of the above, you can 'filter' for a
specific callsign -- if you are watching for a
dxpedition or such.

w2jc





On 27 Jan 2021 at 18:32, Dave Garber wrote:

is this what you seek


Dave Garber
VE3WEJ / VE3IE


On Wed, Jan 27, 2021 at 5:15 PM Mark W2OR via groups.io
<reston2010mm-orders@...> wrote:

> This is a request for a call sign alert feature - - an
audible/visual
> alert when a desired call sign (or a desired DX Entity) is called by
other
> stations, though not yet decoded at one's own QTH.
>
> The idea here is probably obvious.  It'd be great to have advance
> "warning" (also known as a "heads up") when a needed entity or rare
call
> sign has shown up on the band and is seen being called by others,
but not
> being decoded (yet) at our own QTH. Advance notice would give an
operator a
> chance to better set up his station for a possible contact,
attending to
> the antenna, making appropriate preparations, halting QSO's with
other
> stations, checking PSK-Reporter for exact frequency, and otherwise
turning
> away from other distracting tasks at hand.  Such an alert would be
> especially helpful for when potential contact with rare DX stations
depends
> on a small 'window' of opportunity, sometimes lasting only for
10-15
> minutes or so, such as during certain Grey Line conditions.  Thank
you!
>
>
>
>
>




  


locked Re: Request for Call Sign alert feature

KL7NW
 

Another good option which is fairly easily setup is to use https://hamalert.org/about which can send alerts to your cell phone with either their HamAlert app or another app called Threema.  You can configure it for many conditions.

 

John KL7NW

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of KL7NW via groups.io
Sent: Wednesday, January 27, 2021 18:17
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Request for Call Sign alert feature

 

He wants to get alerted for a callsign that is being called by others.  What the Wanted Callsign does is this:

 

 

While this might be useful some of the time, the DXCluster alerts might be just as useful, but I have not found it easy to setup!

 

John KL7NW

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Dave Garber
Sent: Wednesday, January 27, 2021 17:32
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Request for Call Sign alert feature

 

is this what you seek

 

 

Dave Garber

VE3WEJ / VE3IE

 

 

On Wed, Jan 27, 2021 at 5:15 PM Mark W2OR via groups.io <reston2010mm-orders=yahoo.com@groups.io> wrote:

This is a request for a call sign alert feature - - an audible/visual alert when a desired call sign (or a desired DX Entity) is called by other stations, though not yet decoded at one's own QTH.

The idea here is probably obvious.  It'd be great to have advance "warning" (also known as a "heads up") when a needed entity or rare call sign has shown up on the band and is seen being called by others, but not being decoded (yet) at our own QTH. Advance notice would give an operator a chance to better set up his station for a possible contact, attending to the antenna, making appropriate preparations, halting QSO's with other stations, checking PSK-Reporter for exact frequency, and otherwise turning away from other distracting tasks at hand.  Such an alert would be especially helpful for when potential contact with rare DX stations depends on a small 'window' of opportunity, sometimes lasting only for 10-15 minutes or so, such as during certain Grey Line conditions.  Thank you!  

  


locked Re: Request for Call Sign alert feature

KL7NW
 

He wants to get alerted for a callsign that is being called by others.  What the Wanted Callsign does is this:

 

 

While this might be useful some of the time, the DXCluster alerts might be just as useful, but I have not found it easy to setup!

 

John KL7NW

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Dave Garber
Sent: Wednesday, January 27, 2021 17:32
To: Support@hamapps.groups.io
Subject: Re: [HamApps] Request for Call Sign alert feature

 

is this what you seek

 

 

Dave Garber

VE3WEJ / VE3IE

 

 

On Wed, Jan 27, 2021 at 5:15 PM Mark W2OR via groups.io <reston2010mm-orders=yahoo.com@groups.io> wrote:

This is a request for a call sign alert feature - - an audible/visual alert when a desired call sign (or a desired DX Entity) is called by other stations, though not yet decoded at one's own QTH.

The idea here is probably obvious.  It'd be great to have advance "warning" (also known as a "heads up") when a needed entity or rare call sign has shown up on the band and is seen being called by others, but not being decoded (yet) at our own QTH. Advance notice would give an operator a chance to better set up his station for a possible contact, attending to the antenna, making appropriate preparations, halting QSO's with other stations, checking PSK-Reporter for exact frequency, and otherwise turning away from other distracting tasks at hand.  Such an alert would be especially helpful for when potential contact with rare DX stations depends on a small 'window' of opportunity, sometimes lasting only for 10-15 minutes or so, such as during certain Grey Line conditions.  Thank you!  

  


locked Re: Request for Call Sign alert feature

Dave Garber
 

is this what you seek


Dave Garber
VE3WEJ / VE3IE


On Wed, Jan 27, 2021 at 5:15 PM Mark W2OR via groups.io <reston2010mm-orders=yahoo.com@groups.io> wrote:
This is a request for a call sign alert feature - - an audible/visual alert when a desired call sign (or a desired DX Entity) is called by other stations, though not yet decoded at one's own QTH.

The idea here is probably obvious.  It'd be great to have advance "warning" (also known as a "heads up") when a needed entity or rare call sign has shown up on the band and is seen being called by others, but not being decoded (yet) at our own QTH. Advance notice would give an operator a chance to better set up his station for a possible contact, attending to the antenna, making appropriate preparations, halting QSO's with other stations, checking PSK-Reporter for exact frequency, and otherwise turning away from other distracting tasks at hand.  Such an alert would be especially helpful for when potential contact with rare DX stations depends on a small 'window' of opportunity, sometimes lasting only for 10-15 minutes or so, such as during certain Grey Line conditions.  Thank you!  

  


locked Request for Call Sign alert feature

Mark W2OR
 

This is a request for a call sign alert feature - - an audible/visual alert when a desired call sign (or a desired DX Entity) is called by other stations, though not yet decoded at one's own QTH.

The idea here is probably obvious.  It'd be great to have advance "warning" (also known as a "heads up") when a needed entity or rare call sign has shown up on the band and is seen being called by others, but not being decoded (yet) at our own QTH. Advance notice would give an operator a chance to better set up his station for a possible contact, attending to the antenna, making appropriate preparations, halting QSO's with other stations, checking PSK-Reporter for exact frequency, and otherwise turning away from other distracting tasks at hand.  Such an alert would be especially helpful for when potential contact with rare DX stations depends on a small 'window' of opportunity, sometimes lasting only for 10-15 minutes or so, such as during certain Grey Line conditions.  Thank you!  

  


locked Re: Post WSJT 2.2.3 rc3

Dave Garber
 

check the reporting tab in wsjt for udp check boxes

Dave Garber
VE3WEJ / VE3IE


On Wed, Jan 27, 2021 at 10:37 AM Dana Smith <ah6rim9@...> wrote:
After using rc 3 for several weeks without issue. Once gone and move the rc4, JTAlert and Log4OM are not communicating. Moved back to 2.2.2 with same result after going thru the install directions for both again. Win 10, IC-7410, direct CAT.
Any ideas what has happened?
Thanks,
Dana  K7QH

--
Any chance there is a version of Alert that works on a Mac or to be developed?
K7QH


locked Post WSJT 2.2.3 rc3

Dana Smith
 

After using rc 3 for several weeks without issue. Once gone and move the rc4, JTAlert and Log4OM are not communicating. Moved back to 2.2.2 with same result after going thru the install directions for both again. Win 10, IC-7410, direct CAT.
Any ideas what has happened?
Thanks,
Dana  K7QH

--
Any chance there is a version of Alert that works on a Mac or to be developed?
K7QH


locked Re: "Two" different Software configs with "One" JTAlert

Laurie, VK3AMA
 

On 27/01/2021 11:48 am, nd2k@arrl.net wrote:
But here is where I get confused...when using HRD, what "points" JTAlert to the WSJT-X
adif file under subfolder HRD and writes to HRD log, and likewise, when using FLRIG what "points"
to the WSJT-X adif under FLRIG and writes to Log4om?? Is there a switch/argument I need to add??
Thanks & Regards...
Al ND2K
There is nothing special you need to do with JTAlert except to setup Log4Om logging and then enabling that logger. Your existing HRD settings within JTAlert are remembered and you can switch back by simply re-enabling HRD logging. After switching loggers you should run a JTAlert "Rebuild Alert Database" operation as it examines your current log to setup the internal Alert lists.

JTAlert automatically determines which WSJT-X setup your running and monitor the UDP traffic from WSJT-X for Alerting and Logging. There is nothing you need to do for JTAlert.

JTAlert does not monitor the adif file written by WSJT-X, it doesn't care about it and never looks at it, it monitors the UDP traffic from WSJT-X only for logging. It doesn't matter which WSJT-X instance the UDP data is coming from.

You should not use LOg4OM setup to work with the WSJT-X adi file directly. While possible, it is not recommended and at worse if combined with JTAlert -> Log4OM logging will result in duplicate entries in your Log4OM log, one entry with minimal data (comes directly from WSJT) and the other with additional data received from your xml lookup, previous log entries and the JTAlert Callsign database (coming from JTAlert).

See the JTAlert Help File, "Settings -> Logging -> Log4OM V2" section for correct (and simple with pictures) Log4OM setup for working with JTAlert.

de Laurie VK3AMA


locked "Two" different Software configs with "One" JTAlert

nd2k@...
 

For the longest time, I have used the last free build of HRD with WSJT-X & JTAlert.
I want to migrate to FLRIG/FLDIGI/WSJT-X/Log4om; I have FLRIG/FLDIGI/WSJT-X
working and need to add JTAlert/Log4om.
 
I want to keep the old HRD config along side the FLRIG config, at least for a little while
before migrating over completely. This is with the same rig, so of course only one or 
the other would be used at any one time.
 
So I've created 2 WSJT-X shortcuts using the switch --rig=HRD and --rig=FLRIG
I figured even though I'm using 2 different software packages INSTEAD of rigs, it is creating
the subfolders HRD & FLRIG that I need. (or should I be using --config?? Is there any place where
the various switches are explained??)
 
But here is where I get confused...when using HRD, what "points" JTAlert to the WSJT-X 
adif file under subfolder HRD and writes to HRD log, and likewise, when using FLRIG what "points"
to the WSJT-X adif under FLRIG and writes to Log4om?? Is there a switch/argument I need to add??
 
Thanks & Regards...
 
Al ND2K
 

4881 - 4900 of 37780