Project

General

Profile

Actions

Feature #10283

closed

Free-form power level entry for CSV

Added by C H about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
01/17/2023
Due date:
% Done:

100%

Estimated time:
Chirp Version:
next (py3)
Model affected:
Uv-5r
I read the instructions above:

Description

When it comes to the new feature of the power level being present in a csv sheet the results aren't exactly as I imagined although perhaps it is according to your development model.

I imagined setting the legal limits on all of the frequencies in a csv and copying and pasting the list to different radios and the configs basically set themselves for power level.

Just an imaginary example for testing not any real legal limits or frequencies
lets say uv-5r has
high 4w
low 1w
ch1 has a power level of 2w set in the csv

What I imagine is that when you copy ch1 into the radio img from the csv, since 4w is higher than 2w that means you would need to automatically drop to the low power to stay under the limit set in csv but this is not what happens,

in testing what happens is when I copy a 2w channel to a 4/1w radio it sets the power to high(which on the radio is 4w), in my opinion it should set the power to low(1w) since that radios setting on high(4w) will exceed 2w(limit set in csv).

Also I think there should be a .5w setting because of the top of my head at least certain frs channels still have a .5w limit, vhf marine is 25w, and some bus star dot are 35w, and 2m / 70cm is 1500. Could this field just be user configurable for all the different scenarios?

Anyways if this was not your vision for how it should work or if there are more technical issues present preventing sich behavior I understand but I just figured I would give some constructive feedback.

Actions #1

Updated by Dan Smith about 1 year ago

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.

Actions #2

Updated by C H about 1 year ago

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?

Actions #3

Updated by Dan Smith about 1 year ago

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.

Actions #4

Updated by C H about 1 year ago

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?

Actions #5

Updated by Dan Smith about 1 year ago

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.

Actions #6

Updated by Dan Smith about 1 year ago

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

Actions #7

Updated by C H about 1 year ago

Yes I can test from source

Actions #8

Updated by C H about 1 year ago

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

Actions #9

Updated by Dan Smith about 1 year ago

  • Tracker changed from Bug to Feature
  • Subject changed from Power level copy from csv to img behavior not as expected to Free-form power level entry for CSV
  • Status changed from New to In Progress
  • Assignee set to Dan Smith
  • Target version set to chirp-py3
  • Platform deleted (Windows)

Okay, I'll expect some feedback in the morning then :)

https://github.com/kk7ds/chirp/pull/407

Actions #10

Updated by C H about 1 year ago

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.

Actions #11

Updated by Dan Smith about 1 year ago

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.

Actions #12

Updated by C H about 1 year ago

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

Actions #13

Updated by C H about 1 year ago

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.

Actions #14

Updated by Dan Smith about 1 year ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF