4 Sep
2015
4 Sep
'15
9:20 a.m.
Hi,
If it was broken for all three I would assume that the
problem was with the gr-osmosdr block. That it works correctly for two programs that use
this block and not correctly for Gnuradio made me suspect that the problem is with
Gnuradio. The ticket I logged ( http://gnuradio.org/redmine/issues/834 ) was closed. They
let me know that my two out of three guess was wrong and that this is an issue with the
gr-osmosdr block, so they kindly pointed me in the direction of this mailing list for
help.
I would try and debug it further but I have left my zone of knowledge to look any
further.
Thanks in advance for any help that you can provide,
There is two way to pilot gains :
- The "named" gain stages that are dynamically exposed at runtime to
the application and that map directly to each available gain stage.
That's what osmocom_fft and gqrx use.
- The "fixed" bb / rf / if gains and the mapping of those to the real
gain stage is hw specific depending on what you can call BB / RF / IF
in that particular architecture.
For the airspy, the mapping was defined to not have any gain mapping
to BB because the airspy doesn't have any "baseband" gain control. RF
gain was mapped to LNA afaict and fixed "IF gain" was mapped to the
named "IF gain". I guess it would be more correct to map the fixed IF
gain to both the named "mix" and "if" gain and auto-split within the
two ... patches welcome.
Now GRC (Gnuradio Companion) can only use the "fixed" ones from its UI
just because the "named" ones are only available at runtime and GRC
doesn't actually _run_ the flowgraph yet when building it, so no way
it can know about the named stages.
If you write your own custom GR app manually (in python or c++) you
can control each gain independently by just using the named gain
controls.
Cheers,
Sylvain