Topics

How to log from JTAlert to N1MM+?

Tom Ramberg
 
Edited

Hello. Hopefully this is the correct forum, if not, I beg to be forgiven.

In my radio club, OH2K, we  have been logging FT8/FT4 from JTAlert into N1MM+ for more than a year, but now the qsos arent't logged to N1MM+ any more. The exact date this happened I do not know, but I suspect during july/August. The reason I want to use JTAlert is the ability to upload real time to QRZ.COM, eQsl.cc and Clublog, and this still works.

In JTalert I have enabled  the last qso transmission on UDP port 2333. I have NOT enabled retransmission of UDP packets from WSJT-X on port 2237.

In N1MM+, the config tab for WSJT-X, the UDP port is set to default 2237, but it also says that logging from other programs can take place, usually on port 2333. (I wonder if N1MM+ also listens on 2333, and that this is hardcoded?).

In WSJT-X, settings, reporting tab, I have disabled the seccondary UDP server (2333), and enabled the (primary?) UDP server 2237. As I stated, this used to work, but not now. Can anyone help me get on the right track?

We use WSJT-X 2.1.0, and the latest updates of JTAlert and N1MM+
--
73 de Tom OH6VDA

g4wjs
 

On 04/09/2019 15:31, Tom Ramberg via Groups.Io wrote:

[Edited Message Follows]

Hello. Hopefully this is the correct forum, if not, I beg to be forgiven.

In my radio club, OH2K, we  have been logging FT8/FT4 from JTAlert into N1MM+ for more than a year, but now the qsos arent't logged to N1MM+ any more. The exact date this happened I do not know, but I suspect during july/August. The reason I want to use JTAlert is the ability to upload real time to QRZ.COM, eQsl.cc and Clublog, and this still works.

In JTalert I have enabled  the last qso transmission on UDP port 2333. I have NOT enabled retransmission of UDP packets from WSJT-X on port 2237.

In N1MM+, the config tab for WSJT-X, the UDP port is set to default 2237, but it also says that logging from other programs can take place, usually on port 2333. (I wonder if N1MM+ also listens on 2333, and that this is hardcoded?).

In WSJT-X, settings, reporting tab, I have disabled the seccondary UDP server (2333), and enabled the (primary?) UDP server 2237. As I stated, this used to work, but not now. Can anyone help me get on the right track?

We use WSJT-X 2.1.0, and the latest updates of JTAlert and N1MM+
--
73 de Tom OH6VDA
Hi Tom,

I believe the reason your log entries are not arriving in N1MM Logger+ is that N1MM no longer listens for logged QSO messages on the UDP port (default 2333), instead it listens to the WSJT-X UDP Message Protocol (by default on port 2237), it does this because it needs more information that the basic logged QSO ADIF records sent on port 2333.

In theory multiple applications can interoperate with WSJT-X using the WSJT-X UDP Message Protocol but in practice some applications do not implement the protocol as intended and as a result they consume messages that should be shared with all subscribing applications. JTAlert is one such application so having *both* JTAlert and N1MM Logger+ communicating with WSJT-X instances is not possible.

73
Bill
G4WJS.



--
73
Bill
G4WJS.

Tom Ramberg
 

Thanks for the reply, Bill. So in theory, disabling the "Last qso" in JTAlert, and enabling the (primary) UDP server on port 2237 in WSJT-X should do it? Checking all three options, then, I suppose. I will have to check it out, but my next visit to the club won't be until Tuesday, so I'll just have to wait until then. I would really hate taking JTAlert out of the setup, as the logging to the online services is pure gold.

--
73 de Tom OH6VDA

g4wjs
 

On 05/09/2019 08:27, Tom Ramberg via Groups.Io wrote:
Thanks for the reply, Bill. So in theory, disabling the "Last qso" in JTAlert, and enabling the (primary) UDP server on port 2237 in WSJT-X should do it? Checking all three options, then, I suppose. I will have to check it out, but my next visit to the club won't be until Tuesday, so I'll just have to wait until then. I would really hate taking JTAlert out of the setup, as the logging to the online services is pure gold.

