Connection problem to Icom 7300

1

I have a server/client wfview setup that previously worked, but not any longer. The server wfview on a pi does not connect to the Icom USB port:
https://termbin.com/szly
I have made the usual CI-V settings on the Icom reciever.

The problems begun as I had upgraded wfview to 1.52 and added an SPE Linear amp to the setup. The amp is connected to the CI-V output on the Icom, no CI-V adress in the amp settings, the amp reacts to the antenna CI-V info from the Icom, and these are the CI-V settings on the Icom:
• CI-V transceive on
• Unlink from remote
• USB serial CI-V
• CI-V baud rate 19 200
• USB baud rate 115 200
• CI-V adress 94h
• USB CI-V adress 00h
• CW och RTTY USB off
• Echo back off
• Antenna CI-V out on

I dont know if the linear amp has anything to do with the connection problems, or if the cause is something else. There is also an USB connection from the amp to the pi, using Virtualhere for remote control to the amp, which does work.

One strange thing is that the remote wfview client does get waterfall info from the Icom although the wfview server does not function. But the server wfview does not get a connection to the Icom, regardless if the client is active or not.

Regards,
Jan
SA0KEF

2

you updated
you added an amplifier.
you also have a waterfall
you think the server side does not function

first question, if the server side does not have a connection, do you think ik will show a waterfall or do you think we’ve implemented wireless USB without cables wireless magic waterfall that just fantasizes what happens on a band?

Or do you think… hmm, I did two things, one thing works (sort of) and I also added something and now it’s broken.

I’d say, get away with the PA first, make wfview working like it would normally.

After that, start experimenting with a PA and see whan/if it breaks.

3

I am fond of magic, and I have great respect for your abilities. but there is no waterfall on the server side wfview. I humbly thought that you might see a clue in the log why the connection pi-Icom does not work.

Right now I am not at the location of the server and Icom, so I can just look at the remote desktop link to the pi. But as soon as I get there, I will follow your advice and disconnect the PA.

4

I only see that the configured port may be in use or changed address. Maybe a second wfview

It is the reason I use udev rules here by the way.
Let me know Jan. As long as there is no magic smoke…

5

Janne, perhaps there’s some confusion over the exact details of your “strange thing” paragraph. Do you mean that you can connect from a Wfview client on your remote machine directly to the rig, presumably from something like a PC, but the server you’re trying to set up on the Pi won’t connect (as can be seen in the log file you provided). That is, you’re saying you can get a waterfall directly from the rig from the client system, not that the failing Pi server is magically providing a waterfall to the client.

I’ve encountered the case where I had Wfview connecting to my rig but then the connection or process was killed and the rig still thought there was a connection and wouldn’t accept a new connection. Power cycling the rig then allowed the client to reconnect.

6

Oh, and of course, be sure that you can ping the rig from the Pi. Again, to relate a personal war story, I did some network reconfiguration locally which messed up all sorts of things and debugging it began with basic principles of connectivity.

7

Yes, right on, as in your first paragraph!

8

Yes, I noticed now that the port numbers for the Icom are changing at reboot, sometimes dev/ttyUSB0, sometimes dev/ttyUSB1. And the server wfview will sometimes connect after reboot.

I will have to look into udev as you suggested.

9

I do it like this:

aplop:/etc/udev/rules.d # cat 99-usb-serial.rules
SUBSYSTEM==“tty”, ATTRS{idVendor}==“10c4”, ATTRS{idProduct}==“ea60”, ATTRS{serial}==“IC-7851 03001140 A”, SYMLINK+=“IC7851A”
SUBSYSTEM==“tty”, ATTRS{idVendor}==“10c4”, ATTRS{idProduct}==“ea60”, ATTRS{serial}==“IC-7851 03001140 B”, SYMLINK+=“IC7851B”
SUBSYSTEM==“tty”, ATTRS{idVendor}==“10c4”, ATTRS{idProduct}==“ea60”, ATTRS{serial}==“IC-7300 03001507”, SYMLINK+=“IC7300”
SUBSYSTEM==“tty”, ATTRS{idVendor}==“10c4”, ATTRS{idProduct}==“ea60”, ATTRS{serial}==“IC-9700 13001202 A”, SYMLINK+=“IC9700A”
SUBSYSTEM==“tty”, ATTRS{idVendor}==“10c4”, ATTRS{idProduct}==“ea60”, ATTRS{serial}==“IC-9700 13001202 B”, SYMLINK+=“IC9700B”

so no matter what port I use, what sequence etc, the ports are named:

/dev/IC9700A
/dev/IC9700B
/dev/IC7300
/dev/IC7851A
/dev/IC7851B

as udev will make a symlink in /dev/ with the right names.

Currently:

taplop:/etc/udev/rules.d # ls -l /dev/IC*
lrwxrwxrwx 1 root root 7 Jun 1 18:49 /dev/IC7851A → ttyUSB0
lrwxrwxrwx 1 root root 7 Jun 1 18:49 /dev/IC7851B → ttyUSB1

so if I refer to /dev/IC7851A it always will lead to the right port.

(You need to change the serial numbers though and no I don’t mind someone else knowing my serial numbers)

10

Thanks!
Is the udev rule activated at reboot, or when the USB-connection to the radio is plugged in?

11

Sorry for the unnecessary question, just tested according to your advice, and the connection from /dev/IC7300 at this occasion to ttyUSB0 was alive.

12

After you have put it in you could reload but fastest way is just reboot.

It will always work when usb is detected. So reboot, plug-in, it always works. In a different usb port etc.

13

I think the SD card was corrupt. The black smoke is cleared now and the ghosts exorcised with a safety copy and uppgrade to 1.62.

14

hah lovely ! those frankensteins should be eradicated!