The original commit fixes configuring the direction of the GPIO pins on the 2832 so it actually works. The FC0012 failure is probably a side-effect of the direction bits now really being set. The tuner initialization does this: rtlsdr_set_gpio_output(dev, 5); /* should set GPIO 5 to output mode, but actually does not touch the direction bits and instead turns on GPIO output 5 */ rtlsdr_set_gpio_bit(dev, 5, 1); /* turns on GPIO 5 output */ rtlsdr_set_gpio_bit(dev, 5, 0); /* turns off GPIO 5 output */ I don't know the reset state of the 2832 offhand but assuming GPIO 5 is not set as an output on reset, then that tuner reset was doing nothing much before the GPIO fix. Maybe the FC0012 takes a while to settle after a reset, so when it really gets reset the detection immediately afterwards fails. You could try commenting out those three lines and see if anything changes. Oliver On 27 October 2017 at 18:13, Marcus Müller <mueller@kit.edu> wrote:

Hi Sylvain,

I'd love to, but I honestly don't even have the symptom (whatever that is) of what this commit fixes. Admittedly, I'd assume myself that maybe I just haven't looked hard enough for a symptom, but if you'd have insight on what the fact that the register was wrong effects, then I'd be thankful!

I really just observe that this commit breaks something, and that I haven't been able to find out what out fixes :(

Cheers Marcus

On 27 October 2017 6:09:18 PM GMT+02:00, Sylvain Munaut <246tnt@gmail.com> wrote:

...

That commit might break something but it still looks like the right thing to do. This is just a symptom of another underlying problem. Find that problem and fix it.

On Fri, Oct 27, 2017 at 5:03 PM, Marcus Müller <mueller@kit.edu> wrote:

...

This reverts commit ba64a7459a43652354990855176a7d8dad5b9d54.

The mentioned commit leads to nonfunctionality of Fitipower FC0012 dongles (tested by a small horde of students) and doesn't increase functionality on my "RTL-SDR.com" branded R820T-based dongle. --- src/librtlsdr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/librtlsdr.c b/src/librtlsdr.c index b369a5d..6c079a5 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -570,7 +570,7 @@ void rtlsdr_set_gpio_output(rtlsdr_dev_t *dev, uint8_t gpio) gpio = 1 << gpio;

r = rtlsdr_read_reg(dev, SYSB, GPD, 1); - rtlsdr_write_reg(dev, SYSB, GPD, r & ~gpio, 1); + rtlsdr_write_reg(dev, SYSB, GPO, r & ~gpio, 1); r = rtlsdr_read_reg(dev, SYSB, GPOE, 1); rtlsdr_write_reg(dev, SYSB, GPOE, r | gpio, 1); } -- 2.13.6

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

On Fri, 27 Oct 2017, Oliver Jowett wrote:

The original commit fixes configuring the direction of the GPIO pins on the 2832 so it actually works. The FC0012 failure is probably a side-effect of the direction bits now really being set.

Hi, I ran into the same issue with my RTL dongle with FC0012 tuner (0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T). After some poking around I think the reason for the tuner not being found is that the tuner reset (or, perhaps, just power) pin is connect to GPIO 4, not to GPIO 5 as the code assumes. Making the following change makes rtl_test find the tuner for me: diff --git a/src/librtlsdr.c b/src/librtlsdr.c index b369a5d..4fb2128 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1565,11 +1565,11 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) } /* initialise GPIOs */ - rtlsdr_set_gpio_output(dev, 5); + rtlsdr_set_gpio_output(dev, 4); /* reset tuner before probing */ - rtlsdr_set_gpio_bit(dev, 5, 1); - rtlsdr_set_gpio_bit(dev, 5, 0); + rtlsdr_set_gpio_bit(dev, 4, 1); + rtlsdr_set_gpio_bit(dev, 4, 0); reg = rtlsdr_i2c_read_reg(dev, FC2580_I2C_ADDR, FC2580_CHECK_ADDR); if ((reg & 0x7f) == FC2580_CHECK_VAL) {

The tuner initialization does this:

rtlsdr_set_gpio_output(dev, 5); /* should set GPIO 5 to output mode, but actually does not touch the direction bits and instead turns on GPIO output 5 */

It did more than that: it also sets all other GPIO outputs to 0. If tuner reset is connect to GPIO 4 with 1 meaning reset and 0 normal operation, this brings the tuner from reset. I added some traces and I see the values after plugging in the tuner, just after the call rtlsdr_set_i2c_repeater(dev, 1) in rtlsdr_open, are: GPD = 0x06 GPOE = 0x19 GPO = 0x18 so in my understanding initially: * GPIOs 1 and 2 are set to INPUT * GPIOs 0, 3 and 4 are set to OUTPUT * output GPIOs 3 and 4 are set to 1, GPIO 0 is set to 0 With the code before the GPIO fix (ba64a745) the call rtlsdr_set_gpio_output(dev, 5) read GPD and set its value to GPO while dropping the 5-th bit from the GPD value. So it assigs the value 6 to GPO. This sets all output GPIOs to 0: GPIOs 3 and 4 are dropped to 0. Then it sets GPOE to the previous value of GPOE plus the 5th bit, so it sets GPIO 5 to output and its output value is 0 because of the previous write.

rtlsdr_set_gpio_bit(dev, 5, 1); /* turns on GPIO 5 output */ rtlsdr_set_gpio_bit(dev, 5, 0); /* turns off GPIO 5 output */

In my understanding this then did the expected: it toggled GPIO 5.

I don't know the reset state of the 2832 offhand but assuming GPIO 5 is not set as an output on reset, then that tuner reset was doing nothing much before the GPIO fix.

I think the rtlsdr_write_reg(dev, SYSB, GPOE, r | gpio, 1) did set GPIO 5 to output. But it's quite possible I got lost in trying to follow this.

Maybe the FC0012 takes a while to settle after a reset, so when it really gets reset the detection immediately afterwards fails. You could try commenting out those three lines and see if anything changes.

I tried both commenting out the GPIO direction + toggle and I also tried adding a sleep after the set of GPIO 5 to 0 and still the tuner is not found. I don't know where does the value 5 come from. Is it possible some other dongles have the tuner at GPIO 5? Or is it really supposed to be GPIO 4 and it worked with 5 by accident - by pulling GPIO 4 to 0 accidentally? A friend of mine looked at the PCB of the dongle I'm using and he found out that GPIO 4 seems to be connected - via a transistor - to the TC0012. GPIO 5 didn't seem to be connected - at least not in an obvious way - to the tuner. I have to say this was just a quick look, so we could have missed things. Also, as there's a transistor in between... could it be that GPIO 4 is not really tuner reset, but tuner power? But this would be rather philosophical point. Either way, from my tests, GPIO 4 has to be set to 0 for the tuner to be reachable. Should I send a patch that changes the tuner GPIO from 5 to 4? Or do you see a better way of solving this? Best regards, David