Since I get my internet through bluetooth tethering to my phone, wifi is available on my laptop. So I decided to try connecting to my IC-705 by putting the radio in access point mode. I connect my laptop's wifi to the 705's access point and all seems well.
In wfview, I put all the info in as usual for a lan connection and hit connect.
It connects and audio starts coming across right away. The packet loss indicator shows only about 1 in 12K packets dropped, so it's a great connection. However, the radio type in the lower right corner of the window stays at "NONE" and I get no other data. No waterfall, no controls or frequency. Just audio.
No, I didn't mess with the port numbers. It still works fine if I use an external access point with the radio and computer connected.
Could be a bug I'm guessing.
When the IC-705 is in AP mode, does the laptop and 705 have valid ip addresses? Are they self-assigned? Are they on the same subnet? Is there an internet connection on the laptop at the same time?
Presumably whatever is going on in AP mode, there’s a DHCP server and both devices have reasonable ip addresses – or else you probably wouldn’t have gotten as far as you did. Or maybe they enter “self assigned” mode and make up IP addresses?
Can you verify that CI-V transceive is turned on, when you are in this configuration? Can you also try rotating the VFO knob on the rig and see if wfview responds to the traffic generated by that motion? You can also try entering in the correct CI-V address for the rig under Settings (you would need a newer version of wfview to have this UI option). After entry, press Save Settings, exit wfview, and re-open it.
Beyond the above basic troubleshooting, and given that you had success when you went back to the regular configuration, I am stumped. If you can, remove your wfview log file to clear it out, and then launch wfview in the AP configuration, play with some knobs, quit, and send us the log.
I don’t know how, but CI-V transcieve was turned back off.
I didn’t do that. Weird.
It’s working now. So now I’ll have to try to figure out how CI-V transcieve got turned off. I know I didn’t do that manually… I haven’t messed with any programming software since I last used wfview.
A mystery. Maybe one gamma particle coming from space happened to perfectly hit the right atom in a cell in the flashrom and flipped a bit.
When the IC-705 is in AP mode, does the laptop and 705 have valid ip addresses? Are they self-assigned? Are they on the same subnet? Is there an internet connection on the laptop at the same time?
Presumably whatever is going on in AP mode, there’s a DHCP server and both devices have reasonable ip addresses – or else you probably wouldn’t have gotten as far as you did. Or maybe they enter “self assigned” mode and make up IP addresses?
Can you verify that CI-V transceive is turned on, when you are in this configuration? Can you also try rotating the VFO knob on the rig and see if wfview responds to the traffic generated by that motion? You can also try entering in the correct CI-V address for the rig under Settings (you would need a newer version of wfview to have this UI option). After entry, press Save Settings, exit wfview, and re-open it.
Beyond the above basic troubleshooting, and given that you had success when you went back to the regular configuration, I am stumped. If you can, remove your wfview log file to clear it out, and then launch wfview in the AP configuration, play with some knobs, quit, and send us the log.
This is a known issue, if you connected direct to the radio (via USB) using any program that uses Hamlib for rig control. The first thing it does is disable transceive mode as it can’t deal with it!
We are trying to find a solution where we can detect the radio via other means and then enable transceive mode remotely.
That must be it. I did run FLrig for a bit. I’ve been trying to get FLrig to stop messing with the radios settings when you launch it. They really need to add a switch to disable that. Even with the read/restore options unchecked, FLrig will fiddle with the radio when you launch it and when you shut it down.
Bad behavior. And even worse that you don’t have an option to disable it.
I really like flrig, the code is very nice (c++, and almost all stack-allocation at that!) compared to many rig control programs out there. But that one feature drives me BONKERS. When I launch it, I hold my breath and see what it’ll do – flipping the VFO A/B, changing filters, frequency, etc. I can’t stand it. It’s to the point where I’ve considered fixing it in their code. It’s also why I’ve started just using fldigi into wfview without the layer of flrig lately. (But flrig has so many nice features coded for the modern rigs, like NR/NB adjustment…)
At any rate, glad it worked out for you. As Phil mentioned, we’re looking at alternatives to remove this annoying issue with other programs disabling CI-V Transceive. For now, you can manually define the CI-V address and while you’ll loose some of the responsiveness of wfview to the rig’s physical knobs, it will otherwise work ok without Transceive enabled.
Dude, if it’s an easy fix in FLrigs code, branch it. I love using it for the filter control through fldigi. When I’m running PSK31, if I’m using FLRig for control, within FLdigi, you can mouse over the filter bandwidth and use the scroll wheel to quickly shift the filter bandwidth.
So many times, I’ve had a weak station I’m trying to work, with a stronger station a few hundred HZ away causing the AGC to pull back. Hit the QSY button to center the station I’m working in the passband and mouse wheel to narrow the filter to 50 HZ and boom. The station I want is the only thing coming through the IF chain, gain is up and copy is solid. It’s such a convenient way to operate, but only works if FLRig is the middle man.
I’ve posted over on an FLRig forum about adding a check box to turn off that launch and exit rig fiddling. Nobody responded. I can’t imagine why they think it’s the right thing to do. I don’t see any advantage. When I launch it, I just want it to read the current state from the radio, and when I exit, leave it like it is. I hate when I exit the program and then have to go punch at the radios screen to put it back on the band and mode I was on. Annoying as hell.
That’s great. I’ve been meaning to try a fresh pull of flrig just in case the issue has been addressed and I’m just using an ancient version from my distro.
I can’t imagine why they would really want this feature always on. I have often thought I was the only one, as though I had it configured wrong.
Heh, I hope you don’t mind, but in my email to him, I mentioned that you had referred to it as driving you “bonkers”, just to relay the feelings from another programmer along with my own.
Yeah, it’s not just you and me. I’ve heard many others complain about it too. It didn’t used to do that. I’m not sure when, but it started a few years ago.
I’ll let you know when I hear back from him, if I hear back.
flrig will read various transceiver parameters and restore them upon closing. The next image shows the available read/restore parameters for the Icom 7200. If a parameter is not available (or coded) it will be disabled and grayed out. Check each parameter that you want to read and restore. Reading and restoring transceiver parameters takes time, especially on older transceivers with low baud rate serial i/o. Check “Use xcvr data” i\If you want flrig to NOT change the transceiver operating state when it begins execution.
I can’t recall seeing this option, but I’ll have to go look now.
I swear I checked that use xcever data box and it still did it. Now I have to go verify that so I know I’m not losing my mind. (More so than I already know I am.)
Huh. Well, I’m sure I tried that box before, but it seems to do the trick. With everything unchecked except for the Use xcvr data box, it does a quick read of the radio on startup, switching vfo only to read the settings on the other vfo.
Sure enough, on exit, it only toggled the vfo back and forth once, but didn’t change anything.
| 
I love using it for the filter control through fldigi. When I’m running PSK31, if I’m using FLRig for control, within FLdigi, you can mouse over the filter bandwidth and use the scroll wheel to quickly shift the filter bandwidth.