Date   

locked Decodes window filters

Dave LeDuc
 

Somehow I set a filter for the decodes window and can’t figure out how to clear it.

When I display the filter status “view detailed filter status” it displays “Active filters Callsign = CP6CL”

Also the decodes window displays “Filtered : CP6CL” on the bottom border.

Thanks for your help

 

Dave N1IX


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

Barry Mcdonald <bmcdon9085@...>
 

My problems with too many QSOs is resolved.  First I found some very helpful info on HRD support group.  It suggested creating a new DB and that should resolve it which I had already done once..  The only difference from when I did this before is the Access driver used.  This fixed the problem.  Then I saw in another post with very detailed instructions on setting up and using MariaDB.  This is great and fast also like several of you mentioned.  As far as I am concerned Access is toast.  HRD doesn't like it and will be moving into a SQL DB system in the near future.  Thank you very much for all the input.

73,
Barry
W5CJ


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

John Petrocelli
 

Just adding my 2 cents.........

   For backup purposes and in addition to regular weekly backups of the system,
   there is a FREE program called "DirSyncPro"

   It allows one to schedule compare and copy directories from on drive to another.

   Although I do not use HRD, I still have this utility scheduled to run every 6 hours to copy my critical files to another drive on my home network.

regards all
John
John R. Petrocelli - WA2HIP
¶¶¶¶¶¶¶¶¶¶
Primary Home Page:
   http://wa2hip.com
On 1/30/2021 8:33 PM, Roger M via groups.io wrote:
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


Virus-free. www.avast.com


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!  

  

2421 - 2440 of 35329