Hi,
I recently found my dongle with the FC0012 again after having lost it for a
couple of years, and noticed the tuner wasn't detecting on recent builds
(by recent, it looks like at least a year and a half ago. :) )
There were a few other posts around that I saw with the same issue so I dug
into the problem a bit. It looks it was a behavioural regression in commit
ba64a7459a43652354990855176a7d8dad5b9d54
which was a actually bugfix in the GPIO direction setting code (see below
for the commit comment). The bugfix patch references
http://lea.hamradio.si/~s57uuu/mischam/rtlsdr/ports.html which
The reason this regressed the FC0012 tuner support is that in tuner
detection code, before the probe for the FC00012 there are a few lines:
/* initialise GPIOs */
rtlsdr_set_gpio_output(dev, 5);
/* reset tuner before probing */
rtlsdr_set_gpio_bit(dev, 5, 1);
rtlsdr_set_gpio_bit(dev, 5, 0);
Looking at one of the early (ugly) patches I wrote trying to get the FC0012
working, This is the original code before cleaned up:
https://gist.github.com/dbasden/2171926#file-rtlsdr-fc0012-diff-L123 :
+ if (tuner_type == TUNER_FC0012) {
+ dump_rtl_regs();
+ DEBUGF("reset fs0012 tuner... ");
+ /* the fs0012 has it's RESET line hooked up to GPIO5
+ *
+ * If we don't set GPIO5 to an output and leave it floating,
+ * the tuner never comes up (just stays in RESET state)
+ *
+ * GPIO6 controls the V/U band filter, so we should set that
+ * to an output too
+ */
+ r = rtl_read_reg(SYSB, GPD, 1);
+ r &= (~(0x30)); rtl_write_reg(SYSB, GPO, r, 1);
+ r = rtl_read_reg(SYSB, GPOE, 1);
+ r |= 0x30; rtl_write_reg(SYSB, GPOE, r, 1);
+
+ /* Do reset */
+ rtl_set_gpio_bit(5,1);
+ rtl_set_gpio_bit(5,0);
+ dump_rtl_regs();
+ }
This code was eventually abstracted out to The bug in the code above
described in http://lea.hamradio.si/~s57uuu/mischam/rtlsdr/ports.html,
linked to in the commit log of the ba64a7459a43652354990855176a7d8dad5b9d54
fixing the same bug.
The code was cleaned up eventually abstracted into rtl_sdr_set_output(),
which had the same typo as my original code: I wrote back the GPD register
to GPO. This accidentally worked enough to fix the specific case I was
wanting (to stop the RESET line of the FC0012 floating), but didn't
actually write to the GPIO direction register.
Looking at some of the forum posts, and checking myself, if the older code
runs once, the tuner will be just fine until the dongle loses power. Then
as GPIO5 is not set up into a state for the FC0012 to be happy, it will not
come up again. This seems to have made the problem harder to debug (I
don't know if I would have not known where to look if I had not already hit
the problem when originally porting the driver)
Digging through some more just now (I really don't have a great dev
environment right now, and nothing to probe the hardware itself easily
available), I checked the state of GPD, GPO and GPOE before the tuner
probing, at it looks like the only real side effect from the code above
being buggy would be to set bit 1<<4 low. calling rtl_set_gpio_bit(4,0)
brought up the FC0012 tuner. Re-reading the old and new code, it looks like
it's an off-by-one error in GPIO numbering:
* The original code set GPOE on 0x30, which is (1<<4) | (1<<5).
* These are referred to in the code above as "GPIO5" as the FC0012 RESET
line and
"GPIO6" as the V/U band filter control.
* rtlsdr_set_gpio_output(5) and rtl_set_gpio_bit(5,0) are switching the
V/U band filter, not the RESET line for the FC0012
Sorry, I don't have access to the datasheet for the RTL, so I'm not sure if
bit 0 is GPIO0 or GPIO1. In any case, it looks like the solution is to
just fix the off-by-one error in the FC0012 probe code. I'll post a patch.
Thanks,
David
(commit for bugfix where fc0012 tuner regressed.)
commit ba64a7459a43652354990855176a7d8dad5b9d54
Author: Lucas Teske <lucas(a)teske.net.br>
Date: Wed Aug 17 20:31:33 2016 -0300
lib: fix direction bit in GPIO code
source: http://lea.hamradio.si/~s57uuu/mischam/rtlsdr/ports.html
* Removed unnecessary comment of old code.
Signed-off-by: Fabian P. Schmidt <kerel-fs(a)gmx.de>
Signed-off-by: Steve Markgraf <steve(a)steve-m.de>
:040000 040000 12c5ea73db04c45699d7befa2c5916ae074a1999
2d08166fe31338f5ff90186272b40bc6ed3254fa M src
(HEAD) davidb@grey:~/Personal/sdr/rtl-sdr$
Hi,
I think my messages are getting filtered, but on the chance that someone is
reading these as unmoderated, the fix for the FC0012 is to set GPIO 4 to 0.
It could be that GPIO4 is the RST, or that it is something else entirely.
Looking through the code, and the state of the registers on startup, one
of the surprisingly few side effects of writing GPD to GPO would be to set
GPIO4 to 0. Multiple bugs working together made the whole thing work.
David
Hi,
I recently found my dongle with the FC0012 again after having lost it for a
couple of years, and noticed the tuner wasn't detecting on recent builds
(by recent, it looks like at least a year and a half ago. :) )
There were a few other posts around that I saw with the same issue so I dug
into the problem a bit. It looks it was a behavioural regression in
commit ba64a7459a43652354990855176a7d8dad5b9d54
which was a actually bugfix in the GPIO direction setting code (see below
for the commit comment). The bugfix patch references
http://lea.hamradio.si/~s57uuu/mischam/rtlsdr/ports.html which
The reason this regressed the FC0012 tuner support is that in tuner
detection code, before the probe for the FC00012 there are a few lines:
/* initialise GPIOs */
rtlsdr_set_gpio_output(dev, 5);
/* reset tuner before probing */
rtlsdr_set_gpio_bit(dev, 5, 1);
rtlsdr_set_gpio_bit(dev, 5, 0);
Looking at one of the early (ugly) patches I wrote trying to get the FC0012
working, This is the original code before cleaned up:
https://gist.github.com/dbasden/2171926#file-rtlsdr-fc0012-diff-L123 :
+ if (tuner_type == TUNER_FC0012) {
+ dump_rtl_regs();
+ DEBUGF("reset fs0012 tuner... ");
+ /* the fs0012 has it's RESET line hooked up to GPIO5
+ *
+ * If we don't set GPIO5 to an output and leave it floating,
+ * the tuner never comes up (just stays in RESET state)
+ *
+ * GPIO6 controls the V/U band filter, so we should set that
+ * to an output too
+ */
+ r = rtl_read_reg(SYSB, GPD, 1);
+ r &= (~(0x30)); rtl_write_reg(SYSB, GPO, r, 1);
+ r = rtl_read_reg(SYSB, GPOE, 1);
+ r |= 0x30; rtl_write_reg(SYSB, GPOE, r, 1);
+
+ /* Do reset */
+ rtl_set_gpio_bit(5,1);
+ rtl_set_gpio_bit(5,0);
+ dump_rtl_regs();
+ }
This code was eventually abstracted out to The bug in the code above
described in http://lea.hamradio.si/~s57uuu/mischam/rtlsdr/ports.html,
linked to in the commit log of the ba64a7459a43652354990855176a7d8dad5b9d54
fixing the same bug.
The code was cleaned up eventually abstracted into rtl_sdr_set_output(),
which had the same typo as my original code: I wrote back the GPD register
to GPO. This accidentally worked enough to fix the specific case I was
wanting (to stop the RESET line of the FC0012 floating), but didn't
actually write to the GPIO direction register.
This is as far as I've gotten so far. I don't really have a good setup
right now for debugging much further right this moment, but I at least know
where the problem is. I don't have a copy of the RTL datasheet, or easy
access to anything to measure the levels on that line, but assuming that
the bugfix is the correct behaviour, and the buggy code is undefined
behaviour, it's quite possible that I've managed to get the GPIO5 into a
state just enough to get keep the FC0012 out of reset.
Looking at some of the forum posts, and checking myself, if the older code
runs once, the tuner will be just fine until the dongle loses power. Then
as GPIO5 is not set up into a state for the FC0012 to be happy, it will not
come up again. This seems to have made the problem harder to debug (I
don't know if I would have not known where to look if I had not already hit
the problem when originally porting the driver)
Flipping the gpio bits the other direction is not working, so I'm going to
have to look at it further, but I figured I should at least post to say
where the bug was even if I haven't gotten a solution yet.
If I'm missing anything obvious there, please let me know
Thanks,
David
(commit for bugfix where fc0012 tuner regressed.)
commit ba64a7459a43652354990855176a7d8dad5b9d54
Author: Lucas Teske <lucas(a)teske.net.br>
Date: Wed Aug 17 20:31:33 2016 -0300
lib: fix direction bit in GPIO code
source: http://lea.hamradio.si/~s57uuu/mischam/rtlsdr/ports.html
* Removed unnecessary comment of old code.
Signed-off-by: Fabian P. Schmidt <kerel-fs(a)gmx.de>
Signed-off-by: Steve Markgraf <steve(a)steve-m.de>
:040000 040000 12c5ea73db04c45699d7befa2c5916ae074a1999
2d08166fe31338f5ff90186272b40bc6ed3254fa M src
(HEAD) davidb@grey:~/Personal/sdr/rtl-sdr$
Here is a PyBOMBS recipe file that pulls gr-osmosdr from my sdrplay2
branch. If anyone would like to try out this support with a PyBOMBS build,
this would be the easiest way. Best to build everything from scratch, but
you can remove the src/gr-osmosdr directory, do a pybombs fetch/rebuild if
you're comfortable with that.
The SDRplay SDK v2.11 is required, and should be installed before
gr-osmosdr is rebuilt. The ENABLE_NONFREE flag is turned on for this build.
This is just for testing, so I can get some feedback. Hopefully, this will
go into the gr-osmosdr master at some point. It "works for me".
Note that the gains on SDRplay are actually attenuations, so they appear
backward. The LNA attenuation steps on RSPs are frequency dependent, so I
gave up trying to make them look like gains. My main use case is GQRX, and
that way was even more confusing.
There is a GRC sdrplay source that is a little less generic than the
osmocom source.
There are probably ways to repackage this so it can be distributed freely,
but I'll address that if there's more interest. The SDK include file is
redistributable and its terms seem to be compatible with GPL. The shared
object can be dynamically loaded over a placeholder library that does
nothing. Yes, that's hackish and it would be better to have everything free.
SDRplay support, rewritten, supporting RSP1, RSP1A, and RSP2
Requires ENABLE_NONFREE=yes. Requires SDRplay's SDK v2.11 to be installed
by the user. In the future, if there is a way to redistribute
mirsdrapi-rsp.h from the SDK, that problem could be addressed using a shim
library that looks for /usr/local/lib/libmirsdrapi-rsp.so at runtime.