Wfview and memory locations

Hi All,

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.

Anyway, let me know your thoughts.

Thanks,

–E
de W6EL

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 think this is the most flexible way.

ps – admin control is not implemented yet.

R.

Agreed on all points.

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.

–E

Hi Elliot,

Thanks for your response.

I’d really just like to be able to access and use the existing rig memories with wfview, at least for now.

Bill

Hi Bill,

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…

–E
de W6EL

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

This feature is in my development branch, but this is NOT ready for general use as many other features do not work yet.

1 Like

Thanks Phil, I look forward to the improvements. When do you expect to release the memory and other updates?

Kind regards
Peter Juett
Unit 385/36 Hillier Rd.,
Hillier SA 5116
0418802049
pjuett@adam.com.au

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.

Hi Roland,
Do you get different reports from different platforms? Or are the bugs typically common across all platforms?

Kind regards
Peter Juett
Unit 385/36 Hillier Rd.,
Hillier SA 5116
0418802049
pjuett@adam.com.au

we haven’t released any testversions yet.

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.