[RFC PATCH] rtl-sdr: add support for independent gain settings
luigi.tarenga at gmail.com
Thu Dec 29 16:05:05 UTC 2016
many thanks for the feedback. I apologie for the inconvenient about
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
as an array of int and expose integers if wanted (maybe by just using an
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
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
On 29/12/16 16:45, Sylvain Munaut wrote:
> 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 values
> are possible / valid
> - one function to set the curent gain value
> - one function to get the current gain value
> This way :
> 1) 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the osmocom-sdr