Compilation under Win10

I made some small modifications to the program (in the source code).
The compilation under Linux (Raspberry 4) worked perfectly without any problems. It seems that he modified program is doing what I expected it to do.

The Raspberry will be the server of my remote configuration.

The client will be running under Win10 and needs the same modifications now.
I read your “How to compile with Windows”. Seems to be more complicated than under Linux.

In “Prerequisites” you tell us what software to install first. After a while I succeeded to install everything except Opus (as you recommend to “use our build”). When I’m trying to download it, I need to enter a user and a password. The user and PW for the forum don’t work. How to get the appropiate user and PW?

For your help many thanks in advance!

Frank F5VBD

Hi Frank,

You’re brave to go there! I’ve updated the link on the page, which goes here now:
https://www.wfview.org/public_builds/opus.zip

The build on windows is indeed a little more complicated, but once you have it working, you can easily use common commands to update the source and rebuild it any time. I probably went out of my way in the documentation to show how to make it similar to my linux build environment. Alternatively, you can probably do it a more “windows style” if you are more familiar with that. I personally wanted it all scriptable, so that is where my emphasis was.

–E
de W6EL

Hi Elliott,

Many thanks for your very fast response.

The download worked this time.

Many thanks to you and to the whole team for this excellent software.

It works fine with me to run my IC-7300 and IC-705 remotely (tested by
means of: server: RaspberryPi 4, clients: different Win10 computers and
one Linuxmint system).

Also my 20 years old IC-706 can be remotely controlled, in a rather
limited way (via CV-I I’m able to read and write the frequency and to
chance the mode), but it works too.

To toggle between TX/RX I’m using the RST-signal coming from a USB to
TTL converter.

The problem is the audio exchange. There is no
“rigCaps.inputs.append(inputUSB)” for model 706 in rigcommander.cpp. For
the RaspberyPi I could include this additional line in the compilation.

The idea is to connect an external usb-audio device to the RaspberryPi
and connect mic-in and speaker-out to the appropriate pins of the IC-706
ACC socket. The RTS is already connected to this ACC socket.

If this works, it would be the simplest way to exchange the audio
signals between a client and the remote IC-706.

My thoughts were, if it works with built-in USB-cards (build in IC-7300
and IC-705) that are connected to an USB-port of the RaspberryPi, why it
shouldn’t work the same way with an external USB-card connected to an
USB-port of the RaspberryPi.

Perhaps I’m wrong, but if not I would be able to revive an old rig in
using it as a remote station.

Greetings from the French Alps,

Frank F5VBD

Hi Frank,

How cool it is that you are using the 706! I too have one, although I only briefly used it with wfview (when adding that radio to the code). Yes, the commands are super limited, but I like it!

The rigCaps.inputs thing is only used to populate the modulation source menu in wfview. It simply lets the UI know that there are various input sources one can choose between. Since the 706 doesn’t have an audio source select command, this won’t need to be set to anything.

For the wfview server, the audio menu (for “what audio to put on the server”) is populated by the operating system simply showing the user all the available inputs and outputs. All you need to do is attach some kind of sound card or sound fob to your Pi and wire it into the IC-706 audio port, and then select that audio device in the wfview server audio menus under “Radio Server” in the settings (presumably you’ll do TX and RX audio).

For transmit, on the server side, don’t forget to select “Send RTS for PTT”. This lets you wire the RTS (“Ready To Send”) signal from the TTL converter. Sounds like you got that working already though!

My best results with older rigs:

  • Use the highest supported baud rate
  • Keep CI-V Transceive ON
  • Set the server polling rate rather high, such as 200ms
  • Set the client side polling rate as you wish so that you don’t see too many errors and the radio feels responsive enough. Since the 706 doesn’t have an S-meter, you can probably set it pretty high.

Do let me know how this works out. I have a soft spot in my heart for getting older radios connected to wfview.

Have a good evening,

–E
de W6EL

Elliot,

I was thinking to make a build slave myself and since you’ve scripted it - and I haven’t looked at it yet - can you spin up a vm, ssh into the machine; kick off the automated build, scp the artifact and shut down the vm?

(Reason I ask is here as it may benefit others too)

Yeah, except that I have not scripted turning the VM off. But it should be easy to add that. I just run a modified version of the fullbuild script that includes some error checking, no user prompts, and a log file of all the output. Plus an scp command at the end.

—E
de W6EL

Hi Elliott,

Here a first report on my experiences running an old IC-706 by means of
the wfview software.

