At first I thought the LNA was dead, as checking it on the bench with GQRX showed no results (even though I can measure 4.7v from the dongle when I “switch” the bias-t on using the command shown in the second link above. So I opened the LNA and hooked up a 4.5V power supply, and it works just dandy in GQRX!
So I turned on the Bias-t via the software switch, and while it was on and producting 4.7V, I opened GQRX. As soon as GQRX opened a connection to the dongle, the bias-t turned off. I suspect this is what is happening in my UHF station that I was testing this LNA in. Does anybody know how to keep the bias-t turned on when I launch GQRX? And even better, is there a way to get the satnogs client to switch it on and off before and after an observation? I was using the software commands in the pre/post observation script - but the observations were showing no active signal amplification so I think maybe when satnogs accesses the RTL-SDR it just switches off the bias-t just like GQRX?
Yeah, this unfortunate topic has been beaten to death over and over again on the gqrx mailing list…
I think the bias tee is switched off when the dongle is re-initialized by another software. Unfortunately, the only way to control the bias-tee in the gr-osmosdr backend is through the device string and that is why there is no easy control for it in gqrx. You can change your device string to:
rtl=0,bias=1
Note that there must be no spaces in the device string.
It is most likely the same issue with SatNOGS as gr-satnogs also uses gr-osmosdr as backend. Not sure where to edit the device string, though…
I would trace the SDR type from the config file all the way to the device string in gr-satnogs. Perhaps you can simply add bias=1 in the config file… I’m too busy right now to do it, sorry.
Update: got the setup updated and even with the RF gain in satnogs set to max (49.6 or something like that), I am still getting result worse than what I would see with no LNA at all (consistent with the loss associated with a non-functioning LNA, I guess).
I haven’t had a chance to check voltage at the dongle, though. I’ll get to that tonight.
Just a quick note, more gain can lead to less signal.
Try turning the gain down to between 7 and 15.
(I find it best to use a program like SDR# to view the waterfall of a local signal (either a 2m or 70cm repeater - depending on your antenna) and then adjust the gain and see the signal peak and watch the noise floor. This value then is what you put into SatNOGS advanced settings for RF gain).
Recently tracked down the issue with why satnogs-client and activating the bias-T on the RTL-SDR blog v3 receiver works-but-doesn’t.
The current version of GNU Radio that the Ansible scripts install is exactly 0.0.1 point revision older than required to support the bias-T. This is because it depends on a version of gr-osmosdr just before support was added for the feature, which in turn depends on a slightly-too-old version of librtlsdr that exposes the API / ABI for controlling the GPIO pins (which enables the bias-T LDO regulator).
Adding bias=1 to SATNOGS_DEV_ARGS is indeed the correct way to activate the bias-T on that receiver, except that the version is slightly too old wherein the option is ignored. Worse receive performance is then simply because the LNA is not powered at all and attenuating the signal instead
Pretty much any upgrade to satnogs-client-ansible that bumps the GNU Radio dependency will also cause the bias-T option to work as advertised. Moving the Raspberry Pi image to buster is sufficient for this to happen – a task that is being worked on already most likely. Enabling bias-T use without additional hardware is an important enabler for lowering the expertise required to setup a decent-performance GS.
The short term fix is to re-compile the dependency chain of gnuradio <-- gr-osmosdr <-- librtlsdr. I ran out of steam and time before writing down the specific version numbers required for this that are still compatible with the released version of gr-satnogs and plays well with satnogs-client-ansible. If/when I do this, how-to details will get posted in the forums.
After upgrading to the Buster satnogs image, it seems as though I can turn on the bias-t via the dev args above. However it appears that the bias-t will not turn off after the observation. I’m going to attempt to turn it off using a post-observation script.
As an update - the LNA doesn’t seem to be doing anything. I’ve been making observations all day long slowly upping the RTLSDR’s rf gain and I’m up to over 40db, and my results still look the same (started from 0). I believe I may have blown out the LNA when I was bench testing it on a 5v power supply last week. I’m going to leave it on overnight and then check it on the bench tomorrow to confirm that it is functioning. In other news, I hoped to use the RTL-SDR.com software to turn the bias-t off (using the post-observation script), however when I went to “cmake” the software, I got the following error: LibUSB 1.0 required to compile rtl-sdr
I’m hoping this isn’t some kind of circular error…
Just tried this on a Pi 4 with the buster image on #979, attached the big antennas of #834, observation 1012324. FOX-1A is not a great sat to listen to for such tests, so no receive comparisons were possible…
Can confirm the bias-T is activated and not turned off automatically. The LNA was a cheap SPF5189-based unit, modified by shorting the output capacitor.
Dan, thanks for the help. I just performed an experiment using the /full-path-here/rtl_biast -b 0 post-observation script and it does indeed turn the bias-t off. Just checked the following observation and the bias-t is back on, so it looks like we have a working bias-t!
I believe the “weak” noise at the extremes of the observation are when the RTLSDR wasn’t hooked up to any coax at all. The completely silent bands that are towards the inside of those are where the multimeter was hooked up to the SDR (I didn’t have any means of tapping the center conductor without breaking the coax connection), and then the normal middle band is with the RTLSDR connected to the antenna as normal.
Like I said, I’m pretty sure the LNA is non-functional at this point. I’ll check it tomorrow.
I think I’ll still climb up in the attic one more time to bench test it, but I think maybe it is working. Note that the current “RF Gain” setting is over 40, so I’m really scratching my head.
[edit] Just bench tested the LNA - it’s working just fine. I guess “garbage in - garbage out”. I need to move this antenna out of the attic.
I just added this to the wiki yesterday, and to my knowledge nobody has tried to do with these instructions. Please feel free to edit as necessary (or let me know if there should be changes).
I wasn’t sure where to put these instructions, and this location looked as good as any other. Mods should move if they feel it is better off somewhere else.
Thanks for that @K3RLD … unfortunately after following that, I am still getting blue waterfalls and not even seeing anything. That indicates to me that the bias T is not enabling!
No, that is NOT what it means. The waterfall colors are automatically set based on the total range of received signals. So if you receive nothing but background noise, the color of the waterfall is not likely to change at all.
Can you post observations both before and after the installation of the LNA?
