Date   

locked Re: JTalert vs. WSJT-X --rig-name config file path confusion

g4wjs
 

On 04/06/2018 19:00, Neal Pollack wrote:
I am confused about how to properly use WSJT-X.exe --rig-name=ICOM or Yaesu for a multi-rig config,
and how that interacts with JTalert.   I tried switching to the multi rig configuration last ngiht, and using
WSJT-X with the command line starting option did indeed create a new configuration directory for each
of my different transceivers.  BUT, when JTalert did not seem to match behavior, I looked in JTalert, clicked
the "?" then clicked ABOUT, and the pop-up dialog box on JTalert shows that it was using the default WSJT-X
config file path, and NOT the new ones in the folders I created with the WSJT-X --rig-name= options.

Does anyone have more experience/education/documentation to share with me so I can understand how
to properly make use of the wsjt-x -r option, or *IF* that option is even compatible with JTalert at this time?

Cheers,

Neal  N6YFM
Hi Neal,

you have to start as many JTAlertX instances as you have WSJT-X instances running. There is one gotcha, because of a limitation in JTAlert it cannot use the multicast UDP topology that WSJT-X expects for this sort of configuration, so instead you must set a different UDP server port in each WSJT-X instance that you have. You will need to do some checking that the port numbers you choose are not in use by other UDP servers.

73
Bill
G4WJS.



--
73
Bill
G4WJS.


locked JTalert vs. WSJT-X --rig-name config file path confusion

Neal Pollack
 

Hi:

I am confused about how to properly use WSJT-X.exe --rig-name=ICOM or Yaesu for a multi-rig config,
and how that interacts with JTalert.   I tried switching to the multi rig configuration last ngiht, and using
WSJT-X with the command line starting option did indeed create a new configuration directory for each
of my different transceivers.  BUT, when JTalert did not seem to match behavior, I looked in JTalert, clicked
the "?" then clicked ABOUT, and the pop-up dialog box on JTalert shows that it was using the default WSJT-X
config file path, and NOT the new ones in the folders I created with the WSJT-X --rig-name= options.

Does anyone have more experience/education/documentation to share with me so I can understand how
to properly make use of the wsjt-x -r option, or *IF* that option is even compatible with JTalert at this time?

Cheers,

Neal  N6YFM


locked Re: Problems JTAlert 2.11.2

David - AK2L
 

Upgraded to 2.11.2.  Using it with WSJT-X 1.9.1 and HRD 840.
Some QSOs do not log.
One logged, but only after 30 seconds.  Very fast computer.
QSO History window not updating.
Reverted to 2.11.1.  Everything working fine again.


locked JTAlert 2.11.2 not working as previous versions

N7AED <signalhz@...>
 

I have this new version installed and it's not logging every qso to the logbook. It is also not showing decoded call signs of all of the decoded signals. One qso I tried to log several times but it just would not log it into the logbook HRD. It logged it to WSJT-X but not HRD.

WIN 10 Ham Radio Deluxe JTAlert 2.11.2 WSJT-X 1.9.1


73 Steve N7AED



locked Re: Problems JTAlert 2.11.2

Rich Force
 

I installed ver 2.11.2 and it at first seemed the logging problem had disappeared.  However now when I log two QSOs JTA then fails to decode.  The only way I can get it to resume decoding is to shut down JTA and start it again and then after two QSOs it fails decoding again.  I am running Win 10 and the latest version of WSJT-x. 

Rich WB1ASL


locked Re: DXKeeper Logging Issue

Rick Johnson
 

Test shows 12 QSO's.....1 fail and 11 success logging to DXK.  Everything else works fine.using 2.11.2.
BTW....system is AMD 3 core 2.5Ghz/1TB hybrid/16GB/
If not for you and JTAlert FT/JT would be useless on HF.
Good goin'.......

de Rick W3BI
 

On Mon, Jun 4, 2018 at 9:05 AM, Larry Bryan <larry@...> wrote:
Laurie,

I downloaded version 2.11.2 and worked some Q's this morning. Your update has fixed the DXKeeper logging issue. Thanks as always for the great support from down under.

73
Larry
W8LIG



locked Re: Problems JTAlert 2.11.2

Morris WA4MIT
 

Windows 10 64 home updated and Microsoft antivirus/firewall.

Morris WA4MIT


locked Re: Problems JTAlert 2.11.2

Michael Black
 

What OS?  What antivirus are you running?

de Mike W9MDB




On Monday, June 4, 2018, 9:22:34 AM CDT, Morris WA4MIT via Groups.Io <wa4mit@...> wrote:


I have went back to .17 which I get the same disk full error msg when installing but it has worked flawlessly all morning on wild 6M band opening here. When upgrading to HRD .840 no error msg when installing. Go figure
73 Morris wa4mit


locked Re: Problems JTAlert 2.11.2

Morris WA4MIT
 

I have went back to .17 which I get the same disk full error msg when installing but it has worked flawlessly all morning on wild 6M band opening here. When upgrading to HRD .840 no error msg when installing. Go figure
73 Morris wa4mit


locked Re: Time info, Log ADIF and list for chat?

Michael Black
 

FYI...I'm working now on a COM port solution for hamlib.

You will be able to use a virtual serial port program and hook up any program that can open a TS-2000 on a COM port (which should be most any ham program).

This will (should) allow multiple programs to communicate without having to know anything about hamlib or your rig...just needs to know about a TS-2000 on a COM port which is one of the most common ones supported.

You will have to run one copy of rigctl for each com port pair (i.e. application needing rig access) but it should work.  The rigctl's will hook up to rigctld or flrig and all other programs can talk to a TS-2000 emulator that translates to your rig.

Hope to have this done in a week or two depending on my available time.


de Mike W9MDB



On Sunday, June 3, 2018, 11:04:33 AM CDT, g4wjs <bill.8@...> wrote:


On 03/06/2018 16:49, Franco Borsa [HB9oab] wrote:
I have the impression that this "timout delete" comes from frequency CAT commands that are passed on UDP traffic, that when something changes on the WSJTx CAT for example the frequency, JTalert receives a UDP that causes the "monitor" to reset to zero . But this is not always the case when I use VSPE above all this problem, however not always, I can not monitor UDP traffic but I think it depends on this.

Hi Franco,

dumb serial port splitters like VSPE are not supported with WSJT-X as reliable CAT control is not possible using them.

73
Bill
G4WJS.


--
73
Bill
G4WJS.


locked Re: Malwarebytes quarantines both 2.11.1 and 2.11.2

m_scot_alex
 


locked DXKeeper Logging Issue

Larry Bryan
 

Laurie,

I downloaded version 2.11.2 and worked some Q's this morning. Your update has fixed the DXKeeper logging issue. Thanks as always for the great support from down under.

73
Larry
W8LIG


locked Re: Problems JTAlert 2.11.2

Ron W3RJW
 

