Integration with contest logging softwareįor ease of operation, you will want the software that is running RTTY and PSK to integrate with your chosen contest logging programme. In RSGB HF contests, points are awarded for contacts with the same station in both modes so it is recommended that you set up this capability from the outset.
This section assumes that you have used data modes (either RTTY, PSK or others) before and are thus familiar with the basics. 73 Bill G4WJS.All of the RSGB data contests require contacts to be made in one or both of two modes: RTTY and PSK63, the only ones, currently, that are suitable for contest operation. OTOH relaying them isĪlmost certainly benign. Unrecognized magic number, they cannot be WSJT-X UDP protocol If it is easy to do so I would not forward datagrams with an Rebroadcast will be a true rebroadcast including garbage or I have now moved it to the start of the method, so the
Rebroadcast having been added at the end of the UDP processing Number in the header, is using an unsupported schema or if the
Processing code if the UDP packet contains an invalid magic Rebroadcast will not occur if there is an early exit from the With how the UDP processing code is structured, a A correction after I went an reviewed theĬode. (VK3AMA) via Groups.Io wrote: It doesn't matter, JTAlert doesn't look at theĬontent of the UDP data, it simply rebroadcasts every packet JTAlert is one such application so having *both* JTAlert and N1MM Logger+ communicating with WSJT-X instances is not possible. 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. 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. We use WSJT-X 2.1.0, and the latest updates of JTAlert and N1MM+ Can anyone help me get on the right track? As I stated, this used to work, but not now. In WSJT-X, settings, reporting tab, I have disabled the seccondary UDP server (2333), and enabled the (primary?) UDP server 2237. (I wonder if N1MM+ also listens on 2333, and that this is hardcoded?). 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 have NOT enabled retransmission of UDP packets from WSJT-X on port 2237. In JTalert I have enabled the last qso transmission on UDP port 2333. The reason I want to use JTAlert is the ability to upload real time to QRZ.COM, and Clublog, and this still works. The exact date this happened I do not know, but I suspect during july/August. 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. Hopefully this is the correct forum, if not, I beg to be forgiven. On 15:31, Tom Ramberg via Groups.Io wrote: 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