I have almost managed to control my IC-706MKIIG rig using wfview.
As long as I constantly change frequency the communication is up and the radio follow my frequency changes but as soon as I stop changing the frequency wfview stops responding and eventually crash after a few seconds.
I’ll attach my debug log from one of the runs. I tried to upload my config file as well but it was not allowed.
The version is:
[Program]
version=1.62
majorVersion=1
minorVersion=62
gitShort=3fa14eb
My Radion settings are:
[Radio]
RigCIVuInt=88
CIVisRadioModel=false
ForceRTSasPTT=true
polling_ms=250
SerialPortRadio=COM3
SerialPortBaud=19200
VirtualSerialPort=none
localAFgain=255
AudioSystem=0
I have tried polling_ms=75 and also CIVisRadioModel=true but no difference.
I have tried control my radio using manual commands from a serial terminal and the Ci-V works. I also do see the S-meter and the correct frequency in the wfview display.
Is the MKIIG version of IC-706 not tested and not working or is it something else I have missed?
I will try and replicate your issue, although I’ll be using linux.
Questions for you: What kind of serial interface are you using? Are any other programs running that might be attempting to use the serial port at the same time?
Ci-V is set as you suggests.
I have also tried Transceive off and 731 on.
I can control the radio using e.g. JS8Call and PC-ALE. Just to be sure nothing is still using the COM port I rebooted but no difference.
I run Windows 10 Pro updated to current status, forgot to say that.
My interface is a homebrew as of this schematic but changed to be powered from the radio through a 5V regulator connected to the 13.8V pin on the multi pin connector. I.e. I cut the diod from pin 1,4,6 and feed the two 4k7 resistors with 5V directly:
I have another 706MKIIG I can try as well but no time right now and ‘should’ not matter.
I could also try to reinstall wfview to see if something has happened to it, or try a previous version.
I found I had a previous version of wfview installed as well. The dates on the install files are 2021-05-30.
When running this instance of wfview there are no crashes and I can control the radio. I guess something has happened affecting the control of an old radio as the 706 since that version.
Hope this info helps in some way. Let me know if I can try something else on my side.
Windows automatic updates have caused me a lot of issues in the past with software not keeping up, device drivers not updating, etc. Basic incompatibility problems. My solution is, unfortunately to disconnect the PC from the internet permanently. So now I have one PC on W7 dedicated to driving my HP plotter which is probably 30 years old but works fine as long as nothing changes.
I don’t have a solution for you and for Wfview, unfortunately, and even when I get it running, this auto update issue may be a problem. And in windows, it can’t be shut off only delayed.
The ONLY time that a Windows Update will have any detrimental affect wfview is with USB connected rigs as Windows will try to replace the Icom supplied driver with it’s own on.
As to the original question, if you can provide a log file that would be helpful.
Also I would recommend that you NEVER enter a manual C-IV address in wfview, ALWAYS use C-IV transceive and allow wfview to detect what rig is connected.
As you previously had a very old version of wfview, it is possible that there is something incompatible in the stored configuration, you can run wfview from a command line and specify it uses a custom .ini file (rather than the Windows registry) Command-Line Arguments | wfview then setup wfview again.
As you are using a .ini file already, I assume that you are on Linux?
If this is the case, make sure that you have all of the latest versions of the pre-requisite packages, especially libudev (apt install libudev-dev). I don’t think that this has anything to do with the radio to be honest.
There is no problem with my serial port as it works great with JS8Call.
As this is an old radio no Icom drivers are necessary, or should be used, to talk to the radio.
Regarding your question about a log file I did attach a log to my original question. Can you not see it at the bottom of it?
I can email you directly if necessary.
I have set the config file manually using command line arguments and I have erased it several times to be able to test new settings as the program crashes before I have an opportunity to make changes.
I have now tried one session without manually setting the Ci-V in wfview with no change in behaviour.
I entered the Ci-V address manually as that is what was recommended for older rigs. Perhaps the 706 is not old enough?
I’m now not at the site where the radio is situated but I can test everything except change settings on the radio itself.
No, I’m on Windows 10 Pro but I have set the arguments in the shortcut.
Perhaps that is the problem. Maybe arguments in windows is not very well tested?
No that’s not it. Arguments in windows should work just as well as any other environment.
You could try going back a version or two, https://wfview.org/older-downloads/ there were significant changes in 1.60 release and something may be incompatible with your machine.
Ok. I’ll give it a try later tonight.
Thank you for trying so hard to help with a rig actually not aimed to be supported as it does not have a waterfall :o)
It is a 64-bit issue.
I installed wfview 1.6 x86 which works.
Then I installed wfview 1.6 x64 which crash.
I then tried to install 1.62 x86 version and that works as well.
Either there is a general problem with the 64-bit version or there is something on my computer not liked in 64-programs.
Tell me what to do if you want to move on with debugging. Otherwise I’m satisfied as I now can run the program in 32-bit mode.
One of the major problems that we have faced with older radios is knowing what commands are (and aren’t) supported, radios like the 706 have a very limited C-IV command set.
According to your log, the last command we sent to the radio was actually an empty command, which should never happen:
2023-04-27 22:18:25.435 DBG rigTraffic: Final payload in rig commander to be sent to rig:
2023-04-27 22:18:25.435 DBG rigTraffic: "---- Begin hex dump -----:"
2023-04-27 22:18:25.435 DBG rigTraffic: "DATA: fe fe 58 e1 fd "
2023-04-27 22:18:25.435 DBG rigTraffic: "INDEX: 00 01 02 03 04 "
2023-04-27 22:18:25.435 DBG rigTraffic: "---- End hex dump -----"
This ‘may’ be the cause of the crash?
I am in the process of completely re-writing this part of wfview to have rig specific configuration files. This is something that we have planning for a long time, but kept putting-off as it was going to be a lot of work.
I am quite a long way through this process now and one benefit is that wfview will always know exactly what commands are supported by the connected rig.
I think sticking with 32bit may be the easiest solution for now
Good enough for me to stick with the 32-bit version.
Glad we could sort it out to a working solution.
Perhaps someone else will be helped by our conversation in the future :o)
I saw the last packet without actual data as well but interpreted it as the crash has already started…
Thank you again, and good luck with the develpoment!
I look forward to see a CW server accepting straight key CW with unchanged timing from key to RF if you had any use of my suggested solition earlier. Not your highest priority, I know but I hope for it anyway.
I can now report that the remote server also seam to work to my IC-706 over VPN with audio and all (via a USB soundcard connected to the multi-pin connector on back of radio)
