Re: [Hamlib-developer] ft817 memory support

[Marco F. I. <iz3...@gm...>]

On 09/01/2012 13:36, Nate Bargmann wrote:
> * On 2012 09 Jan 03:55 -0600, Derry Hamilton wrote:
>> Hi Tomi,
>> Your recollection agrees with mine.  I've found a link to my old patch and
>> the thread:
>> http://osdir.com/ml/linux.hams.hamlib.devel/2007-10/msg00009.html
>
> Detty, and Tomi, thank you very much for your input on this.  I blithely
> assumed such direct writes were not needed, but as I think of it, I know
> that both of you are correct.
>
> Marco, you may want to look at the CHIRP project:
>
> http://chirp.danplanet.com/
>
> which is aimed at working with rigs that have a clone capability.  I
> don't know if they have tackled anything that has a CAT interface and
> then uses direct memory writes for managing rig memories.  I'm in the
> same boat with the K3 where writing/reading the rig memories is
> apparently a direct EEPROM access operation and not documented.
>
>> Basically, there were several suggestions about how to include it, but I
>> never got round to them,
>> things like "#ifded DANGEROUS_EXPERIMENTAL", or adding a
>> --yes-i-know-this-might-break-my-rig flag.
>
> Ewwww!
>
> Perhaps in the future we could consider working with the CHIRP project
> on some way to make use of their capability in Hamlib.
>
> 73, de Nate>>
>

Hi all ...
memory support means going to the dark side of undocumented commands, 
that's for sure.
BTW the clone protocol also is undocumented as far as I know.

 From my point of view hamlib should be as complete as possible to avoid 
the temptation of building up a new library to support 
"that-feature-i-cant-live-without".
I agree users (of the library) have to be aware that they are going to 
use might-break-my-rig features, one way could be having a function say
void EnableUndocumentedDangerousExperimental();
to call before being able to go on using functions in the dark side.

To a larger extent all cat command, including documented one, to ft817 
are inherently dangerous being exposed to noise errors due to the 
absence of parity and checksum. The same apply to 857 and 897 as well.

Well ... for sure I want to program my rig memories and I'm not going to 
buy any non free sw, in the while we think to have it in hamlib or not 
I'll take a look to clone protocol and chirp itself.

Thanks to all
73 de IZ3GME Marco