Add UDP Server to receive messages from WSJT-X

[ny4i]

Project Steps:

• [x] Add a UDP server using TIDUDPServer into the code.

• [x] Add more modes than RY and DG so we can explore the items properly as FT8 and MFSK/FT4 (mode/submode). Internally, the mode can be FT8 and FT4.

• [x] Add support to look up the callsigns send in the Decode message and response with our current colors iff they are a dupe, multiplier or needed. Use whatever colors are set. Make sure the background colors doesn't interfere depending upon the background colors of WSJT-X.

• [x] Handle rig control somehow. The obviously mechanism is to do the DX Commander interface but I fear we will have the same support issue that N1MM has with people thinking they need to install DXCommander. Another option is that while we are using WSJT-X, offer an option to give up the serial port (close it, etc). That might be clunky though. I am leaning towards the Commander interface in the form of a TCP/IP server in a thread. Maybe we can petition the WSJT-X team to rename it to something like TCP Rig Control Interface (DXCommander, N1MM, TR4W, etc). Or how about AA6YQ's tcp right control protocol.

• [x] Add scoring for FT8 and FT4. Most likely it follows digital but we should support Field Day, RTTY RU (which could be both or just N1MM). I am not sure of the status of our MMTTY interfacing so that is another question for a combined RTTY Roundup.

[ny4i]

This is needed more urgently. I'm not thrilled with the complexity of the current contest software integration with WSJT-X. I am thinking something that can co-exist with JTAlert to just receive the ADIF records of the contacts. It should also run standing with WSJT-X and do the callsign highlighting if a contact is a dupe or not.

The difference from N1MM for example is I do not need it to be the main driver. I do not need to start WSJT-X from N1MM nor use its own config file. That seems needlessly complex and confusing to the user.

Rig control is a factor and implementing the DX Commander TCP/IP interface does make sense but I am still thinking on it.

We do need to add more mode support than just DG and RY. We would need a mode of FT8 and FT4 *(but generate the ADIF properly with MODE MFSK and submode of FT4 but for FT8, the mode is FT8).

[ny4i]

I saved the current UDP API into our Wiki for convenience. Please always check that it is the latest.

The first step is to add a UDP Server in a thread to TR4W. I am trying to use Indy and not propagate the use of native Win32 constructs. but that might be harder than to just implement a thread the way it current does it with other TCP/IP listeners (if there are any at the moment in a server configuration versus a client, i.e, telnet to DX Cluster, etc).

The logic off the top of my head would be to receive the decode messages, check the calls to see if they are needed, send back the Highlight Callsign message to set the color according to the dupe colors in TR4W: Red for DUPE, Gray for DUPE, etc.

Some other things to handle:

Heartbeat message

If the user hits ESC while in TX mode, we want to send the Halt TX message.

It would be god to check the status message (as it has the special WSJT-X mode like FIELD DAY or ROUND UP) and make sure we are in an appropriate contest mode if that is set. At least, warn the user there might be an inconsistency.

Handle the Log ADIF message to write an entry to the log.

[ny4i]

Great progress towards this change. I now understand the packet format sent by WSJT-X and most importantly, I have a UDP Server receive thread running in TR4W that displays a QuickDisplay message whenever I receive a message. I can log normally and the program displays the heartbeat was received from WSJT-X periodically. So next step is to make an object to parse out the messages to handle the logging. This means I have to add a better ADIF parser (this ties into another issue I entered). I also have to consider if we have to do any sort of locking of the log write as I would not want a UDPReceive to interrupt other logging functions (although it is doubtful both the UI and WSJT-X would be logging). I do have to figure out how I am sent the callsigns to decode. It seems that is not sent but perhaps I have to respond to a heartbeat to see that.

[ny4i]

I found a Delphi implementation of the WSJT-X UDP spec in SourceForge. What a great find and this makes things much easier. I do love open source!

[n4af]

wow, great news. open source rocks !

On Tue, Jun 30, 2020 at 11:50 AM Tom Schaefer notifications@github.com wrote:

I found a Delphi implementation https://sourceforge.net/p/alarmejt/code/HEAD/tree/trunk/uudp.pas of the WSJT-X UDP spec in SourceForge. What a great find and this makes things much easier. I do love open source!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/n4af/TR4W/issues/379#issuecomment-651882157, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVLCUGS2N544HG2YNJ7JA3RZICVHANCNFSM4HPTWLSQ .

[ny4i]

Using a little test app and some significant massaging of the data types in f5jmh's code (that is FreePascal which has better data types than Delphi 7), I was able to create some output from WSJT-X. There are still a few bugs such as frequency and time when a QSO is logged, but it is close. Here is a sample I dumped to a Memo.

Decode: -1 0414 -23 0 951 ~ NX8E K0SWT +00 4:14:30 AM 0 15270000 Decode: -1 0414 -10 3.408E-312 1787 ~ OE7UU AC2SB FN03 4:14:30 AM 3.40792534102725E-312 15270000 Status: Frequency: 3505416960 Mode: FT8 DX Call: K4YT Report: -22 TX Mode: FT8 TX Enabled: 0 Transmitting: 0 Decoding: 0 RXDF: 1158 TXDF: 1158 DECall: NY4I DEGrid: EL87 DXGrid: FM19 QSO logged: Date:01-Jul-2020 00:14:56 DX Call:K4YT DX Grid:FM19 Frequency:1458924288 Mode:FT8 Report sent: -21 Report received:-06 TX Power:100 Comments: Name: ADIF Record to log:

3.1.0 WSJT-X K4YT FM19 FT8 -21 -06 20200701 041454 20200701 041454 40m 7.075158 NY4I EL87 100 Status: Frequency: 3505416960 Mode: FT8 DX Call: K4YT Report: -22 TX Mode: FT8 TX Enabled: 0 Transmitting: 0 Decoding: -1 RXDF: 1158 TXDF: 1158 DECall: NY4I DEGrid: EL87 DXGrid: FM19 Decode: -1 0414 -13 0 765 ~ K0SWT NX8E R-02 4:14:45 AM 0 15285000 Decode: -1 0414 -9 1.362E-312 1584 ~ KK7SB W1NA RRR 4:14:45 AM 1.36232150022729E-312 15285000 Decode: -1 0414 -18 0 952 ~ CQ AG5XI EL09 4:14:45 AM 0 15285000 Decode: -1 0414 -14 3.408E-312 2002 ~ K0KP W8SSM EN76 4:14:45 AM 3.40792530118579E-312 15285000 Decode: -1 0414 -9 3.408E-312 390 ~ KI4TYK F5RRS RR73 4:14:45 AM 3.40792530055339E-312 15285000 Decode: -1 0414 -20 2.836E-319 2248 ~ CQ ZL3IO RF80 4:14:45 AM 2.83628265308084E-319 15285000 Decode: -1 0414 -21 3.408E-312 768 ~ YO9HP WD5BYQ EM12 4:14:45 AM 3.40792528031646E-312 15285000 Status: Frequency: 3505416960 Mode: FT8 DX Call: K4YT Report: -22 TX Mode: FT8 TX Enabled: 0 Transmitting: 0 Decoding: 0 RXDF: 1158 TXDF: 1158 DECall: NY4I DEGrid: EL87 DXGrid: FM19 Status: Frequency: 3505416960 Mode: FT8 DX Call: K4YT Report: -22 TX Mode: FT8 TX Enabled: 0 Transmitting: 0 Decoding: -1 RXDF: 1158 TXDF: 1158 DECall: NY4I DEGrid: EL87 DXGrid: FM19 Status: Frequency: 3505416960 Mode: FT8 DX Call: K4YT Report: -22 TX Mode: FT8 TX Enabled: 0 Transmitting: 0 Decoding: 0 RXDF: 1158 TXDF: 1158 DECall: NY4I DEGrid: EL87 DXGrid: FM19 Status: Frequency: 3505416960 Mode: FT8 DX Call: K4YT Report: -22 TX Mode: FT8 TX Enabled: 0 Transmitting: 0 Decoding: -1 RXDF: 1158 TXDF: 1158 DECall: NY4I DEGrid: EL87 DXGrid: FM19 Decode: -1 0414 -15 3.408E-312 1803 ~ W5BDB AB2EZ R+00 4:14:45 AM 3.40792528031646E-312 15285000 Decode: -1 0414 -13 3.408E-312 1701 ~ CQ K3LA EN91 4:14:45 AM 3.40792528031646E-312 15285000 Decode: -1 0414 -22 6.324E-322 725 ~ CQ VA2PM FN46 a1 4:14:45 AM 6.32404026676796E-322 15285000 Status: Frequency: 3505416960 Mode: FT8 DX Call: K4YT Report: -22 TX Mode: FT8 TX Enabled: 0 Transmitting: 0 Decoding: 0 RXDF: 1158 TXDF: 1158 DECall: NY4I DEGrid: EL87 DXGrid: FM19

