29 Dec
2016
29 Dec
'16
5:05 p.m.
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