[chirp_devel] [PATCH] Add import support for Kenwood *.hmk files

Dan Smith
Wed Apr 4 08:01:20 PDT 2012


> I was hoping to inherit CSVRadio, but CSVRadio inherits
> IcomDstarSupport and I don't want that. If I inherit from CSVRadio, is
> there a way to disable the Dstar stuff?

Ah, right. Dang. I wonder what would be involved in making a base CSV
driver that doesn't support D-STAR and then subclassing it for the
actual one that does? I'll take a look.

> Ok, are you saying get_features() is not used during import? I can
> remove it if it's not used.

No, it is, but all the valid_* features are unnecessary. Not a big deal
to leave them in I guess, it just seems confusing to put stuff there
that is not needed.

> In this loop we only have access to one column at a time, so I am
> saving the vars odd_split and tx_freq to a broader scope and making
> the final assignment outside the loop. What exactly are you
> suggesting?

Looking back at your hmk example, it looks like the Tx Freq. column
always contains the transmit frequency, regardless of whether it's an
odd or normal split, and even regardless of the duplex, right? I was
just hoping to avoid the special casing there to allow for more re-use
from the CSV driver, but maybe that isn't as easy.

> I have three example hmk files from three different Kenwood
> programming software and they are all 10 lines. But yes, I think I can
> do better. The header line always starts with !!Ch, so I can look for
> that, back up one line, and send that to the csv reader.

Or maybe just read and parse and keep throwing stuff away until the
first column is !!Ch, to avoid the "going back a line" behavior?

-- 
Dan Smith
www.danplanet.com
KK7DS

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
Url : http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20120404/446bb6eb/attachment-0001.bin 


More information about the chirp_devel mailing list