From james at peroulas.com Tue Sep 4 23:22:49 2012 From: james at peroulas.com (James Peroulas) Date: Tue, 4 Sep 2012 18:22:49 -0500 Subject: "Best" sampling rate? Message-ID: I was wondering if certain sampling rates were better than others for the RTL2832 dongles? I'm finding that if the sampling rate is below 1.1MSPS, I get few samples being dropped (but they still get dropped). Above this rate, randomly, I get a multiple of 94 samples being dropped. Are there certain sampling frequencies that are sweet-spots for the RTL2832 that produce very stable performance? Perhaps frequencies that are a fraction of DVB sampling frequencies? JP -- Integrity is a binary state - either you have it or you don?t. - John Doerr From benryanau at hotmail.com Wed Sep 5 19:22:25 2012 From: benryanau at hotmail.com (Ben Ryan) Date: Thu, 6 Sep 2012 05:22:25 +1000 Subject: "Best" sampling rate? In-Reply-To: References: Message-ID: Come to think of it, I've also found some samplerates to be better than others. No further info to share beyond the fact that I've noticed it too. Drops at higher samplerates are probably due to your CPU, IO latency, etc (esp if virtualised). You should be able to run 2.048Msps with AF rate of 44.1khz with next to no drops and smooth carrier audio. If not, and your CPU isn't maxed out, likely you have a latency or bandwidth issue. What's the rig you're running on? There appears to be an interaction between AF samplerate and IQ samplerate.. under HDSDR/Win32 anyways. It might well reduce skips and cpu load if the two rates were cleanly divisible but I haven't tried to work the theoreticals out.. I just set 3.2Msps for spectrum scoping, then narrow to around 1.2Msps for FM/AM work. The audio rate is usually 44.1khz although sometimes whendoing an "audio print" of a signal using DRM mode I'll up it to 48khz. On the Core2Duo I get quite a few dropped samples at 3.2Msps/48khz though - it's hitting the limits for this system as-is (it's running VMWare MS plus it's got layers of drivers on it). Another thing to consider if under Win32: differing versions of libusb, ExtIO_RTL, ExtIO_USRP, rtl2832u++.dll files all behave differently wrt cpu, samplerates and drops. I haven't documented my findings yet but there's a complex relationship between the above elements and tuner range.. some RTL libs will permit 50mhz-~2000mhz, others puke at various spots on the dial etc. > I was wondering if certain sampling rates were better than others for > the RTL2832 dongles? I'm finding that if the sampling rate is below > 1.1MSPS, I get few samples being dropped (but they still get dropped). > Above this rate, randomly, I get a multiple of 94 samples being > dropped. > > Are there certain sampling frequencies that are sweet-spots for the > RTL2832 that produce very stable performance? Perhaps frequencies that > are a fraction of DVB sampling frequencies? > > JP > > -- > Integrity is a binary state - either you have it or you don?t. - John Doerr -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at peroulas.com Thu Sep 6 20:16:21 2012 From: james at peroulas.com (James Peroulas) Date: Thu, 6 Sep 2012 15:16:21 -0500 Subject: "Best" sampling rate? Message-ID: Message: 1 > Date: Thu, 6 Sep 2012 05:22:25 +1000 > From: Ben Ryan > To: > Subject: "Best" sampling rate? > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > > > > Come to think of it, I've also found some samplerates to be better than > others. No further info to share beyond the fact that I've noticed it too. > > Drops at higher samplerates are probably due to your CPU, IO latency, etc > (esp if virtualised). You should be able to run 2.048Msps with AF rate of > 44.1khz with next to no drops and smooth carrier audio. If not, and your > CPU isn't maxed out, likely you have a latency or bandwidth issue. > What's the rig you're running on? > > There appears to be an interaction between AF samplerate and IQ > samplerate.. under HDSDR/Win32 anyways. > It might well reduce skips and cpu load if the two rates were cleanly > divisible but I haven't tried to work the theoreticals out.. > > I just set 3.2Msps for spectrum scoping, then narrow to around 1.2Msps for > FM/AM work. The audio rate is usually 44.1khz although sometimes whendoing > an "audio print" of a signal using DRM mode I'll up it to 48khz. On the > Core2Duo I get quite a few dropped samples at 3.2Msps/48khz though - it's > hitting the limits for this system as-is (it's running VMWare MS plus it's > got layers of drivers on it). > > Another thing to consider if under Win32: differing versions of libusb, > ExtIO_RTL, ExtIO_USRP, rtl2832u++.dll files all behave differently wrt cpu, > samplerates and drops. > I haven't documented my findings yet but there's a complex relationship > between the above elements and tuner range.. some RTL libs will permit > 50mhz-~2000mhz, others puke at various spots on the dial etc. > Thanks for the inspiration. I actually re-wrote my code to use async mode and now I'm getting reliable captures up to 1.92MSPS (my desired sampling rate). I was using sync mode but apparently that's not fast enough to capture all samples! BR, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From forum.chronicler at gmail.com Thu Sep 6 23:06:30 2012 From: forum.chronicler at gmail.com (Bharath Bhushan Lohray) Date: Thu, 6 Sep 2012 18:06:30 -0500 Subject: ISDB-T USB TV RTL-SDR FM+DAB Radio Tuner Receiver Stick Realtek RTL2832U E4000 In-Reply-To: References: Message-ID: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=271041428220 I am new to SDR and such hardware. The ebay listing states that the hardware does not work in the US. I am wondering if this hardware is going to work for the purpose of playing around as a SDR? Thank you, Bharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.gugliuzza at hacklabproject.org Thu Sep 6 23:16:09 2012 From: f.gugliuzza at hacklabproject.org (Francesco Gugliuzza) Date: Fri, 7 Sep 2012 01:16:09 +0200 Subject: ISDB-T USB TV RTL-SDR FM+DAB Radio Tuner Receiver Stick Realtek RTL2832U E4000 In-Reply-To: References: Message-ID: As long as it has a RTL2832 and a compatible tuner, it'll work everywhere as a SDR. You can't watch US digital television though, since it's broadcasted in a standard the chip can't decode. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steve-m.de Sat Sep 8 17:51:25 2012 From: steve at steve-m.de (Steve Markgraf) Date: Sat, 08 Sep 2012 19:51:25 +0200 Subject: R820T tuner support in librtlsdr Message-ID: <504B859D.3020206@steve-m.de> Hi list, yesterday I committed code for the Rafael Micro R820T tuner to librtlsdr. Sticks with this combination (RTL2832 + R820T) are relatively new on the market. The main difference to all the other supported tuners so far is that it uses a Low-IF (3.57 MHz) architecture instead of Zero-IF. That means the tuner is only connected to the In-Phase ADC input, and the internal downconverter of the RTL2832 is generating the complex samples. This has the benefit of having no DC offset spike in the middle of the spectrum. So far the tuner driver comes straight from the kernel driver that Realtek supplies, and setting gain manually is not supported yet, although functions for that seem to exist. There is still is a lot that needs to be done, the best thing most likely would be to completely rewrite the driver, or at least clean it up dramatically. Initializing the tuner takes way too long at the moment, since the driver produces a lot of I2C traffic, most of it being redundant as it seems. The driver originally had a frequency limitation of 40 MHz to 900 MHz, but tests showed that the PLL of my stick can achieve lock up to 1766 MHz, and indeed both ADS-B at 1090 MHz and L-Band DAB at 1463 MHz, as well as GMR at 1556 MHz can be received just fine with the R820T. Also, the PLL could lock again at 1850 MHz to 1860 MHz, and the reception of a GSM 1800 BTS at 1854 MHz worked as well. Some initial comparisons [1] between the E4000 and R820T seem to hint at the R820T being a bit more sensitive, especially visible in the Tetra screenshots. Given that the supply of E4000-based sticks is dwindling, I'm pleased to see a new tuner that has the potential of becoming a good replacement, and staying for a while on the market. Regards, Steve [1] http://steve-m.de/projects/rtl-sdr/tuner_comparison From a.nielsen at shikadi.net Sat Sep 8 23:29:15 2012 From: a.nielsen at shikadi.net (Adam Nielsen) Date: Sun, 09 Sep 2012 09:29:15 +1000 Subject: R820T tuner support in librtlsdr In-Reply-To: <504B859D.3020206@steve-m.de> References: <504B859D.3020206@steve-m.de> Message-ID: <504BD4CB.2020802@shikadi.net> Hi Steve, > yesterday I committed code for the Rafael Micro R820T tuner to > librtlsdr. That's great! The code Rafael supply doesn't look very neat, and I haven't been able to get a register map out of them either, so great job on getting it to work with librtlsdr. > Sticks with this combination (RTL2832 + R820T) are relatively new on > the market. The main difference to all the other supported tuners so > far is that it uses a Low-IF (3.57 MHz) architecture instead of > Zero-IF. That means the tuner is only connected to the In-Phase ADC > input, and the internal downconverter of the RTL2832 is generating the > complex samples. This has the benefit of having no DC offset spike in > the middle of the spectrum. If I have read the datasheets correctly, the E4000 is also able to use a non-zero IF. Would doing this help reduce the spike in the middle of the spectrum for sticks using the E4000? > The driver originally had a frequency limitation of 40 MHz to 900 MHz, > but tests showed that the PLL of my stick can achieve lock up to 1766 > MHz, and indeed both ADS-B at 1090 MHz and L-Band DAB at 1463 MHz, as well as > GMR at 1556 MHz can be received just fine with the R820T. > Also, the PLL could lock again at 1850 MHz to 1860 MHz, and the > reception of a GSM 1800 BTS at 1854 MHz worked as well. Wow, this sounds like a really good IC! I might have to go buy one now :-) Cheers, Adam. From christian.buchner at gmail.com Sun Sep 9 19:01:28 2012 From: christian.buchner at gmail.com (Christian Buchner) Date: Sun, 9 Sep 2012 21:01:28 +0200 Subject: R820T tuner support in librtlsdr In-Reply-To: <504BD4CB.2020802@shikadi.net> References: <504B859D.3020206@steve-m.de> <504BD4CB.2020802@shikadi.net> Message-ID: > If I have read the datasheets correctly, the E4000 is also able to use a > non-zero IF. Would doing this help reduce the spike in the middle of the > spectrum for sticks using the E4000? Here's a question for windows users.... Why do I not see a notable spike in the middle of the spectrum spike in the SDR Sharp application, but a very strong one in the HDSDR application using same the same USB dongle? This strikes me as odd. Christian From frubi at frubi.net Sun Sep 9 19:18:50 2012 From: frubi at frubi.net (Felix Rublack) Date: Sun, 09 Sep 2012 21:18:50 +0200 Subject: R820T tuner support in librtlsdr In-Reply-To: References: <504B859D.3020206@steve-m.de> <504BD4CB.2020802@shikadi.net> Message-ID: <504CEB9A.9090903@frubi.net> Hi! Am 09.09.2012 21:01, schrieb Christian Buchner: > Here's a question for windows users.... Why do I not see a notable spike > in the middle of the spectrum spike in the SDR Sharp application, but a very > strong one in the HDSDR application using same the same USB dongle? There is a "Correct IQ" option in SDR# to fix the DC offset (DC offset = spike at center frequency). If you disable this option, you should see the spike in SDR#. Greetings Felix From jsalsburg at bellsouth.net Sun Sep 9 21:47:07 2012 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Sun, 9 Sep 2012 16:47:07 -0500 Subject: R820T tuner support in librtlsdr In-Reply-To: References: <504B859D.3020206@steve-m.de> <504BD4CB.2020802@shikadi.net> Message-ID: It is probably the difference in RF Gain. Jay Salsburg -----Original Message----- From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Christian Buchner Sent: Sunday, September 09, 2012 2:01 PM To: osmocom-sdr at lists.osmocom.org Subject: Re: R820T tuner support in librtlsdr > If I have read the datasheets correctly, the E4000 is also able to use > a non-zero IF. Would doing this help reduce the spike in the middle > of the spectrum for sticks using the E4000? Here's a question for windows users.... Why do I not see a notable spike in the middle of the spectrum spike in the SDR Sharp application, but a very strong one in the HDSDR application using same the same USB dongle? This strikes me as odd. Christian From scott at scottcutler.net Tue Sep 25 22:36:11 2012 From: scott at scottcutler.net (Scott Cutler) Date: Tue, 25 Sep 2012 15:36:11 -0700 Subject: Licensing issues Message-ID: Greetings, all! I've recently been bitten by the rtlsdr bug and have since developed some software around it. It's Windows-based and currently decodes (mono) WFM, NFM, POCSAG, FLEX 1600/6400, and (very limited) AX.25 frames. I would like to make a semi-limited release but have some concerns about the licensing of the rtlsdr library after what SDR# went through (or seemed to go through--I'm not sure what the whole story was). I do plan on open-sourcing the whole thing eventually, but in the short term I'll probably have a limited read-only license. Simply put, am I in the clear if I: - only access rtlsdr.dll through my own reimplementation of rtl-sdr.h and rtl-sdr_export.h - do not distribute the binary rtlsdr.dll, but instead link to the Osmocom binaries Thanks for the help! - Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Wed Sep 26 04:17:29 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 26 Sep 2012 00:17:29 -0400 Subject: Licensing issues In-Reply-To: References: Message-ID: Hi, > Simply put, am I in the clear if I: > - only access rtlsdr.dll through my own reimplementation of rtl-sdr.h and > rtl-sdr_export.h > - do not distribute the binary rtlsdr.dll, but instead link to the Osmocom > binaries Simply put: No. Cheers, Sylvain From scott at scottcutler.net Wed Sep 26 04:30:21 2012 From: scott at scottcutler.net (Scott Cutler) Date: Tue, 25 Sep 2012 21:30:21 -0700 Subject: Licensing issues In-Reply-To: References: Message-ID: Do you have suggestions, then, as to the approach I should take? I plan on using a GPL-compatible license eventually, but the code isn't ready for that yet, and I'd like to head off any licensing issues in advance. What about interfacing only with ExtIO? So far, I have avoided that option because I've only had access to rtlsdr devices. Thanks for any help! - Scott On Tue, Sep 25, 2012 at 9:17 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > > Simply put, am I in the clear if I: > > - only access rtlsdr.dll through my own reimplementation of rtl-sdr.h and > > rtl-sdr_export.h > > - do not distribute the binary rtlsdr.dll, but instead link to the > Osmocom > > binaries > > Simply put: No. > > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Wed Sep 26 04:34:23 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 26 Sep 2012 00:34:23 -0400 Subject: Licensing issues In-Reply-To: References: Message-ID: On Wed, Sep 26, 2012 at 12:30 AM, Scott Cutler wrote: > Do you have suggestions, then, as to the approach I should take? I plan on > using a GPL-compatible license eventually, but the code isn't ready for that > yet, and I'd like to head off any licensing issues in advance. What about > interfacing only with ExtIO? So far, I have avoided that option because > I've only had access to rtlsdr devices. ExtIO would be acceptable if you don't distribute it bundled with it. rtl_tcp is the completely isolated way. Cheers, Sylvain PS: Of course this does not constitute legal advice and only represent my personal opinion and I don't represent all the copyright owners ... (I mean how could I ? Realtek owns some of the code in there AFAIK ...) From alexander.chemeris at gmail.com Wed Sep 26 04:40:40 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 26 Sep 2012 00:40:40 -0400 Subject: Licensing issues In-Reply-To: References: Message-ID: On Wed, Sep 26, 2012 at 12:30 AM, Scott Cutler wrote: > Do you have suggestions, then, as to the approach I should take? I plan on > using a GPL-compatible license eventually, but the code isn't ready for that > yet Suggestion - don't spend time circumventing the GPL compatibility and release your code in open-source from the day one. Saved time could spend to get the software working better. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From scott at scottcutler.net Wed Sep 26 04:41:12 2012 From: scott at scottcutler.net (Scott Cutler) Date: Tue, 25 Sep 2012 21:41:12 -0700 Subject: Licensing issues In-Reply-To: References: Message-ID: Understood--thanks. I am not looking for legal advice, just reasonable confidence that I won't be responsible for a "diplomatic incident". I don't want to make enemies with a simple software release. - Scott On Tue, Sep 25, 2012 at 9:34 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > On Wed, Sep 26, 2012 at 12:30 AM, Scott Cutler > wrote: > > Do you have suggestions, then, as to the approach I should take? I plan > on > > using a GPL-compatible license eventually, but the code isn't ready for > that > > yet, and I'd like to head off any licensing issues in advance. What > about > > interfacing only with ExtIO? So far, I have avoided that option because > > I've only had access to rtlsdr devices. > > ExtIO would be acceptable if you don't distribute it bundled with it. > > rtl_tcp is the completely isolated way. > > > Cheers, > > Sylvain > > > PS: Of course this does not constitute legal advice and only represent > my personal opinion and I don't represent all the copyright owners ... > (I mean how could I ? Realtek owns some of the code in there AFAIK > ...) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at scottcutler.net Wed Sep 26 05:18:10 2012 From: scott at scottcutler.net (Scott Cutler) Date: Tue, 25 Sep 2012 22:18:10 -0700 Subject: Licensing issues In-Reply-To: References: Message-ID: I have nothing against the GPL--but to me it represents an unknown that I would like to get out of the way as early as possible so that I no longer have to think about it. Although the software will never be commercial, I may have a future purpose for the software that involves connecting with closed-source code, and I simply don't know enough about the legal aspects there. I'd rather err on the side of safety when it comes to licensing. Part of the reason for developing my own software was to avoid just these kinds of difficulties. Also, since ExtIO was on my list of things to support anyway, I may as well do it sooner rather than later. At any rate, thanks for the advice. -Scott On Tue, Sep 25, 2012 at 9:40 PM, Alexander Chemeris < alexander.chemeris at gmail.com> wrote: > On Wed, Sep 26, 2012 at 12:30 AM, Scott Cutler > wrote: > > Do you have suggestions, then, as to the approach I should take? I plan > on > > using a GPL-compatible license eventually, but the code isn't ready for > that > > yet > > Suggestion - don't spend time circumventing the GPL compatibility and > release your code in open-source from the day one. Saved time could > spend to get the software working better. > > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves LLC / ??? ??????? > http://fairwaves.ru > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at sdr-radio.com Wed Sep 26 08:22:00 2012 From: simon at sdr-radio.com (Simon G4ELI/HB9DRV) Date: Wed, 26 Sep 2012 10:22:00 +0200 Subject: Licensing issues In-Reply-To: References: Message-ID: <061c01cd9bc0$00657e50$01307af0$@sdr-radio.com> Scott, I?m in the situation where I can?t ship my code because I use commercial libraries which prevents me from supporting the RTL SDR as I can?t ship these libraries. The only way my software can support this device is for another developer to write a DLL which conforms to my own spec. (similar to ExtIO but different). Simon G4ELI/HB9DRV http://dit-dit-dit.com From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Scott Cutler Although the software will never be commercial, I may have a future purpose for the software that involves connecting with closed-source code, and I simply don't know enough about the legal aspects there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Wed Sep 26 08:29:02 2012 From: peter at stuge.se (Peter Stuge) Date: Wed, 26 Sep 2012 10:29:02 +0200 Subject: Licensing issues In-Reply-To: References: Message-ID: <20120926082902.7820.qmail@stuge.se> Scott Cutler wrote: > I have nothing against the GPL--but to me it represents an unknown Why don't you make it a known? It's not really difficult to use dual licensing for your software should you want that at some point. > I may have a future purpose for the software that involves connecting with > closed-source code, and I simply don't know enough about the legal aspects > there. So FIND OUT. You can ask license-related questions on the list too. //Peter From scott at scottcutler.net Wed Sep 26 08:45:56 2012 From: scott at scottcutler.net (Scott Cutler) Date: Wed, 26 Sep 2012 01:45:56 -0700 Subject: Licensing issues In-Reply-To: <20120926082902.7820.qmail@stuge.se> References: <20120926082902.7820.qmail@stuge.se> Message-ID: <5062C0C4.7090408@scottcutler.net> Dual-licensing is an option I've considered. It may work, but I haven't thought through it fully yet. The short answer here is that the legal stuff is *unbelievably boring* to me in comparison to coding, so if I can write 10 hours of code to save 2 hours of bashing my head against license documents, I will. The rtl_tcp route sounds valid, and easy, and something I'd want anyway. I know there was a lot of drama surrounding SDR#, which is precisely why I came here to clear things up and not repeat the same mistakes. So who wants to talk about actual SDR stuff instead? I see on the Osmocom pages that people already have POCSAG decoding, but FLEX isn't mentioned (I've only seen closed-source decoders). I have it working pretty well, both at 1600 and 6400 bps. Amazing how much medical stuff is being broadcast in the clear... -Scott On 9/26/2012 1:29 AM, Peter Stuge wrote: > Scott Cutler wrote: >> I have nothing against the GPL--but to me it represents an unknown > Why don't you make it a known? > > It's not really difficult to use dual licensing for your software > should you want that at some point. > > >> I may have a future purpose for the software that involves connecting with >> closed-source code, and I simply don't know enough about the legal aspects >> there. > So FIND OUT. You can ask license-related questions on the list too. > > > //Peter > From peter at stuge.se Wed Sep 26 08:49:46 2012 From: peter at stuge.se (Peter Stuge) Date: Wed, 26 Sep 2012 10:49:46 +0200 Subject: Licensing issues In-Reply-To: <5062C0C4.7090408@scottcutler.net> References: <20120926082902.7820.qmail@stuge.se> <5062C0C4.7090408@scottcutler.net> Message-ID: <20120926084946.9526.qmail@stuge.se> Scott Cutler wrote: > The short answer here is that the legal stuff is *unbelievably boring* to > me in comparison to coding, so if I can write 10 hours of code to save 2 > hours of bashing my head against license documents, I will. > > The rtl_tcp route sounds valid, and easy, and something I'd want anyway. The interface clearly goes against the spirit of the license though. You shouldn't want to use it, if that makes sense. //Peter From scott at scottcutler.net Wed Sep 26 09:06:40 2012 From: scott at scottcutler.net (Scott Cutler) Date: Wed, 26 Sep 2012 02:06:40 -0700 Subject: Licensing issues In-Reply-To: <20120926084946.9526.qmail@stuge.se> References: <20120926082902.7820.qmail@stuge.se> <5062C0C4.7090408@scottcutler.net> <20120926084946.9526.qmail@stuge.se> Message-ID: <5062C5A0.5040600@scottcutler.net> A separate executable, interfaced only over the network, implies pretty wide separation in my opinion. Web browsers that connect to GPL web servers aren't obligated to be open. The reason I'd want it anyway is the network transparency--once I thought about it some, I really like the idea of setting up 3-4 dongles in my attic with different antennas. I have a server up there already, so I wouldn't need to run more wiring. Look, as I said, I plan on open-sourcing this stuff anyway. I just need to reserve the possibility of distributing a closed-source personal branch that's still compatible with rtlsdr, and to possibly have a temporary period with a more restrictive license, like MS-RSL. I haven't decided yet, at any rate. It may just remain a personal pet project if I don't have enough time to spend improving it first. -Scott On 9/26/2012 1:49 AM, Peter Stuge wrote: > Scott Cutler wrote: >> The short answer here is that the legal stuff is *unbelievably boring* to >> me in comparison to coding, so if I can write 10 hours of code to save 2 >> hours of bashing my head against license documents, I will. >> >> The rtl_tcp route sounds valid, and easy, and something I'd want anyway. > The interface clearly goes against the spirit of the license though. > You shouldn't want to use it, if that makes sense. > > > //Peter > From scott at scottcutler.net Wed Sep 26 10:23:38 2012 From: scott at scottcutler.net (Scott Cutler) Date: Wed, 26 Sep 2012 03:23:38 -0700 Subject: Issues with rtl_tcp Message-ID: <5062D7AA.7050506@scottcutler.net> I've ported my app to use rtl_tcp.exe instead of the native rtlsdr libs, and while it is partly working (samples reading correctly, no dropped samples, etc.), I have run into two issues. First--when I start reading samples too quickly after setting the sample rate, I get this error: C:\Users\Scott Cutler\Projects\p4\0\projects\sdr\SeeDeR\SeeDeR\rtl-sdr-release\x32>rtl_tcp.exe -f 100000000 -s 2048000 Found 1 device(s). Found Elonics E4000 tuner Using Generic RTL2832U (e.g. hama nano) Tuned to 100000000 Hz. listening... Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR (gr-osmosdr) source to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...). client accepted! set freq 105000000 set sample rate 1920000 worker cond timeout Signal caught, exiting! comm recv socket error Signal caught, exiting! all threads dead.. listening... Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR (gr-osmosdr) source to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...). If I instead wait about two seconds after setting the sample rate, there is no problem. There is also no problem if I immediately read samples after connecting, where I set the sample rate on the command line. The other issue is that tuning is very slow--about one second per call to rtlsdr_set_center_freq. I had a similar problem with the rtlsdr.dll library, and I found that tuning was very slow if performed from the main thread, but fairly quick (maybe 10-20 hz) if done from the async proc thread that rtlsdr_read_async launches. That seemed a bit odd to me but it worked. I suspect that rtl_tcp.exe is doing the same thing; calling rtlsdr_set_center_freq from the main thread. Ideas, anyone? Thanks! -Scott PS: I'm running Win7-64, in case it matters. Also using the latest version here: http://sdr.osmocom.org/trac/attachment/wiki/rtl-sdr/RelWithDebInfo.zip -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at scottcutler.net Wed Sep 26 10:35:34 2012 From: scott at scottcutler.net (Scott Cutler) Date: Wed, 26 Sep 2012 03:35:34 -0700 Subject: Issues with rtl_tcp In-Reply-To: <5062D7AA.7050506@scottcutler.net> References: <5062D7AA.7050506@scottcutler.net> Message-ID: <5062DA76.10808@scottcutler.net> Slight correction/clarification to the below: obviously, I am not calling rtlsdr_set_center_freq when using rtl_tcp.exe. Instead, what I see is that I can queue up a bunch of tuning calls, but they only kick in at a very slow rate (1 hz). The effect is similar to when I used the native libs, where rtlsdr_set_center_freq also took 1 s on the main thread. -Scott On 9/26/2012 3:23 AM, Scott Cutler wrote: > I've ported my app to use rtl_tcp.exe instead of the native rtlsdr > libs, and while it is partly working (samples reading correctly, no > dropped samples, etc.), I have run into two issues. > > First--when I start reading samples too quickly after setting the > sample rate, I get this error: > C:\Users\Scott > Cutler\Projects\p4\0\projects\sdr\SeeDeR\SeeDeR\rtl-sdr-release\x32>rtl_tcp.exe > -f 100000000 -s 2048000 > Found 1 device(s). > Found Elonics E4000 tuner > Using Generic RTL2832U (e.g. hama nano) > Tuned to 100000000 Hz. > listening... > Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR > (gr-osmosdr) source > to receive samples in GRC and control rtl_tcp parameters (frequency, > gain, ...). > client accepted! > set freq 105000000 > set sample rate 1920000 > worker cond timeout > Signal caught, exiting! > comm recv socket error > Signal caught, exiting! > all threads dead.. > listening... > Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR > (gr-osmosdr) source > to receive samples in GRC and control rtl_tcp parameters (frequency, > gain, ...). > > If I instead wait about two seconds after setting the sample rate, > there is no problem. There is also no problem if I immediately read > samples after connecting, where I set the sample rate on the command line. > > The other issue is that tuning is very slow--about one second per call > to rtlsdr_set_center_freq. I had a similar problem with the > rtlsdr.dll library, and I found that tuning was very slow if performed > from the main thread, but fairly quick (maybe 10-20 hz) if done from > the async proc thread that rtlsdr_read_async launches. > > That seemed a bit odd to me but it worked. I suspect that rtl_tcp.exe > is doing the same thing; calling rtlsdr_set_center_freq from the main > thread. > > Ideas, anyone? Thanks! > > -Scott > > PS: I'm running Win7-64, in case it matters. Also using the latest > version here: > http://sdr.osmocom.org/trac/attachment/wiki/rtl-sdr/RelWithDebInfo.zip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simeon.miteff at gmail.com Wed Sep 26 11:26:56 2012 From: simeon.miteff at gmail.com (Simeon Miteff) Date: Wed, 26 Sep 2012 13:26:56 +0200 Subject: Issues with rtl_tcp In-Reply-To: <5062DA76.10808@scottcutler.net> References: <5062D7AA.7050506@scottcutler.net> <5062DA76.10808@scottcutler.net> Message-ID: <5062E680.2050809@gmail.com> Hi Scott On 09/26/12 12:35, Scott Cutler wrote: > Slight correction/clarification to the below: obviously, I am not > calling rtlsdr_set_center_freq when using rtl_tcp.exe. Instead, what I > see is that I can queue up a bunch of tuning calls, but they only kick > in at a very slow rate (1 hz). The effect is similar to when I used the > native libs, where rtlsdr_set_center_freq also took 1 s on the main thread. I experienced the same maximum 1 hz tuning rate with rtl_tcp. A quick look at the code shows a select() call in the command_worker thread with a timeout set to 1s, but that doesn't explain the observed behavior, because, as I understand select(), it should return as soon as the UDP socket has data available (the timeout is used to allow the thread to terminate when rtl_tcp shuts down). Nevertheless, my spidey sense tells me this is the place to look... Regards, Simeon. From alexander.chemeris at gmail.com Wed Sep 26 11:52:47 2012 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 26 Sep 2012 07:52:47 -0400 Subject: Licensing issues In-Reply-To: <5062C5A0.5040600@scottcutler.net> References: <20120926082902.7820.qmail@stuge.se> <5062C0C4.7090408@scottcutler.net> <20120926084946.9526.qmail@stuge.se> <5062C5A0.5040600@scottcutler.net> Message-ID: On Wed, Sep 26, 2012 at 5:06 AM, Scott Cutler wrote: > Look, as I said, I plan on open-sourcing this stuff anyway. I just need to > reserve the possibility of distributing a closed-source personal branch > that's still compatible with rtlsdr, and to possibly have a temporary period > with a more restrictive license, like MS-RSL. Note, that GPL has nothing to do with your personal use. GPL is triggered only when you convey your software to someone else, either by publishing on the Internet, or passing a flash drive from hands to hands. In both (and all other) cases GPL'ed software should be accompanied with the respective source code. If you do not give the software to anybody and use it by yourself - you don't have any obligations about the source code. If you give your software to someone on a flash drive, you don't need to put the source code on the Internet, it's fine to put them on the same flash drive. But the person who received the source code will be free to put the on the Internet. This is in short. And surely, this is not a legal advise, etc, etc. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From simos.lists at googlemail.com Wed Sep 26 12:56:57 2012 From: simos.lists at googlemail.com (Simos Xenitellis) Date: Wed, 26 Sep 2012 15:56:57 +0300 Subject: Licensing issues In-Reply-To: References: Message-ID: On Wed, Sep 26, 2012 at 8:18 AM, Scott Cutler wrote: > I have nothing against the GPL--but to me it represents an unknown that I > would like to get out of the way as early as possible so that I no longer > have to think about it. Although the software will never be commercial, I > may have a future purpose for the software that involves connecting with > closed-source code, and I simply don't know enough about the legal aspects > there. I'd rather err on the side of safety when it comes to licensing. > Part of the reason for developing my own software was to avoid just these > kinds of difficulties. > If you keep the full copyright of the source code (that is, if you are the main developer and any other co-developers assign the copyright of their contributions to you), then you can relicense at will the new future versions of the source code. However, the best approach would be to get into contact with the SLFC, http://www.softwarefreedom.org/ These licensing issues are their centre of interest, they like these things and they will help you decide which approach is best. Some terms that help when communicating with the SFLC are 1. 'free software' is software that abides to the Free Software definition, http://en.wikipedia.org/wiki/The_Free_Software_Definition Practically, software licensed with the GPL is 'free software'. 2. 'open-source software' is software that make available the source code but do not fully abide with the Free Software Definition. Here you have the BSD-style licenses (you can take the source code, and you are permitted, if you want, to keep private your enhancements of your product) or the MPL license (the core is like free software, but it's OK to link with closed-source software). 3. 'copyright', anything you create has your copyright, which by default gives you exclusive rights to your creation. If you want others to use your creation, you add a license. Such as one of the above licenses. The free and open-source licences try to fix the situation that too few rights were given with proprietary software. 4. The aim of the free software movement is to create an ecosystem of free software, so that you are not stuck with some proprietary core component that hijacks the whole software stack. It's a novel aim. Simos From simon at sdr-radio.com Wed Sep 26 15:42:29 2012 From: simon at sdr-radio.com (Simon G4ELI/HB9DRV) Date: Wed, 26 Sep 2012 17:42:29 +0200 Subject: OsmoSDR Message-ID: <06fb01cd9bfd$897c0550$9c740ff0$@sdr-radio.com> Hi All, I stumbled across the OsmoSDR on http://sdr.osmocom.org/trac/ - does this supply 16-bit or maybe even higher samples? It looks great J , I'm sure a high quality SDR with this frequency range will be very popular. Simon G4ELI/HB9DRV http://dit-dit-dit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From leif at sm5bsz.com Wed Sep 26 19:33:43 2012 From: leif at sm5bsz.com (Leif Asbrink) Date: Wed, 26 Sep 2012 21:33:43 +0200 Subject: Issues with rtl_tcp In-Reply-To: <5062D7AA.7050506@scottcutler.net> References: <5062D7AA.7050506@scottcutler.net> Message-ID: <20120926213343.10f7cc38.leif@sm5bsz.com> Hi All, The GNU licencing of rtl-sdr is the GNU GENERAL PUBLIC LICENSE. There is also the GNU LIBRARY GENERAL PUBLIC LICENSE that better specifies some of the concepts used by the Free Software Foundation, Inc. The library license states that one can change from it to the general license but that one then not can change back: "Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy." I am not a lawyer, but it seems to me that this statement implicates that the library license is more restricted and that things you are allowed to do under the library license are still allowed under the general license. In the library license we can read this: "5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License." This means you are free to use the rtlsdr dll available at osmocom but you can not distribute an executable in which the library is linked in. Likewise can I distribute Linrad under Linux and give the user the instructions how to link in librtl.so from the osmocom site or from a complete and somewhat modified version that I will supply myself in case the modifications to the library I will propose will not be accepted. The e4k tuner works very well, actually it is very competitive when compared to the FUNcube Pro dongle, but only with a modified library. http://www.sm5bsz.com/linuxdsp/hware/funcube/funcube.htm At the moment I am working with the FC0013 code. So far I found these things: The original code uses AGC. To disable it I change the init for registers 0x0cc and 0x0d: [0x0c]=0x78 (normal) or 0xb8 (-35 dB gain) [0x0d]=0x81 (normal) or 0x89 (-60 dB gain) Regards Leif / SM5BSZ PS. The reason I worry about the GNU license is that Linrad is free software. Free for anyone to use for any purpose. I do not want to discourage people from using my sdr algorithms in commercial products. For that reason I claim no copyright and do not include a GNU license. DS. From 246tnt at gmail.com Wed Sep 26 19:52:23 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 26 Sep 2012 15:52:23 -0400 Subject: Issues with rtl_tcp In-Reply-To: <20120926213343.10f7cc38.leif@sm5bsz.com> References: <5062D7AA.7050506@scottcutler.net> <20120926213343.10f7cc38.leif@sm5bsz.com> Message-ID: Hi, > "Once this change is made in a given copy, it is irreversible > for that copy, so the ordinary GNU General Public License > applies to all subsequent copies and derivative works made > from that copy." > > I am not a lawyer, but it seems to me that this statement > implicates that the library license is more restricted and > that things you are allowed to do under the library license > are still allowed under the general license. Clearly you're not. It's pretty much exactly the opposite actually. LGPL is _LESS_ restrictive and among those additional freedom, you can relicense it under GPL. > In the library license we can read this: > [snip] > This means you are free to use the rtlsdr dll available > at osmocom but you can not distribute an executable in > which the library is linked in. ??? How exactly did you go from taking a software distributed using GPL (rtl-sdr and librtlsdr) and just apply LGPL clauses to it ??? As said above you can't do that at all. > Likewise can I distribute Linrad under Linux and give > the user the instructions how to link in librtl.so > from the osmocom site or from a complete and somewhat > modified version that I will supply myself in case > the modifications to the library I will propose will not > be accepted. If you link to librtlsdr.so, you _have_ to be a GPL compatible license and that's it. That's how GPL works. Now, the only license I saw in linrad seems to be pretty much public domain. So you _can_ link to librtlsdr.so directly without any issue. Any distribution of binaries that are linked to it however will effectively be GPL. But anyone is still completely free to take whatever part of your public domain code and do whatever they want with it. However if they also want to distribute binaries of their modified code linked to rtlsdr, then they'll have to release those under a GPL compatible license as well. So there are no risk to you, anyone will still be free to extract your sdr algorithm and use them however they want, according to your own rules. Only the rtlsdr link will be conditional to GPL terms. For example they'd be free to take your software, disable the rtlsdr part, do some mods, and sell the resulting binaries. Cheers, Sylvain From a.nielsen at shikadi.net Thu Sep 27 00:12:37 2012 From: a.nielsen at shikadi.net (Adam Nielsen) Date: Thu, 27 Sep 2012 10:12:37 +1000 Subject: Issues with rtl_tcp In-Reply-To: References: <5062D7AA.7050506@scottcutler.net> <20120926213343.10f7cc38.leif@sm5bsz.com> Message-ID: <506399F5.4080008@shikadi.net> >> "Once this change is made in a given copy, it is irreversible >> for that copy, so the ordinary GNU General Public License >> applies to all subsequent copies and derivative works made >> from that copy." >> >> I am not a lawyer, but it seems to me that this statement >> implicates that the library license is more restricted and >> that things you are allowed to do under the library license >> are still allowed under the general license. > > Clearly you're not. It's pretty much exactly the opposite actually. I think you misread Leif's message - what was said is correct. You can take an LGPL library and relicense it under the GPL, but you can't go back to LGPL again. Yes, this implies the license becomes more restrictive, because there are things you can do under the LGPL that you can no longer do once it becomes GPL. > LGPL is _LESS_ restrictive and among those additional freedom, you can > relicense it under GPL. Yes, this is what Lief suggested. >> This means you are free to use the rtlsdr dll available >> at osmocom but you can not distribute an executable in >> which the library is linked in. > > ??? How exactly did you go from taking a software distributed using > GPL (rtl-sdr and librtlsdr) and just apply LGPL clauses to it ??? > > As said above you can't do that at all. I think what Leif was getting at is that you can do whatever you want if you don't distribute it. The GPL and other licenses only come into effect once you distribute something to someone else. > If you link to librtlsdr.so, you _have_ to be a GPL compatible license > and that's it. That's how GPL works. If I understand correctly, Leif was suggesting a workaround. Instead of distributing something that violates the license, you could distribute something in two halves (each in compliance), along with instructions on how to link them together. Once linked they can no longer be distributed, but because you were distributing them separately you wouldn't be violating any licenses. I'm not sure what the legal implications of this are. On the one hand what you're distributing complies with the license, but then by providing instructions on how to link them together there is clear intent to bypass the restrictions imposed by the licenses. I guess this is where advice from the SFLC comes in. Cheers, Adam. From 246tnt at gmail.com Thu Sep 27 00:24:30 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 26 Sep 2012 20:24:30 -0400 Subject: Issues with rtl_tcp In-Reply-To: <506399F5.4080008@shikadi.net> References: <5062D7AA.7050506@scottcutler.net> <20120926213343.10f7cc38.leif@sm5bsz.com> <506399F5.4080008@shikadi.net> Message-ID: Hi, > I think you misread Leif's message - what was said is correct. You can take > an LGPL library and relicense it under the GPL, but you can't go back to > LGPL again. Yes, this implies the license becomes more restrictive, because > there are things you can do under the LGPL that you can no longer do once it > becomes GPL. I think you misread it. He clearly stated "the library license is more restricted and that things you are allowed to do under the library license are still allowed under the general license." This is not the case. In LGPL you can link so closed software, in GPL you can't. So everything allowed under LGPL is _not_ allowed under GPL. > I think what Leif was getting at is that you can do whatever you want if you > don't distribute it. The GPL and other licenses only come into effect once > you distribute something to someone else. Well yes, obviously if you want to write source code just for you and never distribute it (not even the source) that's totally fine obviously. > If I understand correctly, Leif was suggesting a workaround. Instead of > distributing something that violates the license, you could distribute > something in two halves (each in compliance), along with instructions on how > to link them together. Once linked they can no longer be distributed, but > because you were distributing them separately you wouldn't be violating any > licenses. Distributing code source that cannot work without the GPL library is not compliant. GPL doesn't mention linking explicitely, just derivative work and a piece of source code that can't be compiled into an executable without the GPL piece of code linked to it would definitely be considered derivative work. If not, the whole concept of "gpl compatible" open-source license wouldn't make sense. But in any case, in his case it's completely irrelevant because the open source license he chooses _is_ GPL compatible so there is no issues to start with. Cheers, Sylvain From peter at stuge.se Thu Sep 27 06:03:21 2012 From: peter at stuge.se (Peter Stuge) Date: Thu, 27 Sep 2012 08:03:21 +0200 Subject: Issues with rtl_tcp In-Reply-To: <20120926213343.10f7cc38.leif@sm5bsz.com> References: <5062D7AA.7050506@scottcutler.net> <20120926213343.10f7cc38.leif@sm5bsz.com> Message-ID: <20120927060321.12391.qmail@stuge.se> Hej Leif! Leif Asbrink wrote: > This means you are free to use the rtlsdr dll available > at osmocom but you can not distribute an executable in > which the library is linked in. I'm afraid it's not so simple. > Likewise can I distribute Linrad under Linux and give > the user the instructions how to link in librtl.so > from the osmocom site or from a complete and somewhat > modified version that I will supply myself in case > the modifications to the library I will propose will not > be accepted. You can do that, but Linrad will also be GPL. Your software (both source and binaries) undisputably constitutes a derivative work of rtl-sdr, because it calls rtl-sdr. A consequence is that your software is not really in the public domain, as long as it calls rtl-sdr. Also keep in mind that the concept of public domain is problematic across international copyright law. All nations do not allow an author to abstain their copyright; I believe that's the case here in Europe for example. For maximum freedom I like to use the MIT license: http://opensource.org/licenses/MIT I understand the only requirement to be that copyright notices and the license itself are also copied, when copying the source code. > The e4k tuner works very well, actually it is > very competitive when compared to the FUNcube Pro dongle, > but only with a modified library. > http://www.sm5bsz.com/linuxdsp/hware/funcube/funcube.htm I urge you to work with the rtl-sdr maintainers to find how your improvements can be reworked so that they are included in rtl-sdr. It is a waste of everyone's time that you keep some local changes. > PS. The reason I worry about the GNU license is that > Linrad is free software. Free for anyone to use for > any purpose. I do not want to discourage people from > using my sdr algorithms in commercial products. For that > reason I claim no copyright and do not include a GNU > license. DS. I hope it is clear that the way you currently do this doesn't work, or that it at the very least is more problematic than it needs to be. Any software which calls rtl-sdr automatically becomes GPL. It is of course easy to accomplish what you want. Just like those who wish to distribute their software with a less free license than GPL you must create an abstraction in Linrad where the only calls to rtl-sdr occur in a process which is separate from Linrad. The source code of that (small) program will always be GPL. Linrad which communicates with that (small) program can use another license. One easy solution is to just use the rtl-sdr TCP protocol, but you may have some reason to create a different abstraction. With an abstraction over TCP you have isolated your software from rtl-sdr. Like authors of closed software you are circumventing the intent of the rtl-sdr authors, but that is of course your prerogative. To make your software unproblematic for others to use I urge you to choose a permissive license that you like, in the list of popular approved open source licenses. Here's the list: http://opensource.org/licenses/category MIT is IMO the shortest and simplest of them. That's why I like it a lot for maximum freedom software. //Peter From scott at scottcutler.net Thu Sep 27 07:05:16 2012 From: scott at scottcutler.net (Scott Cutler) Date: Thu, 27 Sep 2012 00:05:16 -0700 Subject: Issues with rtl_tcp In-Reply-To: <5062E680.2050809@gmail.com> References: <5062D7AA.7050506@scottcutler.net> <5062DA76.10808@scottcutler.net> <5062E680.2050809@gmail.com> Message-ID: <5063FAAC.5070600@scottcutler.net> It appears that both of my problems are nearly the same: the "worker cond timeout" happens because the first thing my program does is set the sample rate, which takes a whopping 2.58 seconds. This apparently delays rtlsdr_callback long enough that the timeout in pthread_cond_timedwait is hit, causing tcp_worker to bail. rtlsdr_set_center_freq takes 1.09 seconds and is unrelated to the select call--that comes down immediately. It is something to do with the rtlsdr library itself (or one of its dependencies). Time to investigate more deeply. -Scott On 9/26/2012 4:26 AM, Simeon Miteff wrote: > Hi Scott > > On 09/26/12 12:35, Scott Cutler wrote: >> Slight correction/clarification to the below: obviously, I am not >> calling rtlsdr_set_center_freq when using rtl_tcp.exe. Instead, what I >> see is that I can queue up a bunch of tuning calls, but they only kick >> in at a very slow rate (1 hz). The effect is similar to when I used the >> native libs, where rtlsdr_set_center_freq also took 1 s on the main thread. > I experienced the same maximum 1 hz tuning rate with rtl_tcp. > > A quick look at the code shows a select() call in the command_worker > thread with a timeout set to 1s, but that doesn't explain the observed > behavior, because, as I understand select(), it should return as soon as > the UDP socket has data available (the timeout is used to allow the > thread to terminate when rtl_tcp shuts down). Nevertheless, my spidey > sense tells me this is the place to look... > > Regards, > Simeon. > From scott at scottcutler.net Thu Sep 27 07:35:39 2012 From: scott at scottcutler.net (Scott Cutler) Date: Thu, 27 Sep 2012 00:35:39 -0700 Subject: Issues with rtl_tcp In-Reply-To: <5063FAAC.5070600@scottcutler.net> References: <5062D7AA.7050506@scottcutler.net> <5062DA76.10808@scottcutler.net> <5062E680.2050809@gmail.com> <5063FAAC.5070600@scottcutler.net> Message-ID: <506401CB.3040206@scottcutler.net> And another followup: A locally-built version of rtlsdr.dll works perfectly, and only takes a few tens of milliseconds for either rtlsdr_set_sample_rate or rtlsdr_set_center_freq. The binaries I am comparing against were built on 9/13 and are from this link: http://sdr.osmocom.org/trac/attachment/wiki/rtl-sdr/RelWithDebInfo.zip I looked through the Git commit log for the past month but didn't see anything that seemed relevant. Does anyone know the precise way in which these binaries were built? It would seem very odd if some build setting caused the difference, but that's my only idea at the moment. -Scott On 9/27/2012 12:05 AM, Scott Cutler wrote: > It appears that both of my problems are nearly the same: the "worker > cond timeout" happens because the first thing my program does is set > the sample rate, which takes a whopping 2.58 seconds. This apparently > delays rtlsdr_callback long enough that the timeout in > pthread_cond_timedwait is hit, causing tcp_worker to bail. > > rtlsdr_set_center_freq takes 1.09 seconds and is unrelated to the > select call--that comes down immediately. It is something to do with > the rtlsdr library itself (or one of its dependencies). Time to > investigate more deeply. > > -Scott > > > On 9/26/2012 4:26 AM, Simeon Miteff wrote: >> Hi Scott >> >> On 09/26/12 12:35, Scott Cutler wrote: >>> Slight correction/clarification to the below: obviously, I am not >>> calling rtlsdr_set_center_freq when using rtl_tcp.exe. Instead, what I >>> see is that I can queue up a bunch of tuning calls, but they only kick >>> in at a very slow rate (1 hz). The effect is similar to when I used >>> the >>> native libs, where rtlsdr_set_center_freq also took 1 s on the main >>> thread. >> I experienced the same maximum 1 hz tuning rate with rtl_tcp. >> >> A quick look at the code shows a select() call in the command_worker >> thread with a timeout set to 1s, but that doesn't explain the observed >> behavior, because, as I understand select(), it should return as soon as >> the UDP socket has data available (the timeout is used to allow the >> thread to terminate when rtl_tcp shuts down). Nevertheless, my spidey >> sense tells me this is the place to look... >> >> Regards, >> Simeon. >> > From simeon.miteff at gmail.com Thu Sep 27 07:43:09 2012 From: simeon.miteff at gmail.com (Simeon Miteff) Date: Thu, 27 Sep 2012 09:43:09 +0200 Subject: Issues with rtl_tcp In-Reply-To: <5063FAAC.5070600@scottcutler.net> References: <5062D7AA.7050506@scottcutler.net> <5062DA76.10808@scottcutler.net> <5062E680.2050809@gmail.com> <5063FAAC.5070600@scottcutler.net> Message-ID: <5064038D.3080502@gmail.com> Hi Scott On 09/27/12 09:05, Scott Cutler wrote: > It appears that both of my problems are nearly the same: the "worker > cond timeout" happens because the first thing my program does is set the > sample rate, which takes a whopping 2.58 seconds. This apparently > delays rtlsdr_callback long enough that the timeout in > pthread_cond_timedwait is hit, causing tcp_worker to bail. > > rtlsdr_set_center_freq takes 1.09 seconds and is unrelated to the select > call--that comes down immediately. It is something to do with the > rtlsdr library itself (or one of its dependencies). Time to investigate > more deeply. I did a little test last night against the latest rtl_tcp code: https://gist.github.com/3792676 On my Linux box, this script is able to command rtl_tcp to set the sample rate and then tune successfully at 10Hz... I would agree that there is something else causing the issues on your system. Perhaps a USB issue? Regards, Simeon. From scott at scottcutler.net Thu Sep 27 09:00:26 2012 From: scott at scottcutler.net (Scott Cutler) Date: Thu, 27 Sep 2012 02:00:26 -0700 Subject: Issues with rtl_tcp In-Reply-To: <5064038D.3080502@gmail.com> References: <5062D7AA.7050506@scottcutler.net> <5062DA76.10808@scottcutler.net> <5062E680.2050809@gmail.com> <5063FAAC.5070600@scottcutler.net> <5064038D.3080502@gmail.com> Message-ID: <506415AA.2030404@scottcutler.net> Thanks for the sanity check. As I mentioned in my last email, I don't see the same problem with the latest version from Git (able to tune at ~20 hz). It seems that the precompiled binary on the Osmocom site is somewhat broken. So for the moment I don't have any problems, although it would be nice to get the public binaries updated. -Scott On 9/27/2012 12:43 AM, Simeon Miteff wrote: > Hi Scott > > On 09/27/12 09:05, Scott Cutler wrote: >> It appears that both of my problems are nearly the same: the "worker >> cond timeout" happens because the first thing my program does is set the >> sample rate, which takes a whopping 2.58 seconds. This apparently >> delays rtlsdr_callback long enough that the timeout in >> pthread_cond_timedwait is hit, causing tcp_worker to bail. >> >> rtlsdr_set_center_freq takes 1.09 seconds and is unrelated to the select >> call--that comes down immediately. It is something to do with the >> rtlsdr library itself (or one of its dependencies). Time to investigate >> more deeply. > I did a little test last night against the latest rtl_tcp code: > > https://gist.github.com/3792676 > > On my Linux box, this script is able to command rtl_tcp to set the > sample rate and then tune successfully at 10Hz... > > I would agree that there is something else causing the issues on your > system. Perhaps a USB issue? > > Regards, > Simeon. From limaunion at fibertel.com.ar Fri Sep 28 00:57:39 2012 From: limaunion at fibertel.com.ar (Limaunion) Date: Thu, 27 Sep 2012 21:57:39 -0300 Subject: OsmoSDR In-Reply-To: <06fb01cd9bfd$897c0550$9c740ff0$@sdr-radio.com> References: <06fb01cd9bfd$897c0550$9c740ff0$@sdr-radio.com> Message-ID: <5064F603.4070407@fibertel.com.ar> On 09/26/2012 12:42 PM, Simon G4ELI/HB9DRV wrote: > Hi All, > > I stumbled across the OsmoSDR on http://sdr.osmocom.org/trac/ - does > this supply 16-bit or maybe even higher samples? > > It looks great J, I?m sure a high quality SDR with this frequency range > will be very popular. > > Simon G4ELI/HB9DRV > I share your opinion, any ETA on availability? estimated price? how different it is from the fcd? TIA. From alan_r_cam at yahoo.com.au Sat Sep 29 02:14:12 2012 From: alan_r_cam at yahoo.com.au (Alan Campbell) Date: Fri, 28 Sep 2012 19:14:12 -0700 (PDT) Subject: Pricing and Availability Message-ID: <1348884852.37352.YahooMailNeo@web161904.mail.bf1.yahoo.com> There's been a couple of messages now, asking when you intend to release actual product. I suspect that, provided you warn people about the "rough around the edges" code, the actual HARDWARE is good enough to sell. The repair of code, relating to debugging, will improve when more people have the hardware - and can send fault reports. You may want your code to be as perfect as the Sistine Chapel - but even Michaelangelo had to let? the chapel be used while he painted. -- Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Sat Sep 29 02:50:53 2012 From: peter at stuge.se (Peter Stuge) Date: Sat, 29 Sep 2012 04:50:53 +0200 Subject: Pricing and Availability In-Reply-To: <1348884852.37352.YahooMailNeo@web161904.mail.bf1.yahoo.com> References: <1348884852.37352.YahooMailNeo@web161904.mail.bf1.yahoo.com> Message-ID: <20120929025053.30931.qmail@stuge.se> Alan Campbell wrote: > There's been a couple of messages now, asking when you intend to > release actual product. http://shop.sysmocom.de/products/osmosdr //Peter From harrisonheli at gmail.com Fri Sep 28 19:02:45 2012 From: harrisonheli at gmail.com (Andrew Harrison) Date: Sat, 29 Sep 2012 07:02:45 +1200 Subject: Sweex USB dongle with rtl_sdr Message-ID: Hi There I have been working with a Sweex USB dongle that has the RTL3282u - FC0012 chipset. Its id is "1f4d:a803 G-Tek Electronics Group" I have been able to get it working with rtl_sdr and rtl_fm. Can you add its id to the source code for others to use. Andrew Harrison. -------------- next part -------------- An HTML attachment was scrubbed... URL: