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?
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.
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.
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.
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.
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.
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,