My test arrangement:

  • Frequency read/write, mode read/write is done by the CV-I interface.
    RX/TX is realized using the RTS-signal.

  • Both CV-I and RTS commands to the IC706 are coming from the server (my
    Raspberry Pi 4) using an USB to TTL converter (CP2102 chip).

  • For the audio signal signals I’m using an external USB audio converter
    connected to another USB port of my Raspberry Pi.

  • For the tests the server (my Raspberry) communicates with the client
    (my desktop PC) via a wifi connection. Both devices are in the same room.

  • The IC-706 is in the same room as well and I’m able to compare the
    display readings on the IC-706 and on the client window.

My observations:

  • rx latency: typically 115 ms

  • rtt: typically less than 5 ms

  • loss: e.g. 6/845236

  • Everything normally works fine, but I discovered (up to now) 2
    malfunctions, one of no importance, but the other needs to be fixed.

  • The frequency display on the client shows sometime a complete wrong
    frequency (e.g. 163.xxxx MHz). This only happens for a very short time
    and seems not to have any impact on the working frequency of the
    transceiver itself. => not important to me.

  • Especially when I run the test arrangement for a longer time (after 1
    hour or more) it happens that suddenly appears a multiple echo on my
    modulation and my signal becomes unreadable. It seems that only when I
    reboot the server (the Raspberry Pi) I’m able to fix this kind of problem.

What could be the reason for this strange behavior? A buffer overflow?

Please instruct me, how I can figure out what the origin of this failure
could be and how to fix it.

73, Frank F5VBD

Hi Frank,

Excellent progress!

As for your bugs:

The frequency bug happens when the CI-V traffic gets corrupted. Remember that the IC-706 runs transmit and receive traffic over a single wire. Often it seems, especially on radios with older CPUs, there can be corruption due to concurrent CI-V traffic or other CI-V issues. I’m definitely open to suggestions on this one. I’ve thought about rejecting frequencies that aren’t sensible, but the issue becomes that the 706 can actually tune to some of those bands and so you end up making a bit of a compromise. I’d really like to discover a better method of timing on the CI-V bus so as to not have this problem. I’ve never seen this problem in flrig or fldigi, for example (but to be fair, I have not really used these programs but for a moment with the older rigs). I think the best strategy for now is to run the baud rate as fast as that radio can go (9600 baud I think) and then to set the polling value in wfview to a rather large one, such as 200ms. This way we get the fastest messages with the most time between them. It’s not perfect but it may improve.

With the audio: The fact that you have to reboot the pi to fix it sort of points to it being outside of wfview. But I cannot say for sure. I definitely recommend trying the somewhat-experimental “wfserver” branch of the code, for both your client and server, as the audio back-end has been almost completely re-worked, especially in terms of buffering, re-transmission, latency, etc. Maybe you are already on this branch, I don’t know, but this branch is the one to go with if you are compiling on your own. We will merge it into master very soon.

Using my x86 (Xeon) computer, I am able to use my vintage IC-736 radio with around 30-50ms latency on the audio. I’m running gigabit ethernet from that computer to my laptop. It wouldn’t surprise me if your larger latency is due to the Pi, but it could be other factors as well. Make sure to specify the Opus codec for best performance.

Thank you for keeping us posted, this is really good feedback for us,

–E
de W6EL

Hi Elliott,

You were right. I didn’t “press Y to install dependencies”.

But this didn’t fix the problem. Attached you will find the messages
when I’m running your script.

These are the messages on my Raspberry Pi 4, but on my LinuxMint OS
happens exactly the same.

As you can notice on line 209 and 210 and 228 and 229, it seems that
RtAudio and PortAudio had been correctly installed.

That means that still did something wrongly or there is still something
missing.

Do you have any thoughts?

Thanks in advance for your help!

73, Frank - F5VBD/DF1KT

(Attachment NewErrorMessage_en.pdf is missing)

Hi Frank.

There is no attachment, please can you attach it as txt file?

73
Phil

Hi Phil,

Here it comes!

NewErrorMessage_en.txt (20.7 KB)

Hi Frank.

It looks like it doesn’t have the development version of portaudio, only the runtime library?

Can you try the command:

sudo apt-get install portaudio19-dev

Then try to build wfview again?

73 Phil M0VSE

Hi Phil,

It worked!!! Compiling/building is ok on my raspberry pi.

I have now the choice three audio programs (portaudio, rtaudio and qtaudio).

Thanks a lot for your ultra fast response!

I will try your hint on my LinuxMint os later.

How about compiling under Win10?

73, Frank - F5VBD/DF1KT

Hi Frank,

Please see this thread where Dave is taking that on right now:

We’ve made some changes to wfview and it’s requiring a little extra care right now to get everything just right.

–E
de W6EL

Thanks, Elliot. I’ve taken today off to deal with my day job! Will get back to it soon and will keep in touch.

Dave