CHIRP

Thanks for circling back, it's far too common that we implement something and never hear back about its suitability.

The delta between what you expect, what I expect, and what fits the model in chirp is one of the reasons I've been putting this off for a long time :)

First, your example points out a bug that I will fix, which is that pasting a 2W memory into a 1/4W radio should choose the 1W setting not 4W. The intent is to choose the closest power level in the destination radio. I think the reason this is happening is because we store power levels internally in dBm and choosing the "closest" in a log scale is not what a human wants or expects. I think this will also solve your FRS problem without the need for a 0.5W setting because 1W will match 0.5W in a radio constrained as such.

Your desire to have your channels configured as "legal limit" is interesting and I hadn't thought about that. The problem is, like everything else with software that tries to bridge between incompatible devices, is that will yield the wrong behavior in other cases. Consider the Icom IC-2300H. This (and its brethren before it) has always been a bit strange in that it has a 5, 10, 25, 65W power setting. The Yaesu FT-2900 is similar and has an even larger delta between its highest and next power levels (75W and 30W). If you copy a memory from a 50W radio (which is very common) to it and we consider the source power level as the limit, we'd have to choose the 25W or 30W level in the destination radio. That's right for your limit case, but I'd wager it's not what most people (especially hams) want - they want "high power here means high power there."

In terms of the proliferation of power levels, the situation is a little less dire, but also not trivial. The radio model in chirp exposes discrete power levels like (most) radios and the UI expects this as well. So the CSV driver has to support something similar to play along. I could:

1. Make the CSV driver augment its list when loading a CSV file, adding any power levels it finds along the way. This would let you hand-enter a power level, but you couldn't edit it in the spreadsheet until you had loaded one with the thing you want. This is also problematic because we expect to be able to get the features of the radio driver before it has loaded, which means this could be flaky.
2. Implement a new feature that says "this radio has variable power from X to Y" and have the spreadsheet let you enter them as integers instead of choices. It sounds like this is more of what you want, but it's not a thing that exists and cuts through a bunch of layers.

Even still, unless the limit logic is in place, I think that if you need 25W to represent a VHF Marine channel, 25W will select the 30W (instead of the 5W) option in a 5/30W radio just like 20W will. Right? Or is there also an element of "documentation" here, such that having a sheet of channels with not-quite-the-limit values is unsightly?

For what it's worth, I chose the current list of power options by surveying (via script) all the power levels exposed in the current set of drivers, coming up with a reasonably rounded set of options that would cover everything we currently support. The "closest level" bug mentioned above aside, the current list should be pretty comprehensive.

I am kind of OCD and a data hoarder. I was hoping for my csv to be more of a reference to pull from with precise info. I suppose I can manually add the numbers I want to the csvgeneric driver as I go along and this wont create issues?

Yeah, for the moment if you add values to the POWER_LEVELS_WATTS it will create new power levels that you can choose. Your CSVs should still be readable by other people, it will just choose the closest value in their list at load time.

I do like option 1 and 2 though...

But I know this is a rabbit hole

My only problem with manual edits is that if I update chirp and forget to load my csvdriver then all my hard work on manually entering values in my csv is erased if I open and save.

Could there be a 2nd driver option for user configured values or something I can do to prevent this?

Not easily, the drivers are insulated from config specifically to prevent config-driven driver behavior, which for almost everything else makes no sense and would be a source of bugs.

I'll investigate how bad it is (and how much of what I just did has to get thrown away) to make option 2 above a thing. The more I think about it, I really don't want to do option 1.

Are you able to test directly from source if I give you a github branch?

Yes I can test from source

But it will be close to 2am est time likely before I can get to a computer

I just thought of one more thing. What happens if you set power to 0W in generic csv and copy paste to radio img.

This might be useful for setting up a generic csv file containing info about repeaters that one could not legally transmit on that you still wish to retain the offset data for reference purposes on the generic csv file but when you copy/paste the data to a radio img it could set it the duplex to off so transmitting would be disabled.

Just a thought for making things more useful. I know I have asked a lot and its already a great program even before these features and has great devs behind it. Thanks again. Will test soon.

We already have something that means this, it's duplex=off. Since duplex means "what do I do when I transmit", "off" fits fairly well.

I think I wasnt articulate enough in that thought.

Duplex=off is great for the radio img and how i have my "scanner" freqs setup

But in the generic csv reference file when duplex is set to off then you lose the information about any offsets for repeaters.

So I was wondering if there was a way to set the generic csv to Power=0w and when copied to a radio img that channel automatically sets duplex=off in the radio img file but preserves the repeater offset data in the generic csv reference file.

Its easy enough to proofread and manually set but it would be a neat feature in my opinion

It appeared to function more closely to what I expected, I was able to modify the values to whatever I wanted in my csv and they copied over to my img with the expected power levels. Thank you fpr taking the time to make this happen. I also saw the comments on img looked like it is in the works as well. Definitely looking forward to the time all of these changes gets merged.