Responses inline.

On Apr 24, 2014, at 8:33 AM, Tom Hayward - esarfl@gmail.com wrote:

On Thu, Apr 24, 2014 at 8:15 AM, chirp.cordless@xoxy.net wrote:

...

Tom,

Thanks for the agreement on the direction, and I'll be happy to implement any way that makes sense.

The import_logic function _import_tone() isn't setting rtone to 88.5, it's setting it it to ctone, which csv import set to 88.5 because there isn't any such column in the csv, and then because the CSV pseudo radio is defined as having both rtone and ctone:

Let me try to understand this a little more thoroughly. Correct me if any of the following is not true.

• The logic you are suggesting already exists in import logic

No, that's not the case. The current import_logic is what's actually breaking it, although I don't think it needs to change.

The current import_logic code sets rtone = ctone if tmode is TSQL, without any concern that rtone is a user-suppled value and ctone is an 88.5 default supplied by csv import because there is no cToneFreq column.

• Import logic doesn't help in your case because you have an out-of-spec CSV

If there were a cToneFreq column, import_logic would be a no-op, which would not so much 'help it' as 'not break it'. I think it would actually save the day here if cToneFreq were present but rToneFreq wasn't.

Where'd you get a CSV without all the Chirp columns? (just curious)

I created a spreadsheet in Libre Office with the memories I want to load in my radio, and saved as csv. The column heading values were obtained by exporting something from Chirp some time ago. Recognizing that for me, and Id expect 90+% of users, there is no utility, just cruft, in having separate rToneFreq and cToneFreq columns, making my speadsheet wider and harder to maintain etc., I just left cToneFreq out. It worked fine until I wanted TSQL.

I also leave out URCALL,RPT1CALL,RPT2CALL and a few others. It's great that Chirp provides an extensible input method that handles a lot of user's requirements, but smart defaults make for a good user interface.

We already have lots of support for interpreting various differences in CSV. I don't see how supporting more oddities (like a missing column) is a problem--go for it!

I'll take that as a go-ahead. Bug and patch coming, probably later today if I can get to it.

I wonder if there is a better way to handle this. Like, if a CSV file is detected as to not be the standard format, maybe we pipe it through import logic so we don't have to essentially duplicate those rules in the CSV driver.

Again, import_logic doesn't fix this problem, it actually triggers it. I think it's actually doing what it's supposed to be doing.

Imagine someone with a radio with separate rtone/ctone importing to a radio like my FT-60 that only has one, with a TSQL channel. That, and the reverse, is what _import_tone() in import_logic.py is there to handle, and nothing else.

Now suppose that one of the defined memories uses TSQL, rtone = 107.2, and ctone = 88.5 (deliberately). The existing code sets rtone = ctone. I assume that that's what's wanted, since that's how it's coded.

How can this piece of code tell the difference between this case with a real radio, and mine with a CSV pseudo-radio? Why should it?

IMO, the place to recognize a "missing column oddity" in a csv file is the csv import. The csv import code is already handling the case of the missing column, just sub-optimally.

-dan