I have an IC-705

I have the RS-BA1 software version 1, it doesn’t work
I need the version 2 to connect a computer to the IC-705 for wireless

Is there a way to upgrade my version 1 to version 2, if there is I can’t find it and it looks like I have to buy version 2

Is that correct?

I would try contacting Icom direct on this one.

I got it working on windows 10 with

1 WFview free software
2. Virtual audio cables
3. Virtual com port

WSJ-T works by selecting the virtual com port and IC-705 rig

FLDigi and JS8Call work by using FLRig ( selecting IC-705 as the rig) and then in FLDigi and JS8Call selecting FLRig as the radio.

When I get a chance I will post the specific software I used to get the virtual com port and the virtual audio cables

Ok, for anybody else that gets one of these and doesn't feel like spending $150 for the software that should come free after spending $1400 for a 5 watt radio.

For Windows 10. These programs are freeware / send us a donation or register if you like it, so you can try it first. I don't think there are any  time limits, but I could be wrong.
Turn on radio, set to connect to your wifi network ( allows internet access to your computer ) then your computer to the network, this allows the 2 to talk to each other and you have internet access to the computer for downloads. later you can set the radio to the access point server and connect directly to the radio like you would for portable ops away from the internet.


1. Download VSPE ( Virtual Serial Ports Emulator ) at http://www.eterlogic.com/Products.VSPE.html
 create a virtual com port by making a new comnector, I made com 10, then activate it with the play button. leav the program in the back ground.

2. Download VB-CABLE Virtual Audio Device at https://vb-audio.com/Cable/. Create an A-B virtual audio cable

Download WFview at  https://wfview.org/.
In Settings, fill in the name and password for the radio that you created in the radio,
select vb-audio cable for the output and input audio cable.
select virtual com port 10 ( or which ever one you created )
save and exit then restart the VFview. Test PTT on and off. You should see the water fall from the radio on the computer. Kepp in running on the background

Start WSJT-X and select IC-705 and Com 10 ( or what ever com you created )

It should work.

To get FLDogi and JS8Call working, download FLRig at https://sourceforge.net/projects/fldigi/files/flrig/

Select IC-705 in FLRig and intialize in the config menu

It should work. If not make sure the computer is connected to the right wifi.

If you don't want to use FLRig, you can download the IC-705 XML file from https://sourceforge.net/projects/fldigi/files/xmls/icom/ open up FLDigi and select config and RIGCat and select the IC705.xml file from the downloads or where ever you put it.

I have not figured out how to add the xml file to JS8Call yet. If I do i will post it, if anybody knows, please post it.

I’m a bit lost

What do you mean by wireless connection?  Like… wireless audio?  But you have to go from computer to computers anyway do you not?

The IC-705 has wifi and a wifi access point built it.

So you connect directly from the computer for digital modes and or remote control to the radio for cat control and audio for digital modes and remote control of the radio via wifi.

There are no audio cables or USB cable, all the data is passed via wifi when connected via wifi.

I just did this yesterday - as I got a MS Surface Go 3.  It's a pain in the ass to setup and half of the videos on YT suck ass because they don't tell the whole story.  There are a lot of settings that you need to have correct for it to work, leaving me to guess and play around to get it to work.  I plan on trying to do a YT video to cover the complete settings to get it to work to try and help others.

I'm looking forward to your video.  I also have a Surface Go 3, and while I have it connected to the IC705 via wfview and "mostly" working, on transmit I often get dropouts in my signal.  Sometimes it's fine, and sometimes it cuts out repeatedly in a single FT8 transmission, and I can't figure out what the cause is.  I've played with latency, different VB audio cable options, and everything else I can think of, and it still happens.  

I had the same thing happen.  I even rebooted the computer and it did not fix the problem. The green receive audio bar in FT8 was cycling through zero. WFView had complete audio but FT8 did not. My drop out happen during transmit and receive. In receive it was not decoding because the receive audio was cycling to nothing and in transmit, the power output goes up and down. Something is interfering with the audio transmission.

Hate to say it, but it's very likely that the problem is associated with the properties of Wi-Fi. It is difficult to impossible to run low latency audio/video/IF data over Wi-Fi with any degree of success.

The key words in that assertion are "low latency". Streaming audio and video runs fine over Wi-Fi because that uses large buffers, sometimes whole seconds in length. Any requirements for retransmission of drop-outs are easily accommodated And, since it is one-way transmission, there is no requirement for low latency or turn around times. Plus who hasn't experienced some occasional buffering that interrupts their favorite Netflix entertainment?

Now you are probably thinking "But what about Skype/Zoom/Meetings/etc? That stuff works." But does it? Who has not been on a VOIP call or on a video-telecon where there a) wasn't as much as a half second of latency and b) both audio and video drop-outs. Everybody has. But such minor issues are now an accepted part and parcel of VOIP and VTCs, especially after COVID forced a new level of experience with it.

But that sort of behavior is not acceptable for amateur radio work, especially when working modes like FT8 where ANY drop-out is a death sentence.

Worse still, the 705 uses UDP, not TCP, to move audio and other data. UDP is a lossy protocol. Once a packet is gone it's gone. There is no retransmission of them like there is with TCP. So if you've got dropouts no amount of buffering is going to help you.

Then you've got consider that if you are running your 705 in "station" mode, it is competing for bandwidth on your Wi-Fi network with every other device in your house. If a packet needs to go and it can't then it's gone. That's the cherry on top of this low latency, UDP, recipe for failure.

So what to do? If you are sufficiently close to your 705 then run it in access point mode. Then you are not competing for bandwidth. If necessary add an additional USB Wi-Fi adapter to your PC so that you can connect to the radio at the same time as connecting the internet Wi-Fi. But I suspect even that will be sort of pointless, as you will likely find you have to be so close that you might as well get a long USB cable.

Bottom line: Wi-Fi access to your 705 is probably only acceptable for AM/SSB, where the occasional dropped packet is just an annoyance. It might be acceptable for CW (can it do CW over the LAN?) But for most data modes it's going to be a problem.

I am running it access point mode, direct connection.

WFView has a waterfall and shows no loss of audio, I think it is the connection between FT8 and WFView, not the Wi-Fi.

Something between those 2 programs is causing packet loss. When I use FLRig to use JS8Call since JS8Call does not have an xlm file for the IC-705, FLRig which also shows no audio interruption. I have no audio interruption using JS8Call, only with wsjt-x , even when using FLRig with wsjt-x I have the audio interruption, so it seems limited to wsjt-x.

Other times it will run for hours without a problem, other times it is constant.

Where VB Cable is concerned did you make certain that all of your sampling rates are exactly the same across all devices? 48KHz for everything? You have to go into the legacy version of the Windows Sound Control Panel and set the advanced settings for all instances of VB Cable to 48KHz.

Example (not VB Cable):

Attached File

uhhhhhh. never looked at it.

Going to right now.

Ok It is fixed.

I think the problem was a combination of different sampling rates of the audio settings.

Here is what was done. Thanks to AA77 and my son.

In windows, go to settings,system,sound, sound control panel on right top
Playback, Cable input,  properties, advanced, set 1 ch, 16 bit 48,000, apply
Recording,Cable output, properties, advanced, set 1 ch, 16 but, 48,000, apply
Close it.


The virtual audio cable has a control panel in the installation folder called VBCABLE-ControlPanel. Make a shortcut to that so it is easy to find and use.

In WFView set 48,000 on the sample rate in settings tab. Set 1 ch 16 bit for the audio input and output.

Run the VB cable control panel. Set the sampling rate under options to 48,000.
Set the max Latency to 4096 smp.

Reboot the computer

That is what made it work perfectly.

Glad I was able to help

I was immediately suspicious of the Wi-Fi because in the Apache Labs/openHPSDR community there are a lot of problems with that. But there are also a lot of problems with folks not running their virtual audio 48KHz "clean" throughout the entire system, so that was an easy second answer.

Somewhat obviously, when there are sample rate mismatches there will ultimately be some buffer under or over-runs somewhere, sometime. Even with the everything 48KHz across the board you will see this occasionally because the IC-705 clock domain is separate from the PC clock domain. I.e. the 48KHz sample rate clock in the 705 hardware is not exactly the same frequency as the 48KHz sample clock in the PC, and that tiny mismatch will bite you every once in a while. But those bites will be much, much less frequent than what a gross sample rate mismatch will cause.

Based on all that, it seems keeping a low power PC connected to the 705 via USB (even a raspberry pi) and then remoting in to do FT8 and/or other time sensitive type things would be less prone to strange issues.


I understand that isn't the question Mach had in the OP though.  Glad it's working as you need.


ETA:  Would it not be better to use a higher rate, as long as everything in the signal chain supports the higher rate?

This is why I am going to try and make a YT video to capture this stuff.  It's not intuitive and there are a ton of settings to ensure that are set correctly or it won't work.  This radio is super complex and there are still settings I have no clue what they do.

I appreciate the setup info, I think it solved my problem as well.   I had set things previously to 16bit/48KHz in the Windows sound control panel and wfview, but had neglected to also set bitrate and max latency via the VB-audio cable control panel program itself.  

Since getting EVERYTHING synced up per the info in this thread, I think I've only had one "glitch" since, and the loss packet count went up a bit when that happened, so it may have been due to a wifi issue.  (Surface Go connected to IC-705 in access point mode).


Thanks!

In theory, yes. But as a practical matter nearly every bit of digi mode software out there expects a 48KHz sample rate. There's a few odds and ends like CW Skimmer that can accept up to 192KHz but that's to obtain a wider processing bandwidth and not to achieve higher fidelity.

There are also limits associated with the source. Can the 705 produce anything but a 48KHz audio sample rate?

I will have to look next time I turn on the radio but I don't remember seeing a bit rate selection for audio.

But by increasing the bit rate, you run into the limiting factor described by the MDT.

( Mach's Digital Theorem in general says the more bits there are the more likely stuff will go to shit )