Date   

locked Re: mshv #HamSpots

Tom Melvin
 

Sorry Dave

It will not work - Laurie has been in touch with Christo (Author of MSHV) pointing out areas needing tidied up but he has refused to make changes. He will happily support new modes developed by the wsjtx team at drop of a hat but will not make changes to allow udp messages to work.

Post over in the MSHV forum - MSHV@groups.io - perhaps if enough people comment it may appear.

I only use MSHV as it support modes WSJT-X has dropped.

Tom
GM8MJV


On 1 Mar 2021, at 15:17, Dave Tucker Nu4N <dwtucker19@...> wrote:

Will JT Alert with MSHV software. Or is it in the future??
73's

--
DAVE NU4N


 

Will JT Alert with MSHV software. Or is it in the future??
73's

--
DAVE NU4N


locked Re: Worked B4 issue

neil_zampella
 

Do you even want to fix the installation?   Have you used the 'CONTACT SUPPORT' link under the HELP menu so that Laurie can see exactly what is happening?

Why accept something that is easily fixed, as I have been using DXKeeper for years with JT-Alert and have always seen the correct B4 list, even when using 'ignore B4 status date'. in contests.

Neil, KN3ILZ


locked Re: Worked B4 issue

Joe
 
Edited

OK then.  I guess witt the vagaries of software, I accept that I have an installation that DOESNT WORK.  But like I said, there are workarounds.

Cheers,

Joe/WQ6Q


locked Re: Duplicate HRD Logbook Entries With Invalid Time Stamps from JAlert #HRD

HamApps Support (VK3AMA)
 

On 1/03/2021 5:27 am, Ronald Panetta wrote:
  • The entry with the missing date (shows as 12/30/1899 when you double click on the entry) is from JTAlert. In my case Settings -> Logging -> Last QSO API -> UDP Transmission (enabled and UDP port 2333.
  • The entry with the date is from WSJT-X. In my case Settings -> Reporting -> Secondary UDP Server -> Enabled via IP address 127.0.0.1 port 2333.
  • I log with both as once HRD fixes the bug, I plan to use JTAlert for  logging and disable it in WSJT-X as that shows as deprecated. As stated earlier, I just clean up with the "Refresh"  button.
73, Ron WB2WGH


Ron,

There is no need to wait for HRD to fix their badly broken ADIF parser. The easy fix is to set JTAlert to use HRD logging and leave the WSJT-X secondary server and the JTAlert Last QSO function turned off.

By having JTAlert perform the HRD logging, which happens via the HRDLogbook TCP interface (no direct writing to the log, it is handled by HRD), is that you instantly gain accurate B4 checking against you log and one-click updating of the JTAlert Alert database for the different Alert types, rather than having to manually adjust the Alert settings which is tedious and error (human) prone.


de Laurie VK3AMA


locked Re: Worked B4 issue

Laurie, VK3AMA
 

On 1/03/2021 10:00 am, Joe wrote:
I think it is properly configured.  Works like a charm.  Love the whole DXLabs set of apps.  Same for JTAlert.  So, bottom line, this feature in JTAlert is broken??  Laurie, do you agree??

thanks,

Joe
No I don't agree. DXKeeper is my primary logger used with JTAlert. Of all the supported loggers, DXKeeper gets the most attention in terms of testing and features. B4 checking is not broken in my tests.

The B4 checks are done against DXKeeper. In another message you asked does JTAlert uses the WSJTX log file for dupe checking. The answer is NO. JTAlert never ever goes anywhere near the WSJT-X log.

What is not working exactly?

Use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis. I may have to follow up with a request to see your DXKeeper log file.

de Laurie VK3AMA


locked Re: Worked B4 issue

Joe Subich, W4TV
 

On 2021-02-28 6:00 PM, Joe wrote:

So, bottom line, this feature in JTAlert is broken?? Laurie, do you agree??
No. B4 works just fine for me with DXKeeper/DXLab.

73,

... Joe, W4TV


On 2021-02-28 6:00 PM, Joe wrote:
[Edited Message Follows]
I think it is properly configured.  Works like a charm.  Love the whole DXLabs set of apps.  Same for JTAlert.  So, bottom line, this feature in JTAlert is broken??  Laurie, do you agree??
thanks,
Joe


locked Re: JTAlert with JTDX and WSJT-X at the same time.

K0GU
 

A slight correction. When you start two instances of JTDX you only start JTAlert for JTDX once and it starta up on the second instance of JTDX and completely skips over the first instance.


locked Re: JTAlert with JTDX and WSJT-X at the same time.

K0GU
 

FWIW I found something of a kludge work around for using one WSJT-X with other instances of JTDX.

Stop all instances of JTDX and JTAlert. Start one instance of WSJT-X and JTAlert for WSJT. Start two instances of JTDX and JTAlert for JTDX. The first instance of JTDX will not work with JTAlert but the second instance will (and a third and a fourth). I've only had this running for a couple of hours so maybe I'll run into a problem sooner or later.

I have my 1st instance of JTDX minimized and getting it's audio from an unused input source to keep the load down. My computer can handle the extra overhead but slower computers might not.

There is probably some fatal flaw with this idea!??

73,  Jay  K0GU

 


locked Re: Worked B4 issue

Joe
 
Edited

I think it is properly configured.  Works like a charm.  Love the whole DXLabs set of apps.  Same for JTAlert.  So, bottom line, this feature in JTAlert is broken??  Laurie, do you agree??

thanks,

Joe


locked Re: Feature Request for "Alert Types" screen (f1)

Jim Cooper
 

On 27 Feb 2021 at 22:12, Mark W2OR via groups.io wrote:

Then, many hour later in the day or
morning, the change of continent
process in JTA is repeated when EU &
AF have long since faded away and AS
and OC are the primary focus, and
once again 7-8 selections are made in
JTA to make the switch. 
Have you looked into making an AutoHotkey
sequence for each of the two processes?
which would let you do them with one keypress.


locked Re: Worked B4 issue

Joe Subich, W4TV
 

Am I wrong to assume that JTALert uses the WSJTX log file for dupe checking, or does it query the DXKeeper database?
If you have properly configured DXKeeper (DXLab Suite) logging, JTAlert
uses the DXKeeper log for B4 (dupe) checking.

73,

... Joe, W4TV


On 2021-02-28 1:48 PM, Joe wrote:
I am using DXKeeper for logging.  There are several ways around this, but if the feature doesn't work, you should probably remove it.  Am I wrong to assume that JTALert uses the WSJTX log file for dupe checking, or does it query the DXKeeper database?


locked Re: Worked B4 issue

Joe
 

I am using DXKeeper for logging.  There are several ways around this, but if the feature doesn't work, you should probably remove it.  Am I wrong to assume that JTALert uses the WSJTX log file for dupe checking, or does it query the DXKeeper database?


locked Re: Duplicate HRD Logbook Entries With Invalid Time Stamps from JAlert #HRD

Ronald Panetta, WB2WGH
 

Rick, Are you seeing something like the screen snapshot below? If so, several comments:
  • The "Refresh" button (above "Time On" column) cleans up the dups
  • The blank dates are a known bug in HRD (V6.7.0.323). HRD is aware of the issue and I have been told by HRD it will be fixed in the next release. I opened a help desk ticket with HRD on this about a month ago and after some "not my problem" responses, finally got confirmation from Mike of HRD that it is indeed a bug and slated for a fix.
  • The entry with the missing date (shows as 12/30/1899 when you double click on the entry) is from JTAlert. In my case Settings -> Logging -> Last QSO API -> UDP Transmission (enabled and UDP port 2333.
  • The entry with the date is from WSJT-X. In my case Settings -> Reporting -> Secondary UDP Server -> Enabled via IP address 127.0.0.1 port 2333.
  • I log with both as once HRD fixes the bug, I plan to use JTAlert for  logging and disable it in WSJT-X as that shows as deprecated. As stated earlier, I just clean up with the "Refresh"  button.
73, Ron WB2WGH

image.png

On Sun, Feb 28, 2021 at 12:09 PM Rick <rick.tyo@...> wrote:
Nevermind. I found my own answer.  I had to tell JTAlert not to send the last QSO. Once that was unchecked, everything worked fine. 

On Sun, Feb 28, 2021, 9:52 AM Rick via groups.io <rick.tyo=gmail.com@groups.io> wrote:
I have it setup that when I run WSJT-X and HRD, my QSOs log automatically to the HRD Logbook. It works fine. But when I add JTAlert to the mix, I get a duplicate log entry in HRD Logbook with an invalid time stamp. (Then I have to open that entry in HRD Logbook and delete it.) What settings do I need to change to get JTAlert to stop sending duplicate log entries with invalid time stamps?



--
Ron


locked Re: Duplicate HRD Logbook Entries With Invalid Time Stamps from JAlert #HRD

Rick <rick.tyo@...>
 

Nevermind. I found my own answer.  I had to tell JTAlert not to send the last QSO. Once that was unchecked, everything worked fine. 


On Sun, Feb 28, 2021, 9:52 AM Rick via groups.io <rick.tyo=gmail.com@groups.io> wrote:
I have it setup that when I run WSJT-X and HRD, my QSOs log automatically to the HRD Logbook. It works fine. But when I add JTAlert to the mix, I get a duplicate log entry in HRD Logbook with an invalid time stamp. (Then I have to open that entry in HRD Logbook and delete it.) What settings do I need to change to get JTAlert to stop sending duplicate log entries with invalid time stamps?


locked Duplicate HRD Logbook Entries With Invalid Time Stamps from JAlert #HRD

Rick <rick.tyo@...>
 

I have it setup that when I run WSJT-X and HRD, my QSOs log automatically to the HRD Logbook. It works fine. But when I add JTAlert to the mix, I get a duplicate log entry in HRD Logbook with an invalid time stamp. (Then I have to open that entry in HRD Logbook and delete it.) What settings do I need to change to get JTAlert to stop sending duplicate log entries with invalid time stamps?


locked WSJT-X an JTAlert / QSO before B4 #DXLAB

suitbert@...
 

Hello,
I have run thru the description http://www.dxlabsuite.com/dxlabwiki/GettingStartedwithK1JTModesWithJTAlert serval times and set all
the switches asked for. But I still do not get a correct indication of calls, I have already worked before. They are still shown in the
JTAlert-display, but not marked B4.
What JTAlert-setting does effect this point most? Where to look at first? Thanks for your hint.
regards,
Suitbert, DF2PI


locked Start problem Subscript used on non-accessible variable

Frank IZ7AUH
 

Hi Guys,
need help today I have this problem




I try to reinstall JTAlert, try to delete users directory on AppData but not work :-(

Any solutions?

Best 73 IZ7AUH


locked Re: Feature Request for "Alert Types" screen (f1)

Mark W2OR
 

On Tue, Feb 23, 2021 at 04:28 PM, HamApps Support (VK3AMA) wrote:
<< If a Continent is needed in the Morning, how can it be not-needed in the Afternoon and then needed again the next morning?>>
In so many cases, as in this one, the continent alert feature is helpful in alerting the operator to an opening to DX in a particular part of the world (continent), not that the continent is "needed" for an award, but that propagation is opening (finally) towards that part of the world, and once alerted, the operator, who may have not been sitting right in front of the computer staring at decodes, or who may be working at an adjacent operating position, or who may be working in the adjacent room (work bench), can then return to the operating position to make adjustments such as (a) changing antenna direction; change antenna type favoring a particular continent; (c) change to a different operating position in the radio room to one that is dedicated to a particular band/antenna/mode (e.g. Six Meters), or (d) return to the radio room if he is not present when an opening is taking place.  See example below.
       In the afternoons here it's great to be alerted by JTA when props are finally changing in favor of Europe and Africa. So the op returns to the computer screen and those two continents are then removed from the JTA selection to avoid the now continuous EU & AF audio alerts, while leaving other continents of interest (Antarctica, OC, and others) still active in JTA.   Making those two afternoon continent changes in JTA is a process that involves spending time making seven or eight separate key stroke selections (Log Fields bar >> F11 >> then wait >> then Wanted Continent >> then Bands >> then add/remove two continents >> then click OK).   Then, many hour later in the day or morning, the change of continent process in JTA is repeated when EU & AF have long since faded away and AS and OC are the primary focus, and once again 7-8 selections are made in JTA to make the switch.  No big deal.  But, if the JTA Alert Types bar (F1) had two continent fields to choose from instead of just one, it'd make life easier for some of us DX'ers.


locked Re: Dozens of WSJT-X config files

K1APJ@...
 

Good day-

Yes, of course the title of the thread is wrong, I understand these are JTAlert files, per the directory tree, but I am happy to hear that they should not ALL be saved. I'll need to dig into that a bit.

Thank you for your timely and concise response, and your tireless support of the hobby


4601 - 4620 of 37833