Wfview not operational with IC-736

1

I’ve had a quick look through the Topics, and see that this has been mentioned before, but I’ve not seen if there is a resolution.

Hardware/Software is:

Windows 10 Pro
Icom IC-736
Icom Com/CI-V Interface – (Not USB) on the PC’s true physical COM 1 Port (9600/8/1/N Int 4)
IC-736 CI-V set to 9600 Address 40H Data Bit 5 (although have tried with 4)
PTT is set to RTS on COM1

All other software works fine JS8Call/WSJT-X/HRD etc etc. I have ensured that none of these Programs are running when attempting to use WFView – even to doing a full reboot after making changes in WFView.

Tried with WFView 1.1 - COM1 - 9600 - 40 - however there is no “Use as Model” Menu Item. Rig Unrecognised.

Tried with WFView 1.2c - COM1 - 9600 - 40 - however there is no “Use as Model” Menu Item Rig Unrecognised.

Tried with WFView 1.2d (Beta) - COM1 - 9600 - 40 - “Use as Model” Menu Item is present and selected. Rig Recognised (shows IC-736 at the bottom of the display), PTT works, but that’s all folks!

I’m fairly certain that I’ve covered everything obvious, but maybe there is someone out there with a working 736/738???

Thanks for any help

Peter Knight

2

Hi Peter,

Definitely stick with the default radio settings all around at first before experimenting too much. Only the latest versions of wfview have IC-736 support. You need to really make sure the CI-V address is the default address on the radio and that this address is in wfview, with the “use as model” menu item checked. Get that all set up and press “Save Settings”, then re-launch wfview, just to make sure. Also make sure that CI-V Transceive is turned ON with the radio. This is on by default but you should make sure it wasn’t turned off by some other program, for example.

PTT will work even without proper radio comms because it just toggles a line. So it’s a good step!

Try rotating the tuning dial on the radio once you connect. wfview works asynchronously and will pick up on the CI-V traffic that the radio automatically spits out when there are changes at the rig.

Also make sure that no other radio control programs are running at the same time as wfview. There are ways to run multiple at once, but start with just wfview open.

Let me know if that helps,

–E
de W6EL

3

Also, you may want to try one of our weekly builds:
public

Just drop the exe right into the same folder as your existing (and somewhat functional) wfview.exe.

We haven’t made a major update in a few weeks, but the weekly builds are pretty good usually.

–E
de W6EL

4

Hi Elliott,

Thanks for your time in looking at this problem. I realise that the IC-736 is old technology, and there will be very few owners out there wanting Remote Control; however Wfview looks as if it would be a perfect solution to use instead of HRD/Commander, which are a bit overkill.

As I said in my initial Post, the 736 runs perfectly under other software. The only “default” setting on the rig that has ever been changed was the Baud Rate, changed from 1200 to 9600.

As per your suggestion, I have downloaded the latest weekly Update and popped that into the Program Files Folder, and run that. The User Interface is now so much cleaner!

However, still no Rig Control……. There is a clue though – which I mentioned in my Post. I am using the “real” legacy hardware COM Port (9p Sub-D) on an HP ProDesk PC, and your software says “Serial (USB)” Port. Is that a possibility?

Thanks again,

73 de Peter G6EPN

5

Hi Peter,

I have an IC-736, and it does work pretty well. The control is limited a bit by the command set, but it’s just fine for a casual remote QSO or listening to the bands.

The “USB” name was just a clue as many people might not think a radio with a USB port is really a serial port emulated over USB. wfview doesn’t know or care. What do you see in the menu? Does it show the correct serial port?

If you can send us the log file that may help a lot. Open wfview, try to operate the radio, and then close it, and then send the (fresh) log file.

Here is how to access the log file:

https://wfview.org/wfview-user-manual/log-file/

–E
de W6EL

6

Hi Elliott,

I’m working away from base today, quickly ran the Program and trying a few Controls, then opened the Log:

PS C:\Users\Peter> Get-Content $env:TEMP\wfview.log -Wait -Tail 30 2022-03-09 07:31:42.067 INF system: “wfview version: 1.2d (Git:440429b on Mar 7 2022 at 03:00:53 by build@wfview.org)\nOperating System: Windows 10 Version 2009 (i386)\nBuild Qt Version 5.15.2. Current Qt Version: 5.15.2\n”
2022-03-09 07:31:42.867 INF default: setState 1
2022-03-09 07:31:42.868 INF default: setState 0
2022-03-09 07:31:42.868 INF default: setState 1
2022-03-09 07:31:43.468 INF system: Loading settings from “\HKEY_CURRENT_USER\Software\wfview\wfview”
2022-03-09 07:31:43.509 INF gui: Got Audio Output: “SignaLink Output (2- USB Audio CODEC )”
2022-03-09 07:31:43.509 INF gui: Got Audio Input: “”
2022-03-09 07:31:43.509 INF gui: Got Server Audio Input: “”
2022-03-09 07:31:43.509 INF gui: Got Server Audio Output: “”
2022-03-09 07:31:43.596 INF system: Cannot prepare WF view without rigCaps. Waiting on this.
2022-03-09 07:31:43.599 INF serial: Opened port: “COM1”
2022-03-09 07:31:43.653 INF system: Received CommReady!!
2022-03-09 07:31:43.653 INF system: Delay command interval timing: 75 ms
2022-03-09 07:31:43.653 INF system: Skipping automatic CIV, using user-supplied value of 64
2022-03-09 07:31:43.653 INF system: Skipping Rig ID query, using user-supplied model from CI-V address: 64
2022-03-09 07:31:43.653 INF rig: Sending rig ID to: (int) 64
2022-03-09 07:31:43.653 INF rig: Using incomingCIVAddr: (int): 64 hex: 40
2022-03-09 07:31:43.653 INF serial: Received rigCapabilities for “IC-736”
2022-03-09 07:31:43.653 INF default: Setting rig state for wfmain
2022-03-09 07:31:43.659 INF system: Delay command interval timing: 75 ms

I will try again later today in the “Debug” Mode

Thanks for your help

73 de Perter G6EPN

7

Hi Peter,

Everything in the log looks quite normal. A debug log is a good idea. I would also say, make sure CI-V transceive is enabled on the radio, and give the tuning dial a twist while wfview is open. See if the log file shows the traffic from that. If it does not show this kind of traffic, then a more fundamental issue could be happening, such as:

Serial port resource conflict (other programs running that you don’t intend)
Wrong baud rate (try some others)
Other odd CI-V menu setting on the 736… set things to their default value when in doubt.

Menu item and recommended settings:

  • 12: 40H
  • 13: 1200 (but ultimately, you want this at 9600)
  • 14: CI-trn ON
  • 15: CI-731 mode: OFF

–E
de W6EL

8

Hi Elliott,

I can confirm the IC-736 Menu Settings are as you recommend, excepting Baud Rate was 9600, which I have changed to 1200 as a further test. Obviously, I changed the Baud Rate to 1200 in WFView as well.

Still no joy, I’m afraid!

The Legacy Com 1 Port has never had anything but the Icom IC-736 connected, leaving the usual Windows Port Settings in-place 9600/8/1/N FIFOs enabled etc etc.

There are no Programs Starting at Boot Time that would use Com 1, nor any Services that would use Com 1.

I have an identical machine - unused, running a virgin Win 10 install. I installed WFView on this machine, and hooked the 736 to the Com 1 Port on it - and exactly the same problem. Debug looks like this:

PS C:\Users\Peter.PHASORNET> Get-Content $env:TEMP\wfview.log -Wait -Tail 30

2022-03-10 15:05:25.422 DBG rig: ----- End hex dump -----

2022-03-10 15:05:30.327 DBG rig: Final payload in rig commander to be sent to rig:

2022-03-10 15:05:30.327 DBG rig: ---- Begin hex dump -----:

2022-03-10 15:05:30.327 DBG rig: "INDEX: 00 01 02 03 04 05 "

2022-03-10 15:05:30.327 DBG rig: "DATA: fe fe 40 e1 11 fd "

2022-03-10 15:05:30.327 DBG rig: ----- End hex dump -----

2022-03-10 15:05:35.206 DBG rig: Final payload in rig commander to be sent to rig:

2022-03-10 15:05:35.206 DBG rig: ---- Begin hex dump -----:

2022-03-10 15:05:35.206 DBG rig: "INDEX: 00 01 02 03 04 05 06 "

2022-03-10 15:05:35.206 DBG rig: "DATA: fe fe 40 e1 1c 00 fd "

2022-03-10 15:05:35.206 DBG rig: ----- End hex dump -----

2022-03-10 15:05:35.206 DBG serial: ---- Begin hex dump -----:

2022-03-10 15:05:35.206 DBG serial: "INDEX: 00 01 02 03 04 05 06 07 "

2022-03-10 15:05:35.206 DBG serial: "DATA: fe fe e1 40 1c 00 00 fd "

2022-03-10 15:05:35.206 DBG serial: ----- End hex dump -----

2022-03-10 15:05:35.206 DBG rig: ---- Begin hex dump -----:

2022-03-10 15:05:35.206 DBG rig: "INDEX: 00 01 02 03 "

2022-03-10 15:05:35.206 DBG rig: "DATA: 1c 00 00 fd "

2022-03-10 15:05:35.206 DBG rig: ----- End hex dump -----

2022-03-10 15:05:39.083 DBG rig: Final payload in rig commander to be sent to rig:

2022-03-10 15:05:39.083 DBG rig: ---- Begin hex dump -----:

2022-03-10 15:05:39.083 DBG rig: "INDEX: 00 01 02 03 04 05 06 07 08 09 10 "

2022-03-10 15:05:39.083 DBG rig: "DATA: fe fe 40 e1 00 00 68 20 14 00 fd "

2022-03-10 15:05:39.083 DBG rig: ----- End hex dump -----

2022-03-10 15:05:40.056 DBG rig: Final payload in rig commander to be sent to rig:

2022-03-10 15:05:40.056 DBG rig: ---- Begin hex dump -----:

2022-03-10 15:05:40.056 DBG rig: "INDEX: 00 01 02 03 04 05 06 07 08 09 10 "

2022-03-10 15:05:40.056 DBG rig: "DATA: fe fe 40 e1 00 00 55 21 14 00 fd "

2022-03-10 15:05:40.056 DBG rig: ----- End hex dump -----

2022-03-10 15:05:41.929 DBG rig: Closing rig comms

The only thing I can think of is the Icom CT17 Serial to CI-V Converter. However, it’s been operating fine for 20+ years, with many differing Programs, and is just a MAX232 and 5 Volt regulator!

I cannot think of anything else. If I get time one weekend, I’ll knock-up another RS232 – CIV converter as see how that fares. I’ll also try a FTDI USB- COM Adapter, although ultimately I have run out of free COM Ports and would prefer to leave the 736 on Com 1. (If it’s not broke, don’t fix it).

Thanks for all your help – I think that we have run-out of all other options – but I will keep the Forum informed if I find a solution, and/or the results of any further tests.

Regards and best 73

de Peter G6E

9

Hi Peter,

You may be the first person using wfview with a genuine Icom CI-V to Serial adapter, so I suppose there could be something to it? It seems like, as you said, it should be quite transparent.

I see traffic from the radio in that debug log, I believe. Did you try spinning the tuning knob during the test? (I don’t see it.)

Keep in mind if you change the baud rate in wfview, you will need to press “Disconnect” and then press “Connect” again. Or for the most safe route, press “Save Settings”, close wfview, and re-open. More recent betas should be ok without reopening, but I like to start it fresh whenever I have any uncertainty about things.

I’m using an xggcomms USB to CI-V (and isolated audio, PTT) adapter for my IC-736 and IC-718, and I have only tested these radios using linux, although I think some other folks on this forum have tested these or similar radios using windows.

–E
de W6EL

10

Hi Peter.

I noticed on your original log that you have the CI-V address entered within wfview? You are generally best to leave this as auto and enable CI-V transceive on the rig as I have found the auto-detection can be unreliable if a manual address is entered.

2022-03-09 07:31:43.653 INF system: Skipping Rig ID query, using user-supplied model from CI-V address: 64
2022-03-09 07:31:43.653 INF rig: Sending rig ID to: (int) 64
2022-03-09 07:31:43.653 INF rig: Using incomingCIVAddr: (int): 64 hex: 40

73 Phil M0VSE

11

Hi Phil,

I think for the 736, it lacks a proper Rig ID response, so we have to specify it manually. But for all (or most) other rigs, I agree, leave it on auto.

–E
de W6EL

12

Hi Elliott (and Phil),

Phil - the CI-V Address needs to be specified for the 736, as does the “Use as Model”…….

Yes, Elliott, I have been using “Save Settings”, then “Disconnect”, the Exit the Program and Restart. I have even rebooted the PC at times “just in case”.

I am now testing with my “spare” HP ProDesk – it has a clean Win 10 install, and no other Programs/Apps excepting WFView and FLDigi (to ensure that all is well when using FLDigi).

I did notice in the CT-17 Service manual that Pins 11/12 (TX/RX) of the MAX232 are connected together. Apparently this is a bit of a “No-No”, and other designs using the MAX232 have buffer components. The MAX232 has a limited “sink” current, and if 11/12 are directly connected – it can sometimes not produce enough drive to the Rig. This tends to happen if the Rig CI-V Receive transistor is of low gain – or if the Rig is being used in very cold conditions.

However, my 736 is in a warm environment, and has never suffered any problems with other software……

The CT-17 gets its power from the 736 – 13.8 V on the Aux Socket. Just as a check, I have tested using an External 13.8 V PSU……. Still no joy.

The next thing I’ve investigated was the fact that the CT-17 has no PTT circuitry taken from the RTS Line. The CT-17 has an RS232 25 Pin D Connector, so I made a 9 Pin to 25 Pin Cable, and fitted the PTT circuitry inside the 25 Pin Shell (plenty of room), with a cable coming out to the 736 Aux Socket PTT.

Just in case that may be a factor – I replaced the cable with a ready made 9P to 25P – FLDigi works fine, but still no joy from WFView (but obviously no PTT). I’ve noticed that PowerShell can be left running with the Log File open, so it’s possible to monitor the Log File “live”. Whenever I spin the Tuning Dial, or make any other changes (e.g., Band Change, Direct freq Entry), then the Log File gets another two Lines of data, so things seem to be alive – but the 736 stubbornly refuses.

I’ve spotted a rather elegant Com to CI-V design on the Net, which I may have a bash at building, as it includes a Sound Card, which would save me swapping over leads to a SignaLink. Everything in one box…… The MAX 232 I/P and O/P and PTT Line are isolated using Opto Couplers for complete isolation.

It might be a while before I can Breadboard it – but keep watching this space!

Thanks for your help Elliott; it is appreciated, and to anyone else who has any ideas!. Incidentally, I installed the USB Drivers for a IC-705 and tried WFView on that – and that works perfectly, so it’s not a dodgy App install!

Regards and best 73

de Peter G6EPN

13

Hi Peter,

If fldigi is working, then wfview should. I wouldn’t question the adapter much seeing as how one program is working. (I too find it odd that they connected those two pins directly together…)

Can you send a log with the dial spinning?

What does wfview say in the lower-right corner? IC-736?

–E
de W6EL

14

Hi Elliott, and thanks again for your time. Yes, it does show as IC-736, and “Found Radio at address 40H…” when hitting “Disconnect/Connect”. However, I think I may have found the problem. I opened up the CT-17, and the circuit is a little different to the Service Manual. This CT-17 is a later model - there is an extra IC connected to further pins on the Com Port.

As I looked, my little grey cells remembered a similar problem years ago, with a customer’s Kenwood Serial Interface - it would work with some software and not others.

I expect that you remember many Com Port RTTY and Wefax “Decoders” years ago used the DCD Line to detect if there was anything connected to the Dongle, and DTR/CTS/DSR Lines to power the Op Amp that was used as the “Decoder”. Some had DIP Switches to switch which Line was being used as Power. Some just put in series diodes in each Line with a large smoothing C after.

This was the problem with the Kenwood Serial Interface - although it was powered by external 13.8 V, it needed to see a High on one of the other Control Lines - which caused the MAX232 to “Enable”.

It looks like the CT-17 Mk 2 needs to see a High on the DTR Line (or any of the DTR/CTS/DSR Lines) which then Connects the RX Input to the MAX232. I believe this was done to stop people from making their own Serial Interfaces.

If I am correct, then does WFView enable the DTR Line? And if not, I would imagine that all that is needed is a further “Button” (or three) to say “Use DTR Line to Enable Interface”. (I say “All that is needed”, in the knowledge that it may not be that easy!)

Any thoughts?

Regards and best 73

de Peter G6EPN

15

I do not think that this was done to stop people from making their own serial interface. A genuine RS-232 interface
should always honour the state of the hardware handshake lines. But many newer interfaces just ignore them or use them
for purposes they never were specified for (for example as PTT-Line).

73
Uli DF7SC

16

Maybe it supports hardware handshaking? That would be something new for sure. Hmm. I’ll pull up the info and see what I can figure out.

17

Hi Elliott,

I popped an RS Line Tester onto the COM1 Port connected to the CT-17 232/TTL Interface. It’s a RS232/422 hardware/software analyser. After Windows Boot and COM Port initialisation, all Lines go Low, except RX/TX which stay mid-state - “Off”. All as expected.

On running WSJT-X or FLDigi - both already set for an Icom 736 on COM1, the DTR Line goes High - as per the software settings. The TX/RX Data Lines twinkle away, and I have full Rig CAT control. On Exiting WSJT-X or FLDigi, both, quite correctly, re-initialise the COM Port (normally 9600/8/1/N, Handshaking Lines - Low).

As I predicted, WFView leaves the Handshaking Lines “as is”, and with many Serial Adapters wanting one of more of the Handshaking Lines High, there will be some, or no, control over the Rig (see later).

The TX Line twinkles every 400mS, with random flashes on the RX Line, and no Rig CAT Control. Within the Analyser software I can toggle DTR “High” - and then WFView immediately starts to operate correctly - regular TX/RX every 400mS and full CAT control over the Rig - including the Read-Back of the Frequency. The Icom CT-17 therefore does need DTR “High”, even though there is no technical reason or requirement for this.

I say some, or no, control, of some Interfaces - depending on the design of the Interface. Some, such as “Dongles” - which are still made and are for sale today, use the DTR or RTS as a Power Source. In this case, without DTR (or RTS) “High”, the Dongle just doesn’t work (excepting perhaps for a separate PTT from RTS or DTR).

Looking back at my notes of 1991, the original Kenwood Interface uses the DTR Line to “Enable” a NE555 used to derive a Neg Power Line. Without DTR “High”, the Interface fails to work. Once correctly powered, the Interface then toggles the DSR Line “High” to tell the software that a genuine Kenwood Interface was connected. The Kenwood Service Manual does not show the DTR/DSR connections, but does mention that the Interface “will only work with their Control software”.

The Icom CT-17 uses the DTR Line to Enable the MAX232 RX Data Line - without this there are very erratic results from the Rig - or nothing at all. Again, not a technical requirement, and this circuitry is not shown in the Service Manual.

Remember, the CI-V Protocol is a Single Wire (bi-directional) Model, and with some configurations TX Data may be “echoed” - which can cause confusion when an Interface is not operating correctly. TX Data can be confused as RX Data, where control software can interpret things as operating correctly.

Many people consider that RS232 and 422 have had their day, and are old-fashioned technology. “USB is the only way forward”, they cry. But look at all the Amateur Radio Forums (“Fora”?) with comments such as: “My CAT Comms fail when I transmit”, and: “Why can’t I buy a USB Cable more than 1.8m long?”. Then there is the price of decent toroids to wrap your USB cables around, or sourcing decent screened USB Cables. And the price of USB Opto-Isolators to remove ground loops.

MIL Spec RS232/RS422 with IP Rated lockable Connectors are still in-vogue, with double screened cables with separate Signal Ground and Earth… No stray RF problems there!

A further off-topic comment - "Why did the Makers produce Interfaces that don’t technically require Handshaking Lines to go “High”, but have done so, and then don’t show that in the Service Manuals? Money of course… Back then you needed to buy both the Interface and the software. And look at Icom now, with the RA-BA1 software at over £100 (or $100), Win4Icom at half that cost, and WFView, very generously available at no cost to us. Thanks Elliott!

