More gain knobs

[ckuethe]

This changeset exposes osmocom's IF and BB gain settings for people wishing to use this with a hackrf or airspy ... something with multiple gain knobs.

[bistromath]

On the one hand, this compensates for a defect (as I see it) in HackRF's API, which doesn't allow intelligent autoselection of gain parameters. On the other hand, it breaks gr-air-modes for any non-Osmocom device as the other drivers lack calls to set_bb_gain and set_if_gain, so attempting to call them will cause a barf.

If you can think of a way to gracefully detect and cope with the HackRF case, I'm happy to merge it, but I can't merge this. The "right way" is probably to 1) detect that the user is using a HackRF, 2) implement gain binning logic in radio.py to distribute gains appropriately.

[ckuethe]

Hm. I meant to only adjust the osmocom path.

Airspy is another osmocom device that has separate RF/IF/BB gain controls. Unlike hackrf, the gain values are not dB; they're apparently indices into some internal tables

[bistromath]

Another problem is that osmocom doesn't appear to provide a good API to identify the attached device, so any logic that determines how to allocate gain based on specific hardware details can't be implemented outside the driver itself.

On Sun, May 10, 2015 at 4:03 PM, ckuethe notifications@github.com wrote:

Hm. I meant to only adjust the osmocom path.

Airspy is another osmocom device that has separate RF/IF/BB gain controls. Unlike hackrf, the gain values are not dB; they're apparently indices into some internal tables

— Reply to this email directly or view it on GitHub https://github.com/bistromath/gr-air-modes/pull/69#issuecomment-100713704 .

[ckuethe]

I suppose I could abuse the constructor arguments (-D) to pass in hints ("hackrf=0" "airspy=0" etc) on how to distribute the gain. If no device hint is given, just put it all in RF gain and don't even set IF/BB?

[ckuethe]

I'd like to resurrect this diff; osmocom seems handles devices that don't have 3 separate gains. And this doesn't choke when I pass the extra gain knobs to UHD.

[vsboost]

yes please.

[bistromath]

OK, give me a few days to test, if it's harmless I'll merge it in. There's probably going to be some UI arrangements to select auto vs. manual gain.

On Mon, Jun 29, 2015 at 11:08 PM vsboost notifications@github.com wrote:

yes please.

— Reply to this email directly or view it on GitHub https://github.com/bistromath/gr-air-modes/pull/69#issuecomment-116994147 .

[bistromath]

ckuethe, are you familiar with the osmo interface? is there any way at all to pull the underlying device type (RTL, Airspy, HackRF, etc.) from the Osmo driver? it would make it much easier to set device-specific behavior.

--n

On Tue, Jun 30, 2015 at 10:04 AM Nick Foster bistromath@gmail.com wrote:

OK, give me a few days to test, if it's harmless I'll merge it in. There's probably going to be some UI arrangements to select auto vs. manual gain.

On Mon, Jun 29, 2015 at 11:08 PM vsboost notifications@github.com wrote:

yes please.

— Reply to this email directly or view it on GitHub https://github.com/bistromath/gr-air-modes/pull/69#issuecomment-116994147 .

[ckuethe]

I don't see anything in the osmosdr binding that gives us device name. Maybe the get_gain_names() function is useful, but the hardware device selection is not exposed by the API... https://github.com/osmocom/gr-osmosdr/blob/master/include/osmosdr/source.h

On Fri, Jul 10, 2015 at 9:35 AM, bistromath notifications@github.com wrote:

ckuethe, are you familiar with the osmo interface? is there any way at all to pull the underlying device type (RTL, Airspy, HackRF, etc.) from the Osmo driver? it would make it much easier to set device-specific behavior.

--n

On Tue, Jun 30, 2015 at 10:04 AM Nick Foster bistromath@gmail.com wrote:

OK, give me a few days to test, if it's harmless I'll merge it in. There's probably going to be some UI arrangements to select auto vs. manual gain.

On Mon, Jun 29, 2015 at 11:08 PM vsboost notifications@github.com wrote:

yes please.

— Reply to this email directly or view it on GitHub < https://github.com/bistromath/gr-air-modes/pull/69#issuecomment-116994147> .

— Reply to this email directly or view it on GitHub https://github.com/bistromath/gr-air-modes/pull/69#issuecomment-120453696 .

GDB has a 'break' feature; why doesn't it have 'fix' too?

[kpreid]

Things I have learned about osmosdr:

• Once you have the osmosdr source/sink object, you can't tell what type of device it is. (This means that autoselect with args = '' makes it impossible to tell at all, but any use of that could be replaced with device_find.)
• get_gain_names and get_gain_range together let you make a fully generic gain control UI. (If airspy's gain values are not dB as a comment above says, then I would call that a bug in the airspy interface, since source.h explicitly says the values are in dB.)
• There is no accessor that tells you whether AGC is supported, but set_gain_mode nominally tells you whether it succeeded. (Some drivers return true while not implementing AGC, unfortunately.)

[ckuethe]

Are the units of the gain controls relevant? I assert that it is not..

UHD can operate in either normalized or absolute gain mode. Airspy goes from 0-45 but you're not expect to use the whole range ... http://airspy.com/index.php/quickstart/ On Jul 10, 2015 4:37 PM, "Kevin Reid" notifications@github.com wrote:

Things I have learned about osmosdr:

• Once you have the osmosdr source/sink object, you can't tell what type of device it is. (This means that autoselect with args = '' makes it impossible to tell at all, but any use of that could be replaced with device_find.)
• get_gain_names and get_gain_range together let you make a fully generic gain control UI. (If airspy's gain values are not dB as a comment above says, then I would call that a bug in the airspy interface, since source.h explicitly says the values are in dB.)
• There is no accessor that tells you whether AGC is supported, but set_gain_mode nominally tells you whether it succeeded. (Some drivers return true while not implementing AGC, unfortunately.)

— Reply to this email directly or view it on GitHub https://github.com/bistromath/gr-air-modes/pull/69#issuecomment-120550926 .