Hi Roland,
This is great information, I appreciate your post.
I’d like some clarification on what you’re doing so that I understand it better.
ICOM 7300 connected via USB to Raspberry 3B, creating ports 50001 to -3, port 4533 as rigctld and choose 4545 as raw tcp forward of CIV traffic.
Client side:
Raspberry 4B with wfview, connecting to the ports 50xxx and presenting audio to my headset.
When I now start rum log on my MacBook, use a 7300-ctrl setup and connect to the port 4545,
rumlog AND wfview struggle to be the CIV-controller with address “E0”, as seen in the logs of wfview:
So in this instance, you’re connecting rumlog using the raw “TCP Server Port” option, correct? And the connection flow would be something like this:
7300 → ServerPi wfview → TCP Server → mac with rumlog
And at the same time, also connecting to the ServerPi, a Raspberry Pi running wfview as a client.
Correct?
The 7300 and CI-V in general have no problem with multiple controllers (computers) on the bus. wfview defaults to address 0xE1 just to stay out of the way of what most programs are hard-coded to be (0xE0). I think CI-V was very forward-thinking for a 1980s creation in that it allows for multiple radios and computers on the same single-wire connection.
The message " INF udp.server: Got data for different ID “0xe0” : “0x94” " that you posted, is this from the client wfview or the server wfview? It would seem likely the server side. Looking at the source code (forgive me, I did not write the network stuff), I’m seeing that when this condition is encountered, it does not move past the dataForServer function.
I can tell you that multiple CI-V controllers seems to work for the pseudo-terminal device. But I have not personally tried the raw TCP port. Hmm.
Another question for you, what is the “ICOM Server” option in RumLog intended to do? Is it supposed to speak native icom network? If so, it should be able to talk to the wfview server. When you tried this, how many clients were connected to the wfview server? Try just one at a time if it was multiple. I feel like we can probably work on this and make it succeed.
And your 4th setup:
Server and client side as first setup, but now I enable the raw TCP CI-V traffic port (4545) on the Client RasPi 4B’s wfview.
On rumlog, I use model “7300” instead of “7300-ctl”, connecting via TCP to the client RasPi port 4545.
The difference here is that the client-side wfview is providing the TCP server, correct? And this works?
What is model “7300” and what is model “7300-ctl” ? Can you explain what is different between them?
I like your idea of providing radio access to those without antennas. HF is challenging for so many people, but we should be able to leverage technology to bridge the gap, so to speak. Personally, I think they would be better served with wfview on their own computers, due to the more fluid experience of having a normal desktop application and of course, not having to fiddle with VNC and IP addresses. Or just using the Pi directly. But I can see the merits of what you’re talking about. You might also want to tell them to just plug a screen and keyboard+mouse in to the Pi and enjoy it that way, without messing with anything. Just… plug it in and see a radio! I assume you have the desktop on the Pi set to automatic login, run wfview on startup, using a dynamic dns, etc? You can also set wfview to run full-screen on startup, which would make your Pi box a nice link to the radio. Just turn it on and see the rig!
Very curious about your details with Rum. It seems like the TCP connection to the wfview client side is the way to go. Maybe you can send me some screenshots if that consistently works out ok, and then we can include it in the manual.
Sorry for the rambling reply, coffee is still soaking in…
–E
de W6EL
