From zub at linux.fjfi.cvut.cz Tue Nov 7 18:38:21 2017 From: zub at linux.fjfi.cvut.cz (David Kozub) Date: Tue, 7 Nov 2017 19:38:21 +0100 (CET) Subject: [PATCH] Revert "lib: fix direction bit in GPIO code" In-Reply-To: References: <20171027150300.20176-1-mueller@kit.edu> Message-ID: 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 From oliver.jowett at gmail.com Tue Nov 7 20:38:42 2017 From: oliver.jowett at gmail.com (Oliver Jowett) Date: Tue, 7 Nov 2017 20:38:42 +0000 Subject: [PATCH] Revert "lib: fix direction bit in GPIO code" In-Reply-To: References: <20171027150300.20176-1-mueller@kit.edu> Message-ID: (Caveat: I don't have a FC0012 and I'm mostly guessing at the meaning of the GPIO registers here..) On 7 November 2017 at 18:38, David Kozub wrote: > 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 > I read those values as: GPD ("direction"): pins 1,2 inputs, others outputs GPO ("output"): outputs 3,4 high, others low GPOE ("output enable"): output drivers for pins 0,3,4 enabled i.e. pin 0: driven low pin 1, pin 2: inputs pin 3: driven high pin 4: driven high pin 5, pin 6, pin 7: high impedance > 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. So now we have: pin 0: driven low pin 1, pin 2: inputs pin 3: driven low pin 4: driven low pin 5: driven low pin 6, pin 7: high impedance 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. > "Working by accident" seems fairly plausible given that you didn't have any luck regardless of what you did with GPIO 5. It seems like it has to be either GPIO 3 or 4, and if your PCB works with 4 then that's a strong argument. Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From zub.272 at gmail.com Wed Nov 15 20:23:21 2017 From: zub.272 at gmail.com (David Kozub) Date: Wed, 15 Nov 2017 21:23:21 +0100 Subject: [PATCH] lib: fix regression on Fitipower FC0012 Message-ID: <20171115204556.D9B496004D@linux.fjfi.cvut.cz> The commit ba64a745 fixed rtlsdr_set_gpio_output() but also caused librtlsdr to stop working with (at least some) dongles with the FC0012 tuner. It seems that the FC0012 is connected to GPIO 4 while rtlsdr_open() assumes it's connected to GPIO 5. Before ba64a745 the bug in rtlsdr_set_gpio_output() caused GPIOs 3 and 4 to be set low and so everything worked. This changes the GPIO used in rtlsdr_open() from 5 to 4. At least on my dongle this fixes the regression. --- src/librtlsdr.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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) { -- 2.14.2 From vk4tec at tech-software.net Sun Nov 19 00:09:25 2017 From: vk4tec at tech-software.net (vk4tec at tech-software.net) Date: Sun, 19 Nov 2017 10:09:25 +1000 Subject: rtl_fm bias tee Message-ID: <01a901d360ca$ab0777d0$01166770$@tech-software.net> Hello I am installing a satgate on the raspberry pi with an rtl dongle I use the rtl_fm from the sources and I get an error about bias tee I have had to use another source Here is my install script #!/bin/sh clear echo "VK4TEC SATGATE install" echo " " #sudo apt-get update #sudo apt-get install cmake build-essential libusb-1.0-0-dev git clone https://github.com/niofis/rtl-sdr.git cd rtl-sdr/ mkdir build cd build cmake ../ make sudo make install sudo ldconfig git clone https://www.github.com/wb2osz/direwolf cd ~/direwolf make sudo make install make install-rpi make install-conf cd ~ sudo mv sdr.old sdr.confcd ~ sudo cp sdr.conf sdr.old cd ~ sudo apt-get uninstall rtl-sdr sudo apt-get install rtl-sdr sudo apt-get install librtlsdr-dev /usr/bin/rtl_fm -f 145.825M - | direwolf -t 0 -dii -c sdr.conf -r 24000 -D 1 - Andrew Rich Nov 2017 From cinaed.simson at gmail.com Sun Nov 19 04:56:26 2017 From: cinaed.simson at gmail.com (Cinaed Simson) Date: Sat, 18 Nov 2017 20:56:26 -0800 Subject: rtl_fm bias tee In-Reply-To: <01a901d360ca$ab0777d0$01166770$@tech-software.net> References: <01a901d360ca$ab0777d0$01166770$@tech-software.net> Message-ID: <124aca78-8490-8e51-5f20-ffe0da8686b5@GMail.COM> There are a number of forks of rtl-sdr, but the one I use is from https://github.com/osmocom/rtl-sdr.git which has support for the bias tee. I'm not familiar with the git URLs you posted. When I built it from source I get everything - the binaries, the includes and the libraries. And rtl_fm worked. As long as you don't randomly mix the source for the rtl-sdr and the source for the librtlsdr from different forks it shouldn't matter. -- Cinaed On 11/18/2017 04:09 PM, vk4tec at tech-software.net wrote: > Hello > > I am installing a satgate on the raspberry pi with an rtl dongle > > I use the rtl_fm from the sources and I get an error about bias tee > > I have had to use another source > > Here is my install script > > #!/bin/sh > clear > echo "VK4TEC SATGATE install" > echo " " > #sudo apt-get update > #sudo apt-get install cmake build-essential libusb-1.0-0-dev > git clone https://github.com/niofis/rtl-sdr.git > cd rtl-sdr/ > mkdir build > cd build > cmake ../ > make > sudo make install > sudo ldconfig > git clone https://www.github.com/wb2osz/direwolf > cd ~/direwolf > make > sudo make install > make install-rpi > make install-conf > cd ~ > sudo mv sdr.old sdr.confcd ~ > sudo cp sdr.conf sdr.old > cd ~ > sudo apt-get uninstall rtl-sdr > sudo apt-get install rtl-sdr > sudo apt-get install librtlsdr-dev > /usr/bin/rtl_fm -f 145.825M - | direwolf -t 0 -dii -c sdr.conf -r 24000 -D 1 > - > > Andrew Rich Nov 2017 > > From vk4tec at tech-software.net Sun Nov 19 04:59:17 2017 From: vk4tec at tech-software.net (Andrew Rich) Date: Sun, 19 Nov 2017 14:59:17 +1000 Subject: rtl_fm bias tee In-Reply-To: <124aca78-8490-8e51-5f20-ffe0da8686b5@GMail.COM> References: <01a901d360ca$ab0777d0$01166770$@tech-software.net> <124aca78-8490-8e51-5f20-ffe0da8686b5@GMail.COM> Message-ID: sorted http://tech-software.net/satgate/satgate.htm > On 19 Nov 2017, at 2:56 pm, Cinaed Simson wrote: > > There are a number of forks of rtl-sdr, but the one I use is from > > https://github.com/osmocom/rtl-sdr.git > > which has support for the bias tee. > > I'm not familiar with the git URLs you posted. > > When I built it from source I get everything - the binaries, the > includes and the libraries. > > And rtl_fm worked. > > As long as you don't randomly mix the source for the rtl-sdr and the > source for the librtlsdr from different forks it shouldn't matter. > > -- Cinaed > > > On 11/18/2017 04:09 PM, vk4tec at tech-software.net wrote: >> Hello >> >> I am installing a satgate on the raspberry pi with an rtl dongle >> >> I use the rtl_fm from the sources and I get an error about bias tee >> >> I have had to use another source >> >> Here is my install script >> >> #!/bin/sh >> clear >> echo "VK4TEC SATGATE install" >> echo " " >> #sudo apt-get update >> #sudo apt-get install cmake build-essential libusb-1.0-0-dev >> git clone https://github.com/niofis/rtl-sdr.git >> cd rtl-sdr/ >> mkdir build >> cd build >> cmake ../ >> make >> sudo make install >> sudo ldconfig >> git clone https://www.github.com/wb2osz/direwolf >> cd ~/direwolf >> make >> sudo make install >> make install-rpi >> make install-conf >> cd ~ >> sudo mv sdr.old sdr.confcd ~ >> sudo cp sdr.conf sdr.old >> cd ~ >> sudo apt-get uninstall rtl-sdr >> sudo apt-get install rtl-sdr >> sudo apt-get install librtlsdr-dev >> /usr/bin/rtl_fm -f 145.825M - | direwolf -t 0 -dii -c sdr.conf -r 24000 -D 1 >> - >> >> Andrew Rich Nov 2017 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssgautam at tatapowersed.com Tue Nov 21 04:31:28 2017 From: ssgautam at tatapowersed.com (Shiv Shankar Gautam) Date: Tue, 21 Nov 2017 10:01:28 +0530 (IST) Subject: SDR board design for hand Held tactical SDR Message-ID: <00e601d36281$97886d00$c6994700$@com> We are looking for SCA compliance SDR hardware design. Please send us the design Warm Regrads, Shiv Gautam | Manager Communication Systems -------------------------------------------------------------------------- -------------------------- The Tata Power Company Limited Strategic Engineering Division (Tata Power SED) 42 - 43 Electronics City Hosur Road Bengaluru 560 100 India Tel: +91 80 6785 4501 | Fax: +91 80 6785 9901 | Mobile: +91 74110 01394 Website: www.TataPowerSED.in *Disclaimer* ------------------------------------------------------------ Notice: This e-mail and / or attachments (communication) may contain information that is confidential and proprietary to The Tata Power Company Limited, Strategic Engineering Division (Tata Power SED). If you are not the intended recipient of this communication, please do not use or disseminate the information contained therein, notify the sender by e-mail or telephone and delete the communication (permanently) from your system. Any information in this communication that does not relate to the official business of Tata Power SED shall be understood as neither given nor endorsed by it. Please note that e-mails are susceptible to change and Tata Power SED shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt. This communication is not guaranteed to be free from computer viruses and it is recommended that you check for all viruses before download. Print this communication only if absolutely essential. Thank you for your co-operation. ------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssgautam at tatapowersed.com Wed Nov 22 04:23:18 2017 From: ssgautam at tatapowersed.com (Shiv Shankar Gautam) Date: Wed, 22 Nov 2017 09:53:18 +0530 (IST) Subject: SDR board design for hand Held tactical SDR Message-ID: <005701d36349$9f985780$dec90680$@com> Waiting for your response. Warm Regrads, Shiv Gautam | Manager Communication Systems -------------------------------------------------------------------------- -------------------------- The Tata Power Company Limited Strategic Engineering Division (Tata Power SED) 42 - 43 Electronics City Hosur Road Bengaluru 560 100 India Tel: +91 80 6785 4501 | Fax: +91 80 6785 9901 | Mobile: +91 74110 01394 Website: www.TataPowerSED.in From: Shiv Shankar Gautam [mailto:ssgautam at tatapowersed.com] Sent: 21 November 2017 10:01 To: 'osmocom-sdr at lists.osmocom.org' Subject: SDR board design for hand Held tactical SDR We are looking for SCA compliance SDR hardware design. Please send us the design Warm Regrads, Shiv Gautam | Manager Communication Systems -------------------------------------------------------------------------- -------------------------- The Tata Power Company Limited Strategic Engineering Division (Tata Power SED) 42 - 43 Electronics City Hosur Road Bengaluru 560 100 India Tel: +91 80 6785 4501 | Fax: +91 80 6785 9901 | Mobile: +91 74110 01394 Website: www.TataPowerSED.in *Disclaimer* ------------------------------------------------------------ Notice: This e-mail and / or attachments (communication) may contain information that is confidential and proprietary to The Tata Power Company Limited, Strategic Engineering Division (Tata Power SED). If you are not the intended recipient of this communication, please do not use or disseminate the information contained therein, notify the sender by e-mail or telephone and delete the communication (permanently) from your system. Any information in this communication that does not relate to the official business of Tata Power SED shall be understood as neither given nor endorsed by it. Please note that e-mails are susceptible to change and Tata Power SED shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt. This communication is not guaranteed to be free from computer viruses and it is recommended that you check for all viruses before download. Print this communication only if absolutely essential. Thank you for your co-operation. ------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From s3583925 at student.rmit.edu.au Thu Nov 23 03:42:06 2017 From: s3583925 at student.rmit.edu.au (Shuai Sun) Date: Thu, 23 Nov 2017 14:42:06 +1100 Subject: Modulation Format Enquiry Message-ID: Hello Under gnuradio platform, when I send a pure sinusoid using gr-osmocom, what is the modulation format that osmocom uses? Thank you very much. Regards Shuai -------------- next part -------------- An HTML attachment was scrubbed... URL: