I’m just curious about how you all see the utility of wfview and memory locations.
Obviously, a computer has effectively limitless memory for storing frequencies. And using a computer as a source for frequency memory has the advantage that you can pick exactly what parameters to store and recall.
On the other hand, using the radio’s memory is nice for when you are sitting at the radio. This also eliminates issues with wfview having to determine which memory presets are appropriate for which radio (for example, memory locations on an IC-7850 wouldn’t work on an IC-9700, but would on an IC-705…). There also could be advantages to using the radio’s memory with the IC-R8600, which has advanced scanning capabilities that pretty much rely on the memory channels being configured. (As far as I know – I don’t have access to one of these fine radios yet though.)
With either approach, I’m thinking that the next major revision to the memory code will produce and accept a CSV format with the same headers as is used by CHIRP.
I think the master here is “the controller” so wfview.
The reasoning is that if someone else would access the radio, he or she can’t control
the memory content.
To fix the issue where you want to have the rig’s settings, we can add a way to download/import the memory contents of the rig.
Also, if you are administrator (as being defined inthe rig’s settings) we could allow uploading
a new view of the memory settings to the rig.
I do see that the recent version of CHIRP supports the 7300, so for anyone looking to just manage and edit the radio’s memories, that’s a way to do it right now. And given the typical Icom compatibility, it would not surprise me if it works on other recent Icom rigs.
Yes, I think this is what we’ll aim for. It’ll actually be easier to start with this approach since it is defined very clearly in the documentation. Once that works, then we can explore other options. Hopefully each rig isn’t too different…
Hi Elliot,
Has there been any progress on a csv approach to memory presets? Manually entering repeaters and beacons for the IC9700 is painful when you’re entering many different offsets and tone/DTCS access frequencies.
73s
VK5COV
we havn’t set a target date yet. It’s a major change that happened and while it’s exciting, we don’t want to make people sad because xx worked and with the new version it is broken.
So even if we release teststuff – much testing is needed on all kind of rigs. Unluckily that does not always
bring us bug reports.
There are lots of changes; it will have dual scope with controls. It will have detached windows for bands, input freq, settigngs. An updated rgctld, and one of the really interesting things is that it has a rig-editor. Each rig supported will have a separate definition file that is used to define capabilities, commands. It has a memory editor yes.
This will make adding a new rig easier – create a rig definition file and it should work.
Some of the rigs we do have, 7300, 705, 785x, 7610, 905, 9700. Some we don’t.
The guts really are ripped apart; we don’t even changed the version internally yet for this.