Memory: Kenwood R-5000


lynx@...
 


-------- Original Message --------

Subject: Memory: Kenwood R-5000
Date: 2021-07-15 18:59
From: lynx@...
To: DXLab@groups.io



When looking into Commander's capabilities, it said that it had 100 memories in 10 banks (10x10). This coincides with the memory on-board the R-5000 and, it seemed sensible and intuitive that Commander could be used to easily upload up to 100 memory location's worth of settings from a Text or CSV-type of file, to the memory of my Kenwood R-5000 with just a few key strokes. That task having been done, one would not always need the connection to a computer and to use Commander ---- one could simply make use of the on-board memories.

This was desirable, particularly during mobile and emergency operations when carrying and putting additional reliance on a PC isn't sensible.

Perhaps I am missing something, but this very desirable function seems to be lacking. I can change the frequency and VFO (A vs B) and mode (FM, AM...etc). Perhaps someone can explain what, if anything, I am missing here.

Mike G



Dave AA6YQ
 

+ AA6YQ comments below

When looking into Commander's capabilities, it said that it had 100 memories in 10 banks (10x10). This coincides with the memory on-board the R-5000 and, it seemed sensible and intuitive that Commander could be used to easily upload up to 100 memory location's worth of settings from a Text or CSV-type of file, to the memory of my Kenwood R-5000 with just a few key strokes. That task having been done, one would not always need the connection to a computer and to use Commander ---- one could simply make use of the on-board memories.

This was desirable, particularly during mobile and emergency operations when carrying and putting additional reliance on a PC isn't sensible.

Perhaps I am missing something, but this very desirable function seems to be lacking. I can change the frequency and VFO (A vs B) and mode (FM, AM...etc). Perhaps someone can explain what, if anything, I am missing here.

+ Commander provides 10 banks of 10 memories for all supported transceivers; these memories remain accessible when Commander is switched from one primary transceiver to another. These capability rule out relying on the memories that some transceivers provide.

+ Most DXers do not use files that specify large numbers of frequencies, as shortwave listeners might do. They save frequencies on an ad hoc basis, e.g. for a sked or a net or to be able to monitor a frequency on which needed DX is may appear.

+ DXLab users all have computers, and most run Commander to control their transceivers and provide the other DXLab applications with access to the transceiver. Being able to use a transceiver without a computer is not useful.

+ In summary, what you characterize as a "very desirable function" isn't, at least for most DXLab users.

           73,

                   Dave, AA6YQ

 


lynx@...
 

Thanks, I now feel that I have been squarely Put in My Place. Perhaps it is not a "very desirable" feature iff 1) you measure desirability by popularity, and 2) if you are only considering 'working DX' from a base-station that has plenty of workspace and 3) your trusty tower-of-power computer is right there, plugged into the wall outlet.

But, that is not the case for someone operating emergency-service comms from a remote location with NO mains power; possibly also a shortfall of fuel to run an AC generator 24/7.

Why not have the capability of writing to the on-board memory of the transceiver or receiver? That write-to functionality is inherent in the R-5000 and (without recourse to the specifications of other receivers / transceivers...), I suspect it's true of many other radios.



Dave AA6YQ
 

+ AA6YQ comments below

Thanks, I now feel that I have been squarely Put in My Place. Perhaps it is not a "very desirable" feature iff 1) you measure desirability by popularity

+ I measure it by value to DXLab's target users

and 2) if you are only considering 'working DX' from a base-station that has plenty of workspace

+ That's what most DXers do.

and 3) your trusty tower-of-power computer is right there, plugged into the wall outlet

+ That's what most DXers do.

.But, that is not the case for someone operating emergency-service comms from a remote location with NO mains power; possibly also a shortfall of fuel to run an AC generator 24/7.

+ That's not what most DXers do, or what the DXLab Suite aims to support.

Why not have the capability of writing to the on-board memory of the transceiver or receiver?

+ Because the time spent implementing it would be time not spent implementing far more valuable new capabilities; in product management, this concept is referred to as "opportunity cost".

That write-to functionality is inherent in the R-5000 and (without recourse to the specifications of other receivers / transceivers...), I suspect it's true of many other radios.

+ It's true of some but certainly not all radios.  Worse, Elecraft, FlexRadio, Icom, Kenwood, TenTec, and Yaesu all implement memories differently, and thus unique code is required for each approach (and testing, and documentation). Commander provides memories for all transceivers, whether they provide "hardware support" or not. And those memories remain accessible when the user switches from one primary transceiver to another.

+ You are proposing that a large amount of time be spent building, testing, and documenting something that is inferior to what's already provided to support a usage scenario (no computer, emergency service) that is far outside DXLab's target: Dxers primary, and general operators secondarily.

+ DXLab explicitly does not target contesting. It also does not target emergency communications.

+ If you're seeking transceiver control for emergency communications, DXLab is the wrong choice.

         73,

                 Dave, AA6YQ


Dave AA6YQ
 

+ AA6YQ comments below
I now feel that I have been squarely Put in My Place
+ No, your suggestion has been put in its place. .

      73,

             Dave, AA6YQ