Icom ic-7200

1

Is these any chance of supporting the ICOM IC-7200? It’s robust construction makes it popular with boaters and outdoor operation.

Mike N2MS

2

we have that model in sight too and we’re aiming to et it to work with such devices.

3

Hi Mike,

I have added preliminary and untested support for the IC-7200. In a few days there should be some builds in our download section that include this change. I’d love to hear how it works.

Thanks,

–E
de W6EL

4

Will test this week.

MIke N2MS

5

It’s up! The 2021-05-16 windows and linux builds have the updated code for the IC-7200.

If, when you run it, the bottom-right corner of the program says “NONE”, then you may need to define the CI-V manually in the preferences. Be sure and match the baud rate on the radio to what you set in the preferences, turn off CI-V echo (if available), and turn on CI-V Transceive.

Let us know what happens!

–E
de W6EL

6

Elliot,

My 7200 is set to default CIV address of 76. CI-V transceive is ON.

The com port is COM6 which I verified via device manager, speed 19200. I manually set the COM6 but WFVIEW does not detect radio

Mike N2MS

7

Hi Mike,

Try manually setting the CI-V and baud rate for wfview. You can find the details here:
https://wfview.org/wfview-user-manual/using-older-radios/
You’ll need to specify SerialPortBaud and RigCIVuInt. I’ll get those controls added to the UI soon as it’s becoming a popular need.

I’m really interested in your feedback on the 7200, as it’s a great radio with many modern features that doesn’t cost an arm and leg. I think it would be really cool to make some remote base stations using an IC-7200 and a Pi with wfview, for example.

If you try the above suggestion – manually modifying the preferences outside of wfview – and you still see “NONE” in the lower-right corner of wfview, then see if you can send me the log file, ideally with debug enabled first.

Thanks,

–E
de W6EL

8

I checked registry setting and spped is incorrect. It should be 19200. How do I set speed?

Mike N2MS

9

Reading the preferences document it may not be in the settings tab at this time. I am leery about changing registry settings,

The 7200 CI-V baud rates are 300, 1200, 4800, 9600, 19200 or Auto.

Mike N2MS

10

Hi Mike,

You have to change the value in the registry on your computer from 115200 to 19200. If CI-V transceive is on, you probably do not need to set the CI-V address in the settings, but if you do, your radio has hex address 0x76, which is entered as 118 in the registry.

Note: Keep the rig at the default baud rate and CI-V address setting. ONLY change the wfview preferences.

Let me know how it goes,

–E

11

Elliot,

I have the default settings.

CIV Baud Auto
CIV Address 76h
CIV Transceive On.

I had to set the speed to 19200 via regedit. I set the wfview com port tp COM6, exited and restarted wfview and it recognizes the IC-7200.

Quick check shows frequency, Transmit, Mode, Preamp and Attenuator work.

I exited program, disconnected 7200, connected 7300 and restarted program. It did not connect to 7300 because registry still show speed of 19200

I would be more comfortable if I could set speed and other parameters via Settings tab, not registry.

Mike N2MS

12

Hi Mike,

Thank you for testing it out!

We will get some kind of rig profile feature going soon for folks with more than one rig.

And I will see about putting baud rate and CIV into the graphical Settings tab – this is what everyone is going to want with an older rig. I may get to that this weekend.

Thank you again,

–E
de W6EL

13

Thanks for the support.

I would like to copy the memories from a spreadsheet or text file to my radios, or to copy7300 memories to the 7200. Are there plans for these features in the future?

Mike N2MS

14

Hi Mike,

This is a feature I want too. We plan to implement access to the rig’s memory in Release 2. For now, we just have very basic frequency storage using the computer and the preferences (and it doesn’t currently understand many things, such as people using more than one rig).

For Relase 2, we will have import and export to CSV file, which you can edit in excel. We’ll also see if we can keep it compatible with the sort of CSV that CHIRP typically makes.

Stay tuned :-). I’m really pleased that it worked with the IC-7200, so you can expect more in terms of support for this rig.

–E
de W6EL

15

I know this is old, but I’ve got a 7200 that I could make available remotely if it would help. I used wfview with it a little before I got my 7300. It mostly worked (v1.1a) but it seemed a little too buggy to be super useful (better with the 7300, of course).

If remote access to a 7200 would help, let me know. Also, @eliggett if there’s some interesting CHIRP integration we could do to avoid wfview having to re-implement memory stuff itself, let me know :slight_smile:

1 Like
16

Hi Dan,

