Date   

locked Re: Windows 10 JTAlert-x

HamApps Support (VK3AMA)
 

On 9/04/2018 7:11 AM, 2e0keh@... wrote:

Hello Laurie

Thanks for reply, cat is fine with HRD

 

I can’t get JT-x alert communicate with HRD logbook. Just found error in HRD network server log WSAError Socket Bind failure = Unknown Windows socket error 0. I tried uploading a small *.jpeg still cant make any sence of why I am having comms issue on Win 10 and none on Win 7.

 

Rgds

Pete

Pete

JTAlert communicates with HRD, only with its log file, via the ODBC DSN setup for the HRD Log, no networking involved. That socket error may indicate some sort of configuration issue within HRD, I don't know. I am unable to provide HRD networking specific advice.

If JTAlert is not working with the HRD log, make sure the JTAlert settings are correct. You need to have the Version 5 radio button and checkbox enabled and the correct DSN selected (that matches your HRD configured log).

eg...



If you still have troubles, Please use the "? -> Contact Support" menu, on the JTAlert title-bar, to send me your Configuration and Session files for analysis.

de Laurie VK3AMA
   


locked Re: Windows 10 JTAlert-x

2e0keh@...
 

Hello Laurie

Thanks for reply, cat is fine with HRD

 

I can’t get JT-x alert communicate with HRD logbook. Just found error in HRD network server log WSAError Socket Bind failure = Unknown Windows socket error 0. I tried uploading a small *.jpeg still cant make any sence of why I am having comms issue on Win 10 and none on Win 7.

 

Rgds

Pete

 

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: 08 April 2018 22:02
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Windows 10 JTAlert-x

 

On 9/04/2018 6:42 AM, 2e0keh@... wrote:


Can anyone answer why I am having a load of grief when wanting to run JTAlert-x on windows 10, to communicate with HRD v5 heres a outline of what I have tried
.
Windows 7 x64 Pro HRD V5 b2893 JTAlert-X WSIT-X works without any issues.& fine with FT8

Using same setup for Windows 10 x64 pro RS3 Cant get JTAlert FT8 to communicate with HRD

Tried ports 7809 & 7825
Host addresses 1 2 & 3
Turning Windows defender and firewall off

Not sure why this is happening, is it something wrong I am doing or is it down to Windows 10?

Thanks
Pete 2e0keh

Pete,

You haven't said what is not working. Is it JTAlert logging to HRD or is it WSJT-X rig control via HRD?

There is nothing within JTAlert that requires Win10 specific configuration. All JTAlert development is done under Win10 and the vast majority of JTAlert users run Win10

de Laurie VK3AMA
   


locked Re: Changing UDP-Port possible ?

HamApps Support (VK3AMA)
 

On 8/04/2018 8:14 PM, g4wjs wrote:
On 08/04/2018 00:09, HamApps Support (VK3AMA) wrote:
JTAlert will not work with a port splitter, as it needs to be able to receive packets from WSJT-X and also send packets back to WSJT-X. Unless your udp port splitter also forwards packets from JTAlert back to the WSJT-X port it transmitted from (this is not the 2237 port, but a port dynamically allocated by Windows) it will not work.

Hi Laurie and Torsten,

UDP messages returning to WSJT-X when a port splitter is in use requires that the port splitter application "spoofs" the sender address and port so that datagrams received by JTAlert appear to have come directly from WSJT-X. Such port spoofing is possible but requires advanced techniques and administrator rights.

Until JTAlert can support multicast IP addressing; any arrangement that involves multiple applications consuming UDP traffic from WSJT-X will not work correctly with JTAlert.

73
Bill
G4WJS.

Adding to what Bill said....

JTAlert V2 is unable to support UDP multicast, JTAlert V3 does. That component of the V3 code has already been coded and tested, but V3 is still months away from release unfortunately.

de Laurie VK3AMA
   


locked Re: Windows 10 JTAlert-x

