Hi Sylvain, many thanks for the feedback. I apologie for the inconvenient about patch format. I used git format-email but seems I did something wrong in the cut&paste. If nobody ask for, I will avoid repost the patch at the current state.
I agree with you on all point but one. I would like to have a way to get gains values as an array of int and expose integers if wanted (maybe by just using an index?) . I can copy values from those measured by Steve of course but there can be a case where a device diverge from those (not linear, bad batch, overtemp etc..)? Since usually we work with dbFS that have nothing to do with dBm or dbuV I think using simple integer is still ok. Still I will try to put things in a way where you can query the gains value choosing between integers and tenth of dB.
I will try to put the new patch down asap but I will be on vacation next week so I'm not sure to be able to finish very soon.
best regards and happy new year Luigi
On 29/12/16 16:45, Sylvain Munaut wrote:
Hi,
First off, thanks for trying to clean this up into a mergeable state !
I can't actually try the patch, it doesn't apply. How did you generate and send the patch to the list ? Make sure to use git-send-email as mail-software will usually mangle the patch and prevent it from being used ...
Comments on the patch itself :
- Doc and API for the top-level functions (exposed one) should be
tuner independent, so you can't reference R820T directly in there, nor can you expect the user to know register values ... that's why API use tenth of dB there and do the mapping in a tuner specific way in the actual tuner driver.
- I'm not a big fan of adding 3 methods to the API ... what happens
when the R820T3 comes out with one more gain stage ? ... And yes, I know there is a "IF" one in there that pretty much matches E4k only, but IMHO that's a mistage. We can't change the past but we can certainly learn from it and avoid repeating it.
So from the API standpoint, I would use the concept of "named" gain stages. You get : - one function to query the available gain stages - one function to query for a given gain stages what gain valuesare possible / valid - one function to set the curent gain value - one function to get the current gain value
This way :
- We could actually cleanup the E4k impl as well and also properly
expose its various gain stages 2) In gr-osmosdr you can also query / register named gain stages at runtime depending on what's really available 3) That API should be fairly future proof.
I didn't really understand the linearity / gain question but IIUC that should be doable without new functions : The meaning of the set_gain_mode existing API could be extended to be a bitfield / flags. ( With the existing defined 0|1 value staying what they are but allowing new ones to be defined). And so you'd have the 0|2 flag to select the preferred gain setting algorithm. then the tuner can store that in its internal state and act appropriately on the next gain setting call.
CC to steve and dimitri, please chime in if you disagree with my view on this :)
Cheers,
Sylvain