Date   

locked Turning off (Copy to Clipboard)

Mike Steiner
 

Maybe I’m missing it but is there a way to turn off where the callsign is automatically copied to clip board. It seems like this wants there a few versions back.

 

Thanks

Mike K7QDX


locked Re: Call sign database downloads

Joseph Hurd
 

Bill,

You're correct, the link is at the bottom of the page, I missed it, thanks. I downloaded the update and installed it.

Note that my license was updated with the FCC database on 3-9-2019. I think that would be enough time to get thru the system. :)


locked Re: Call sign database downloads

g4wjs
 
Edited

On 30/01/2020 17:49, Joseph Hurd wrote:
My call is being reported as SC in JTAlert. This was true until about a year ago. As I under stand i, the data for look ups if pulled from FCC records. I have updated my address in the FFC records and just checked the ULS - it is correct as a NC address. I do not see a database download on the HamApps webpage, just ones for the program itself and the sound files. Searching google, I found this link, but it is on somebody's blog and I don't trust it:

https://dnl.hamapps.com/Databases/HamApps.Databases.2020.01.24.Setup.exe

Where do I go to download a JTAlert call sign database update?

this issue existed with the last current version.

Hi Joseph,

that's the correct file. Why would you doubt a link that is within the hamapps.com domain? The link is also right there on the home page http://hamapps.com/, scroll down to "Support File Downloads". It may take a while for your address change with the FCC to filter through to Laurie's callsign database as I am sure there are few steps involved.


--
73
Bill
G4WJS.


locked Call sign database downloads

Joseph Hurd
 
Edited

My call is being reported as SC in JTAlert. This was true until about a year ago. As I under stand i, the data for look ups if pulled from FCC records. I have updated my address in the FFC records and just checked the ULS - it is correct as a NC address. I do not see a database download on the HamApps webpage, just ones for the program itself and the sound files. Searching google, I found this link, but it is on somebody's blog and I don't trust it:

https://dnl.hamapps.com/Databases/HamApps.Databases.2020.01.24.Setup.exe

Where do I go to download a JTAlert call sign database update?

this issue existed with the last current version.


locked Re: Issue with 2.15.8 and settings

Michael Black
 

Are you perhaps running Webroot?
If so use JTAlert_AL.exe instead.

de Mike W9MDB




On Thursday, January 30, 2020, 10:06:41 AM CST, Raymond Kasprzak <raykasprzak@...> wrote:


Also have a problem with 2.15.8.
Jt alert keeps displaying waiting for WSJTX to start even though WSJTX has started and  is running. This is not a Windows 10 problem.. Went back to 2.15.7 which works fine.


locked Re: Issue with 2.15.8 and settings

Raymond Kasprzak
 

Also have a problem with 2.15.8.
Jt alert keeps displaying waiting for WSJTX to start even though WSJTX has started and  is running. This is not a Windows 10 problem.. Went back to 2.15.7 which works fine.


locked Re: Issue with 2.15.8 and settings

g4wjs
 

On 30/01/2020 10:45, Joseph Hurd wrote:
Bill,

Understood. Just checked my PC, both x86 & x64 MS VC++ 2015 Redistributable are installed.
Joseph,

that means either your MSVC++ 2015 redistributable component is corrupt (unlikely), or you are suffering a different issue than the one discussed recently here: https://hamapps.groups.io/g/Support/topic/can_t_get_to_jtaler_manage/70137039?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,70137039

You could try reinstalling the redistributable component: https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads



--
73
Bill
G4WJS.


locked Re: Issue with 2.15.8 and settings

Joseph Hurd
 

Bill,

Understood. Just checked my PC, both x86 & x64 MS VC++ 2015 Redistributable are installed.


locked Re: Issue with 2.15.8 and settings

g4wjs
 

On 30/01/2020 10:28, Joseph Hurd wrote:
Hi Bill,

Did you mean to say the 64 bit [x64] version?
Joseph,

no, I meant what I typed.



--
73
Bill
G4WJS.


locked Re: Issue with 2.15.8 and settings

Joseph Hurd
 

Hi Bill,

Did you mean to say the 64 bit [x64] version?


locked Re: Issue with 2.15.8 and settings

g4wjs
 

On 30/01/2020 09:52, Joseph Hurd wrote:
This is apparently related to MS C++. My PC has many version of Visual C++ from 2015 [current] back to 2005, as different apps need different versions [some older] to run.
Hi Joseph,

you need to install the MS VC++ 2015 Redistributable 32-bit version.



--
73
Bill
G4WJS.


locked Issue with 2.15.8 and settings

Joseph Hurd
 

W7 Home x64 PC: I just updated JTAlert to v. 2.15.8. Decodes and alerts were ok, but when trying to open either settings, view or alerts, I get the error that:
API-MS-Win-CRT-Runtime-L1-1-0 DLL
is missing.

This is apparently related to MS C++. My PC has many version of Visual C++ from 2015 [current] back to 2005, as different apps need different versions [some older] to run. A google search revealed that the first suggestion for a missing API-MS-Win-CRT-Runtime-L1-1-0 DLL was to run "repair" on the latest version of C++. This did not resolve my issue.

My solution was to uninstall JTAlert v. 2.15.8 and then to re-install v.2-15-7. This resolved the issue.
I am not sure if this is a Windows issue or a JTAlert issue but thought it may be of help to others.

Note: Just to be sure, I suggest that you save your current configuration settings for JTAlert before uninstalling it.


locked Re: WSJT-X UDP -- piggyback messages to WSJT-X

Erik Icket
 

Thank you Bill, once more, for your thorough insights.

For the moment, I have something working for a single WSJTX instance along the limitations which you described earlier.

Let's see how JTalert or AutoIT evolves with respect to multicasting.

Thanks again and 73's,
Erik
ON4PB


locked Text Messaging #TIP

B. Smith
 

I wrote a simple .bat file that makes using the Text Messaging feature a little easier by invoking NotePad. I put some 73 types of messages that I commonly might want to send in the file and can cut-and-paste them,  rather than typing them out when using text messaging. I placed the .bat file in "Applications > Auto-start" area of JTAlert. Example of a path into Auto Start:  C:\Users\Bill\JTAlert.txt.bat
Bat file: @echo off
             Start D:\Documents\JTAlert.txt
I saved the text file as follows: C:\Users\Bill\JTAlert.txt.bat
Nice feature is that the file is editable, as you think of things and refine it - just "save" the edit.
It won't close out automatically, like real apps will in Auto-start - but it's just one mouse click to resolve.
73, Bill n3xl


locked Re: JTDX*JTALERT*GRIDTRACKER all together

Ham Email
 

Thanks Dave I ll try it this evening and let you know
73 Tom

On Jan 29, 2020, at 12:28 PM, D Visser <visserdekorte@...> wrote:

Hello,

Now running here all these 3 programs together.
This are my settings:

1 JTDX
settings*reporting:
ip adress udp server 127.0.0.1
udp server port 2237
acc udp request thicked
notify          thicked
acc udp restore windows thicked
 
2 JTALERT via JTDX
 
manage settings*applications wsjt-x/jtdx
ip adress 224.0.0.1
port 2238
rebroadcast thicked
 
3 Gridtracker
general*received udp messages from jtdx:
multicast thicked
ip adress 224.0.0.1
port 2238
forward upd messages
ip adress 127.0.0.1
port 2237
 
BTW start first program JTDX than JTALERT (JTDX) and last Gridtracker

David Visser


--
73, Tom K5AX


locked Re: JTDX*JTALERT*GRIDTRACKER all together

HamApps Support (VK3AMA)
 

FYI, the problem with this setup is that JTAlert losses the ability to send instructions to WSJT-X. Callsign coloring, initiate a WSJT-X QSO by a Callsign click in JTAlert, sending macros will all stop functioning.

de Laurie VK3AMA


locked Re: JTDX*JTALERT*GRIDTRACKER all together

g4wjs
 

On 29/01/2020 18:26, D Visser wrote:
Hello,

Now running here all these 3 programs together.
This are my settings:

1 JTDX
settings*reporting:
ip adress udp server 127.0.0.1
udp server port 2237
acc udp request thicked
notify          thicked
acc udp restore windows thicked
2 JTALERT via JTDX
manage settings*applications wsjt-x/jtdx
ip adress 224.0.0.1
port 2238
rebroadcast thicked
3 Gridtracker
general*received udp messages from jtdx:
multicast thicked
ip adress 224.0.0.1
port 2238
forward upd messages
ip adress 127.0.0.1
port 2237
BTW start first program JTDX than JTALERT (JTDX) and last Gridtracker

David Visser
David,

I am intrigued by your choice of 224.0.0.1 as a multicast address, why have you chosen that? 224.0.0.1 is a reserved IPv4 address that is used within the multicast routing protocol by routers that wish to query hosts on the local subnet for memberships of a multicast group. It should not be used by arbitrary applications for other purposes.



--
73
Bill
G4WJS.


locked Re: WSJT-X UDP -- piggyback messages to WSJT-X

g4wjs
 

On 29/01/2020 14:52, Erik Icket wrote:
Hi Laurie,

I understand that the JTAlert development environment does not support UDP multicasting and you had to implement the rebroadcasting functionality as a workaround.

Would it be however be possible for JTAlert to piggyback the UDP traffic from "the application to which the rebroadcasting is done" back to WSJT-X ?

I have developed an application which listens to the rebroadcasted UDP traffic, and does some specific highlighting in the Band Activity window.
The way I implemented this, is by doing a Windows "netstat -ab -p UDP" and retrieve the sending port for the WSJT-X to JTAlert flow.
I then re-use that port to issue "Highlight Callsign" messages from my app to WSJT-X. As you observe, it looks more like a "menage a trois", and is not very healthy ...

A possible implementation could be that JTAlert listens for incoming UDP traffic on its sending re-broadcasting socket, verify the "magic number" and forwards the traffic back to WSJT-X ....

What do you think ?

73's and greetings from Belgium,
ON4PB
Hi Erik,

what you are requesting is not as easy as you state. The reply datagrams would need to be correctly addressed to the instance of WSJT-X they are intended for, that would require JTAlert to keep a table of WSJT-X clients along with their service port numbers to reply to. That table probably already exists within JTAlert so that it can itself send reply datagrams, but it is hard to see how reply datagrams from your application can be allocated to the correct WSJT-X instance when routing them through, since JTAlert does not know to which original outgoing message the reply is to. More specifically, JTAlert has no knowledge of which sender service port of incoming reply datagrams belongs to which application.

All of this is elegantly handled if each application interoperating with WSJT-X is capable of listening on a UDP multicast group address, and each application need do no more than that, over and above what they would do using unicast addressing. It is unfortunate that the support libraries provided with AutoIT (the original implementation language of JTAlert) do not directly support listening for UDP traffic on a multicast group addresses. Someone with moderate AutoIT programming skills and some systems programming knowledge on MS Windows could write the necessary add-on for AutoIT to do what is required. Until that happens, or until Laurie is in a position to roll out the next generation of JTAlert, it is not practical to try and spoof multicast UDP handling in any way that meets your requirement.



--
73
Bill
G4WJS.


locked JTDX*JTALERT*GRIDTRACKER all together

D Visser
 

Hello,

Now running here all these 3 programs together.
This are my settings:

1 JTDX
settings*reporting:
ip adress udp server 127.0.0.1
udp server port 2237
acc udp request thicked
notify          thicked
acc udp restore windows thicked
 
2 JTALERT via JTDX
 
manage settings*applications wsjt-x/jtdx
ip adress 224.0.0.1
port 2238
rebroadcast thicked
 
3 Gridtracker
general*received udp messages from jtdx:
multicast thicked
ip adress 224.0.0.1
port 2238
forward upd messages
ip adress 127.0.0.1
port 2237
 
BTW start first program JTDX than JTALERT (JTDX) and last Gridtracker

David Visser


locked WSJT-X UDP -- piggyback messages to WSJT-X

Erik Icket
 

Hi Laurie,

I understand that the JTAlert development environment does not support UDP multicasting and you had to implement the rebroadcasting functionality as a workaround.
 
Would it be however be possible for JTAlert to piggyback the UDP traffic from "the application to which the rebroadcasting is done" back to WSJT-X ?

I have developed an application which listens to the rebroadcasted UDP traffic, and does some specific highlighting in the Band Activity window.
The way I implemented this, is by doing a Windows "netstat -ab -p UDP" and retrieve the sending port for the WSJT-X to JTAlert flow.
I then re-use that port to issue "Highlight Callsign" messages from my app to WSJT-X. As you observe, it looks more like a "menage a trois", and is not very healthy ...

A possible implementation could be that JTAlert listens for incoming UDP traffic on its sending re-broadcasting socket, verify the "magic number" and forwards the traffic back to WSJT-X ....

What do you think ?

73's and greetings from Belgium,
ON4PB