Icom LAN Protocol

I’m trying to learn the Icom LAN protocol from studying the WFView code (in udphandler) and watching data with Wireshark.

Initially, WFView sends a control packet to the radio that contains “myId” “myId” appears to be created by:

localPort = udp->localPort();
uint32_t addr = localIP.toIPv4Address();
myId = (addr >> 8 & 0xff) << 24 | (addr & 0xff) << 16 | (localPort & 0xffff);

which appears to be based on the host (WFView) IP address and port.

I am running WFView on a Raspberry Pi 4 with an IP address of 192.168.12.126 on port 50001. That should make the top two bytes of myId to be 0c 7e, but in Wireshark I see “08 cf 00 00” in the four bytes for id. I understand that the port is bound to a different internal port.

What am I missing?

73,
Mark, N8ME

Hi Mark.

To be honest, I wouldn’t worry about this too much. It is just a method of providing a unique Id to the remote server. The only requirement appears to be that each end of the connection has a different ID.

73 Phil M0VSE

Thanks Phil,

I suspected that that might be the case. I haven’t tested any code yet.

73,
Mark

Hi Mark,

You can easily print out the hex as the program is running if you want to see how it works. You’ll need (I think) to build a “DEBUG” build to see the output in the log file:
qInfo(logUdp()) << "UDP myId: " << myId << "(int), 0x" << hex << myId << "(hex)";
Can be added right under the code you pasted, and will produce output like this:
2022-01-07 10:06:09.605 INF udp: UDP myId: 59298 (int), 0x e7a2 (hex)

PS: Can you add wfview server to the uBITX?

–E
de W6EL

Elliott,

Thanks for the info on the DEBUG output. Can I use the Raspberry Pi build script? What would I need to change for DEBUG?

Were you being serious about the server for uBITX? What would you want the server to do My (N8ME) firmware implements a enough of a subset of the Yaesu CAT protocol that you can run WSJT-X with just the USB interface for control and a sound card audio interface. I never tried that with a Raspberry Pi, but I don’t see why it wouldn’t work (but that doesn’t need WFView).

73,
Mark

Hi Mark,

I think you can actually just start wfview with the --debug argument to get the verbose logging going. But you can also just build a debug build, which leaves the debug symbols intact too. Just edit the qmake step in the build script so that it looks like this:
qmake CONFIG+=debug ../wfview/wfview.conf (check this carefully, I usually just use qtcreator for debug builds since it has a nice GUI for gdb).

With the uBITX… I recalled that you had worked on the firmware. Does the uBITX has access to any spectrum data? Either way, if it had CI-V that would be neat, because we could then serve it remotely using a Pi (with audio, such as a CM118 or similar “fob” converter).

–E
de W6EL

Elliott,

No, the Arduino that controls the uBITX does not have access to any spectrum data, nor does it have access to any audio data. As you suggest, you would have to use an external A/D converter connected to the audio in and out.

The stock firmware was supposed to emulate the Yaesu CAT for the FT-817, but I found that it didn’t always work with external programs, such as FLDigi and WSJT-X, so I just cleaned that up to get it working. I suspect it would be possible to replace the CAT with CI-V, but the the CAT commands are much simpler than the dialog format of CI-V, so the code would probably be bigger. On the upside, there’s not much that the Arduino can actually do, basically just PTT, frequency and mode. There are no selectable filters and no way to adjust the AF gain.

Hi Mark,

Good to know, I wasn’t really sure how many things the Arduino could actually adjust there. In a way, this is similar to my ongoing IC-736 saga. That radio lets you command frequency, mode, and some memory functions. But you can’t even read the s-meter or set PTT! I have been debating hiding a Pi inside it to do these functions (and add an ethernet jack). A Pi is much easier for me to work with than an Arduino, as it runs an operating system with a debugger, filesystem, etc. Such a concept would probably work well for the uBITX as well, with a Pi and a simple DAC+ADC board like a CM118 fob for streaming audio and maybe an MPC3008 for reading out the s-meter or other analog voltage parameters.

I only mention this because I’d really like to see some of the popular low-cost HF radios implement network control for wfview. I think it’s the most complete protocol option of the ones I’ve seen out there so far. The xiegu x6100 seems like a really good candidate, as it runs linux, has a network (wifi), and even seems to ship with qt libraries that wfview uses.

–E
de W6EL

I’d also be interested to understand how to implement control via ethernet. I’m currently using a an Arduino Nano EVERY connected via some custom hardware into the Remote ( CI-V ) port. demo Smart Controller - YouTube

Hi John,

Your best bet is to study the source code. Just spend a few days reading it carefully, taking notes. If you use the Qt Creator IDE (free) and gdb, you can easily set break points and monitor what’s happening. To date I don’t think anyone has written a description of the protocol, but the code in wfview is a good start. Phil worked very hard on what we have in wfview, and I would not take it trivially. What you see in the code is what’s necessary for a stable connection.

I like the video! Radios need more knobs and LEDs in my opinion!

–E
de W6EL