[ny4i]

I have TR4W logging contacts from WSJT-X. There is some cleanup to do to make sure the points are logged, it is places in band map and other things.

I have found this code is the classic definition of spaghetti code. While there is a single function called LogContact, it does not do everything. Then you have other functions like ParametersOkay that check some thing and call LogContact. So which is it.

A contact should be logged by populating the proper data structure ContestExchange and calling LogContact. Everything else should be handles in that function. AN even better way too do it would be to have a TContestLog class and it gets called with log.NewContact(ReceivedData). It can be given the station configuration and operator info as well as a link to radio info in the Create. This really needs a rewrite to simply this code. It functions great but it sure is hard to modify and has no concept of encapsulation.

[n4af]

Sounds like you are making great progress Tom ! 73, Howie

[ny4i]

I added a tcp server to uWSJTX and lo and behold, it works. I wanted to make sure I did not interested with the threading of any other network interfaces. I added a very tailored server (hard coded messages) and it works!!! Now I have to add a bit more processing to tie the radio control in so for example, when WSJT-X wants to know the status of split mode, we inquire the radio control and return the actual state of split. But that is easy stuff (just parsing).

[ny4i]

Howie - Can you grab this branch to your PC and build it again. I believe I made the pull request before the last set of changes were committed. I also forgot to disable the debug tracing. Thanks

[n4af]

Done. url via gmail. 73, Howie

On Tue, Jul 14, 2020 at 11:27 PM Tom Schaefer notifications@github.com wrote:

Howie - Can you grab this branch to your PC and build it again. I believe I made the pull request before the last set of changes were committed. I also forgot to disable the debug tracing. Thanks

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/n4af/TR4W/issues/379#issuecomment-658524168, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVLCUGQRQWINU3ZFLPA3CLR3UO3FANCNFSM4HPTWLSQ .

[n4af]

MINGW64 /d/newsrc/tr4w/src (iss423) $ git pull origin WSJT-X-Implementation From github.com:n4af/TR4W

• branch WSJT-X-Implementation -> FETCH_HEAD Merge made by the 'recursive' strategy. tr4w/src/VC.pas | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

On Tue, Jul 14, 2020 at 11:27 PM Tom Schaefer notifications@github.com wrote:

Howie - Can you grab this branch to your PC and build it again. I believe I made the pull request before the last set of changes were committed. I also forgot to disable the debug tracing. Thanks

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/n4af/TR4W/issues/379#issuecomment-658524168, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVLCUGQRQWINU3ZFLPA3CLR3UO3FANCNFSM4HPTWLSQ .

[ny4i]

This issue was closed previously.