Similar problem:  It does not freeze and no error message,  but fails to log QSO even though the Successful log QSO popup comes up , also decodes in JTAlert window stop showing, while "Decodes History" continues to work ...... Have sent e-mail with files (the last two QSO's did not log) ...   JTAlert 2.11.2 Win 8.1 .. Had been working fine with v2.11.1 and earlier versions ...
--
73
Ron, W3RJW


locked Re: 2.11.1 & 2.11.2 fails

 

Excluding the HamApps folder in Malwarebytes allows 2.11.2 to install and run.

 

__________

Dan – K4SHQ

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of KG4W
Sent: Monday, June 4, 2018 7:23 AM
To: Support@HamApps.groups.io
Subject: [HamApps] 2.11.1 & 2.11.2 fails

 

Using Win 7 & WSJTX 1.9.1
The following happens when installing either version 2.11.1 or 2.11.2 of JTAlert. Previous versions install and work FB.
Malwarebytes quarantines the "jtalert.exe" file and the program is unusable.

I deactivate malwarebytes and install either of the 2 latest versions of JTAlert and the program works ok, except I notice the following difference compared to version 2.10.17. With the new versions, decoded callsigns do not disappear until (2) 15 second decodes have accumulated. With version 2.10.17, all decodes clear out with each 15 second period.

Of course, when I activate malwarebytes again, it deletes the "jtalert.exe" file. No changes have been made to my system, that I know about.

Dan K4SHQ posted a message yesterday and I think the same type of failure is happening on his end.

When I revert back to 2.10.17, all is good.

Ed
KG4W


--
Dan - K4SHQ


locked Re: 2.11.1 & 2.11.2 fails

 

Ed is correct.  I might add that Malwarebytes is up to date on my system.

 

__________

Dan – K4SHQ

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of KG4W
Sent: Monday, June 4, 2018 7:23 AM
To: Support@HamApps.groups.io
Subject: [HamApps] 2.11.1 & 2.11.2 fails

 

Using Win 7 & WSJTX 1.9.1
The following happens when installing either version 2.11.1 or 2.11.2 of JTAlert. Previous versions install and work FB.
Malwarebytes quarantines the "jtalert.exe" file and the program is unusable.

I deactivate malwarebytes and install either of the 2 latest versions of JTAlert and the program works ok, except I notice the following difference compared to version 2.10.17. With the new versions, decoded callsigns do not disappear until (2) 15 second decodes have accumulated. With version 2.10.17, all decodes clear out with each 15 second period.

Of course, when I activate malwarebytes again, it deletes the "jtalert.exe" file. No changes have been made to my system, that I know about.

Dan K4SHQ posted a message yesterday and I think the same type of failure is happening on his end.

When I revert back to 2.10.17, all is good.

Ed
KG4W


--
Dan - K4SHQ


locked MachineLearning/Anomalous.100% False Positive?

Mike N4LKB
 

Per your recommendations regarding possible false positives, I have submitted to following to Malwarebytes....I will let you know their response...

After installing the HamApps_JTAlert_2.11.2_Setup.exe, running the program results in an automatic quarantine of the exe, which my Malwarebytes Premium v3.4.5 shows as a file named "MachineLearning/Anomalous.100%". This also occurs on the previous version v 2.11.1. However, previous to that, v2.10.17 runs fine, has run fine since April 2017, and reverting to that shows no malware.

The JTAlert file is located at https://HamApps.com , and is a reputable site as well as author. Their previous files have been fault free, and they pay great attention to virus/malware issues. To quote them:

      Since JTAlert was released in 2011, there have never been any documented virus/malware/trojan infections caused by JTAlert.
     Prior to making a new JTAlert release publicly available, all JTAlert files and the Installer are submitted to the VirusTotal Online Scanner where scans from over 60 commercial scanners are performed.

I would like to see if your organization feels this is a false positive. Thank you in advance.

From a HamApps perspective, I am running Intel quad processor desktop, Windows 10 16299.431, wsjtx-1.9.1-win32, HRD Logbook v6.4.0.840 with an IC-735 and MFJ-1279 Sound card interface.

I'll just revert to 2.10.17 until further notice.

Regards,

N4LKB


locked Malwarebytes quarantines both 2.11.1 and 2.11.2

Mike N4LKB
 

Malwarebytes Premium (v3.4.5) automatically quarantines a file called "MachineLearning/Anomalous.100%" which effectively deletes JTAlert.exe for versions 2.11.1 (tried 3 times yesterday) or 2.11.2 (this morning)..

2.10.7 works fine, and has, from April thru yesterday morning..then tried 2.11.1 resulting in quarantine 3 times, reverted to 2.10.7 yesterday which then worked fine. Tried 2.11.2 this morning: quarantine.

Running Windows 10 (v1709), wsjtx-1.9.1-win32 , HRD Logbook (v6.4.0.840) (without CAT control) on IC-735.

N4LKB


locked 2.11.1 & 2.11.2 fails

KG4W
 

Using Win 7 & WSJTX 1.9.1
The following happens when installing either version 2.11.1 or 2.11.2 of JTAlert. Previous versions install and work FB.
Malwarebytes quarantines the "jtalert.exe" file and the program is unusable.

I deactivate malwarebytes and install either of the 2 latest versions of JTAlert and the program works ok, except I notice the following difference compared to version 2.10.17. With the new versions, decoded callsigns do not disappear until (2) 15 second decodes have accumulated. With version 2.10.17, all decodes clear out with each 15 second period.

Of course, when I activate malwarebytes again, it deletes the "jtalert.exe" file. No changes have been made to my system, that I know about.

Dan K4SHQ posted a message yesterday and I think the same type of failure is happening on his end.

When I revert back to 2.10.17, all is good.

Ed
KG4W


locked Problems JTAlert 2.11.2

Morris WA4MIT
 

Hello upon installing Alert 2.11.2 I received a error msg about disk full and after install the program will hang up freeze at about the 10 minute mark after starting see attached screen shots and a report has been sent of events this day. The call sign shown was previous qso it was logged the WA3 station when finished Alert sent logged msg but was not actually logged. The freezing occurred with both WSJTX and JTDX. Using HRD 840 on a Windows 10 64 home build 1803 Dell 660 I5 with 8gb ram. 
Thanks 73 Morris wa4mit
 


locked New JTAlert 2.11.2 Available : Fixes Intermittent TCP Logging failures : #Announcement #NewRelease

HamApps Support (VK3AMA)
 

New JTAlert 2.11.2 is available for download.

This release fixes the
(2.11.1 defect) intermittent logging failures to HRD, DXKeeper and ACLog experienced by some users.

Important to note is this is the last JTAlert release that will install under Windows XP and Vista.

Visit https://HamApps.com for the download link and upgrade/install instructions.

Release Notes...
2.11.2 (04-Jun-2018)

   *** Important Note:
   *** This is the last version that supports installation on Windows XP & Vista.

  Fixes:
    - Intermittent logging failures to HRD, DXKeeper and ACLog. Caused by the TCP
       connect timeout value being too short for some systems. (2.11.1 defect)

de Laurie VK3AMA

18321 - 18340 of 38532