HamApps Support (VK3AMA)
 

On 9/04/2018 6:42 AM, 2e0keh@... wrote:

Can anyone answer why I am having a load of grief when wanting to run JTAlert-x on windows 10, to communicate with HRD v5 heres a outline of what I have tried
.
Windows 7 x64 Pro HRD V5 b2893 JTAlert-X WSIT-X works without any issues.& fine with FT8

Using same setup for Windows 10 x64 pro RS3 Cant get JTAlert FT8 to communicate with HRD

Tried ports 7809 & 7825
Host addresses 1 2 & 3
Turning Windows defender and firewall off

Not sure why this is happening, is it something wrong I am doing or is it down to Windows 10?

Thanks
Pete 2e0keh
Pete,

You haven't said what is not working. Is it JTAlert logging to HRD or is it WSJT-X rig control via HRD?

There is nothing within JTAlert that requires Win10 specific configuration. All JTAlert development is done under Win10 and the vast majority of JTAlert users run Win10

de Laurie VK3AMA
   



locked Windows 10 JTAlert-x

2e0keh@...
 

Hello Group
I am new to groups.io used Yahoo groups in the past been using Digital modes for several years.

Can anyone answer why I am having a load of grief when wanting to run JTAlert-x on windows 10, to communicate with HRD v5 heres a outline of what I have tried
.
Windows 7 x64 Pro HRD V5 b2893 JTAlert-X WSIT-X works without any issues.& fine with FT8

Using same setup for Windows 10 x64 pro RS3 Cant get JTAlert FT8 to communicate with HRD

Tried ports 7809 & 7825
Host addresses 1 2 & 3
Turning Windows defender and firewall off

Not sure why this is happening, is it something wrong I am doing or is it down to Windows 10?

Thanks
Pete 2e0keh


locked Re: UDP doesn't work between WSJTX running on another computer

HamApps Support (VK3AMA)
 
Edited

On 9/04/2018 4:00 AM, Brian wrote:
It seems that JTAlert must have wsjtx running on the same windows computer.  I am not sure why this is given that the two programs communicate via an internet protocol - UDP.  Another HAM buddy of mine uses HRD for his main log.  Installed JTAlert on the same Windows computer.  But, he installed wsjtx on a RaspberryPi.  I mentioned to him that I have been successful in a similar setup, but I use CQRLog (multi-platform) on a Linux computer (Ubuntu 16.04).  I indicated that I was able to configure the wsjtx running on Raspbian (RPi) to point to the nic's IP Address (network interface card) on the main shack computer (Ubuntu) and have CQRLog's wsjtx listener interface receive the UDP packets.  Worked really well.  Main log program on one computer and wsjtx on another computer.

However, JTAlert won't even start if you don't have wsjtx running on the local Windows computer.  What?  That seems odd.  A UDP server and client shouldn't care who is started first or second or where.  wsjtx sends periodic heartbeats on its UDP stream.  So a UDP server should be able to sync up.  Ok, to satisfy JTAlert's need to have the local version (on Windows) of wsjtx started, my buddy starts wsjtx.  It is not connected to his rig in anyway.  Interestingly enough, JTAlert recognizes the started wsjtx on windows.  But there is no traffic coming from that instance of wsjtx.  There is UDP traffic being streamed from the Raspberry PI at the Windows computer.  When the heartbeat and decodes start to arrive at the Windows server's doorstep from the wsjtx instance running on the RPi, JTAlert recognizes the packets and now works.  However, a JTAlert error comes up saying something like "array variable subscript badly formatted".  If he just leaves that error displayed (or move it off to the side), JTAlert continues to run happily.

Question and Request:
  • Why does JTALert require wsjtx to execute locally on the same computer when an internet protocol is being used to connect the two programs: wsjtx and JTAlert?
  • If there isn't a reason and this use case was not considered, I would like to request that the JTAlert UDP support allow for wsjtx to execute on another computer so that JTAlert can listen on a Windows computer's nic (not the loopback adaptor - 127.0.0.1) for wsjtx UDP traffic.

regards, 
Brian
VE3IBW
Brian,

While JTAlert communicates with WSJT-X via UDP, the code for WSJT-X support dates back to when WSJT-X didn't have the UDP interface, where communications with WSJT-X was via direct window manipulation/reading and monitoring of a WSJT-X status file.

When UDP was added, a decision was made to make that as painless as possible to the end user (zero changes needed), with no need for setting ip/port/filepaths, this is automatically handled by JTAlert reading the WSJT-X config file which JTAlert locates by determining the --rig-name of the running WSJT-X process. Each instance of WSJT-X has a unique config file and file location. Performance was also considered, potentially high-latency network comms (slow local networks, wifi, internet) would be detrimental to JTAlert responsiveness to decodes (especially now with FT8). The decision was made to have JTAlert work only with local WSJT-X processes.

Also, JTAlert supports up to 16 instances of WSJT-X with near zero setup required by the JTAlert user (only requiring the setting of unique udp ports in WSJT-X) for seamless multi-instance JTAlert/WSJT-X operation. Start the required number of WSJT-X instances followed by the same number of JTAlert instances, all automatic. There are many JTAlert users running multiple instances, some with 10 or more, 24x7.

I mention all the above to provide some insight into what is happening internally with JTAlert. While at first glance providing settings to manually specify the UDP port and IP is a trivial matter making that work with the current JTAlert code is far from trivial and would require a significant expenditure in time, coding and testing, to provide a facility to JTAlert V2 (which is near end-off-life) that may only be used by a very small number of users.

Yours is the first request I have had to allow JTAlert to work with a remote instance of WSJT-X (so the demand for such a facility is extremely low). While that is technically possible and rather simple using the UDP interface, it is far from simple implementing it within the current code. The uptake of such a feature would be very minimal among the JTAlert user-base, IMHO.

Spending precious coding time away from the higher priority JTAlert V3 coding,
I feel would be unwise. The
reward-for-effort ratio is too low to get your request onto the JTAlert V2 enhancement list at this time, sorry.

I have added your request to the todo/wish list, but implementation is unlikely until the new JTAlert V3 is released (still several months away). JTAlert V3 is being coded with no expectation that WSJT-X will be running locally, this also applies to the supported Loggers.

de Laurie VK3AMA
   


locked Re: FT8 DXPedition Test

John H. Long Jr.
 

Thanks,

As usual, your responses are very quick and helpful.




John H. Long Jr.
KW7A
1370 N 150E
Nephi, Utah 84648
USA
 
(435) 888-LONG
 
Cool Admit it ... Life Would be Boring without me! Cool


-------- Original Message --------
Subject: Re: [HamApps] FT8 DXPedition Test
From: "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...>
Date: Sun, April 08, 2018 1:31 pm
To: Support@HamApps.groups.io

On 9/04/2018 4:10 AM, John H. Long Jr. wrote:
Can anyone confirm if the FOX call sign was passed to JTAlert when in DXpedition mode?

I was not able to copy the FOX and have no way to confirm if the FOX contact is passed to JTAlert or not.


Perhaps I can clarify my request.

During the last FT8 DXpedition test I could see a lot of hounds calling / responding to the FOX.
My problem was that I never saw anything from the FOX (He was in AZ and too close to me).

Now if this had been a real DXpedition they would be on the air for days.
It is not practical to sit and watch the monitor for long periods of time just waiting to see if I could copy a transmission from the FOX.

It would be nice if WSJT-X sent the FOX information to JTAlert and then Have JTAlert sound the alarm and/or send a text message when I could receive the FOX's transmission.

Could you please assist me in getting this request to the correct party?

Any and all help would be appreciated.



Thanks again and 73,

John H. Long Jr.
KW7A
John,

