7300 no connect with 1.2d on raspberry pi.

I downloaded the latest 2.0 version of the Hampi Linux distro for my Pi400 computer.
I did the updates on it and found that 1.2d was the latest Wfview installed
The 1.1 worked perfectly and I tried to duplicate the settings, but nothing would connect to the 7300. I’m wondering if anyone else has had issues with this one? I know it’s still a beta, so that could be something.
Any ideas what to try?

Just for info, I have the 1.1 version set to connect to USB [auto] at baud [115200]. Nothing else was needed to be changed and it works perfectly with all features, and it does recognize the IC-7300 in the lower right corner.
1.2d - I get nothing happening at all with the same settings. For now I’m just using the older HamPi build. At least with the OS on an SD card, it’s supper easy to go back and forth.
Tom

Hi Tom.

Generally the auto serial port configuration in Linux requires various configuration, as per Serial Port Management | wfview

You should be able to manually select the serial port for the rig in 1.2d. I don’t think that anything has changed in wfview recently that would cause this to change though, so I would suspect something has changed in HamPi (I have never used it)

73 Phil M0VSe

1 Like

Thanks Phil. The permissions thing may make sense. That link looks helpful, I’ll give that a try. Seems odd that it won’t work after I do track down the port that the 7300 is on. I’ve been using Linux for years, but still so much to learn. I kind of wish there was a “Device manager” like Windows has, but I usually just Google for ideas.
I’ll update my findings!
Tom KA7VIK

You can try this command:
ls -lR /dev/serial
and it should show you the various serial devices connected.

If you encounter issues, perhaps post us the contents of /tmp/wfview.log so we can have a look at the log.

Thanks,

–E
de W6EL

1 Like

That looks good. A nice tidy way to see what I want. Thanks for that tip. I’ll dig deeper into this again and see if I can connect to the Icom.

Tom

I set to ‘auto’ and got nothing. Then tried it on /dev/ttyUSB0 and looking at the end of the log, it looks kind of promising, but still no control. I did reboot each time also.
Some other info: HamPi does have the Hamlib RigCrl installed and that is what I was using before on Wsjtx to control the radio through Wfview set on “auto”. Works great! Just not this version.
Here is the log contents.

pi@hampi:/tmp $ cat wfview.log
2022-02-07 22:13:56.501 INF system: “wfview version: 1.2d (Git:440429b on Feb 5 2022 at 20:00:15 by pi@hampi)\nOperating System: Raspbian GNU/Linux 11 (bullseye) (arm)\nBuild Qt Version 5.15.2. Current Qt Version: 5.15.2\n”
2022-02-07 22:13:56.834 INF default: setState 1
2022-02-07 22:13:56.836 INF default: setState 0
2022-02-07 22:13:56.836 INF default: setState 1
2022-02-07 22:13:58.553 INF system: Loading settings from “/home/pi/.config/wfview/wfview.conf”
2022-02-07 22:13:58.720 INF rigctld: started on port 4532
2022-02-07 22:13:58.747 INF gui: Got Audio Output: “alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo”
2022-02-07 22:13:58.747 INF gui: Got Audio Input: “alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo”
2022-02-07 22:13:58.747 INF gui: Got Server Audio Input: “alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo”
2022-02-07 22:13:58.748 INF gui: Got Server Audio Output: “alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo”
2022-02-07 22:13:59.073 INF system: Cannot prepare WF view without rigCaps. Waiting on this.
2022-02-07 22:13:59.074 INF system: Could not find Icom serial port. Falling back to OS default. Use --port to specify, or modify preferences.
2022-02-07 22:13:59.074 INF serial: Could not open serial port “/dev/ttyUSB0” , please restart.
2022-02-07 22:13:59.075 INF udp.server: Starting udp server
2022-02-07 22:13:59.076 INF udp.server: My IP Address: “0.0.0.0” My MAC Address: “DC:A6:32:FA:CC:47”
2022-02-07 22:13:59.076 INF udp.server: Server Binding Control to: 50001
2022-02-07 22:13:59.077 INF udp.server: Server Binding CIV to: 50002
2022-02-07 22:13:59.077 INF udp.server: Server Binding Audio to: 50003
2022-02-07 22:13:59.077 INF udp.server: Server audio input (RX): “alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo”
2022-02-07 22:13:59.077 INF udp.server: Server audio output (TX): “alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo”
2022-02-07 22:13:59.308 INF system: Received CommReady!!
2022-02-07 22:13:59.308 INF system: Delay command interval timing: 75 ms
2022-02-07 22:13:59.308 INF default: Setting rig state for wfmain
2022-02-07 22:13:59.308 INF default: Setting rig state
2022-02-07 22:13:59.314 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:13:59.420 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:13:59.530 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:13:59.680 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:13:59.830 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:13:59.980 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:00.130 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:00.280 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:00.430 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:00.580 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:00.730 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:00.918 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:01.030 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:01.183 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:01.330 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:01.480 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:01.630 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:01.780 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:01.930 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:02.080 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:02.230 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:02.380 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:02.530 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:02.680 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:02.830 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:02.989 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:03.130 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:03.280 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:03.430 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:03.622 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:03.730 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:03.880 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:04.030 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:04.180 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:04.330 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:04.480 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:04.630 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:04.780 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:04.930 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:05.080 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:05.230 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:05.380 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:05.530 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:05.680 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:05.830 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:05.980 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:06.139 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:06.279 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:06.430 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:06.580 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:06.636 INF system: Saving settings to “/home/pi/.config/wfview/wfview.conf”
2022-02-07 22:14:06.637 INF default: Server config stored
2022-02-07 22:14:06.760 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:06.880 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:07.030 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:07.179 WRN default: QIODevice::write (QSerialPort): device not open
2022-02-07 22:14:07.213 INF serial: Opened port: “/dev/ttyAMA0”
2022-02-07 22:14:07.215 INF system: Received CommReady!!
2022-02-07 22:14:07.215 INF system: Delay command interval timing: 75 ms
2022-02-07 22:14:07.215 INF default: Setting rig state for wfmain
2022-02-07 22:14:07.215 INF default: Setting rig state
2022-02-07 22:14:14.933 WRN default: QString::arg: Argument missing: Failed to get sink information: %s, No such entity
2022-02-07 22:14:14.933 WRN default: “Failed to get sink information: %s”
2022-02-07 22:14:33.776 INF udp.server: Closing udpServer
2022-02-07 22:14:33.777 INF rigctld: closing rigctld

