This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/.
Luigi Tarenga luigi.tarenga at gmail.comHi 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.htm>