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/.
Sylvain Munaut 246tnt at gmail.comHi, 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