Date   

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

Roger- AC6BW
 

I echo Anthony's comment. I have over 10K QSOs and I am using HRD with Maria DB, and there are no delays or other problems. HRD is soon going to be moving away from MS Access, due to all of the problems, and will switch over to some other database. I'm not sure, but it may be SQL.
Barry,
Copy and paste is not the best way to import your log. Backup your log to an XML file, using the usual HRD backup tool. Then create a new database. Then import the XML file into the new database.
Also, since you seem to be having problems during Tx, have you ruled out the possibility of RFI to your CAT cable or USB cable?
--
73,
Roger
AC6BW


locked Re: Multiple instances #JTDX #FT8

John Holmes W9ILY
 

Hi Laurie.
You were exactly right, as usual! The UDP ports were not different and everything now works. One further question...can multiple "view decodes" windows be opened? When 4 instances are open and a spot is announced it is difficult to tell which decode produced the spot. Being able to scroll back would be very helpful. Also it seems that a decodes window is only launched when you choose "view decodes" from the very first instance.Thanks!
John W9iLY


locked Suggestion for future releases #HRD

WB5JJJ - George
 
Edited

I use JTA to log to HRD LB and all is "almost" great.  The only problem is strictly a visual one.  

When a word has something like this "Andrés", the  "é" becomes a "?".  Also if there is something like "Jr, SR or III", after a comma in the name (George, Jr), the space is omitted after the comma while other spaces in the name field are preserved no matter how many words are there.  This does not happen when logging from WSJTx or directly in HRD LB from QRZ.com (XML).  

Perhaps a look-see at this for a future release would be most appreciated.  

--
73's
George - WB5JJJ
Hamshack Holine #4969


locked Re: Request for Call Sign alert feature

Mark W2OR
 

Nice to see the seven replies to the initial post and request here ... especially the one reply that actually addressed the issue at hand.  

The typical spotting networks and such, great as they are, are not at all a substitute to the feature being requested here. 

Laurie, if you could consider this suggested feature for one of your future updates, that'd be terrific.    
73 / Mark
.. w2or ..


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

Antony
 

I am using the latest HRD with Maria Db. I have over 88K QSOs in the log and get no delays at all. JTAlert works very well with HRD. I hope you get it sorted soon.
Antivirus is active.
73, Antony G4CUS


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

f8nhf
 

Hello friends
I have the same problem as I noticed, it happens when I change tape, when I change mode.
when I start a day everything works great for a few hours but as soon as I change the frequency or mode the blockage occurs I have to restart the PC for it to work again.
my PC win 10 64 Bits 64 of RAM intel I5 3400
hrd logboock 53007 qso
 no antivirus
73 Denis F8NHF


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!  

  

4761 - 4780 of 37666