It looks like you need to either own the port or make absolutely sure nothing else is currently running that might use the serial port.

—E
de W6EL

To own the port:
chown $USER /dev/ttyUSB*
to check for current serial port users:
lsof | grep ttyUSB

I hope that helps. We’ve done hardly anything to change how this sort of thing is handled under the hood, so this is quite surprising.

–E
de W6EL

I’ll check that out. I wonder if something got copied over that messed up settings? I tried the upgrade method here and copied all my data over. I’ll try to re-image the card and try again before moving my data over. Then if it works, just move the FT8 Log over and go from there.
https://s3-us-west-1.amazonaws.com/groupsioattachments/14133/88068569/11947/1?AWSAccessKeyId=AKIAJECNKOVMCCU3ATNQ&Expires=1644350321&Signature=qtAzFtVzezlr1lKoUTyBjP%2FT8cI%3D&response-content-disposition=inline%3B+filename%3D"UPGRADE_FROM_PRIOR_VERSION.TXT"

Ok, the latest. I did a new image of the Hampi OS and booted it up. Worked perfectly!
Then I did the apt update / apt upgrade and it stopped working again.
When I looked before it did say 1.2d version, but looked the same always. After the apt upgrade was run, it now shows new bands at the top Air, WFM…etc that weren’t there before
I changed the ownership of all the tty ports since there wasn’t a USB listed, just /dev/ttyAMA0 which appears to be the port I need.
Is there a quick easy way to go backwards a version without doing the full re-image (and never the apt upgrade?),
When running lsof | grep ttyAMA0 I get this:

pi@hampi:/dev $ lsof | grep ttyAMA0
wfview 3286 pi 28uW REG 0,22 88 7 /run/lock/LCK…ttyAMA0
wfview 3286 pi 29u CHR 204,64 0t0 135 /dev/ttyAMA0
wfview 3286 3287 QXcbEvent pi 28uW REG 0,22 88 7 /run/lock/LCK…ttyAMA0
wfview 3286 3287 QXcbEvent pi 29u CHR 204,64 0t0 135 /dev/ttyAMA0
wfview 3286 3292 QDBusConn pi 28uW REG 0,22 88 7 /run/lock/LCK…ttyAMA0
wfview 3286 3292 QDBusConn pi 29u CHR 204,64 0t0 135 /dev/ttyAMA0
wfview 3286 3293 threaded- pi 28uW REG 0,22 88 7 /run/lock/LCK…ttyAMA0
wfview 3286 3293 threaded- pi 29u CHR 204,64 0t0 135 /dev/ttyAMA0
wfview 3286 3308 QThread pi 28uW REG 0,22 88 7 /run/lock/LCK…ttyAMA0
wfview 3286 3308 QThread pi 29u CHR 204,64 0t0 135 /dev/ttyAMA0
wfview 3286 3309 QThread pi 28uW REG 0,22 88 7 /run/lock/LCK…ttyAMA0
wfview 3286 3309 QThread pi 29u CHR 204,64 0t0 135 /dev/ttyAMA0

I hope this is helpful if anyone else runs into this problem. I’d think the HamPi image may be pretty popular with Pi users and maybe this could help them too.
– Tom

Hi Tom,

I do not believe /dev/ttyAMA0 is the IC-7300. This must be part of the problem. /dev/ttyAMA0 is a serial port made up of two of the GPIO pins on the Pi. You’ll definitely need to be using a ttyUSB device with the 7300. If you don’t see the 7300 as a USB device, try power cycling the radio and/or unplugging the USB cable and reconnecting it.

–E
de W6EL

Oh, that makes sense. I also use a Pi4 in my home observatory and those USB ports to appear a lot easier than the 7300. I have a tty for the dome control, another for the mount, and focuser is on a third. Somehow that all works, but I think the software on that does detect and list them all, just a matter of sorting them out. (That is with Astroberry if you are into that hobby).
It’s confusing that it worked fine on ‘automatic’ right away, but then all blew up when I updated. I just have to confirm the ttyUSB it automatically chooses.
Tom

The cause is that brltty is set to use / dev / ttyUSB0.
I don’t know how to change brltty, so I can solve it by deleting brltty for the time being.
$ sudo apt remove brltty

I forgot.
If you remove it, HamPi will be quiet.

1 Like

That makes sense! I had a similar issue where “ModemManager” kept grabbing my Yaesu FT-70 serial port on my laptop. Drove me nuts for a few hours until I did as you did and got rid of it!

I had to look that up. For blind users and a braille display. I can see that having some interface ready to just plug into that.
I’ll try removing that and see what happens. Thanks for the idea!
Tom

Hey guys, that was it. I removed brltty and the Wfview was connected once I started it up. I did see the ttyUSB0 also which never appeared in /dev when it was taken by brltty so that was confusing.
I just need to find out why WSJTX won’t work now, but I just have to review your comments on the QRZ forum you left when I had this question before.
Make note of the brltty thing I’m sure someone may have that issue also.
Thanks for the tips! Wfview is great, and happy I got the latest figured out.

Tom KA7VIK