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