Hi all -
The roadmap mentions
" * Memory management (of the rig’s memories, similar to CHIRP)"
Under the planned January 2022 release. Did that get implemented? I’m not seeing how to do it with my IC-7100.
If not available yet, I’d vote for memory recall as the first priority. I can set the memories with chirp. But, switching to a repeater frequency (with offset and tone) is cumbersome without memory recall.
– Jeff, N0JUH
I appreciate your enthusiasm. What you have to remember is that we’ve got a lot of irons in the fire. There are lots of important features being worked on, plus dramatic changes to the way the program works inside (which are generally transparent to the user). wfview is an open source project maintained by people with jobs, families, and other interests, so you have to understand that there really isn’t much of a road map (despite one being on our website). We’ll work on things as they come up or as we feel inspired.
You can monitor all the changes being made on gitlab, for example, on our branches page. Or check out the commits on our creator-widgets branch for some exciting action.
Do note that about two months ago an entirely new memory manager was added in the “creator-widgets” branch. This is the feature you’re asking about.
You can probably expect to see this feature (memory management) in the next major release of wfview. In the mean time, don’t forget that things like repeater offsets and PL tones can be changed already within wfview. And you can of course plug a radio in to your computer and use CHIRP – many of the HF Icom rigs are supported actually. See our manual for details on repeater settings.
Thanks for the update!
I was trying not to sound like an impatient, demanding newbie - I’m sorry if it came off that way!
It’s always hard to find one’s bearings in a new project. I couldn’t find an update on that particular feature, so I broke down and asked. Thanks to the pointer on the creator widgets, I’ll give that a look, and maybe try building it.
It’s all good, I should have updated that roadmap page long ago anyway.
In terms of an API, I assume you are wanting to script communication with the radio?
There are a few ways to do it. The simplest method is to use wfview’s built-in rigctld-compatible server. This is a plaintext protocol that you can interface with quite easily. Here’s an example (not excellent code, but you’ll see the idea) where I kept two radios tuned together. One radio was using wfview, the other was gqrx (rtl-sdr). You can see all the rigctld commands if you do
man rigctld on a linux system (or google it). The commands are super simple and the radio is well-abstracted from the user – rigctl commands are not different for different radios, although the available features are of course.
There’s also the virtual serial port for sending raw serial traffic to the radio. You can use this for scripting as well, especially if you need a feature we have not implemented in wfview. On linux, the pseudo terminal device can be accessed just as easily as a regular serial port. Sometimes serial traffic can get pretty wild, so try and use the rigctld-compatible server as much as you can.
Will one of those interfaces work for you, or did you want to script things within wfview itself?