According to
Hasan, N0AN, in this post https://hamapps.groups.io/g/Support/message/19739 the Fox Callsign is decoded by JTAlert.

My suggestion for getting alerted to the Fox being decoded at your end is to set the Fox as a Wanted Call in JTAlert and to enable the Out of Shack alert being sure to enable the Wanted Callsign as the trigger (Settings section, Alerts -> Miscellaneous Alerts -> Out of Shack).

Additionally you could set up a User-Defined alert (with a Wanted Callsign alert) and setup emailing of the alert, but do note, this is not a trivial task and it is expected the user has the computer skill to setup the smtp mailer and write the necessary batch file (see the help file, Settings -> Alerts -> Miscellaneous Alerts -> User Defined Alert topic). The help file also contains a sample batch file for using the freeware blat smtp emailer, looks under the Tutorials topic.

de Laurie VK3AMA
   


locked Re: FT8 DXPedition Test

HamApps Support (VK3AMA)
 

On 9/04/2018 4:10 AM, John H. Long Jr. wrote:
Can anyone confirm if the FOX call sign was passed to JTAlert when in DXpedition mode?

I was not able to copy the FOX and have no way to confirm if the FOX contact is passed to JTAlert or not.


Perhaps I can clarify my request.

During the last FT8 DXpedition test I could see a lot of hounds calling / responding to the FOX.
My problem was that I never saw anything from the FOX (He was in AZ and too close to me).

Now if this had been a real DXpedition they would be on the air for days.
It is not practical to sit and watch the monitor for long periods of time just waiting to see if I could copy a transmission from the FOX.

It would be nice if WSJT-X sent the FOX information to JTAlert and then Have JTAlert sound the alarm and/or send a text message when I could receive the FOX's transmission.

Could you please assist me in getting this request to the correct party?

Any and all help would be appreciated.



Thanks again and 73,

John H. Long Jr.
KW7A
John,

According to
Hasan, N0AN, in this post https://hamapps.groups.io/g/Support/message/19739 the Fox Callsign is decoded by JTAlert.

My suggestion for getting alerted to the Fox being decoded at your end is to set the Fox as a Wanted Call in JTAlert and to enable the Out of Shack alert being sure to enable the Wanted Callsign as the trigger (Settings section, Alerts -> Miscellaneous Alerts -> Out of Shack).

Additionally you could set up a User-Defined alert (with a Wanted Callsign alert) and setup emailing of the alert, but do note, this is not a trivial task and it is expected the user has the computer skill to setup the smtp mailer and write the necessary batch file (see the help file, Settings -> Alerts -> Miscellaneous Alerts -> User Defined Alert topic). The help file also contains a sample batch file for using the freeware blat smtp emailer, looks under the Tutorials topic.

de Laurie VK3AMA
   


locked Re: JT Alert window clearing times

HamApps Support (VK3AMA)
 

