N1MM and wfview work together well for about the first hour after starting them up. Then N1MM starts complaining it has lost communication with the radio, either the 7300 or wfview. I can’t tell. I click the button N1MM provides in order to reconnect but the red warning banner reappears immediately.
I don’t know where the problem is. All I know is N1MM is complaining a lot. I’m not trying to lay blame anywhere (because it’s likely my fault!)
When I posted here that I had problems setting things up I was told to literally pull a port number out of thin air and use that, which I did. And it worked for a short while. Now I’m wondering if I was unlucky enough to choose a port number that is in use by something else.
How can I check if a given port is already in use or not? Is there some kind of network admin’s app that can do this?
If you’re talking about using wfview’s built-in rigctld, then yes, you need to pick a port. But there are rules.
The port that you specify in wfview must be the same number that you specify in N1MM. That’s the first rule!
Second, the number must be larger than 1024 and less than 65535.
Lastly, as you touched on, the port must not already be in use.
I googled how to tell if a port is in use and I came up with this (sorry, I have not used windows since 3.11):
It may also be that a windows firewall needs to be adjusted for the port to actually work. I don’t know the process though. I think windows usually asks the user?
It was as I said but not in those words, with the same caveats you mentioned. I picked a number within the proper range but I had no way of knowing whether the port was already in use. Hence my question.
Well, I had another unsuccessful session at the radio this morning. To start with, I forgot to check the wfview logfile when it started acting up. However, I think I’m closing in on the ower level sweetspot where it doesn’t mess up comms (as much). I dropped power in 10 watt increments from 100W to 30W, where it seemed not to upset things.
I’m beginning to wonder if my host moved things around and maybe dropped the USB cable, shattering the ferrite core. Or maybe after 4 years the cables just need to be unplugged and reseated? I’ll ask him to have a look and unplug and plug in the USB cable. If that doesn’t work I’ll buy a new cable, wind it on a toroid core, ship it to him and ask him to replace the existing cable.
It’s interesting. I have an Airspy R2 SDR receiver that connects to my computer via USB. If I wrap just one full turn of the USB cable around an FT-240-31 toroid all data from the SDR is choked off! Yet I was instructed to wrap as many turns of my USB cable between the 7300 and my computer as can fit. Go figure…
I habe seen that where moving an USB cable or laptop maybe one inch, drastically can reduce (or increase) port “failures”. It can happen if someone just moves stuff to remove dust, places cable/laptop back.
a good choked and probably also shielded cable can help you there.
in general, always check the hardware paths and double check, rule out etc etc all these things.
Ken, I commonly wrap multiple turns of USB cables around ferrites and have never seen the data flow affected. Perhaps your cable is defective and wrapping it was breaking a connection internally. Just further agreement that getting a real good USB cable would be A Real Good Thing
That may be, but it’s worked perfectly for the last 4 years. However, I’ll replace it anyway as a preventive maintenance practice.
Just now I tried transmitting again to trigger an error so I can check the wfview log. No errors, even after bumping the power back up to 100W and sending long (approx 30 sec) messages.
like said: it can work flawless for years. I can mimic this behaviour on my 7300.
If all the stuff is taped on the bureau and the laptop is not moved in any way (all cables that I have) – it will work perfect. If I move things apart, take out the connector once, clean up, place laptop back, I need to find the sweet spot to not “die” on RF ingress. It takes 5 mm. (1/5 inch).
I just didnt take the time to find a short shieded cable of good quality. that’s all.
(also: I don’t run my 7300 remotely generally, I run 160–>23 over ethernet. The only left out band then would be 4m)
I’ve also got the enclosure of my PC connected to the ground terminals of my rigs. A DC ground isn’t necessarily a good RF ground, you can’t depend on the shield of a data cable to give you good bonding.
Some very low quality USB cords are actually not shielded! I’ve run into that one. A multimeter test between the two usb metal shrouds will usually show if there is a shield.
This caused me endless (well ok, hours) pain and frustration once. Every time I keyed up on 40M, wfview would loose the radio connection. Finally swapped the cable and it never did it again! The cable turned out to not even have a shield.
I just ordered a new shielded USB cable and will wrap it around an FT-240-31 and ship it off to my host when it arrives. In the mean time, I asked him to check around the radio and unplug and re-insert the USB cable a few times to clear out what cobwebs may have accumulated in the last 4 years.
Next time I’m back in Canada (next year or after that) I’ll do that as well.
My new USB cable arrived yesterday. It’s a printer cable and unfortunately the plug that normally fits the printer (my 7300 in this case) is an oddball plug that’s too large to fit my rig. I did find an acceptable one in the meantime.
I have had several discussions with N1MM support people about this loss-of-communication. They explained that N1MM normally polls the rig and if it doesn’t receive a response it tries again and again until a 15 second timer times out. After the timer times out it throws up a red flag (literally) asking me to reconnect to the rig. It claims that 15 seconds is a lifetime when dealing with polling a rig.
In this case, N1MM is polling wfview, which they assume must be keeping a copy of the 7300’s status in order to return reliable information. However, they can’t be sure how wfview behaves because it isn’t a physical rig and they didn’t write the software. Maybe wfview passes poll requests through to the 7300 and relays the responses back through to N1MM. They don’t know.
Can you help us to understand how polling works?
73,
Ken VE3HLS
This places me squarely between a rock and a hard place
15 seconds is the timeout after a series of retries, the question is how quickly do they timeout on each poll. If it’s a handful of milliseconds, that’s going to be a problem. If they wait for a second, then all should be fine. Perhaps there’s a setting in N1MM+ that will relax the impatience on each poll?