--
73 de Tom OH6VDA
Hi Tom,

no, that will not work. If JTAlert is running then it will consume UDP traffic from WSJT-X so that traffic will not get to N1MM Logger+. I believe the only way to have logging to N1MM Logger+ from WSJT-X is to not run JTAlert.

YMMV.



--
73
Bill
G4WJS.

Tom Ramberg
 

Allright, I have an idea, based on the setup on my laptop at my home station, where I'm using Swisslog for Windows as my logger:
In WSJT-X, the UDP server 2237 is enabeled, thus facilitating communication with JTAlert. In JTAlert, (settings -> Applications -> WSJT/JTDX, "Rebroadcast WSJT-X UDP packets (receive only)" is enabled on port 2334. 
Swisslog is set up to listen on port 2334. That works fine, and before I ditch JTAlert at the club station OH2K, I will test a similar setup, making N1MM+ listen on 2334 instead of 2237.  (The only reason to keep JTAlert in this grid on my home station, is the text messages. All logging to online services is done by Swisslog). Anyway, if it works, I'll report back. If not, I'll keep quiet.
--
73 de Tom OH6VDA

HamApps Support (VK3AMA)
 

On 5/09/2019 5:27 pm, Tom Ramberg via Groups.Io wrote:
Thanks for the reply, Bill. So in theory, disabling the "Last qso" in JTAlert, and enabling the (primary) UDP server on port 2237 in WSJT-X should do it? Checking all three options, then, I suppose. I will have to check it out, but my next visit to the club won't be until Tuesday, so I'll just have to wait until then. I would really hate taking JTAlert out of the setup, as the logging to the online services is pure gold.

--
73 de Tom OH6VDA
Tom,

Enable the "Rebroadcast WSJT-X UDP packets" in JTAlert. Settings window, Applications -> WSJT-X/JTDX section and set N1MM+ to listen for logging packets on that port rather than the WSJT-X 2237 default.

de Laurie VK3AMA

g4wjs
 

On 05/09/2019 11:02, HamApps Support (VK3AMA) wrote:
On 5/09/2019 5:27 pm, Tom Ramberg via Groups.Io wrote:
Thanks for the reply, Bill. So in theory, disabling the "Last qso" in JTAlert, and enabling the (primary) UDP server on port 2237 in WSJT-X should do it? Checking all three options, then, I suppose. I will have to check it out, but my next visit to the club won't be until Tuesday, so I'll just have to wait until then. I would really hate taking JTAlert out of the setup, as the logging to the online services is pure gold.

--
73 de Tom OH6VDA
Tom,

Enable the "Rebroadcast WSJT-X UDP packets" in JTAlert. Settings window, Applications -> WSJT-X/JTDX section and set N1MM+ to listen for logging packets on that port rather than the WSJT-X 2237 default.

de Laurie VK3AMA

Hi Laurie,

which WSJT-X message types are forwarded by that service?


--
73
Bill
G4WJS.

HamApps Support (VK3AMA)
 

On 5/09/2019 8:05 pm, g4wjs wrote:

Hi Laurie,

which WSJT-X message types are forwarded by that service?


--
73
Bill
G4WJS.
It doesn't matter, JTAlert doesn't look at the content of the UDP data, it simply rebroadcasts every packet it receives on the new port.

de Laurie VK3AMA

g4wjs
 

On 05/09/2019 23:28, HamApps Support (VK3AMA) wrote:
On 5/09/2019 8:05 pm, g4wjs wrote:

Hi Laurie,

which WSJT-X message types are forwarded by that service?


--
73
Bill
G4WJS.
It doesn't matter, JTAlert doesn't look at the content of the UDP data, it simply rebroadcasts every packet it receives on the new port.

de Laurie VK3AMA

Hi Laurie,

thanks for that. It does matter insofar that, I assume, decode datagrams forwarded to N1MM+ cannot be replied to by N1MM+. It will be fine for N1MM+ doing logging but the N1MM+ WSJT-X integration does more than just logging these days.

73
Bill
G4WJS.


--
73
Bill
G4WJS.

HamApps Support (VK3AMA)
 

On 6/09/2019 8:28 am, HamApps Support (VK3AMA) via Groups.Io wrote:
It doesn't matter, JTAlert doesn't look at the content of the UDP data, it simply rebroadcasts every packet it receives on the new port.
A correction after I went an reviewed the code... With how the UDP processing code is structured, a rebroadcast will not occur if there is an early exit from the processing code if the UDP packet contains an invalid magic number in the header, is using an unsupported schema or if the packet is a "off-air" decode. This is simply due to the rebroadcast having been added at the end of the UDP processing method. I have now moved it to the start of the method, so the rebroadcast will be a true rebroadcast including garbage or unsupported packets.

de Laurie VK3AMA



g4wjs
 

On 05/09/2019 23:41, HamApps Support (VK3AMA) wrote:
On 6/09/2019 8:28 am, HamApps Support (VK3AMA) via Groups.Io wrote:
It doesn't matter, JTAlert doesn't look at the content of the UDP data, it simply rebroadcasts every packet it receives on the new port.
A correction after I went an reviewed the code... With how the UDP processing code is structured, a rebroadcast will not occur if there is an early exit from the processing code if the UDP packet contains an invalid magic number in the header, is using an unsupported schema or if the packet is a "off-air" decode. This is simply due to the rebroadcast having been added at the end of the UDP processing method. I have now moved it to the start of the method, so the rebroadcast will be a true rebroadcast including garbage or unsupported packets.

de Laurie VK3AMA

Hi Laurie,

if it is easy to do so I would not forward datagrams with an unrecognized magic number, they cannot be WSJT-X UDP protocol messages and therefore not applicable. OTOH relaying them is almost certainly benign.


--
73
Bill
G4WJS.

HamApps Support (VK3AMA)
 

On 6/09/2019 8:31 am, g4wjs wrote:
It will be fine for N1MM+ doing logging but the N1MM+ WSJT-X integration does more than just logging these days.
That's true. The JTAlert UDP rebroadcast is not two-way, it is only resending the received packets, which is fine when logging is all that is required as was the request of the original poster. My answer was correct for the posted request.

de Laurie VK3AMA

Tom Ramberg
 

Laurie, by "that port", you mean 2334?
--
73 de Tom OH6VDA

HamApps Support (VK3AMA)
 

On 7/09/2019 2:38 pm, Tom Ramberg via Groups.Io wrote:
Laurie, by "that port", you mean 2334?
--
73 de Tom OH6VDA
Yes, 2334 or what ever port you have set for the rebroadcast. It should be different from the WSJT-X default 2237.

   

de Laurie VK3AMA

Tom Ramberg
 

Thanks, Laurie. I'll test this as soon as I get back from the summer cottage. Interestingly though, Swisslog does not need the "Last qso" broadcast. It logs fine with the setup I described in my first post. But I'll do soem testing with that as well. Have a nice weeekend.
--
73 de Tom OH6VDA

HamApps Support (VK3AMA)
 

On 7/09/2019 4:53 pm, Tom Ramberg via Groups.Io wrote:
Swisslog does not need the "Last qso" broadcast. It logs fine
Sounds like SwissLog is listening for the WSJT-X UDP traffic directly.

de Laurie VK3AMA

Tom Ramberg
 

Sitrep from OH2K club station: Logging to N1MM+ works now. JTAlert "enable transmission of last qso" on UDP port 2333. N1MM+ set to listen (Radio 1) on port 2333. JTAlert uploads directly to eqsl.cc, qrz.com and Clublog. All is well.
--
73 de Tom OH6VDA