[RFC PATCH] rtl-sdr: add support for independent gain settings

Luigi Tarenga luigi.tarenga at gmail.com
Thu Dec 29 16:05:05 UTC 2016


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 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 :)
>
> Cheers,
>
>      Sylvain

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20161229/e4f3c901/attachment.html>


More information about the osmocom-sdr mailing list