Access to an IC-7200 would be super helpful. Most of the issues are probably going to need to be addressed within the serial interface and the radio polling mechanisms. Do you have a way to do it such that we can update the code remotely? If you’re running a Pi, I can imagine that one could automate a nightly build, kill the existing copy off, and re-run from the build. (Or, you can reply off-list and provide ssh details, that would work too of course.) I regularly access my IC-718, and I really want to get these smaller, simpler radios working remotely – they are very easy to stuff in a rack with a Pi at a remote location, for example.

As for memory management, CHIRP is clearly the champ here! However, CHIRP being written in python and wfview in c++, plus the major differences in architecture, would make this very difficult to connect together at the code level. The level of effort to implement the UI for memory management (a “chart” and then small UI elements to adjust each thing, field validators, etc), would be a lot of work, and you guys have already done it!

The more I think about it, the functionality we have been asked for mostly in wfview is the ability to recall memories. That is, if someone has programmed in many local repeaters and wants to make use of it while using wfview. This is especially the case with the IC-R8600, for which there are not many inexpensive memory management programs, and users often have hundreds of programmed memories (ie, folks using the R8600 as a traditional “scanner”). I could see implementing a memory browser and memory recall feature. But you are correct, re-implementing memory management / organization, which CHIRP really excels at, would be counter-productive.

One thing I could see doing would be working together to make sure the virtual serial port functions between wfview and CHIRP. With this working, one could open both at once and adjust the memory contents using CHIRP, while at the same time using the radio. Besides facilitating a way for the user to enter a virtual serial port (or pseudo-terminal in linux), we would want to look at if CHIRP can contend with unsolicited serial traffic that it could encounter. We can filter out most data unintended for CHIRP by using a separate controller address (which we do right now), but there could be other considerations, as I’m sure you are aware.

In summary, if the programs can operate together well, then wfview really only needs memory recall and browse capability.

Thoughts and ideas?

Thanks!

–Elliott
de W6EL

17

Hi Elliott,

Yeah, for CHIRP integration I was thinking more along the lines of some sort of way to just provide connection details to wfview and use a socket to send/receive CIV as if the radio were directly connected. So, you’d open CHIRP, tell it your connection to the radio is “via wfview” instead of a serial port. I haven’t looked at what that protocol looks like, but I assume the wfview server side is just proxying CV commands to the radio? If so, CHIRP could likely just use its own drivers, but with a socket and maybe a wrapper to filter out opportunistic extraneous messages, proxied through wfview.

I will reach out next week with access details to some sort of machine connected directly to the 7200 and let you have at it.

–Dan

18

Hi Dan,

The virtual serial port mechanism is pretty raw. The client side can just pretend it is a serial port, and in most cases work without any modification. For linux, we use a true pseudo-terminal (“pty”) device. On Windows, that can’t be done without a signed driver (I think), so we use a similar mechanism that seems to be used a lot these days. It’s all covered on this page of our manual:

https://wfview.org/wfview-user-manual/sharing-control/

Usually the big hurdle on the user end is to get the client program to allow the user to freely type in a somewhat unusual serial port name like “/home/elliott/radio-pty” or whatever the user specifies. It looks like the version of CHIRP I have installed here locally allows the user to freely type over the combo selection, so that part is done!

Since CI-V is a multi-point bus protocol, we are able to filter out “packets” of radio information so that other programs won’t see wfview traffic - assuming that the other programs don’t have a hard-coded “from” address of 0xE1, which is what wfview defaults to. Currently we filter out anything that is intended to go to wfview, and we also can filter out “transceive” packets that the radios fire off to everyone, such as the user rotating the dial.

In other words, it might just work as it is. I’ll update my local copy of CHIRP and see if there are profiles for the 7300, 718, or 9700 – those are the rigs I can easily get to and try it.

–E
de W6EL

19

FYI, I downloaded the latest flatpak of CHIRP, and I was able to connect it through the pseudo-terminal via wfview on my linux desktop, and access the IC-7300 in my garage (wfview to wfview connection).

I see about 10-30% failures in reading out the memory. If I turn off the waterfall and change the polling from about 25ms to 200ms, then I can get a clean read about half the time, maybe an error or two in total.

The errors are about timeout issues. I suspect a little flexibility in command timing might fix things up. I can dig deeper later if you like. Here’s a few of the errors I see in the console:

ERROR: ----------------
ERROR: Job Args:   (29,)
ERROR: Job KWArgs: {}
ERROR: Job Called from:
  File "/app/bin/chirpw", line 153, in <module>
    gtk.main()
  File "/app/lib/python2.7/site-packages/chirp/ui/memedit.py", line 1210, in <lambda>
    refresh.connect("clicked", lambda x: self.prefill())
  File "/app/lib/python2.7/site-packages/chirp/ui/memedit.py", line 1069, in prefill
    job = common.RadioJob(handler, "get_memory", i)

ERROR: Exception running RadioJob: Timeout
ERROR: -- Exception: --
ERROR: Traceback (most recent call last):
  File "/app/lib/python2.7/site-packages/chirp/ui/common.py", line 116, in _execute
    result = func(*self.args, **self.kwargs)
  File "/app/lib/python2.7/site-packages/chirp/drivers/icomciv.py", line 482, in get_memory
    f = self._recv_frame(f)
  File "/app/lib/python2.7/site-packages/chirp/drivers/icomciv.py", line 351, in _recv_frame
    frame.read(self.pipe)
  File "/app/lib/python2.7/site-packages/chirp/drivers/icomciv.py", line 189, in read
    raise errors.RadioError("Timeout")
RadioError: Timeout

ERROR: ----------------
ERROR: Job Args:   (47,)
ERROR: Job KWArgs: {}
ERROR: Job Called from:
  File "/app/bin/chirpw", line 153, in <module>
    gtk.main()
  File "/app/lib/python2.7/site-packages/chirp/ui/memedit.py", line 1210, in <lambda>
    refresh.connect("clicked", lambda x: self.prefill())
  File "/app/lib/python2.7/site-packages/chirp/ui/memedit.py", line 1069, in prefill
    job = common.RadioJob(handler, "get_memory", i)

ERROR: Exception running RadioJob: ord() expected a character, but string of length 0 found
ERROR: -- Exception: --
ERROR: Traceback (most recent call last):
  File "/app/lib/python2.7/site-packages/chirp/ui/common.py", line 116, in _execute
    result = func(*self.args, **self.kwargs)
  File "/app/lib/python2.7/site-packages/chirp/drivers/icomciv.py", line 491, in get_memory
    LOG.debug(repr(memobj))
  File "/app/lib/python2.7/site-packages/chirp/bitwise.py", line 638, in __repr__
    s += "  %15s: %s%s" % (prop, repr(self._generators[prop]),
  File "/app/lib/python2.7/site-packages/chirp/bitwise.py", line 181, in __repr__
    return "%i:[(%i)]" % (len(self.__items), int(self))
  File "/app/lib/python2.7/site-packages/chirp/bitwise.py", line 227, in __int__
    tens, ones = i.get_value()
  File "/app/lib/python2.7/site-packages/chirp/bitwise.py", line 157, in get_value
    return self._get_value(value)
  File "/app/lib/python2.7/site-packages/chirp/bitwise.py", line 592, in _get_value
    a = (ord(data) & 0xF0) >> 4
TypeError: ord() expected a character, but string of length 0 found

ERROR: ----------------
ERROR: Job Args:   ('P1',)
ERROR: Job KWArgs: {}
ERROR: Job Called from:
  File "/app/bin/chirpw", line 153, in <module>
    gtk.main()
  File "/app/lib/python2.7/site-packages/chirp/ui/memedit.py", line 1210, in <lambda>
    refresh.connect("clicked", lambda x: self.prefill())
  File "/app/lib/python2.7/site-packages/chirp/ui/memedit.py", line 1076, in prefill
    job = common.RadioJob(handler, "get_memory", i)

Traceback (most recent call last):
  File "/app/lib/python2.7/site-packages/chirp/ui/memedit.py", line 1118, in set_memory
    self._set_memory(iter, memory)
  File "/app/lib/python2.7/site-packages/chirp/ui/memedit.py", line 1101, in _set_memory
    self.col(_("Comment")), memory.comment)
TypeError: value is of the wrong type for this column
20

Yep, I’m already using wfview locally with a virtual serial port for ft8. Mostly works great, except that wsjt-x seems to get out of sync every once in a while and complain, but a retry makes it happy again.

CHIRP definitely lets you choose any port (as you noted), and I’m not surprised there are some timing differences so I can take a look at those. It seems like maybe if wfview had a socket interface as well as the pty type interface that might be easier. Of course on linux and macos, the pty is easy, but on my one windows box (I’m not a windows user) getting the com0com thing in place was a little finicky. If we knew that wfview opens some known tcp port for CIV, then chirp could just probe for and use that instead of requiring people to do any pty or serial loopback work.

Anyway, I’ll definitely look and see if I can stabilize it when using the existing interface and we can go from there.