Ham Radio Digital Harmony: IC-7300, WSJT-x, GridTracker, and N3FJP ACL
HTML-код
- Опубликовано: 6 сен 2024
- Here’s the final installment of connecting your rig to WSJT-x, GridTracker, and N3FJP’s Amateur Contact Log. Though I used the IC-7300, the processes in this video will work on just about any HF Rig.
This video is limited to just making the connections. Bells and whistles of all of these bits and pieces will be in future videos.
Links to everything mentioned in this video:
WSJT-x: wsjt.sourcefor...
GridTracker: gridtracker.or...
N3FJP: www.n3fjp.com/
Ham Radio Deluxe: tinyurl.com/238...
Log4OM: www.log4om.com...
Chapters:
00:46 Quick Review WSJT-x + GridTracker
03:38 Integrating N3FJP Amateur Contact Log
04:29 Integrating HRD LogBook and Log4OM
08:24 Demo - watching them play together
Thanks for watching. Please remember to Like, Share, and Comment. Also, please consider subscribing to this channel. Your support is greatly appreciated!
73 de Tom, ND3N
Great video! Excellent job simplifying the TCP/UDP multiple port configuration! 73 de K9RI
Glad you enjoyed it!
Thank you so much for all of your helpful videos!!
Glad you like them!
First, a matter of basic understanding of network protocols. UDP: You can have ONE broadcast sender (or server) and MULTIPLE broadcast listeners (or direct requesters / clients). There is no ongoing connection. TCP: You can have one server that accepts connections, but it is possible to have multiple clients connect the same server - they each get their OWN connection. That connection persists as long as both the server and client want it to persist. One cannot mix the two: one cannot have UDP client talk to a TCP server, or vice versa. Now, on to your video:
(A @ 1:14) As you set it up, WSJT-X would listen (so they call it a "server") for information requests on port 2237. This means that a program, like N3FJP or GT can send WSJT-X requests for information, and it will respond. This is a *polling* mode of operation. It is perfectly fine for multiple programs to send such requests. [WSJT-X may also be broadcasting UDP packets on port 2237- I have not traced the activity to check that out, but I suspect that is the case.]
(B @ 1:14) You took some pains to also set up WSJT-X to broadcast out using UDP ADIF the logged contact information to any program that might be listening on port 2333. However, you did not configure any other programs to pick up on those broadcasts, as near as I could tell. There should be no need for this - and the developers have indicated it is "deprecated" which is a warning to NOT do that unless you absolutely have to. This means that WSJT-X would "bind" to that port as a sender, either all the time, or any time it wants to do such a broadcast. If it were the only application sending stuff out on port 2333 that would be OK, but of no particular value.
(C @ 2:08) Next you set up GT to receive UDP messages (by request and/or broadcast) from WSJT-X on port 2237. That is normally how one configures it to be. Thus GT will obtain info from WSJT-X on that port. (That is the same port as in (A) -- which is fine.)
(D @ 2:08) Next you configure GT to re-broadcast on UDP port 2333. This is in *conflict* with (B). You cannot reliably have two programs on the same machine "bind" as a listener/server on the same port. It might work, so long as both programs only bind to the port briefly to dispatch their packets, but I would not want to depend on that!
(E @ 2:49) You set up GT to send information to the N3FJP loggers on port 1100. This would be an inbound TCP connection. However, as we will see in a bit, you do not configure N3FJP to accept connections there (as its API server.)
(F @ 4:10) You take great pains to set the port number for the N3FJP TCP API to port 1100 (to match GT), but then take great pains to NOT enable the TCP API server on N3FJP. That actually makes the port field irrelevant. This also makes (E) an error - if GT tries to make a connection to N3FJP (say, to log a contact), that attempt will fail.
(G @ 4:10) You enable N3FJP to listen to WSJT-X. By default, this will be requests from N3FJP to WSJT-X on UDP port 2237. Which is fine.
(H @6:06) You have enabled Log4OM to listen to to BOTH GT on port 2236 AND WSJT-X on the deprecated port 2237. Now, it may be that Log4OM is not willing to take WSJT-X messages directly, so that could possibly be a use for the *deprecated* facility in WSJT-X you configured in step B. However, the ports DO NOT MATCH (WSJT-X is set up for port 2237), so Log4OM will never see any traffic on that connection. However, you DID set up GT to talk to Log4OM on port 2236, so that would actually work. (This is GT as a traffic hub, which is how I would do it if I were using Log4OM - but it still will not initialize properly on my W10 laptop - I can't even get the country pull down list to populate.)
I didn't pay much attention to how you configured any other logging programs. Now, all that said, what would I recommend? There are actually (at least) three ways to do this:
(1) Use GT as a traffic hub. This is what I am currently doing. I configured GT to listen on port 2237 as in your video. It does NOT need to rebroadcast UDP on another port - BUT, if you have another program that needs that UDP feed on a different UDP port, such as 2333, it is fine to let GT do that. Then configure GT for the N3FJP logger on port 1100. Finally, configure N3FJP to use the *TCP* server on port 1100, and in so doing it should not be necessary for it to also listen to WSJT-X directly. GT has been designed for this kind of usage, and make it easy - and it can talk to eQSL, LoTW, etc. as well.
(I currently have N3FJP configured to ALSO communicate with eQSL and LoTW in "real time", but have not logged any contacts since I did that, and am not sure I will leave it that way, as it would presumably mean every request to log a QSO on eQSL and LoTW would be sent twice).
(I have tested this to the extent that GT does get the info from WSJT-X and N3FJP does log the connections. I haven't made enough contacts to check real-time uploads to eQSL and LoTW are actually working yet. I also need to look at the GT map with respect to confirmations - it would have to come from N3FJP or directly from eQSL and LoTW - WSJT-X doesn't have that confirmation info.)
(2) Use GT as a client. As with (1) configure GT to listen on port 2237 (and perhaps rebroadcast on 2333 or some other port). Do NOT have it make a connection to N3FJP on TCP port 1100. Instead, configure N3FJP to communicate with WSJT-X on port 2237 as well. Then configure N3FJP to communicate with eQSL and/or LoTW in "real time", and do NOT configure GT to talk to eQSL and LoTW. I have *NOT* actually tried this, but would expect it to work. The potential advantage to this configuration is that N3FJP is then not dependent upon GT to get its info, as it gets it directly from WSJT-X and to forward log entries to eQSL, LoTW, etc. GT then becomes just an information display (or forwarder to other applications if needs be.)
(3) Mixed mode. Use GT as a client as with (2) but ALSO have it communicate with eQSL and/or LoTW as in (1). Configure N3FJP to communicate with WSJT-X on port 2237 as well, as with (2), but do not have it communicate with eQSL or LoTW in Real Time.
Note that I could only provide all of these comments because your videos are very clear about what you are doing, and easy to follow!
73 W9IYN JRJ
Thanks for the in depth explanation and knowledge. I’m just showing what worked for me…. 73
Well the WSJT-X, GridTracker, and N3FJP ACL didn't work here. ACL tells me normally only one connection is allowed.
there’s a fix for that. The work-around isn’t too difficult, but too long to do in a comment, so I’m heading to my shack and will put out another short video with what you need to do. Expect it in a couple of hours.
@@ND3N I went back to ny original configuration. I use Win4Icom and it has 6 "virtual radios" that feed off of one serial port from the IC-7300. I have N3FJP in the first spot and WSJT-X in the third spot, all is well except GridTracker, even though the settings are correct in WSJT-X and grid tracker, GridTracker just shows waiting for message. Not sure what is going on but I will keep trying.
I have setup WSJT-X and Gridtracker as you indicated however AC log will not listen to WSJT-X I have matched all settings you have indicated to but doesn’t work. What could I be doing wrong.
N5BYL.
BRUCE
Double check your UDPs... In WSJT-x, Settings/Reporting tab. UDP Server port number is 2237 with Accept UDP requests checked. Secondary UDP port number should be 2333 with Enabled logged contact ADIF broadcast checked..
Grid Tracker settings/general tab. Receive UDP messages Port 2237 and Forward UDP messages port 2333 and enabled selected.
And finally, In N3FJP ACL, Settings/Application Program Interface. Check only "Listen for WSJT-x" - Click on the Configure Button and at the top of the pop-up, make sure port 2333 is entered. Check Click "Done" on the pop-up and the API page.... Let me know if that works...