Date   

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
 


locked Re: Which U.S. state is it?

Joe Subich, W4TV
 

On 2021-01-25 2:00 PM, WB8ASI Herb wrote:

I think States could be revised as well.
Not in QRZ. US station addresses/states are tied to the
FCC license database and can not be changed without changing
the address on file with the Commission.

73,

... Joe, W4TV


On 2021-01-25 2:00 PM, WB8ASI Herb wrote:
I travel between 2 locations (both in Mich).  Each has their own different station location in LOTW and eQSL.  Each have their own config in Log4OM and WSJT-X.  JTAlert prompts me to change my grid when using a different WSJT-X config.  This also reminds me to change my grid and county in QRZ so look-ups reflect my current location.  I think States could be revised as well.  This all seems to keep things straight.  Just need to be sure and be in the correct config when sending QSLs.  73,  Herb WB8ASI


locked Re: Which U.S. state is it?

WB8ASI Herb
 

I travel between 2 locations (both in Mich).  Each has their own different station location in LOTW and eQSL.  Each have their own config in Log4OM and WSJT-X.  JTAlert prompts me to change my grid when using a different WSJT-X config.  This also reminds me to change my grid and county in QRZ so look-ups reflect my current location.  I think States could be revised as well.  This all seems to keep things straight.  Just need to be sure and be in the correct config when sending QSLs.  73,  Herb WB8ASI  


locked Re: Which U.S. state is it?

Joe Subich, W4TV
 

If the station in question is only a temporary resident of
Nevada (Las Vegas), his FCC address is probably still in
Oregon. Most software WSJTX and JTAlert included use state
databases derived from the FCC ULS.

It is entirely consistent that JTAlert would "alert" on
Oregon based on its internal database but the station would
upload the QSO information to LotW using a "Station Location"
that included the grid for Las Vegas with the State being
Nevada.

You will find the same situation with grid "rovers" - their
"State" as shown by JT Alert will be their home state but
if/when they QSL via LotW the grid and state should be the
grid/state from which they were operating at the time of the
QSO.

73,

... Joe, W4TV

On 2021-01-25 9:50 AM, Michael Black via groups.io wrote:
Because your QSO partner did their upload with Nevada.
Doesn't matter what state you put in.
Mike W9MDB
On Monday, January 25, 2021, 08:46:14 AM CST, <hamradiosouth@webbplace.com> wrote:
Mike,
Then please explain to me how this QSO became "Nevada" in LOTW. Las Vegas is quite a distance from Oregon.
Charlie
W4EBB


locked Re: Which U.S. state is it?

Jim Spears
 

FN41 comprises all of RI plus a sliver of eastern CT and a chunk of MA including Cape Cod.  so 3 states in one grid.  there are probably grids that contain pieces of 4 states but none that have 5.

Jim
N1NK

3281 - 3300 of 36176