On 8/04/2018 9:46 PM, John P wrote:
I notice that all the calls in the JT Alert window seem to get erased at the beginning of a 15 second receive cycle (when I'm calling CQ during the transmit cycle). This makes them disappear faster than I can read them, then the window just sits there empty for 15 seconds. Seems to me that the clearing would better be done near the end of a cycle. Just my thoughts!
--
John P.
WA2FZW
John,

JTAlert has never auto-cleared the Callsign slots at the start of period, it has always cleared approx 1 sec before the end of the period, getting ready for the new batch of decodes to process.

For FT8, the clear times are @ 13, 28, 43, 58 secs.

Are you perhaps manually clearing the decodes in WSJT-X/JTDX (which of these are you running?)? If so, then JTAlert will also clear its Callsigns if you have that option set under the Applications -> WSJT-X section of the Settings.

de Laurie VK3AMA
   


locked Re: FT8 DXPedition Test

HamApps Support (VK3AMA)
 

On 9/04/2018 12:05 AM, Hasan Schiers N0AN wrote:
Laurie,

That 10 min delay business was malfunctioning Fox side software. When it works right, the replies are pretty quick. Nevertheless, as you pointed out, there is nothing to decode in Fox/Hound mode. I am pretty sure, however that the Fox callsign did show up each sequence in JTA and mine said B4...so it must be putting out something in UDP, just not the non Fox callsigns.

In yesterday's test, I worked both East and West coast runs within 2 minutes each, when the Fox side software was working properly.

Also very good news: JTAlert logged the completed qsos just fine with me in Hound.

73, N0AN
Hasan
Hasan,

Thanks for the feedback. I have not personally experienced the Fox/Hound mode yet so am relying on the advice of the the WSJT-X developers and the observations of active users.

de Laurie VK3AMA
   


locked Re: Changing UDP-Port possible ?

Hasan Schiers N0AN
 

I run a 2nd copy of X on another computer and just feed it split audio from the rig...the 2nd computer the runs wsjt-X and Grid program.

73, N0AN 

Hasan


locked UDP doesn't work between WSJTX running on another computer

Brian
 

It seems that JTAlert must have wsjtx running on the same windows computer.  I am not sure why this is given that the two programs communicate via an internet protocol - UDP.  Another HAM buddy of mine uses HRD for his main log.  Installed JTAlert on the same Windows computer.  But, he installed wsjtx on a RaspberryPi.  I mentioned to him that I have been successful in a similar setup, but I use CQRLog (multi-platform) on a Linux computer (Ubuntu 16.04).  I indicated that I was able to configure the wsjtx running on Raspbian (RPi) to point to the nic's IP Address (network interface card) on the main shack computer (Ubuntu) and have CQRLog's wsjtx listener interface receive the UDP packets.  Worked really well.  Main log program on one computer and wsjtx on another computer.

However, JTAlert won't even start if you don't have wsjtx running on the local Windows computer.  What?  That seems odd.  A UDP server and client shouldn't care who is started first or second or where.  wsjtx sends periodic heartbeats on its UDP stream.  So a UDP server should be able to sync up.  Ok, to satisfy JTAlert's need to have the local version (on Windows) of wsjtx started, my buddy starts wsjtx.  It is not connected to his rig in anyway.  Interestingly enough, JTAlert recognizes the started wsjtx on windows.  But there is no traffic coming from that instance of wsjtx.  There is UDP traffic being streamed from the Raspberry PI at the Windows computer.  When the heartbeat and decodes start to arrive at the Windows server's doorstep from the wsjtx instance running on the RPi, JTAlert recognizes the packets and now works.  However, a JTAlert error comes up saying something like "array variable subscript badly formatted".  If he just leaves that error displayed (or move it off to the side), JTAlert continues to run happily.

Question and Request:
  • Why does JTALert require wsjtx to execute locally on the same computer when an internet protocol is being used to connect the two programs: wsjtx and JTAlert?
  • If there isn't a reason and this use case was not considered, I would like to request that the JTAlert UDP support allow for wsjtx to execute on another computer so that JTAlert can listen on a Windows computer's nic (not the loopback adaptor - 127.0.0.1) for wsjtx UDP traffic.

regards, 
Brian
VE3IBW


locked Re: Double-click on call doesn't always populate

Phil Cooper
 

Hi Bill,

 

Both of the calls I listed were actually calling me, both with standard format text.

 

Phil GU0SUP

 

-----Original Message-----
From: "g4wjs" <bill.8@...>
Sent: Sunday, 8 April, 2018 17:19
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Double-click on call doesn't always populate

On 08/04/2018 16:14, Phil Cooper wrote:

Well, one was PU2WSQ, and another was PY7BAT.

I've had this before, where some calls do not respond to the double-click, but didn't note them down due to the pace of FT8.

 

I appreciate that some calls aren't going to work, but the ones I am querying are those that appear to be "normal" callsigns.

Hi Phil,

it is not whether the callsign is a supported one but that the decoded message is a standard format CQ or QRZ message. You can check in the ALL.TXT file in the WSJT-X log file directory to see what you were trying to reply to.

 

--
73
Bill
G4WJS.


locked Re: FT8 DXPedition Test

John H. Long Jr.
 

Can anyone confirm if the FOX call sign was passed to JTAlert when in DXpedition mode?

I was not able to copy the FOX and have no way to confirm if the FOX contact is passed to JTAlert or not.


Perhaps I can clarify my request.

During the last FT8 DXpedition test I could see a lot of hounds calling / responding to the FOX.
My problem was that I never saw anything from the FOX (He was in AZ and too close to me).

Now if this had been a real DXpedition they would be on the air for days.
It is not practical to sit and watch the monitor for long periods of time just waiting to see if I could copy a transmission from the FOX.

It would be nice if WSJT-X sent the FOX information to JTAlert and then Have JTAlert sound the alarm and/or send a text message when I could receive the FOX's transmission.

Could you please assist me in getting this request to the correct party?

Any and all help would be appreciated.



Thanks again and 73,

John H. Long Jr.
KW7A
1370 N 150E
Nephi, Utah 84648
USA
 
(435) 888-LONG
 
Cool Admit it ... Life Would be Boring without me! Cool


-------- Original Message --------
Subject: Re: [HamApps] FT8 DXPedition Test
From: "Hasan Schiers N0AN" <hbasri.schiers6@...>
Date: Sun, April 08, 2018 8:05 am
To: Support@HamApps.groups.io

Laurie,

That 10 min delay business was malfunctioning Fox side software. When it works right, the replies are pretty quick. Nevertheless, as you pointed out, there is nothing to decode in Fox/Hound mode. I am pretty sure, however that the Fox callsign did show up each sequence in JTA and mine said B4...so it must be putting out something in UDP, just not the non Fox callsigns.

In yesterday's test, I worked both East and West coast runs within 2 minutes each, when the Fox side software was working properly.

Also very good news: JTAlert logged the completed qsos just fine with me in Hound.

73, N0AN
Hasan


locked Re: Changing UDP-Port possible ?

Torsten - DL9GTB
 

Thank you Lauri and Bill for the quick reply. Too bad it is not possible, I was hoping to use the GridTracker too.

73 de Torsten - DL9GTB


locked Re: Double-click on call doesn't always populate

g4wjs
 

On 08/04/2018 16:14, Phil Cooper wrote:

Well, one was PU2WSQ, and another was PY7BAT.

I've had this before, where some calls do not respond to the double-click, but didn't note them down due to the pace of FT8.

 

I appreciate that some calls aren't going to work, but the ones I am querying are those that appear to be "normal" callsigns.

Hi Phil,

it is not whether the callsign is a supported one but that the decoded message is a standard format CQ or QRZ message. You can check in the ALL.TXT file in the WSJT-X log file directory to see what you were trying to reply to.


--
73
Bill
G4WJS.


locked Re: Double-click on call doesn't always populate

Tom Melvin
 

Hmm

That’s that theory down the pan - both are valid call signs.

Thinking …..


de Tom GM8MJV

On 8 Apr 2018, at 09:20, Tom Melvin <tom@...> wrote:

Morning,

Do you have an example of some of the calls that you can’t double click on?  There are some callsigns (usually special event ones) that do not adhere to what a valid callsign is.

73’s Tom
GM8MJV


On 8 Apr 2018, at 08:10, Phil Cooper <pcooper@...> wrote:

Hi Laurie,

 

Thanks for the response..
But, the problem is with WSJTx.... Some calls in the RX pane of WSJTx - either those calling CQ, or actually calling me - won't respond to a double-click, and I am forced to enter the call manually.
O probably should have sent this to the WSJTx group, but I am not subscribed to that.
I was hoping that someone in this group would know the answer.

 

73 de Phil GU0SUP

 

-----Original Message-----
From: "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...>
Sent: Saturday, 7 April, 2018 23:46
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Double-click on call doesn't always populate

On 8/04/2018 3:24 AM, Phil Cooper wrote:
Hi all,

Just been using JTAlert & WSJTx to work some SA stations on 15m.
I can't work out why some calls that show up in the window won't respond to a double-click.
Some do, but others I have to manually enter into WSJTx to populate the fields.

I am not a member of the QSJT group, so I am posting here, wondering whether any others have noticed similar issues.

WSJTx and JTAlert are both the latest versions, with all updates installed.

73 de Phil GU0SUP

Phil,

Unless you using the very latest WSJT-X release candidate, the only decodes that WSJT-X will accept a double-click from JTAlert are for CQ decodes, any other decode types and WSJT-X will ignore the double-click from JTAlert.

de Laurie VK3AMA




locked Re: Double-click on call doesn't always populate

Phil Cooper
 

Hi Tom,

 

Well, one was PU2WSQ, and another was PY7BAT.

I've had this before, where some calls do not respond to the double-click, but didn't note them down due to the pace of FT8.

 

I appreciate that some calls aren't going to work, but the ones I am querying are those that appear to be "normal" callsigns.

 

73 de Phil GU0SUP

 

 

-----Original Message-----
From: "Tom Melvin" <tom@...>
Sent: Sunday, 8 April, 2018 09:20
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Double-click on call doesn't always populate

Morning,
Do you have an example of some of the calls that you can’t double click on?  There are some callsigns (usually special event ones) that do not adhere to what a valid callsign is.
73’s Tom
GM8MJV

On 8 Apr 2018, at 08:10, Phil Cooper <pcooper@...> wrote:

Hi Laurie,

 

Thanks for the response..
But, the problem is with WSJTx.... Some calls in the RX pane of WSJTx - either those calling CQ, or actually calling me - won't respond to a double-click, and I am forced to enter the call manually.
O probably should have sent this to the WSJTx group, but I am not subscribed to that.
I was hoping that someone in this group would know the answer.

 

73 de Phil GU0SUP

 

-----Original Message-----
From: "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...>
Sent: Saturday, 7 April, 2018 23:46
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Double-click on call doesn't always populate

On 8/04/2018 3:24 AM, Phil Cooper wrote:
Hi all,

Just been using JTAlert & WSJTx to work some SA stations on 15m.
I can't work out why some calls that show up in the window won't respond to a double-click.
Some do, but others I have to manually enter into WSJTx to populate the fields.

I am not a member of the QSJT group, so I am posting here, wondering whether any others have noticed similar issues.

WSJTx and JTAlert are both the latest versions, with all updates installed.

73 de Phil GU0SUP

Phil,

Unless you using the very latest WSJT-X release candidate, the only decodes that WSJT-X will accept a double-click from JTAlert are for CQ decodes, any other decode types and WSJT-X will ignore the double-click from JTAlert.

de Laurie VK3AMA


locked Re: FT8 DXPedition Test

Hasan Schiers N0AN
 

Laurie,

That 10 min delay business was malfunctioning Fox side software. When it works right, the replies are pretty quick. Nevertheless, as you pointed out, there is nothing to decode in Fox/Hound mode. I am pretty sure, however that the Fox callsign did show up each sequence in JTA and mine said B4...so it must be putting out something in UDP, just not the non Fox callsigns.

In yesterday's test, I worked both East and West coast runs within 2 minutes each, when the Fox side software was working properly.

Also very good news: JTAlert logged the completed qsos just fine with me in Hound.

73, N0AN
Hasan


locked JT Alert window clearing times

John P
 

I notice that all the calls in the JT Alert window seem to get erased at the beginning of a 15 second receive cycle (when I'm calling CQ during the transmit cycle). This makes them disappear faster than I can read them, then the window just sits there empty for 15 seconds. Seems to me that the clearing would better be done near the end of a cycle. Just my thoughts!
--
John P.
WA2FZW

18121 - 18140 of 37815