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?