Hi - I am a member of the N1MM+ development team. We are looking at supporting Icom UDP. Can you tell me what the difference and/or relationship is between the udpserver and udphandler classes ?
BTW, I don’t suppose that TCP works with Icom ? That would make our life a lot easier, since we already support TCP to Elecraft K4, Flex 6600, Kenwood 890/990, etc.
73,
Steve, N2IC
udphandler handles the communications between WFView and the Icom radio. udpserver is code to provide a server that other programs can use to connect to WFView.
As far as I can tell, Icom only supports UDP, not TCP. But, FWIW, the protocol includes sequence numbers and a packet retransmission protocol, so it looks like they try to implement their own session using datagrams.
73,
Mark
ICOM indeed has their remote control protocol implemented strictly over UDP.
It’s possible to have some direct connections here isf needed re the questions, Steve.
You are invited to mail me about this.
(while you are at it, N1MM+ for linux/mac please? ;-))
I very much second the request for N1MM+ for Linux. At a minimum, please make it so that it does not require any special jumps through hoops to install and run reliably and stably using WINE.
Alternately, a Linux binary in a Flatpak distribution would be nice.
Hi Steve.
If you are just looking for Rig Control, then you would need to implement the Control (port 50001) connection, which handles the initial connection, authentication and connection requirements/capabilities. You would also need to implement the Serial/C-IV (port 50002) connection. This simply uses CI-V data appended to a 16 byte ‘control’ packet containing length and sequence information. If you aren’t using audio then you just don’t request it during the control exchange.
You would also need to implement the standard retransmit request code and keepalive/ping, but that’s about it.
I assume that N1MM+ is still developed in Visual Basic .Net, so I suspect a Linux (or Mac) port are unlikely?
73 Phil M0VSE
nah no flatpacks. 
wine is also not a solution to me. native!
Hi Steve,
Have you considered using wfview as your conduit for rig control? wfview supports both virtual serial ports as well as a rigctrld-compatible TCP/IP server socket. This might be a lot easier than implementing the native radio protocol in visual basic!
–E
de W6EL
Hi Elliott,
We have implemented TCP control for Icom in N1MM+. It requires separate (user-provided) TCP-to-serial software or hardware to interface with the radio. This allows the user to control their radio remotely over TCP, with the conversion to/from serial occurring at the radio location. Can wfview perform that conversion role ?
Thanks,
Steve, N2IC
we support rigctl over tcp (hamlib emulation).
I was under the impression that you wolud talk to the rigs directly though – so that you can benefit from the high speed scope operations as well.
I also add to try to influence that there is a Linux port of the N1MM+, and if it is natively, better.
We need more Linux programs that compete with the good programs we already have and use.
Hi Steve,
Yes. Wfview provides a virtual serial port and a TCP/IP interface which emulates the common rigctld TCP/IP server from hamlib.
More information here:
Rigctld emulation: Hamlib rigctld emulation | wfview
Virtual serial ports: Sharing Control | wfview
The idea is that if you run wfview and connect to the radio, wfview allows other programs to connect to the radio as well, acting as a conduit. Rigctld emulation is abstracted control commands, which are the same for every radio supported. The virtual serial port option lets you just send your usual raw CI-V commands as you would with a serial port. In my mind, the rigctld option is better and a more modern interface. Many ham radio programs can connect to rigctld already, and the abstraction makes the interface easy for the clients. (We haven’t implemented every possible rigctld command yet, but do let us know if we’re missing any critical ones.)
–E
de W6EL
Hi Elliott,
I’m curious if the ‘b’ command is implemented – which causes the rig to send CW. I’ve used this with CQRlog (w/o wfview) to send CW in contests. But I find that this does not work when using wfview. As suggested by another poster, I’ve set the rigctld port to 4556 in wfview, fldigi, wsjtx, and qsstv. And in CQRlog, I specify the device as localhost:4556 and the port as 4532. This causes CQRlog to play nicely with the other apps, but no CW with the “hamlib keyer”. Any thoughts?
…DonA
Hi Don,
I don’t think we have the ‘b’ command in yet. If you book mark this page and look at the commits for it, you can see when it’s updated:
We’ve had a few conversations on CW here, and I am genuinely surprised at how many operators wanted to type out CW with a keyboard! I figured such things were forbidden! 
I’m sure we’ll add this and similar CW features in the future.
–E
de W6EL
Thanks Elliott,
Got it bookmarked, and I’ll keep a lookout for an
else if (command[0] == "b || command[0] == "send_cw")
section.
I am somewhat old-school regarding CW, but I do enjoy trying new things–like having my logger (CQRLog) send a contest exchange. I’ve used fldigi to send ersatz CW (rig in USB mode) but find the 1000-1500 hz tone a bit too high for me, yet recommended to keep harmonics out of the passband. Using Hamlib keying allows the rig to be in proper CW mode, where you can take advantage of full break-in. That’s handy if you’re operating locally, but probably less important on a remote.
Thanks again: …DonA
TX via a kbd is not forbidden and in fact a keyer or kbd is way much better compared to the manual straight keying people generally.
It’s more the receiving end that’s “forbidden” in some people’s mind. Idon’t care much – I use my ears but each on it’s own I’d say
Hi Steve. I am recently written a simple TCP server for wfview (which should be committed to master soon) this works well with N1MM+ but I have discovered an issue.
I assume that N1MM+ is expecting the spectrum data in the “slow” UDP format, where it is sent in small chunks? For LAN connected radios, it is sent in a single packet and I assume that N1MM+ isn’t able to handle this?
Is there any plan to support the single packet spectrum data?
73 Phil M0VSE
Hi Steve,
Just to tag on to what Phil mentioned, if you are parsing the spectrum, the data actually tell you how many pieces there are in a complete spectrum line.
After the usual CI-V beginning and the 0x27 0x00:
Main/Sub[00=main 01=sub] SequenceNumber[01-11] TotalSeqneuceSize[01=LAN, 11=USB]
The third byte there, “TotalSequenceSize”, will either be “01” (there is only one chunk, LAN data), or “11” (there are 11 chunks to be assembled, USB/serial data).
Just reading that out will tell your software what’s going on with the data. It should be pretty easy to adapt to read the spectrum data this way, and it’ll pave the way for future extensions of the protocol and/or other Icom radios.
–E
de W6EL