Anyway, what I envisage in a later version of WFView is some Buttons along the lines of WSJT-X. Two buttons: “DTR State” and “RTS State” , of which none, either, or both can be toggled to “High”. Then: “PTT requires RTS or DTR”, with corresponding RTS and DTR Buttons. If DTR has been set to “High”, then only “RTS PTT” can be enabled, and conversely, if RTS has been set “High” then only DTR can be enabled. (otherwise the Rig may transmit when you fire-up WFView…)

As I said earlier RS232 usage my have waned, but it is still used, and as WFView gets more popular, I can envisage this problem occurring more frequently, and being able to select the Handshaking Lines should cover 99.9% of Serial Interfaces without hardware modifications.

Thanks again to all, and to Elliott,

Regards and best 73

de Peter G6EPN

18

Just as a quick addition before I get cries of “USB is fantastic”. I did write the above very much “tongue in cheek”! I have an IC-705 (which I love) and really like the fact that the single USB Port can achieve CI-V on Port A, “other” use on Port B (NMEA GPS…), and a full Sound Card… Compare that with the FDM Duo (which I own and dislike) needing three separate USB Ports to achieve nearly the same functions. And the KX3 (which I love) which needs a FDTI Serial Interface and a separate Sound Card. Horses for Courses, and along the way RS232 still fills a need…

73 all, de Peter G6EPN

19

You could always improvise a local handshaking dongle, similar to what we do with null modem cables.

I’ll look at the serial lines. I was hesitant to dive deep into it since every UI element takes a good bit of time to code, let alone the back-end code, and this is the first I’ve heard of needing more flexibility there. But that said, it’s a genuine Icom adapter! The one in the owner’s manual! We should try and support it.

I use the xggcoms USB adapter (the one with isolated audio and PTT with CI-V) for my usage of older radios. For testing on the bench, where I don’t need the audio, I usually use an inexpensive ($7) eBay adapter. It sits there connected to my 2010 Core 2 Duo iMac with Linux Mint. I’m cheap, believe me. And if it had an RS-232 port, I’d have built an adapter for CI-V likely.

–E
de W6EL

20

Hi Elliott, and thanks again for your time. I do understand that coding takes time and effort, and that currently the need to add Power/Enable on Handshaking Lines is limited. However, I would suggest that WFView will become even more popular if you begin supporting other Manufacturers Transceivers and Receivers, when you will definitely come across this problem more often.

The problem will occur with:

  • Earlier Serial-TTL Interfaces (Kenwood/Icom) that have an “Enable” function needing the DTR or RTS Line being held “High”.
  • Serial-TTL, and Serial-RS232 “Dongles” that are powered via the DTR and/or the RTS Line. There are dozens of differing types on sale out there, so there is obviously a need for them!

N.B. It appears the early Yaesu FIF232 Interface is OK, as it looks like both RTS or DTR are “reserved” solely for PTT purposes.

During my tests, I was using a Hardware/Software RS232 Analyser, where the Hardware RS232 “through” Adapter is powered from a +/- 15 Volt PSU. It has Green (+) and Red (-) LEDs on each Line, 'Scope Test Points, and DIP Switches to apply + or - to the Handshaking Lines. The software looks after the Port Settings and does the data analysis. Using the DIP Switches, it’s easy to set any of the Handshaking Lines to High, Low or Off, and see the results.

Of course, the RS232 25 Pin and 9 Pin “D” standard does not include any Power, so it isn’t that easy to make a Handshaking Dongle, as you recommend. It is actually easier to modify the Interface to set DTR “High”. I have not tried this yet, but I would guess that using the internal +5V or the 13.8V supply would work, as RS232 High is OK from +5 to +15 V. It would need popping a couple of diodes into the existing DTR Line in the Dongle, and from the Supply, just to keep things isolated.

I also have a “Siskin Multi-Cat” Interface that works with Icom, Yaesu, Kenwood and AOR Transceivers and Receivers. It dates from the mid 90’s and I remember Phil Bridges G6DLJ (Siskin) saying that they sold over 2500 of them. I have the instructions for it, but no Circuit Diagram, and have contacted Phil - but if anyone else out there has a diagram, it would be appreciated.

Perhaps ultimately between us we could produce a List of Interfaces that work, Interfaces that don’t, and mods to get them to work? It would benefit the operations of these Interfaces with other software too…

Regards and 73

de Peter G6EPN