Using CAT Control 1.14 on my PC to listen to port 12060 from N1MM+. Most QSO’s made in N1MM+ are “heard” and sync’d, but a fair number are missed. I log them in N1MM+ but they don’t show up in the CAT Control Contact Log page or in my WRL log.
Using this for WRTC. It’s a little disappointing to have an online leaderboard function that is not accurate for me because it is missing some of my contacts.
73,
Rowland K4XD
@K4XD Hey Rowland,
This sounds like a configuration issue more than anything. What does your contact log in the WRL Integrations app look like?
Do the contacts show synced? Do they say ‘Pending’, or ‘Failed’? Or are they not showing up here at all?
Also send a screenshot of the N1MM settings section in the WRL integration app
ie:
Is the logbook you are trying to log contacts into selected from the drop down? Is there a green circle icon showing beside N1MM (like it shows next to WSJTX in the screenshot above)?
The missing contacts are simply not showing up. It is intermittent, appearing as some of the UDP messages, but not all, are not being picked up. I.e. currently I have 58 contacts logged in N1MM+, and 41 showing in WRL (both in the CAT Control page and the online logbook). There are no pending or failed contacts.
N1MM+ has the green circle, and here are the settings.
FWIW, N1MM+ is also reporting my score to contestonlinescore.com and that has all 58 contacts showing.
@K4XD I see now, so that’s most likely just due to the unreliableness of UDP broadcasts. UDP is notoriously hit or miss. So if you are (what we call) speed logging, in N1MM its possible that the QSO broadcasts are getting sent so fast that UDP is just not able to pick it up. If you are not speed logging then i guess it could be something different but, not sure off the top of my head.
Send a screenshot of your N1MM settings, i’ll try and take a look
Thanks & 73
Brad K4AZE
Hi Brad -
I’m not sure what “speed logging” is. I’m doing S&P and there’s no obvious difference between the QSO’s that are making it to WRL and those that are not in terms of how fast they are being logged. My peak rate is around 1 Q/minute.
I agree that some UDP messages are being dropped. Not knowing your code, I don’t know if there are some ways to run a UDP queue in a separate thread and reliably catch them all. I.e., if your code is busy synching to the cloud and while it’s doing that it may not hear a UDP message, that could be one way they are being dropped.
Which N1MM+ settings would you like to see?
Right now I have 101 sync’d contacts in WRL and 190 in N1MM+.
73,
Rowland K4XD
@K4XD Hey Rowland,
You’ll need to set your N1MM settings exactly as is shown in the screenshots. You can set the port to something different if you want but i would even keep it as 12060.
In the WSJTX/JTDX settings you need to make sure both “enabled” checkboxes are disabled.
Then in the broadcast data tab only enable the 'Contacts" checkbox, set the port to your localhost (127.0.0.1:12060).
I hope this helps
Thanks & 73
Brad K4AZE
Hi Brad,
Thanks for all the help.
In the true ham spirit of ignoring good experiment design, I made three changes :-).
One from your instructions: I had the “Radio” checkbox checked on the Broadcast tab. Unchecked that now.
I also disabled “Score Reporting” on that tab in case that was somehow causing an issue with too much real-time network traffic.
Finally, I shut down all the DXLab apps in case any of them were absorbing UDP messages.
I created a Test Dummy logbook on WRL and connected N1MM+ to it with the WRL CAT Control app.
I ran through the band map and “logged” (didn’t really make a QSO, just used the bandmap to populate the QSO info) 37 QSO’s and all 37 appeared in my WRL Test Dummy logbook.
So… fingers crossed, this configuration may be the answer. We’ll find out in the next contest, but this is promising. I may do some more tests without making all those changes, just using the N1MM+ config specs you provided.
73,
Rowland K4XD
Small update - I repeated the experiment with the DXLab apps running and made 40 dummy QSO’s in N1MM+. All 40 made it OK to the Test Dummy2 logbook on WRL.
So that’s not the culprit that was causing missed Q’s.
I’ll try one more time but enable the “Radio” checkbox on the Broadcast data config tab in N1MM+ and see if that causes the drops.
73,
Rowland K4XD
OK - here’ s my final answer :).
I checked the Radio checkbox on the Broadcast data tab and now some of the QSO’s in N1MM+ are not showing up in the WRL Test Dummy2 logbook. I unchecked the Radio checkbox and contacts all came through again.
My conclusion - checking the Radio checkbox causes some of the QSO’s to not make it to the WRL logbook.
It might be worth looking at the code in CAT Control and understanding why this is happening in case there’s something that could be done on that side of things. I’ve used the Broadcast data from N1MM+ with several of the categories of UDP data checked and even with multiple ports for each checkbox, in a remote multi-multi situation, and never lost data before.
But for now, I have a working setup to sync N1MM+ with WRL during a contest.
Cheers,
Rowland K4XD
@K4XD yes, that would make sense as you are enabling n1mm to send radio data (not qso broadcast data) to the same port, in the integrations app we are only looking for QSO broadcast data (not radio data, because there is nothing we can do with it). so enabling the radio broadcast data is most likely interfering with the qso broadcast data.
I hope this makes sense.
Glad you got it figured out
Thanks & 73
Brad K4AZE
Thanks Brad.
I think it would be nice if the integrations app could just ignore UDP packets that are not of interest but still capture the data from the contacts packets. The presence of a Radio packet in the stream shouldn’t cause the contact packet to be ignored.
I’m guessing the integrations app drops the whole packet if the Radio XML comes first followed by the Contact XML but if the Contact XML is first it gets sync’d. Just a guess!!
73,
Rowland K4XD
@K4XD This is just inherently the issue with UDP streaming in general. What I think is happening is that the UDP port is the same for both radio and QSO broadcasts, and its getting overloaded when both are sending simultaneously.
