Setup guide or video for setting up the Icom IC7300 IP service for remote control

I remember seeing a couple of IC7300 users got the IP working for them. Any chance someone can put together a setup guide or video of how to get this up and working? I just can’t seem to figure it out and it all seems to make sense but I don’t get any connection locally or remotely. I think it’s clear I’m missing an important step in this.

Yes, the program works just great to operate the radio directly on the connected computer. I’m interested in connecting to it remotely.

Thanks.

Hi Erik,

It’s a good idea. I’ll get to it eventually myself.

Have you looked carefully at this document: Remote Operation | wfview

Thanks,

–E
de W6EL

Also, if anyone does make a video, we’ll be happy to post it on the video page at wfview.org. Lots of views!

–E
de W6EL

Okay, so I got it working. It was a clear case of the loose nut behind the keyboard that was looking at the settings all backwords. I was trying to make the radio the remote side and the remote the radio server side. I don’t think it really works that way forehead slap!

So now that I have it working and have been able to connect locally, it seems I can still not connect over the internet to that server. It seems like I should be able to, all the ports are forwarded to that server computer but no connection when I use the computer’s IP4v address over the public internet.

Any thoughts on that?

Glad it worked!! What OS are you using?

You’ll need to use the router’s public IPv4 address when you’re not at home.

And make sure the ports are type “UDP” on your router’s port forwarding page.

–E
de W6EL

I am using Windows 10 on that server computer. I am also trying to use the public IPv4 when trying to connect over the internet. The local IP works fine for connecting within my network. Ports are set as TCP/UDP. I guess that must be in duel mode, but if you think putting it to UDP specifically I will try that and get to you.

Hi Erik,

“dual” mode should be fine. Double-check all the ports. Make sure the “to” and “from” port numbers are the same, and that the ip address of the server is correct. It’s one of those things where just one mistake will cause the entire thing to basically not work.

Don’t forget to verify your public ip address, epsecially if it may have changed.

–E
de W6EL

So again the problem was the operator. Not totally my fault. It seems Windows 10 on the laptop I have connected the port numbers are so crammed into the boxes it’s hard to know what they are. I got out the magnifiers and closely looked them over and determined that the number of zeros I had programed into the port forwarding was deficient the number required.

So now I do have full control of the radio by remote, local and public.

Thank you for the guidance.

Woohoo!

Please do let us know how your experience pans out with this configuration. We’d really like to support making rigs remotely accessible just as you are doing.

Thanks,

–E
de W6EL

This is an update to operating WFView by remote. For a month now the radio has been installed in a remote location in Montana. WFView has been working to access the radio very nicely.

I am having one issue that I can’t seem to narrow down what’s causing it. The server computer connected to the radio seems to shut down WFView from time to time or I am somehow doing this by not turning off the WFView here correctly.

When I log on using Teamviewer to restart WFView I don’t see any problems. If I stay logged on with Teamviewer to keep an eye on it for a bit, I can’t seem to make WFView turn off with any combination of turning off the remote side of WFView.

But almost without fail, if I turn off WFView here, at some point before I log on again, WFView on the server computer has turned off.

Does anyone have any idea what might be happening?

Hi Erik,

This is such a cool project that you have going on!

There is a log file for wfview, which may shed some light on whatever is happening. Here is a link that shows how to get access to the log file. Note that the log file is overwritten each time wfview is opened, so if you detect a crashed or hung wfview, grab the log file prior to re-launching. By the way, I think your project would really benefit from one of our long-term goals which is to enable headless servers, including the low-power Raspberry Pi.

Also, be sure and try our latest version. It has a lot of improvements for remote access. version 1.1a (the a means Alpha, as in testing) came out today!

Please let us know how we can help, and what you see in that log file.

73,

–E
de W6EL