From kroemeke at gmail.com Wed May 2 20:51:43 2012 From: kroemeke at gmail.com (Marek Kroemeke) Date: Wed, 2 May 2012 21:51:43 +0100 Subject: Patch for Compro U680F support. Message-ID: Hi guys, Unclear in what format you require patches - but I bought Compro U680F 2 days ago, it has the E4000 chipset and it only required adding usb id in, so as requested in docs - sending a small "patch" that makes it work :-) regards, Marek Kroemeke -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compro_u680f.patch Type: application/octet-stream Size: 1049 bytes Desc: not available URL: From steve at steve-m.de Thu May 3 18:59:34 2012 From: steve at steve-m.de (Steve Markgraf) Date: Thu, 03 May 2012 20:59:34 +0200 Subject: Patch for Compro U680F support. In-Reply-To: References: Message-ID: <4FA2D596.6040801@steve-m.de> Hi, On 02.05.2012 22:51, Marek Kroemeke wrote: > Unclear in what format you require patches - but I bought Compro U680F 2 > days ago, it has the E4000 chipset and it only required adding usb id > in, so as requested in docs - sending a small "patch" that makes it work :-) Thanks a lot, I just committed support for the stick. Regards, Steve From ncjeffgus at zimage.com Mon May 7 18:10:06 2012 From: ncjeffgus at zimage.com (Jeff Gustafson) Date: Mon, 07 May 2012 11:10:06 -0700 Subject: RTL2832 questions Message-ID: <1336414206.13796.11.camel@maclinux> Hi all, First of all, props to the person that found out how to put the RTL chip into a SDR compatible mode! I've been wanting to play around with SDR and, specifically, P25 for a while now. Finally an inexpensive way to get my feet wet. My question is probably a bit of a noob question. I have successfully received a broadcast FM radio station with the RTL dongle. The problem is that I can't seem to decode anything else. I tried to receive some ham radio (NFM) transmissions from my radio and I didn't get any sound. The white noise blanked out, the scope in gnuradio spiked up, but no real demodulation. Would someone be willing to share a .grc file they know will decode NFM with the gr-osmosdr/rtl-sdr driver? I tried taking some files that used the USRP driver and swapping out the USRP driver with the osmosdr/rtl driver, but no go. Could it be that I don't have all the sampling rates and decimation rates set correctly? ...Jeff From andrea.montefusco at gmail.com Mon May 7 21:52:28 2012 From: andrea.montefusco at gmail.com (Andrea Montefusco) Date: Mon, 07 May 2012 23:52:28 +0200 Subject: Recent librtlsdr and example program don't work Message-ID: <4FA8441C.8090105@gmail.com> After about a month, I refreshed the local git sandbox but I was not anymore able to receive any sample, even with the test program. I am using a Terratec NOXON DAB/DAB+ USB dongle (rev 1) on Ubuntu 11.10 x86_64 . ./rtl_sdr - Found 1 device(s): 0: Terratec NOXON DAB/DAB+ USB dongle (rev 1) Using device 0: Terratec NOXON DAB/DAB+ USB dongle (rev 1) Found Fitipower FC0013 tuner Tuned to 100000000 Hz. Tuner gain set to -1.000000 dB. Reading samples in async mode... but I can get no output. *am* --------------------------------------------------------- Andrea Montefusco iw0hdv http://www.montefusco.com tel: +393356992791 fax: +390623318709 --------------------------------------------------------- From laforge at gnumonks.org Tue May 8 07:57:30 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 8 May 2012 09:57:30 +0200 Subject: Recent librtlsdr and example program don't work In-Reply-To: <4FA8441C.8090105@gmail.com> References: <4FA8441C.8090105@gmail.com> Message-ID: <20120508075730.GC31273@prithivi.gnumonks.org> On Mon, May 07, 2012 at 11:52:28PM +0200, Andrea Montefusco wrote: > After about a month, I refreshed the local git sandbox but I was not > anymore able to receive any sample, even with the test program. It would help if you still know which git version you had been using before. You could even try to use "git bisect" to find out which particular change made it break. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From andrea.montefusco at gmail.com Tue May 8 17:47:40 2012 From: andrea.montefusco at gmail.com (Andrea Montefusco) Date: Tue, 08 May 2012 19:47:40 +0200 Subject: Recent librtlsdr and example program don't work In-Reply-To: <20120508075730.GC31273@prithivi.gnumonks.org> References: <4FA8441C.8090105@gmail.com> <20120508075730.GC31273@prithivi.gnumonks.org> Message-ID: <4FA95C3C.6070804@gmail.com> On 05/08/2012 09:57 AM, Harald Welte wrote: > On Mon, May 07, 2012 at 11:52:28PM +0200, Andrea Montefusco wrote: >> After about a month, I refreshed the local git sandbox but I was not >> anymore able to receive any sample, even with the test program. > > It would help if you still know which git version you had been using > before. > > You could even try to use "git bisect" to find out which particular > change made it break. I did that and the result was the same, so the wholly system becomes the suspicious one. Really after Oliver was back, he restarted everything and, now, it is working again. Many other times I managed to lock the dongle, however this is the first time we could access the device but not getting data from it Consider that I am remotely developing the software, thanks to Oliver that is sharing its dongle, Linux PC and Internet connection, and it seems that there is no practical way to do an hard reset the dongle remotely (I would like to be wrong of course, so if anyone know how, please tell me). Sorry to reporting a not existent problem. *am* --------------------------------------------------------- Andrea Montefusco iw0hdv http://www.montefusco.com tel: +393356992791 fax: +390623318709 --------------------------------------------------------- From laforge at gnumonks.org Tue May 8 18:08:46 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 8 May 2012 20:08:46 +0200 Subject: Recent librtlsdr and example program don't work In-Reply-To: <4FA95C3C.6070804@gmail.com> References: <4FA8441C.8090105@gmail.com> <20120508075730.GC31273@prithivi.gnumonks.org> <4FA95C3C.6070804@gmail.com> Message-ID: <20120508180846.GC21953@prithivi.gnumonks.org> Hi Andrea, On Tue, May 08, 2012 at 07:47:40PM +0200, Andrea Montefusco wrote: > and it seems that there is no practical way to do an hard reset the > dongle remotely (I would like to be wrong of course, so if anyone > know how, please tell me). have you tried issuing a USB Bus reset to the bus the device is residing on? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue May 8 19:11:57 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 8 May 2012 21:11:57 +0200 Subject: OsmoSDR developer beta Message-ID: <20120508191157.GG21953@prithivi.gnumonks.org> Hi all! There are something like 16 units of OsmoSDR that we are able to sell in something like one week. Sale will happen via the https://shop.sysmocom.de/ webshop. However, as there are only 16 units right now, and as the firmware and host software is in an incomplete state, we would like to make sure that those 16 units get sold to people who actually have an interest (and time!) to fix and improve the current shortcomings. So if you want to be among the first 16, I suggest you reply to this message and give us a short description of who you are (if you are not a Osmocom regular) as well as some committment that you are actually going to work on improving the code. If you already know an area that you'd like to work on, please state that, too. The price will be 180 EUR incl. VAT (that's 151.26 EUR without), i.e. the same price as for the units that will later be sold openly. I have put together a wiki page with the current status at http://sdr.osmocom.org/trac/wiki/OsmoSDR/Status to make you aware where we are and what is missing. Thanks in advance for your willingness to be early users and help us to improve the codebase. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ncjeffgus at zimage.com Tue May 8 19:52:23 2012 From: ncjeffgus at zimage.com (Jeff Gustafson) Date: Tue, 08 May 2012 12:52:23 -0700 Subject: Sorta working! (was Re: RTL2832 questions) In-Reply-To: <1336414206.13796.11.camel@maclinux> References: <1336414206.13796.11.camel@maclinux> Message-ID: <1336506743.11309.5.camel@maclinux> I git pull'd the newest code today and the NFM seems to do something now. I suspect something is wrong with the sampling rate somewhere. The voices are like recordings played too fast and the audio is jumpy. I'm using the file called fm_rx.grc. It has widgets for changing the max deviation, etc. I replaced the default usrp source with the rtl source. The default sampling rate in the grc file is 250k. Also, has anyone else had issues with the system halting when running gnuradio with a rtl dongle? I've had it happen on two different systems so far. ...Jeff On Mon, 2012-05-07 at 11:10 -0700, Jeff Gustafson wrote: > Hi all, > First of all, props to the person that found out how to put the RTL > chip into a SDR compatible mode! I've been wanting to play around with > SDR and, specifically, P25 for a while now. Finally an inexpensive way > to get my feet wet. > My question is probably a bit of a noob question. I have successfully > received a broadcast FM radio station with the RTL dongle. The problem > is that I can't seem to decode anything else. I tried to receive some > ham radio (NFM) transmissions from my radio and I didn't get any sound. > The white noise blanked out, the scope in gnuradio spiked up, but no > real demodulation. Would someone be willing to share a .grc file they > know will decode NFM with the gr-osmosdr/rtl-sdr driver? > I tried taking some files that used the USRP driver and swapping out > the USRP driver with the osmosdr/rtl driver, but no go. Could it be that > I don't have all the sampling rates and decimation rates set correctly? > > ...Jeff > From alexander.chemeris at gmail.com Tue May 8 20:13:35 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 9 May 2012 00:13:35 +0400 Subject: OsmoSDR developer beta In-Reply-To: <20120508191157.GG21953@prithivi.gnumonks.org> References: <20120508191157.GG21953@prithivi.gnumonks.org> Message-ID: Hi all, On Tue, May 8, 2012 at 11:11 PM, Harald Welte wrote: > There are something like 16 units of OsmoSDR that we are able to sell in > something like one week. ? Sale will happen via the > https://shop.sysmocom.de/ webshop. Great news! Do I recall correctly that it supports 10MHz to 1.4GHz frequency with up to 4MHz bandwidth with 14 bits resolution and does not provide any Rx filtering? Regarding decimation support in FPGA - as a quick way I recommend to look at borrowing code from Ettus' UHD FPGA. It's GPLv3 and is well modular. So you could be able to take only decimation from it. Other blocks like I/Q balance. DC offset removal, VCO are available as well. This could be an easy way to start. Let me know if someone wants to go this way and need some intro into the UHD code structure. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From laforge at gnumonks.org Tue May 8 20:27:30 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 8 May 2012 22:27:30 +0200 Subject: OsmoSDR developer beta In-Reply-To: References: <20120508191157.GG21953@prithivi.gnumonks.org> Message-ID: <20120508202730.GH21953@prithivi.gnumonks.org> Hi Alexander, On Wed, May 09, 2012 at 12:13:35AM +0400, Alexander Chemeris wrote: > Do I recall correctly that it supports 10MHz to 1.4GHz frequency with > up to 4MHz bandwidth with 14 bits resolution and does not provide any > Rx filtering? 64 MHz to 1.7 GHz (spec) but you can still go up to 1.9 GHz without problems. The ADC can do 4MS/s, but the SSC of the sam3u can only do something that roughly correpsonds 1.25 Ms/s. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Tue May 8 20:50:20 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 9 May 2012 00:50:20 +0400 Subject: OsmoSDR developer beta In-Reply-To: <20120508202730.GH21953@prithivi.gnumonks.org> References: <20120508191157.GG21953@prithivi.gnumonks.org> <20120508202730.GH21953@prithivi.gnumonks.org> Message-ID: On Wed, May 9, 2012 at 12:27 AM, Harald Welte wrote: > > Hi Alexander, > > On Wed, May 09, 2012 at 12:13:35AM +0400, Alexander Chemeris wrote: > > > Do I recall correctly that it supports 10MHz to 1.4GHz frequency with > > up to 4MHz bandwidth with 14 bits resolution and does not provide any > > Rx filtering? > > 64 MHz to 1.7 GHz (spec) but you can still go up to 1.9 GHz without > problems. ?The ADC can do 4MS/s, but the SSC of the sam3u can only do > something that roughly correpsonds 1.25 Ms/s. Thanks. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From peter at stuge.se Tue May 8 21:03:36 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 8 May 2012 23:03:36 +0200 Subject: Recent librtlsdr and example program don't work In-Reply-To: <20120508180846.GC21953@prithivi.gnumonks.org> References: <4FA8441C.8090105@gmail.com> <20120508075730.GC31273@prithivi.gnumonks.org> <4FA95C3C.6070804@gmail.com> <20120508180846.GC21953@prithivi.gnumonks.org> Message-ID: <20120508210336.5477.qmail@stuge.se> Harald Welte wrote: > > and it seems that there is no practical way to do an hard reset the > > dongle remotely (I would like to be wrong of course, so if anyone > > know how, please tell me). > > have you tried issuing a USB Bus reset to the bus the device is > residing on? I think that's still only a software reset. :\ USB hubs can optionally allow software to control the power supply of ports individually, and this could of course be used to power cycle any bus powered USB device. As far as I know, no hub driver exposes an API to do this however - but I'd love to be wrong about this, so please tell me if anyone knows! //Peter From laforge at gnumonks.org Tue May 8 21:19:13 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 8 May 2012 23:19:13 +0200 Subject: OT: usb hub power switching (Re: Recent librtlsdr and example program don't work) In-Reply-To: <20120508210336.5477.qmail@stuge.se> References: <4FA8441C.8090105@gmail.com> <20120508075730.GC31273@prithivi.gnumonks.org> <4FA95C3C.6070804@gmail.com> <20120508180846.GC21953@prithivi.gnumonks.org> <20120508210336.5477.qmail@stuge.se> Message-ID: <20120508211913.GI21953@prithivi.gnumonks.org> On Tue, May 08, 2012 at 11:03:36PM +0200, Peter Stuge wrote: > As far as I know, no hub driver exposes an API to do this however - > but I'd love to be wrong about this, so please tell me if anyone knows! The hub drivers inside the kernel export this via the set_port_feature(.. USB_PORT_FEAT_POWER) function, which core/hub.c wraps in the hub_power_on() function. But it seems like it is only used by suspend/resume and overcurrent related code paths. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Tue May 8 21:45:49 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 8 May 2012 23:45:49 +0200 Subject: OsmoSDR developer beta In-Reply-To: <20120508191157.GG21953@prithivi.gnumonks.org> References: <20120508191157.GG21953@prithivi.gnumonks.org> Message-ID: <20120508214549.8794.qmail@stuge.se> Harald Welte wrote: > So if you want to be among the first 16, I suggest you reply to this > message and give us a short description of who you are (if you are not a > Osmocom regular) as well as some committment that you are actually going > to work on improving the code. If you already know an area that you'd > like to work on, please state that, too. I'd like to order one to work on the control interface in firmware as well as on the host. I've said that for a while, and while this can be done even without hardware being able to test helps (at least my) motivation a lot. In any case I'm of course happy to assist others with anything and everything related to libusb, including problems upstream, where being able to test locally can also help. I'll make a deal: Consider reserving a device for me only if I deliver some patches for USB stuff in firmware and host before noon Monday next week! :) I also have another idea: Let's schedule a hackaton (code sprint, pick your favorite name) next week when hardware has arrived, where those with interest meet up in Berlin and hack together on the TODO list, which will allow us to more easily share the hardware even if there are only a few devices available. Peer pressure also helps get things done. //Peter From peter at stuge.se Tue May 8 21:47:33 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 8 May 2012 23:47:33 +0200 Subject: OT: usb hub power switching (Re: Recent librtlsdr and example program don't work) In-Reply-To: <20120508211913.GI21953@prithivi.gnumonks.org> References: <4FA8441C.8090105@gmail.com> <20120508075730.GC31273@prithivi.gnumonks.org> <4FA95C3C.6070804@gmail.com> <20120508180846.GC21953@prithivi.gnumonks.org> <20120508210336.5477.qmail@stuge.se> <20120508211913.GI21953@prithivi.gnumonks.org> Message-ID: <20120508214733.9004.qmail@stuge.se> Harald Welte wrote: > > As far as I know, no hub driver exposes an API to do this however - > > but I'd love to be wrong about this, so please tell me if anyone knows! > > The hub drivers inside the kernel export this via the > set_port_feature(.. USB_PORT_FEAT_POWER) function, which core/hub.c > wraps in the hub_power_on() function. > > But it seems like it is only used by suspend/resume and overcurrent > related code paths. Yes, I haven't seen it available in any userspace API on any system. :\ It may be possible to send the request to the hub from userspace, but I haven't tried it. //Peter From spaar at mirider.augusta.de Wed May 9 07:56:57 2012 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Wed, 09 May 2012 07:56:57 CEST Subject: OT: usb hub power switching (Re: Recent librtlsdr and example program don't work) Message-ID: <4faa2349.mirider@mirider.augusta.de> Hello Peter, On Tue, 8 May 2012 23:47:33 +0200, "Peter Stuge" wrote: > > Yes, I haven't seen it available in any userspace API on any system. :\ > > It may be possible to send the request to the hub from userspace, but > I haven't tried it. Older Windows Version (before Vista) had IOCTL_USB_HUB_CYCLE_PORT to perform a power cycle. I think there is still a way in newer version too, If I am not wrong the WHQL driver testings tools do perform USB power cycles frequently when testing USB devices. Of course the above is only relevant if you care about Windows ;-) Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From andrea.montefusco at gmail.com Wed May 9 21:28:04 2012 From: andrea.montefusco at gmail.com (Andrea Montefusco) Date: Wed, 09 May 2012 23:28:04 +0200 Subject: Recent librtlsdr and example program don't work In-Reply-To: <20120508180846.GC21953@prithivi.gnumonks.org> References: <4FA8441C.8090105@gmail.com> <20120508075730.GC31273@prithivi.gnumonks.org> <4FA95C3C.6070804@gmail.com> <20120508180846.GC21953@prithivi.gnumonks.org> Message-ID: <4FAAE164.8050301@gmail.com> On 05/08/2012 08:08 PM, Harald Welte wrote: > have you tried issuing a USB Bus reset to the bus the device is residing > on? I did, no results. BTW, it seems that Oliver, the owner of dongle on which I remotely try to destroy :-) discovered that, at least some times, the module has been frozen simply trying to set it at a too much low frequency. *am* --------------------------------------------------------- Andrea Montefusco iw0hdv http://www.montefusco.com tel: +393356992791 fax: +390623318709 --------------------------------------------------------- From jsalsburg at bellsouth.net Sun May 13 19:42:00 2012 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Sun, 13 May 2012 14:42:00 -0500 Subject: why Docs for the ELONICS E4000 are not published Message-ID: Is the reason why Docs for the ELONICS E4000 are not published because it is Chinese? If anyone has the Datasheets for the ELONICS E4000 and REALTECH RTL2832, please share them to osmocom-sdr at lists.osmocom.org or post them to http://sdr.osmocom.org/trac/wiki/Hardware Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Sun May 13 20:43:47 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 13 May 2012 22:43:47 +0200 Subject: why Docs for the ELONICS E4000 are not published In-Reply-To: References: Message-ID: Hi, > Is the reason why Docs for the ELONICS E4000 are not published because it is > Chinese? The E4K is from a UK company AFAIK, not chinese. It's only available under Non-Disclosure-Agreement, they don't just give it out. (I tried :) I'm not sure exactly what terms the RTL datasheet are available under, but in any case it's a copyrighted document. Cheers, Sylvain From laforge at gnumonks.org Tue May 15 06:44:40 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 15 May 2012 08:44:40 +0200 Subject: why Docs for the ELONICS E4000 are not published In-Reply-To: References: Message-ID: <20120515064440.GG24346@prithivi.gnumonks.org> Hi Jay, On Sun, May 13, 2012 at 02:42:00PM -0500, Jay Salsburg wrote: > If anyone has the Datasheets for the ELONICS E4000 and REALTECH > RTL2832, please share them to osmocom-sdr at lists.osmocom.org or post them to > http://sdr.osmocom.org/trac/wiki/Hardware As the person operating the *.osmocom.org servers and thus legally responsible for all content on the sites I would like to ask everyone not to do so. Also, I would like to ask you not to request others to publish copyrighted material without approval by the owner. So if anyone has approval from Elonics or Realtek to publicly post those documents (which I doubt, but it is possible theoretically): Please go ahead. Otherwise: Don't. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jsalsburg at bellsouth.net Tue May 15 21:34:17 2012 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Tue, 15 May 2012 16:34:17 -0500 Subject: why Docs for the ELONICS E4000 are not published In-Reply-To: References: Message-ID: Hello I at least learned something about the Chips in these new TV Tuner Sticks, the tuner is perhaps British. Information about these chips, it seems, is kept secret for some (unimportant) reason I cannot understand. You would think a group or company that manufactures something for sale would publish how to use it; non-disclosures are merely ways to protect trade secrets. These chips are in the open and may be reverse engineered or hacked as is the case in this forum, not publishing their datasheets does not protect them, it only limits their sale. Perhaps someone who has a non-disclosure with them should convey that to the Fabricator. Thank you -----Original Message----- From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Sylvain Munaut Sent: Sunday, May 13, 2012 3:44 PM To: Jay Salsburg Cc: osmocom-sdr at lists.osmocom.org Subject: Re: why Docs for the ELONICS E4000 are not published Hi, > Is the reason why Docs for the ELONICS E4000 are not published because > it is Chinese? The E4K is from a UK company AFAIK, not chinese. It's only available under Non-Disclosure-Agreement, they don't just give it out. (I tried :) I'm not sure exactly what terms the RTL datasheet are available under, but in any case it's a copyrighted document. Cheers, Sylvain From laforge at gnumonks.org Tue May 15 22:24:53 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 16 May 2012 00:24:53 +0200 Subject: why Docs for the ELONICS E4000 are not published In-Reply-To: References: Message-ID: <20120515222453.GC929@prithivi.gnumonks.org> Hi Jay, this is very rapidly slipping off-topic, but FYI: On Tue, May 15, 2012 at 04:34:17PM -0500, Jay Salsburg wrote: > I at least learned something about the Chips in these new TV Tuner > Sticks, the tuner is perhaps British. Information about these chips, > it seems, is kept secret for some (unimportant) reason I cannot > understand. One of the typical reason is quite simple and (unfortunately) understandable: If you openly document how your hardware works, then you are inviting patent trolls and patent lawsuits. If they can go to court and show your own documentation as evidence, you will have a hard time arguing that the documentation was wrong. If the documentation is not publicly released and under NDA, than any patent troll getting hold of it (and/or their collaborators) would have been violating the NDA. If there is not documentation, then the patent troll would have to actually do silicon reverse engineering and invest money and time before they have evidence. And then that evidence gets questioned, and the process how it was obtained. Possible, but much more effort. The point is not whether a given device infringes a patent or not. The point is simply that there are companies out there who simply pick the easiest targets. And unfortunately those that have open documentation are easier to attack than those that don't :( -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From vogelchr at vogel.cx Wed May 16 10:00:58 2012 From: vogelchr at vogel.cx (Christian Vogel) Date: Wed, 16 May 2012 12:00:58 +0200 Subject: PATCH: Remove pow() and math.h from rtl-sdr. Message-ID: <20120516100056.GA2502@vogel.cx> Hi, apparently #include is only needed for the declaration of pow(2,22) used in rtlsdr_set_sample_rate(). Now gcc is smart enough to convert pow(2,22) to a constant, but for example clang isn't, and it complains about the missing math library. Attached patches replace pow(2,22) by (float)1<<22 and remove the math headers. Chris [tort /home/chris/rtl-sdr (b345963947b451f6?)] $ make (...) ./.libs/librtlsdr.so: undefined reference to `exp2' collect2: ld returned 1 exit status clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [rtl_sdr] Error 1 make[2]: Leaving directory `/home/chris/rtl-sdr/src' From vogelchr at vogel.cx Wed May 16 09:30:11 2012 From: vogelchr at vogel.cx (Christian Vogel) Date: Wed, 16 May 2012 11:30:11 +0200 Subject: [PATCH] Using a #define for constant 2^22 (not pow()) Message-ID: pow() might require the math library to be linked with rtl-sdl (e.g. when compiling with clang), even though it's actually constant. --- src/rtl-sdr.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/rtl-sdr.c b/src/rtl-sdr.c index 6a9539b..da79acb 100644 --- a/src/rtl-sdr.c +++ b/src/rtl-sdr.c @@ -675,6 +675,9 @@ int rtlsdr_set_tuner_gain_mode(rtlsdr_dev_t *dev, int mode) return r; } +/* two raised to the power of n */ +#define TWO_POW(n) ((double)(1ULL<<(n))) + int rtlsdr_set_sample_rate(rtlsdr_dev_t *dev, uint32_t samp_rate) { uint16_t tmp; @@ -688,10 +691,10 @@ int rtlsdr_set_sample_rate(rtlsdr_dev_t *dev, uint32_t samp_rate) if (samp_rate > MAX_SAMP_RATE) samp_rate = MAX_SAMP_RATE; - rsamp_ratio = (dev->rtl_xtal * pow(2, 22)) / samp_rate; + rsamp_ratio = (dev->rtl_xtal * TWO_POW(22)) / samp_rate; rsamp_ratio &= ~3; - real_rate = (dev->rtl_xtal * pow(2, 22)) / rsamp_ratio; + real_rate = (dev->rtl_xtal * TWO_POW(22)) / rsamp_ratio; if ( ((double)samp_rate) != real_rate ) fprintf(stderr, "Exact sample rate is: %f Hz\n", real_rate); -- 1.7.0.4 --dDRMvlgZJXvWKvBx Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0002-include-math.h-was-not-needed.patch" From vogelchr at vogel.cx Wed May 16 09:48:23 2012 From: vogelchr at vogel.cx (Christian Vogel) Date: Wed, 16 May 2012 11:48:23 +0200 Subject: [PATCH 2/2] #include was not needed. Message-ID: --- src/rtl-sdr.c | 1 - src/rtl_sdr.c | 1 - src/rtl_tcp.c | 1 - 3 files changed, 0 insertions(+), 3 deletions(-) diff --git a/src/rtl-sdr.c b/src/rtl-sdr.c index da79acb..b6f9163 100644 --- a/src/rtl-sdr.c +++ b/src/rtl-sdr.c @@ -22,7 +22,6 @@ #include #include #include -#include #ifndef _WIN32 #include #define min(a, b) (((a) < (b)) ? (a) : (b)) diff --git a/src/rtl_sdr.c b/src/rtl_sdr.c index fed0d30..98d5fc5 100644 --- a/src/rtl_sdr.c +++ b/src/rtl_sdr.c @@ -21,7 +21,6 @@ #include #include #include -#include #ifndef _WIN32 #include diff --git a/src/rtl_tcp.c b/src/rtl_tcp.c index 3cea790..7cfd524 100644 --- a/src/rtl_tcp.c +++ b/src/rtl_tcp.c @@ -22,7 +22,6 @@ #include #include #include -#include #ifndef _WIN32 #include -- 1.7.0.4 --dDRMvlgZJXvWKvBx-- From laforge at gnumonks.org Wed May 16 20:32:23 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 16 May 2012 22:32:23 +0200 Subject: OsmoSDR developer beta In-Reply-To: <20120508191157.GG21953@prithivi.gnumonks.org> References: <20120508191157.GG21953@prithivi.gnumonks.org> Message-ID: <20120516203223.GH929@prithivi.gnumonks.org> Just as a follow-up: There have so far not been that many people interested in getting one of the first units, so maybe my last post was too scary. I think there should still be some 8 boards left after subtracting orders for the "usual suspects". So if you are interested and want to play with it as an early adopter, feel free to send me a mail and I'll let you know how to proceed with the order. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From steve at steve-m.de Thu May 17 20:01:06 2012 From: steve at steve-m.de (Steve Markgraf) Date: Thu, 17 May 2012 22:01:06 +0200 Subject: PATCH: Remove pow() and math.h from rtl-sdr. In-Reply-To: <20120516100056.GA2502@vogel.cx> References: <20120516100056.GA2502@vogel.cx> Message-ID: <4FB55902.20303@steve-m.de> Hi, On 16.05.2012 12:00, Christian Vogel wrote: > Attached patches replace pow(2,22) by (float)1<<22 and remove > the math headers. Thanks a lot, pushed them. Regards, Steve From cd at maintech.de Thu May 17 20:57:40 2012 From: cd at maintech.de (Christian Daniel -- maintech GmbH) Date: Thu, 17 May 2012 22:57:40 +0200 Subject: Sources for VHDL and FPGA flashing committed Message-ID: <4FB56644.5050804@maintech.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everybody, I've committed the VHDL source code and the needed projects files for Lattice Diamond into the repository. With this everybody can build a FPGA image for the OsmoSDR. The most important feature in this new FPGA firmware version is, that we now have an integrated decimation filter, which can be configured in from 1:2 to 1:64. I have added a tool to convert the files, that Lattice Diamond produces to something we can upload via USB DFU and I also modified the DFU loader to include FPGA flashing support. Since the post office was already closed yesterday and today we had a holiday in Germany, the boards will find their way to the mail tomorrow. Best regards, Christian - -- - --------------------------------------------------- | maintech # Dipl. Inf (FH) Christian Daniel | | GmbH ### Otto-Hahn-Str. 15 ? D-97204 H?chberg | - --------------------------------------------------- | AG W?rzburg, HRB 8790 Tax-ID DE242279645 | - --------------------------------------------------- | http://www.maintech.de cd at maintech.de | - --------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPtWY8AAoJEHkgzUIsAWrig/oH/2b9oummF4S/gDN/A6SlIIf4 ppmcg+j+gLCJ7n2Otpb/eq+Uk8BK8NgFu0qlaWVSJ9q2HtHXGsxzUFnkRGRNIjjv I8DIImuUiDpUXfiX/mQEe9kGNJwJIcCB4ulFHeU8EDo7NcbI/O8nHQQOtX46Uegl yzdkqw9KaPJxeABdsa9PzTKOvWDigMrWw6IEibJRqrMVkAOxHby2084NqFQPNLze +f/uSQ4FW64hlc0Gli5nyXGR10CaY8/SXTP7VTNtI3Gnjwvf4VcKkCFrFLR9/UZE +4HuIXu0JMX3jFTF72ttwKG+oGxk9G+IorTgW+VUzKJ2ni+D0Zy8zaCAjnNBYOg= =ykxM -----END PGP SIGNATURE----- From laforge at gnumonks.org Fri May 18 06:23:42 2012 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 18 May 2012 08:23:42 +0200 Subject: Fwd: Calculation of allowed vco frequency in osmocom sources Message-ID: <20120518062342.GS12145@prithivi.gnumonks.org> Hi all, with permission of its author, I'm forwarding this message to the list. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An embedded message was scrubbed... From: Heath Hunnicutt Subject: Calculation of allowed vco frequency in osmocom sources Date: Thu, 17 May 2012 13:39:59 -0700 Size: 3084 URL: From p.munoz at alumnos.upm.es Sat May 19 13:21:26 2012 From: p.munoz at alumnos.upm.es (p.munoz at alumnos.upm.es) Date: Sat, 19 May 2012 15:21:26 +0200 Subject: [PATCH] librtlsdr: libusb detach kernel driver before claiming interface Message-ID: <1337433686-9919-1-git-send-email-p.munoz@alumnos.upm.es> From: Pablo Mu?oz rtl_sdr founds ezcap USB dongle but exits with usb_claim_interface error -6 Signed-off-by: Pablo Mu?oz --- src/librtlsdr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 7721c4a..0599722 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -865,7 +865,7 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) } libusb_free_device_list(list, 1); - + libusb_detach_kernel_driver(dev->devh,0); r = libusb_claim_interface(dev->devh, 0); if (r < 0) { fprintf(stderr, "usb_claim_interface error %d\n", r); -- 1.7.10 From D.J at fiddes.net Sun May 20 20:07:28 2012 From: D.J at fiddes.net (David J. Fiddes) Date: Sun, 20 May 2012 21:07:28 +0100 Subject: [PATCH] Add support for PROlectrix dongle Message-ID: <1337544448.8268.4.camel@snowman.fiddes-enterprises.com> Hi, This adds support for another RTL2832U based device. I've been able to receive FM broadcasts using GNU Radio and rtl-sdr with this device. Dave Subject: [PATCH] Add support for PROlectrix dongle Incorporate support for the PROlectrix DV107669 which appears to be another variant of G-Tek RTL2832U device. This has a FC0012 tuner. Signed-off-by: David J. Fiddes --- rtl-sdr.rules | 3 +++ src/librtlsdr.c | 1 + 2 files changed, 4 insertions(+) diff --git a/rtl-sdr.rules b/rtl-sdr.rules index d5e812f..b775916 100644 --- a/rtl-sdr.rules +++ b/rtl-sdr.rules @@ -51,6 +51,9 @@ SUBSYSTEMS=="usb", ATTRS{idVendor}=="1f4d", ATTRS{idProduct}=="b803", MODE:="066 # Lifeview LV5TDeluxe (FC0012) SUBSYSTEMS=="usb", ATTRS{idVendor}=="1f4d", ATTRS{idProduct}=="c803", MODE:="0666" +# PROlectrix DV107669 (FC0012) +SUBSYSTEMS=="usb", ATTRS{idVendor}=="1f4d", ATTRS{idProduct}=="d803", MODE:="0666" + # Twintech UT-40 (FC0013) SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b80", ATTRS{idProduct}=="d3a4", MODE:="0666" diff --git a/src/librtlsdr.c b/src/librtlsdr.c index d961985..ba14942 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -210,6 +210,7 @@ static rtlsdr_dongle_t known_devices[] = { { 0x185b, 0x0680, "Compro Videomate U680F"}, { 0x1f4d, 0xb803, "GTek T803" }, { 0x1f4d, 0xc803, "Lifeview LV5TDeluxe" }, + { 0x1f4d, 0xd803, "PROlectrix DV107669" }, { 0x1b80, 0xd3a4, "Twintech UT-40" }, { 0x1d19, 0x1101, "Dexatek DK DVB-T Dongle (Logilink VG0002A)" }, { 0x1d19, 0x1102, "Dexatek DK DVB-T Dongle (MSI DigiVox mini II V3.0)" }, From wb6kcn at sbcglobal.net Sun May 20 23:27:10 2012 From: wb6kcn at sbcglobal.net (Erick Schumacher) Date: Sun, 20 May 2012 16:27:10 -0700 Subject: RTL-SDR Help Message-ID: <366C1C1A47694863A976A82445F78E58@EricLenovo> Hello group I need help getting an EZCAP USB deviceusing rtl_sdr running under Windoz7. This is probably the same bug reported on ticket 9 at http://sdr.osmocom.org/trac/query My EZCAP USB device self installs the drivers in Win7 and is recognized by the DVBDream program. Leads me to believe my system and hardware is OK. Below is a screen shot of what happens I try to load RTL-SDR.. I am an RF guy and a serious newby to software so can't contribute much. Help! Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 10929 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 35025 bytes Desc: not available URL: From davidm at davidm.com.au Sun May 20 23:55:15 2012 From: davidm at davidm.com.au (David McKenzie) Date: Mon, 21 May 2012 09:55:15 +1000 Subject: RTL-SDR Help In-Reply-To: <366C1C1A47694863A976A82445F78E58@EricLenovo> References: <366C1C1A47694863A976A82445F78E58@EricLenovo> Message-ID: Try running CMD as Administrator, may not have required permissions. Cheers, Dave On Mon, May 21, 2012 at 9:27 AM, Erick Schumacher wrote: > ** ** > > ** ** > > ** ** > > Hello group**** > > ** ** > > I need help getting an EZCAP USB deviceusing rtl_sdr running under > Windoz7. This is probably the same bug reported on ticket 9 at > http://sdr.osmocom.org/trac/query**** > > ** ** > > My EZCAP USB device self installs the drivers in Win7 and is recognized bythe > DVBDream program. Leads me to believe my system and hardware is OK. Below > is a screen shot of what happens I try to load RTL-SDR..**** > > ** ** > > **** > > ** ** > > I am an RF guy and a serious newby to software so can?t contribute much.** > ** > > ** ** > > Help!**** > > Eric**** > > **** > > ** ** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirepudsje at gmail.com Mon May 21 21:24:10 2012 From: kirepudsje at gmail.com (Kire Pudsje) Date: Mon, 21 May 2012 23:24:10 +0200 Subject: Octave wrapper for rtl-sdr Message-ID: I wrote for myself an octave wrapper for all functions in the header file of the rtl-sdr library. Even the async routine generates a callback to octave functions. The whole is a 1-to-1 mapping of the functions, I tried to stay as close as possible to the C-library. I do not know if it just me using octave, but if there is any interest in this code, I could place it somewhere. sample code: pkg load rtlsdr if rtlsdr_get_device_count()>0 dev = rtlsdr_open(0); samprate=2048e3; nsamples=2048; rtlsdr_set_sample_rate(dev, samprate); rtlsdr_set_center_freq(dev, 100e6); rtlsdr_set_tuner_gain_mode(dev, 0); rtlsdr_reset_buffer(dev); buf = rtlsdr_read_sync(dev, nsamples * 2); d = (double(buf) - 128) / 128.0; d = d(1:2:end) + 1i * d(2:2:end); f = (-.5:1/nsamples:.5-1/nsamples) * samprate; plot(f, 20*log10(abs(fftshift(fft(d .* blackman(nsamples)') / nsamples)))); rtlsdr_close(dev); end From osmosdr at mkarcher.dialup.fu-berlin.de Thu May 24 06:42:04 2012 From: osmosdr at mkarcher.dialup.fu-berlin.de (Michael Karcher) Date: Thu, 24 May 2012 08:42:04 +0200 Subject: [PATCH] FC0012 doc and fixes Message-ID: <1337841725-3632-1-git-send-email-osmosdr@mkarcher.dialup.fu-berlin.de> Fix selection of VCO band (needed for example to get to 166 MHz) for the FC0012 tuner, and add a lot of register descriptions. Signed-Off-by: Michael Karcher --- src/tuner_fc0012.c | 49 +++++++++++++++++++++++++++++++++---------------- 1 file changed, 33 insertions(+), 16 deletions(-) diff --git a/src/tuner_fc0012.c b/src/tuner_fc0012.c index 104a4f7..2d66f3c 100644 --- a/src/tuner_fc0012.c +++ b/src/tuner_fc0012.c @@ -20,21 +20,35 @@ /* Incomplete list of register settings: * * Name Reg Bits Desc + * CHIP_ID 0x00 0-7 Chip ID (constant 0xA1) + * RF_A 0x01 0-3 Number of count-to-9 cycles in RF + * divider (suggested: 2..9) + * RF_M 0x02 0-7 Total number of cycles (to-8 and to-9) + * in RF divider + * RF_K_HIGH 0x03 0-6 Bits 8..14 of fractional divider + * RF_K_LOW 0x04 0-7 Bits 0..7 of fractional RF divider + * RF_OUTDIV_A 0x05 3-7 Power of two required? * LNA_POWER_DOWN 0x06 0 Set to 1 to switch off low noise amp - * VCO_SPEED 0x06 3 Set the speed of the VCO. example - * driver hardcodes to 1 for some reason + * RF_OUTDIV_B 0x06 1 Set to select 3 instead of 2 for the + * RF output divider + * VCO_SPEED 0x06 3 Select tuning range of VCO: + * 0 = Low range, (ca. 1.1 - 1.5GHz) + * 1 = High range (ca. 1.4 - 1.8GHz) * BANDWIDTH 0x06 6-7 Set bandwidth. 6MHz = 0x80, 7MHz=0x40 * 8MHz=0x00 * XTAL_SPEED 0x07 5 Set to 1 for 28.8MHz Crystal input * or 0 for 36MHz + * 0x08 0-7 * EN_CAL_RSSI 0x09 4 Enable calibrate RSSI * (Receive Signal Strength Indicator) * LNA_FORCE 0x0d 0 * AGC_FORCE 0x0d ? - * LNA_GAIN 0x13 0-4 Low noise amp gain + * LNA_GAIN 0x13 3-4 Low noise amp gain * LNA_COMPS 0x15 3 ? * VCO_CALIB 0x0e 7 Set high then low to calibrate VCO - * + * (fast lock?) + * VCO_VOLTAGE 0x0e 0-6 Read Control voltage of VCO + * (big value -> low freq) */ /* glue functions to rtl-sdr code */ @@ -99,12 +113,11 @@ void FC0012_Dump_Registers() DEBUGF("LNA Force:\t%s\n", (regBuf & 0x1) ? "Forced" : "Not Forced"); FC0012_Read(pTuner, 0x13, ®Buf); DEBUGF("LNA Gain:\t"); - switch (regBuf) { - case (0x10): DEBUGF("19.7dB\n"); break; - case (0x17): DEBUGF("17.9dB\n"); break; - case (0x08): DEBUGF("7.1dB\n"); break; - case (0x02): DEBUGF("-9.9dB\n"); break; - default: DEBUGF("unknown gain value 0x02x\n"); + switch (regBuf & 0x18) { + case (0x00): DEBUGF("Low\n"); break; + case (0x08): DEBUGF("Middle\n"); break; + case (0x10): DEBUGF("High\n"); break; + default: DEBUGF("unknown gain value 0x18\n"); } #endif } @@ -173,7 +186,7 @@ void FC0012_Frequency_Control(unsigned int Frequency, unsigned short Bandwidth) int FC0012_SetFrequency(void *pTuner, unsigned long Frequency, unsigned short Bandwidth) { - int VCO1 = 0; + int VCO_band = 0; unsigned long doubleVCO; unsigned short xin, xdiv; unsigned char reg[21], am, pm, multi; @@ -230,7 +243,7 @@ int FC0012_SetFrequency(void *pTuner, unsigned long Frequency, unsigned short Ba doubleVCO = Frequency * multi; reg[6] = reg[6] | 0x08; - VCO1 = 1; + VCO_band = 1; xdiv = (unsigned short)(doubleVCO / (CrystalFreqKhz / 2)); if( (doubleVCO - xdiv * (CrystalFreqKhz / 2)) >= (CrystalFreqKhz / 4) ) xdiv = xdiv + 1; @@ -269,7 +282,6 @@ int FC0012_SetFrequency(void *pTuner, unsigned long Frequency, unsigned short Ba if (FC0012_Write(pTuner, 0x03, reg[3])) return -1; if (FC0012_Write(pTuner, 0x04, reg[4])) return -1; //reg[5] = reg[5] | 0x07; // This is really not cool. Why is it there? - // Same with hardcoding VCO=1 if (FC0012_Write(pTuner, 0x05, reg[5])) return -1; if (FC0012_Write(pTuner, 0x06, reg[6])) return -1; @@ -277,16 +289,19 @@ int FC0012_SetFrequency(void *pTuner, unsigned long Frequency, unsigned short Ba if (FC0012_Write(pTuner, 0x0E, 0x80)) return -1; if (FC0012_Write(pTuner, 0x0E, 0x00)) return -1; - // VCO Re-Calibration if needed + // Read resulting VCO control voltage if (FC0012_Write(pTuner, 0x0E, 0x00)) return -1; if (FC0012_Read(pTuner, 0x0E, &read_byte)) return -1; reg[14] = 0x3F & read_byte; - if (VCO1) + // Adjust VCO range if control voltage is at the limit + if (VCO_band) { + // high-band VCO hitting low frequency bound if (reg[14] > 0x3C) { - reg[6] = 0x08 | reg[6]; + // select low-band VCO + reg[6] = ~0x08 & reg[6]; if (FC0012_Write(pTuner, 0x06, reg[6])) return -1; if (FC0012_Write(pTuner, 0x0E, 0x80)) return -1; @@ -295,7 +310,9 @@ int FC0012_SetFrequency(void *pTuner, unsigned long Frequency, unsigned short Ba } else { + // low-band VCO hitting high frequency bound if (reg[14] < 0x02) { + // select high-band VCO reg[6] = 0x08 | reg[6]; if (FC0012_Write(pTuner, 0x06, reg[6])) return -1; -- 1.7.10 From steve at steve-m.de Thu May 24 10:47:07 2012 From: steve at steve-m.de (Steve Markgraf) Date: Thu, 24 May 2012 12:47:07 +0200 Subject: [PATCH] FC0012 doc and fixes In-Reply-To: <1337841725-3632-1-git-send-email-osmosdr@mkarcher.dialup.fu-berlin.de> References: <1337841725-3632-1-git-send-email-osmosdr@mkarcher.dialup.fu-berlin.de> Message-ID: <4FBE11AB.60308@steve-m.de> Hi, On 24.05.2012 08:42, Michael Karcher wrote: > Fix selection of VCO band (needed for example to get to 166 MHz) for > the FC0012 tuner, and add a lot of register descriptions. Thanks a lot, committed it to master. Regards, Steve From vogelchr at vogel.cx Fri May 25 12:24:59 2012 From: vogelchr at vogel.cx (Christian Vogel) Date: Fri, 25 May 2012 14:24:59 +0200 Subject: PATCH: Silence warning about int/socklen_t signedness Message-ID: <20120525122459.GA12147@vogel.cx> There's only one warning for me when compiling rtl-sdr, which is about the signedness of the third (size) argument in accept(). On linux it's socklen_t* and I *think* (google...) that windows does not have socklen_t at all. In accept it uses int. ftp://ftp.microsoft.com/bussys/winsock/winsock2/winsock2.h WINSOCK_API_LINKAGE SOCKET WSAAPI accept( IN SOCKET s, OUT struct sockaddr FAR * addr, IN OUT int FAR * addrlen ); Can someone please check if it compiles on windows with the attached patch? From vogelchr at vogel.cx Fri May 25 09:02:43 2012 From: vogelchr at vogel.cx (Christian Vogel) Date: Fri, 25 May 2012 11:02:43 +0200 Subject: [PATCH] Silence warning about socklen_t/int sign. Message-ID: rtl_tcp.c:457:57: warning: pointer types point to integer types with different sign passing 'int *', expected 'socklen_t *' [-Wpointer-sign] --- src/rtl_tcp.c | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/src/rtl_tcp.c b/src/rtl_tcp.c index 8b2cf44..849192b 100644 --- a/src/rtl_tcp.c +++ b/src/rtl_tcp.c @@ -42,6 +42,9 @@ #ifdef _WIN32 #pragma comment(lib, "ws2_32.lib") + +typedef int socklen_t; + #else #define closesocket close #define SOCKADDR struct sockaddr @@ -453,8 +456,10 @@ int main(int argc, char **argv) if(do_exit) { goto out; } else if(r) { - r=sizeof(remote); - s = accept(listensocket,(struct sockaddr *)&remote, &r); + socklen_t rlen; + + rlen=sizeof(remote); + s = accept(listensocket,(struct sockaddr *)&remote, &rlen); break; } } -- 1.7.0.4 --Nq2Wo0NMKNjxTN9z-- From joschi.brauchle at tum.de Fri May 25 19:43:28 2012 From: joschi.brauchle at tum.de (Joschi Brauchle) Date: Fri, 25 May 2012 21:43:28 +0200 Subject: Building with autotools - missing -lpthreads Message-ID: <4FBFE0E0.4040003@tum.de> Hello all, when trying to build with autotools, I get an compile error stating that there is a: ---- undefined reference to symbol 'pthread_create@@GLIBC_2.2.5' ---- This seems to be due to "-lpthreads" is missing when using autotools1 -- Dipl.-Ing. Joschi Brauchle, M.Sc. Institute for Communications Engineering (LNT) Technische Universitaet Muenchen (TUM) 80290 Munich, Germany Tel (work): +49 89 289-23474 Fax (work): +49 89 289-23490 E-mail: joschi.brauchle at tum.de Web: http://www.lnt.ei.tum.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4607 bytes Desc: S/MIME Cryptographic Signature URL: From horiz0n at gmx.net Fri May 25 21:22:53 2012 From: horiz0n at gmx.net (Dimitri Stolnikov) Date: Fri, 25 May 2012 23:22:53 +0200 Subject: Building with autotools - missing -lpthreads In-Reply-To: <4FBFE0E0.4040003@tum.de> References: <4FBFE0E0.4040003@tum.de> Message-ID: Hi Joschi, On Fri, 25 May 2012 21:43:28 +0200, Joschi Brauchle wrote: This seems to be due to "-lpthreads" is missing when using autotools1 thanks for reporting this. Please try the HEAD, it should work fine now. Dimitri From horiz0n at gmx.net Fri May 25 21:42:28 2012 From: horiz0n at gmx.net (Dimitri Stolnikov) Date: Fri, 25 May 2012 23:42:28 +0200 Subject: Octave wrapper for rtl-sdr In-Reply-To: References: Message-ID: Hi Kire, i just discovered your post on reddit http://www.reddit.com/r/RTLSDR/comments/u4pjc/measurements_of_e4000_filter_responses/ Thanks a lot for sharing your findings with the community. I'm looking forward to see the NF and IMD measurements :). Also i think the octave code has definitely educational value for me personally and likely for everyone else as well. Dimitri On Mon, 21 May 2012 23:24:10 +0200, Kire Pudsje wrote: > I wrote for myself an octave wrapper for all functions in the header > file of the rtl-sdr library. Even the async routine generates a > callback to octave functions. The whole is a 1-to-1 mapping of the > functions, I tried to stay as close as possible to the C-library. > I do not know if it just me using octave, but if there is any interest > in this code, I could place it somewhere. > > sample code: > pkg load rtlsdr > if rtlsdr_get_device_count()>0 > dev = rtlsdr_open(0); > samprate=2048e3; > nsamples=2048; > rtlsdr_set_sample_rate(dev, samprate); > rtlsdr_set_center_freq(dev, 100e6); > rtlsdr_set_tuner_gain_mode(dev, 0); > rtlsdr_reset_buffer(dev); > buf = rtlsdr_read_sync(dev, nsamples * 2); > d = (double(buf) - 128) / 128.0; > d = d(1:2:end) + 1i * d(2:2:end); > f = (-.5:1/nsamples:.5-1/nsamples) * samprate; > plot(f, 20*log10(abs(fftshift(fft(d .* blackman(nsamples)') / > nsamples)))); > rtlsdr_close(dev); > end From joschi.brauchle at tum.de Sat May 26 16:31:12 2012 From: joschi.brauchle at tum.de (Joschi Brauchle) Date: Sat, 26 May 2012 16:31:12 +0000 Subject: Building with autotools - missing -lpthreads In-Reply-To: References: <4FBFE0E0.4040003@tum.de> Message-ID: <51B7B4A3-E708-4EA8-AC4C-AD997F11E7B6@tum.de> Thanks for the quick fix. Everything works fine. I am currently in the process of building rpm packages for OpenSUSE 11.4 and up. I will post them to the list once I finished testing, in case someone is interested. Am 25.05.2012 um 23:22 schrieb "Dimitri Stolnikov" : > Hi Joschi, > > On Fri, 25 May 2012 21:43:28 +0200, Joschi Brauchle wrote: > > This seems to be due to "-lpthreads" is missing when using autotools1 > > thanks for reporting this. Please try the HEAD, it should work fine now. > > > Dimitri -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5428 bytes Desc: not available URL: From kirepudsje at gmail.com Sun May 27 14:23:51 2012 From: kirepudsje at gmail.com (Kire Pudsje) Date: Sun, 27 May 2012 16:23:51 +0200 Subject: Tuning gap between 325 and 350 MHz Message-ID: Also posted on reddit: I measured another stick and this time I also noticed the gap between 325 and 350 MHz, as was reported earlier by Roger on reddit. http://www.reddit.com/r/RTLSDR/comments/tftz4/some_frequency_response_measurements_potentially/ I could trace it back to the fact that the E4K_REG_SYNTH is not set properly. I do not know why yet, but first setting a different value from the desired one seems to fix the problem. It might be the wrong solution for the wrong problem, but it seems to work for me. change this line in tuner_e4k.c:448 rc = e4k_reg_set_mask(e4k, E4K_REG_SYNTH1, 0x06, band << 1); to: uint8_t tmp = e4k_reg_read(e4k, E4K_REG_SYNTH1) & ~0x06; tmp |= (band << 1) & 0x06; e4k_reg_write(e4k, E4K_REG_SYNTH1, tmp ^ 0x06); rc = e4k_reg_write(e4k, E4K_REG_SYNTH1, tmp); Kire.