From 246tnt at gmail.com Wed Feb 5 10:01:35 2014 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 5 Feb 2014 11:01:35 +0100 Subject: OsmoDevCon 2014: CFP Message-ID: Dear all, Time has come to fill out the "Talks/Discussions/Workshop / Hacking" section of the wiki page. If you have something you'd like to present, talk about or hack on, add it there. A simple descriptive title along with an estimated duration is enough. I guess we'll collect those for 2/3 weeks and then start making the schedule. Cheers, Sylvain From Pin.a.Jiang at alcatel-sbell.com.cn Sun Feb 9 15:42:33 2014 From: Pin.a.Jiang at alcatel-sbell.com.cn (JIANG Pin A) Date: Sun, 9 Feb 2014 15:42:33 +0000 Subject: pfb_decimator_ccf(13): insufficient connected input ports (5 needed, 1 connected) Message-ID: <856075393BEB4F409DFC8E4ECE799DCF250B47@CNSHJMBX02.ad4.ad.alcatel.com> Hi, all I try to re-structure the osmo-tetra to work with GNU Radio 3.7. The osmo-tetra is based on GNU Radio 3.6. The original code has tuner, resampler, demodulater three modules which connected sequentially. The resampler is based on function pfb_decimator_ccf which changes from 3.6 to 3.7. The pfb_decimator_ccf only take single parameter decimation, which changes in 3.7, After reading the manual of 3.7, I made following changes to the python script : Add a low-pass filter " taps = filter.firdes.low_pass_2(1, fs, options.low_pass, options.low_pass * 0.2, attenuation_dB=ATT, window=filter.firdes.WIN_BLACKMAN_hARRIS) " Change "self.resamp = blks2.pfb_decimator_ccf(int(rerate)) " to " self.resamp = filter.pfb_decimator.ccf(int(rerate), taps, 0) " But error still occurs when connecting modules " self.connect(self.src, self.tuner, self.resamp, self.demod, self.output) " : Traceback (most recent call last): File "./osmosdr-tetra_demod_fft.py", line 264, in tb.Run(True) File "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py", line 82, in Run self.Start(start, max_nouts) File "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py", line 73, in Start self.start() File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 103, in start top_block_start_unlocked(self._tb, max_noutput_items) File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line 4612, in top_block_start_unlocked return _runtime_swig.top_block_start_unlocked(*args, **kwargs) RuntimeError: pfb_decimator_ccf(13): insufficient connected input ports (5 needed, 1 connected) Does it indicate pfb_decimator_ccf take 5 inputs ? It puzzled me. Best Regards, Jiang Pin -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.azarian at gmail.com Sun Feb 9 19:55:01 2014 From: sylvain.azarian at gmail.com (Sylvain AZARIAN) Date: Sun, 9 Feb 2014 20:55:01 +0100 Subject: odd results working at 250ksp/s In-Reply-To: References:

<001c01cecf05$30435bf0$90ca13d0$@schmid.xxx> <52664E0E.40400@earthlink.net> Message-ID: Hi, With a lot of delay and my apologizes, as promised a while ago, I finally published some quick notes on the VOR signal today. The complete signal analysis as been posted on my blog at this page : http://www.f4gkr.org/2014/02/in-depth-study-of-the-vor-signals/ I need to save the recorded WAV signals somewhere so people interested in good SNR recordings would get it. I decided to return close to the nearby VOR transmitter (Rambouillet, south west Paris) and put the RTL SDR on my car rooftop and turn on the laptop to capture some signals... Best regards sylvain F4GKR 2013-10-22 17:07 GMT+02:00 David Jacobowitz : > I originally posted about 115.8 and 116.8 MHz, both square in the VOR band > of 108 to 117.95. I might have sent something else in a PM, but if so it > was a typo. :-) I am definitely only interested in the VOR band right now > -- though, as you say, it is adjacent to commercial FM with its high power. > > My application is simple in concept: A fully auomatic VOR-based > positioning system, a fallback from GPS. I want to scan the entire VOR > band, looking for signals in the standard VOR format that can be > demodulated. I do the initial scan with a fast sample rate and FFT, just > looking for peaks. From those, I examine the signals to see if it looks > like a VOR signal. From that list, I will "park" on each signal long enough > (~30s) to decode the VOR's morse code station ID. From that, I will have a > short list of VORs that I can currently receive. From those, if the > geometry is appropriate (I know the VORs positions from a database) I can > calculate a position. > > The software then just round-robin tunes the VORs in range and continually > tries to calculate positions. If too many drop out, it returns to the > initial scan mode. > > Not being able to receive this VOR or that VOR is not generally a problem, > but obviously, the more the better. With extra VORs I have better options > for choosing the closest ones or the ones with the best geometry. > > > This is actually quite difficult to test, because VORs can generally only > be received line-of-sight -- which means in the air. I'm a private pilot > but I found that flying and noodling with a laptop is too much trouble. > From my office window, on a high floor in Oakland, CA, I can receive one > VOR from the Oakland airport. And I have now discovered a ridge near my > home with a scenic overlook from which I can receive two. > > I've tested the software enough to know that the initial scan function > seems to work, and the morse decoding kind of works, but I am not confident > I'll get it to work very well. (One transmitter's dit looks a lot like > another's dah.) The nav signal decoding is simple. (A 30 Hz AM modulated > tone is phase compared with a 30 Hz tone FM modulated at 9960 Hz. The phase > obtained is the azimuth to the station.) > > > If I ever get this working, I looking forward to sharing it with the > community. In the process of building this, I created a simple SDR toolkit > of DSP functions. It's like Gnuradio in concept, but 16b fixed-point, and > has no external dependencies, and C89, so is easier to build on weird and > limited platforms. It also has perl bindings. Compared to GR, it looks like > the work of a rank amateur just learning DSP, but I do like the concept of > there being a GR-like library out there, lightweight and embedded-friendly. > > > Regards, > Dave J > > > On Tue, Oct 22, 2013 at 3:06 AM, jdow wrote: > >> He sent me two frequencies in private email. These were in the FM >> broadcast band (in the US). He probably needs to notch them out >> in order to get adequate response. >> >> As for wanting narrow bandwidth - I am not quite sure why he thinks >> that is a benefit. I use a large FFT (about 10 Hz per bin) and use >> the zoom control to see fine detail. (Different FFT settings suite >> different uses. This one seems to be a good compromise with my two >> needs. I'm too lazy to change it.) >> >> {^_^} >> >> >> >> On 2013/10/22 02:08, Sylvain Munaut wrote: >> >>> Effective filtering must occur between antenna and receiver. All the >>>> problems that a saturated preamp and ADC cause can't be repaired by >>>> software. Never. >>>> >>> >>> But his original problem is not with saturated preamps or ADC ... it's >>> aliasing ... and that can be solved in the digital domain provided >>> fast enough ADC. >>> >>> Cheers, >>> >>> Sylvain >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at schmid.xxx Mon Feb 10 10:54:08 2014 From: ralph at schmid.xxx (Ralph A. Schmid, dk5ras) Date: Mon, 10 Feb 2014 11:54:08 +0100 Subject: odd results working at 250ksp/s In-Reply-To: References:

<001c01cecf05$30435bf0$90ca13d0$@schmid.xxx> <52664E0E.40400@earthlink.net> Message-ID: <007201cf264e$6ccccf20$46666d60$@schmid.xxx> Thanks a lot - very interesting! Ralph. From: Sylvain AZARIAN [mailto:sylvain.azarian at gmail.com] Sent: Sunday, February 09, 2014 8:55 PM To: David Jacobowitz Cc: jdow; Sylvain Munaut; osmocom-sdr at lists.osmocom.org; Ralph A. Schmid, dk5ras Subject: Re: odd results working at 250ksp/s Hi, With a lot of delay and my apologizes, as promised a while ago, I finally published some quick notes on the VOR signal today. The complete signal analysis as been posted on my blog at this page : http://www.f4gkr.org/2014/02/in-depth-study-of-the-vor-signals/ I need to save the recorded WAV signals somewhere so people interested in good SNR recordings would get it. I decided to return close to the nearby VOR transmitter (Rambouillet, south west Paris) and put the RTL SDR on my car rooftop and turn on the laptop to capture some signals... Best regards sylvain F4GKR 2013-10-22 17:07 GMT+02:00 David Jacobowitz : I originally posted about 115.8 and 116.8 MHz, both square in the VOR band of 108 to 117.95. I might have sent something else in a PM, but if so it was a typo. :-) I am definitely only interested in the VOR band right now -- though, as you say, it is adjacent to commercial FM with its high power. My application is simple in concept: A fully auomatic VOR-based positioning system, a fallback from GPS. I want to scan the entire VOR band, looking for signals in the standard VOR format that can be demodulated. I do the initial scan with a fast sample rate and FFT, just looking for peaks. From those, I examine the signals to see if it looks like a VOR signal. From that list, I will "park" on each signal long enough (~30s) to decode the VOR's morse code station ID. From that, I will have a short list of VORs that I can currently receive. From those, if the geometry is appropriate (I know the VORs positions from a database) I can calculate a position. The software then just round-robin tunes the VORs in range and continually tries to calculate positions. If too many drop out, it returns to the initial scan mode. Not being able to receive this VOR or that VOR is not generally a problem, but obviously, the more the better. With extra VORs I have better options for choosing the closest ones or the ones with the best geometry. This is actually quite difficult to test, because VORs can generally only be received line-of-sight -- which means in the air. I'm a private pilot but I found that flying and noodling with a laptop is too much trouble. From my office window, on a high floor in Oakland, CA, I can receive one VOR from the Oakland airport. And I have now discovered a ridge near my home with a scenic overlook from which I can receive two. I've tested the software enough to know that the initial scan function seems to work, and the morse decoding kind of works, but I am not confident I'll get it to work very well. (One transmitter's dit looks a lot like another's dah.) The nav signal decoding is simple. (A 30 Hz AM modulated tone is phase compared with a 30 Hz tone FM modulated at 9960 Hz. The phase obtained is the azimuth to the station.) If I ever get this working, I looking forward to sharing it with the community. In the process of building this, I created a simple SDR toolkit of DSP functions. It's like Gnuradio in concept, but 16b fixed-point, and has no external dependencies, and C89, so is easier to build on weird and limited platforms. It also has perl bindings. Compared to GR, it looks like the work of a rank amateur just learning DSP, but I do like the concept of there being a GR-like library out there, lightweight and embedded-friendly. Regards, Dave J On Tue, Oct 22, 2013 at 3:06 AM, jdow wrote: He sent me two frequencies in private email. These were in the FM broadcast band (in the US). He probably needs to notch them out in order to get adequate response. As for wanting narrow bandwidth - I am not quite sure why he thinks that is a benefit. I use a large FFT (about 10 Hz per bin) and use the zoom control to see fine detail. (Different FFT settings suite different uses. This one seems to be a good compromise with my two needs. I'm too lazy to change it.) {^_^} On 2013/10/22 02:08, Sylvain Munaut wrote: Effective filtering must occur between antenna and receiver. All the problems that a saturated preamp and ADC cause can't be repaired by software. Never. But his original problem is not with saturated preamps or ADC ... it's aliasing ... and that can be solved in the digital domain provided fast enough ADC. Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.azarian at gmail.com Mon Feb 10 12:15:49 2014 From: sylvain.azarian at gmail.com (Sylvain AZARIAN) Date: Mon, 10 Feb 2014 13:15:49 +0100 Subject: odd results working at 250ksp/s In-Reply-To: <007201cf264e$6ccccf20$46666d60$@schmid.xxx> References:

<001c01cecf05$30435bf0$90ca13d0$@schmid.xxx> <52664E0E.40400@earthlink.net> <007201cf264e$6ccccf20$46666d60$@schmid.xxx> Message-ID: I added this morning a post with links to the wav and mat files (matlab files are centered on the VOR signal, and have limited sampling rate to 30 KHz) feel free to ask further details if required sylvain 2014-02-10 11:54 GMT+01:00 Ralph A. Schmid, dk5ras : > Thanks a lot - very interesting! > > > > Ralph. > > > > > > *From:* Sylvain AZARIAN [mailto:sylvain.azarian at gmail.com] > *Sent:* Sunday, February 09, 2014 8:55 PM > *To:* David Jacobowitz > *Cc:* jdow; Sylvain Munaut; osmocom-sdr at lists.osmocom.org; Ralph A. > Schmid, dk5ras > *Subject:* Re: odd results working at 250ksp/s > > > > Hi, > > > > With a lot of delay and my apologizes, as promised a while ago, I finally > published some quick notes on the VOR signal today. > > The complete signal analysis as been posted on my blog at this page : > http://www.f4gkr.org/2014/02/in-depth-study-of-the-vor-signals/ > > > > I need to save the recorded WAV signals somewhere so people interested in > good SNR recordings would get it. > > I decided to return close to the nearby VOR transmitter (Rambouillet, > south west Paris) and put the RTL SDR on my car rooftop and turn on the > laptop to capture some signals... > > > > Best regards > > sylvain F4GKR > > > > 2013-10-22 17:07 GMT+02:00 David Jacobowitz : > > I originally posted about 115.8 and 116.8 MHz, both square in the VOR band > of 108 to 117.95. I might have sent something else in a PM, but if so it > was a typo. :-) I am definitely only interested in the VOR band right now > -- though, as you say, it is adjacent to commercial FM with its high power. > > > > My application is simple in concept: A fully auomatic VOR-based > positioning system, a fallback from GPS. I want to scan the entire VOR > band, looking for signals in the standard VOR format that can be > demodulated. I do the initial scan with a fast sample rate and FFT, just > looking for peaks. From those, I examine the signals to see if it looks > like a VOR signal. From that list, I will "park" on each signal long enough > (~30s) to decode the VOR's morse code station ID. From that, I will have a > short list of VORs that I can currently receive. From those, if the > geometry is appropriate (I know the VORs positions from a database) I can > calculate a position. > > > > The software then just round-robin tunes the VORs in range and continually > tries to calculate positions. If too many drop out, it returns to the > initial scan mode. > > > > Not being able to receive this VOR or that VOR is not generally a problem, > but obviously, the more the better. With extra VORs I have better options > for choosing the closest ones or the ones with the best geometry. > > > > > > This is actually quite difficult to test, because VORs can generally only > be received line-of-sight -- which means in the air. I'm a private pilot > but I found that flying and noodling with a laptop is too much trouble. > From my office window, on a high floor in Oakland, CA, I can receive one > VOR from the Oakland airport. And I have now discovered a ridge near my > home with a scenic overlook from which I can receive two. > > > > I've tested the software enough to know that the initial scan function > seems to work, and the morse decoding kind of works, but I am not confident > I'll get it to work very well. (One transmitter's dit looks a lot like > another's dah.) The nav signal decoding is simple. (A 30 Hz AM modulated > tone is phase compared with a 30 Hz tone FM modulated at 9960 Hz. The phase > obtained is the azimuth to the station.) > > > > > > If I ever get this working, I looking forward to sharing it with the > community. In the process of building this, I created a simple SDR toolkit > of DSP functions. It's like Gnuradio in concept, but 16b fixed-point, and > has no external dependencies, and C89, so is easier to build on weird and > limited platforms. It also has perl bindings. Compared to GR, it looks like > the work of a rank amateur just learning DSP, but I do like the concept of > there being a GR-like library out there, lightweight and embedded-friendly. > > > > > > Regards, > > Dave J > > > > On Tue, Oct 22, 2013 at 3:06 AM, jdow wrote: > > He sent me two frequencies in private email. These were in the FM > broadcast band (in the US). He probably needs to notch them out > in order to get adequate response. > > As for wanting narrow bandwidth - I am not quite sure why he thinks > that is a benefit. I use a large FFT (about 10 Hz per bin) and use > the zoom control to see fine detail. (Different FFT settings suite > different uses. This one seems to be a good compromise with my two > needs. I'm too lazy to change it.) > > {^_^} > > > > > On 2013/10/22 02:08, Sylvain Munaut wrote: > > Effective filtering must occur between antenna and receiver. All the > problems that a saturated preamp and ADC cause can't be repaired by > software. Never. > > > But his original problem is not with saturated preamps or ADC ... it's > aliasing ... and that can be solved in the digital domain provided > fast enough ADC. > > Cheers, > > Sylvain > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtologlu at hotmail.com Mon Feb 10 14:44:05 2014 From: mtologlu at hotmail.com (=?iso-8859-9?Q?Murat_Tolo=F0lu?=) Date: Mon, 10 Feb 2014 16:44:05 +0200 Subject: how to build gr-osmosdr for GnuRadio wheezy-raspbian distribution on Raspberry Pi Message-ID: Hi All, I have easily and smoothly installed GnuRadio 3.7.2.1 on Raspberry Pi with this procedure: 1. Add the following entry to the /etc/apt/sources.list file: deb http://mirrordirector.raspbian.org/raspbian/ jessie main contrib non-free rpi (reboot after modification) 2. sudo apt-get update 3. sudo apt-get install gnuradio Installation completed in about 1 hour and GnuRadio together with GnuRadio Companion Works on my RPi. However, when it comes to build Gr-Osmosdr trouble starts. I couldn't pass the CMAKE stage of Gr-Osmosdr build process. I remembered and applied the classical "export PATH, PYTHOPATH, LD_LIBRARY_PATH, PKG_CONFIG_PATH correction" and added necessary lines at the end of ./.bashrc . My install directory was /usr (without /local) !?? anyway I've added /usr/bin, /usr/lib ..etc. to appropriate places but this couldn't be a solution. Cmake couldn't find GnuradioConfig.cmake file, I found this file of the same version on my other computer running without problem and copied the missed file into correct directory on Rpi. This couldn't be the solution either. Then, Cmake couldn't locate gnuradio-runtime.pc file, similarly I copied gnuradio-runtime.pc of same version from another computer to RPi but this couldn't be a solution either. Now I get the same error message of this : http://gnuradio.org/redmine/issues/591 (Unable to compile out of tree projects due to wrong FindGnuradio.cmake) I am really tired. I have enough experience on installing - uninstalling Gnuradio building from the source, I have made this install uninstall building process several times but I am first time trying installation of a built gnuradio. Is there a way of recovering the existing install and continue building out of tree projects ? I appreciate your help, Kind regards 73 Murat TA1DB -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith.conger at gmail.com Tue Feb 11 16:36:15 2014 From: keith.conger at gmail.com (Keith Conger) Date: Tue, 11 Feb 2014 11:36:15 -0500 Subject: rtl_fm question Message-ID: Hi, I would love to see rtl_fm get support to connect to a rtl_tcp server. Are there any plans to add this? Thanks -- Keith Conger keith DOT conger AT gmail DOT com http://thecongers.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From keenerd at gmail.com Tue Feb 11 17:08:42 2014 From: keenerd at gmail.com (keenerd) Date: Tue, 11 Feb 2014 12:08:42 -0500 Subject: rtl_fm question In-Reply-To: References: Message-ID: On 2/11/14, Keith Conger wrote: > I would love to see rtl_fm get support to connect to a rtl_tcp server. Are > there any plans to add this? Yes. Multiple tcp connections per dongle as well. -Kyle http://kmeen.com From james at fivecats.org Tue Feb 11 17:17:38 2014 From: james at fivecats.org (James Sharp) Date: Tue, 11 Feb 2014 12:17:38 -0500 Subject: rtl_fm question In-Reply-To: References: Message-ID: <52FA5B32.7000309@fivecats.org> On 2/11/2014 12:08 PM, keenerd wrote: > On 2/11/14, Keith Conger wrote: >> I would love to see rtl_fm get support to connect to a rtl_tcp server. Are >> there any plans to add this? > > Yes. Multiple tcp connections per dongle as well. I'm starting on a patch set to enable multicast transmission/reception/decoding of the dongle sample stream, perhaps a combination of efforts is in order? From bemasher at gmail.com Wed Feb 12 18:09:53 2014 From: bemasher at gmail.com (Douglas Hall) Date: Wed, 12 Feb 2014 11:09:53 -0700 Subject: AMR Receiver Message-ID: I just recently finished an rtl-sdr based automatic meter reading receiver for smart commodity meters, thought it might be useful to add to the list of known applications table on the wiki. I don't currently have a trac account so I cannot add it myself. Name: rtlamr Source: https://github.com/bemasher/rtlamr Blog Post: http://bemasher.github.io/rtlamr/2014/02/08/innards.html -BeMasher -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdradio65 at gmail.com Thu Feb 13 20:35:58 2014 From: sdradio65 at gmail.com (Al Smith) Date: Thu, 13 Feb 2014 12:35:58 -0800 Subject: bug report Message-ID: I'm getting some errors when using gnuradio-companion with the osmocom source that I think might be a bug related to this patch: cgit.osmocom.org/gr-osmosdr/commit/?id=e5f7b28093c10f05d272bcf12c6c4b6583af7021 This is the output I get: Using Volk machine: avx_32_mmx_orc gr-osmosdr v0.1.0-66-g154c4ddd (0.1.1git) gnuradio 3.7.1 built-in source types: file fcd rtl_tcp bladerf rfspace [bladeRF source] Using nuand LLC bladeRF #0 SN 909d...c10c FW v1.6.1 FPGA v0.0.2 Failed to set out of bound frequency: 1.37912e+08 aUaUaUaUaUaUaU When I look at the patch in the commit I linked above that error relates to setting the input frequency. There are 2 expected parameters get_freq_range( chan ).start() get_freq_range( chan ).stop() but in the GUI osmocom source there is only Ch0 Frequency (center) and Ch0 Bandwidth, both of which I have set. I don't see a way to define the start and stop frequency which seems to be generating this error. -------------- next part -------------- An HTML attachment was scrubbed... URL: From horiz0n at gmx.net Thu Feb 13 20:49:18 2014 From: horiz0n at gmx.net (Dimitri Stolnikov) Date: Thu, 13 Feb 2014 21:49:18 +0100 Subject: bug report In-Reply-To: References: Message-ID: Al, bladeRF can't tune down to 1.37912e+08. Best regards, Dimitri On Thu, 13 Feb 2014 21:35:58 +0100, Al Smith wrote: > I'm getting some errors when using gnuradio-companion with the osmocom > source that I think might be a bug related to this patch: > cgit.osmocom.org/gr-osmosdr/commit/?id=e5f7b28093c10f05d272bcf12c6c4b6583af7021 > > > > This is the output I get: > > Using Volk machine: avx_32_mmx_orc > > gr-osmosdr v0.1.0-66-g154c4ddd (0.1.1git) gnuradio 3.7.1 > > built-in source types: file fcd rtl_tcp bladerf rfspace > > [bladeRF source] Using nuand LLC bladeRF #0 SN 909d...c10c FW v1.6.1 FPGA > v0.0.2 > > Failed to set out of bound frequency: 1.37912e+08 > > aUaUaUaUaUaUaU > > > > When I look at the patch in the commit I linked above that error relates > to > setting the input frequency. There are 2 expected parameters > get_freq_range( chan ).start() get_freq_range( chan ).stop() but in the > GUI > osmocom source there is only Ch0 Frequency (center) and Ch0 Bandwidth, > both > of which I have set. I don't see a way to define the start and stop > frequency which seems to be generating this error. From sdradio65 at gmail.com Thu Feb 13 21:00:13 2014 From: sdradio65 at gmail.com (Al Smith) Date: Thu, 13 Feb 2014 13:00:13 -0800 Subject: bug report In-Reply-To: References: Message-ID: That is true, but I am still getting this aUaU thing even with a different frequency. Using Volk machine: avx_32_mmx_orc gr-osmosdr v0.1.0-66-g154c4ddd (0.1.1git) gnuradio 3.7.1 built-in source types: file fcd rtl_tcp bladerf rfspace [bladeRF source] Using nuand LLC bladeRF #0 SN 909d...c10c FW v1.6.1 FPGA v0.0.2 aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU On Thu, Feb 13, 2014 at 12:49 PM, Dimitri Stolnikov wrote: > Al, > > bladeRF can't tune down to 1.37912e+08. > > > Best regards, > Dimitri > > > > On Thu, 13 Feb 2014 21:35:58 +0100, Al Smith wrote: > > I'm getting some errors when using gnuradio-companion with the osmocom >> source that I think might be a bug related to this patch: >> cgit.osmocom.org/gr-osmosdr/commit/?id=e5f7b28093c10f05d272bcf12c6c4b >> 6583af7021 >> >> >> >> This is the output I get: >> >> Using Volk machine: avx_32_mmx_orc >> >> gr-osmosdr v0.1.0-66-g154c4ddd (0.1.1git) gnuradio 3.7.1 >> >> built-in source types: file fcd rtl_tcp bladerf rfspace >> >> [bladeRF source] Using nuand LLC bladeRF #0 SN 909d...c10c FW v1.6.1 FPGA >> v0.0.2 >> >> Failed to set out of bound frequency: 1.37912e+08 >> >> aUaUaUaUaUaUaU >> >> >> >> When I look at the patch in the commit I linked above that error relates >> to >> setting the input frequency. There are 2 expected parameters >> get_freq_range( chan ).start() get_freq_range( chan ).stop() but in the >> GUI >> osmocom source there is only Ch0 Frequency (center) and Ch0 Bandwidth, >> both >> of which I have set. I don't see a way to define the start and stop >> frequency which seems to be generating this error. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steve-m.de Thu Feb 13 21:05:26 2014 From: steve at steve-m.de (Steve Markgraf) Date: Thu, 13 Feb 2014 22:05:26 +0100 Subject: bug report In-Reply-To: References:

Message-ID: <52FD3396.2040009@steve-m.de> Hi, On 13.02.2014 22:00, Al Smith wrote: > That is true, but I am still getting this aUaU thing even with a > different frequency. aU means audio underflow and is a problem/rate mismatch in your flowgraph. It's printed by the Audio Sink and not related to gr-osmosdr in any way. Regards, Steve From sdradio65 at gmail.com Thu Feb 13 21:12:07 2014 From: sdradio65 at gmail.com (Al Smith) Date: Thu, 13 Feb 2014 13:12:07 -0800 Subject: bug report In-Reply-To: <52FD3396.2040009@steve-m.de> References:

<52FD3396.2040009@steve-m.de> Message-ID: Sorry. My mistake. Thanks for the assistance. On Thu, Feb 13, 2014 at 1:05 PM, Steve Markgraf wrote: > Hi, > > On 13.02.2014 22:00, Al Smith wrote: > > That is true, but I am still getting this aUaU thing even with a > > different frequency. > > aU means audio underflow and is a problem/rate mismatch in your > flowgraph. It's printed by the Audio Sink and not related to gr-osmosdr > in any way. > > Regards, > Steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skip.tavakkolian at gmail.com Thu Feb 13 23:24:40 2014 From: skip.tavakkolian at gmail.com (Skip Tavakkolian) Date: Thu, 13 Feb 2014 15:24:40 -0800 Subject: AMR Receiver In-Reply-To: References: Message-ID: Very cool. It's great that you're using Go (I'm restructuring/rewriting rtl_acars.c in Go at the moment). FYI, if you want to bypass rtl_tcp, there is Go wrapper for librtlsdr here: https://github.com/jpoirier/gortlsdr -Skip On Wed, Feb 12, 2014 at 10:09 AM, Douglas Hall wrote: > I just recently finished an rtl-sdr based automatic meter reading receiver > for smart commodity meters, thought it might be useful to add to the list > of known applications table on the wiki. I don't currently have a trac > account so I cannot add it myself. > > Name: rtlamr > Source: https://github.com/bemasher/rtlamr > Blog Post: http://bemasher.github.io/rtlamr/2014/02/08/innards.html > > -BeMasher > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcquiggi at sfu.ca Fri Feb 14 19:32:04 2014 From: mcquiggi at sfu.ca (Kevin McQuiggin) Date: Fri, 14 Feb 2014 11:32:04 -0800 Subject: Build Problem: gr-osmosdr and FreeBSD Message-ID: <50041887-D160-418E-B026-28C2B7DF4665@sfu.ca> Hi All: I have gnuradio 3.6 running under FreeBSD 9.2. This is the latest port of gnuradio on that platform. I would like to build gr-osmosdr so that I can use my Realtek USB dongle under gnuradio-companion. I followed the procedure at http://sdr.osmocom.org/trac/wiki/GrOsmoSDR: 1) Got the source: git clone git://git.osmocom.org/gr-osmosdr cd gr-osmosdr/ 2) Followed the direction for use with gnuradio 3.6: git checkout gr3.6 3) Created the build environment: mkdir build cd build/ cmake ../ 4) However, "make" fails with the following error: make [ 24%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o /home/kevin/gr-osmosdr/lib/rtl/rtl_source_c.cc: In member function 'virtual osmosdr::freq_range_t rtl_source_c::get_freq_range(size_t)': /home/kevin/gr-osmosdr/lib/rtl/rtl_source_c.cc:468: error: 'RTLSDR_TUNER_R828D' was not declared in this scope /usr/local/include/boost/system/error_code.hpp: At global scope: /usr/local/include/boost/system/error_code.hpp:222: warning: 'boost::system::posix_category' defined but not used /usr/local/include/boost/system/error_code.hpp:223: warning: 'boost::system::errno_ecat' defined but not used /usr/local/include/boost/system/error_code.hpp:224: warning: 'boost::system::native_ecat' defined but not used *** [lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o] Error code 1 Stop in /usr/home/kevin/gr-osmosdr/build. *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error code 1 Stop in /usr/home/kevin/gr-osmosdr/build. *** [all] Error code 1 Stop in /usr/home/kevin/gr-osmosdr/build. I did some research on the error and the missing declaration. While there is a previous post from another person who experienced this error, I can't follow the proven solution of "upgrade to gnuradio 3.7" as I expect that this would not be trivial, and in fact very complex, under FreeBSD. I have no porting/port conversion experience. Just thought I'd ask if anyone else has experienced this, and whether there is a known solution. Thanks, Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From horiz0n at gmx.net Fri Feb 14 19:41:33 2014 From: horiz0n at gmx.net (Dimitri Stolnikov) Date: Fri, 14 Feb 2014 20:41:33 +0100 Subject: Build Problem: gr-osmosdr and FreeBSD In-Reply-To: <50041887-D160-418E-B026-28C2B7DF4665@sfu.ca> References: <50041887-D160-418E-B026-28C2B7DF4665@sfu.ca> Message-ID: Kevin, > /home/kevin/gr-osmosdr/lib/rtl/rtl_source_c.cc:468: error: > 'RTLSDR_TUNER_R828D' was not declared in this scope Your rtl-sdr installation is out of date. > error, I can't follow the proven solution of "upgrade to gnuradio 3.7" > as I expect that this would not be trivial, and in fact very complex, > under FreeBSD. No need to update gnuradio, i keep all branches in sync to master. Best regards, Dimitri From mcquiggi at sfu.ca Fri Feb 14 19:57:35 2014 From: mcquiggi at sfu.ca (Kevin McQuiggin) Date: Fri, 14 Feb 2014 11:57:35 -0800 Subject: Build Problem: gr-osmosdr and FreeBSD In-Reply-To: References: <50041887-D160-418E-B026-28C2B7DF4665@sfu.ca> Message-ID: <60D138E9-5373-4E2C-BD53-4087112F2F92@sfu.ca> Hi Dimitri: Thanks! I will find a newer rtl-sdr and install it. Thanks for the quick solution! I'll post back with the results. Kevin On Feb 14, 2014, at 11:41 AM, Dimitri Stolnikov wrote: > Kevin, > >> /home/kevin/gr-osmosdr/lib/rtl/rtl_source_c.cc:468: error: 'RTLSDR_TUNER_R828D' was not declared in this scope > > Your rtl-sdr installation is out of date. > >> error, I can't follow the proven solution of "upgrade to gnuradio 3.7" as I expect that this would not be trivial, and in fact very complex, under FreeBSD. > > No need to update gnuradio, i keep all branches in sync to master. > > > Best regards, > Dimitri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mcquiggi at sfu.ca Fri Feb 14 20:15:52 2014 From: mcquiggi at sfu.ca (Kevin McQuiggin) Date: Fri, 14 Feb 2014 12:15:52 -0800 Subject: Build Problem: gr-osmosdr and FreeBSD In-Reply-To: <60D138E9-5373-4E2C-BD53-4087112F2F92@sfu.ca> References: <50041887-D160-418E-B026-28C2B7DF4665@sfu.ca> <60D138E9-5373-4E2C-BD53-4087112F2F92@sfu.ca> Message-ID: Hi Dimitri: I grabbed and built the latest rtl-sdr, and then the gr-osmosdr builds fine! I have the proper sources in gnuradio-companion. THANKS for the speedy and accurate assistance. Kevin On Feb 14, 2014, at 11:57 AM, Kevin McQuiggin wrote: > Hi Dimitri: > > Thanks! > > I will find a newer rtl-sdr and install it. > > Thanks for the quick solution! I'll post back with the results. > > Kevin > > On Feb 14, 2014, at 11:41 AM, Dimitri Stolnikov wrote: > >> Kevin, >> >>> /home/kevin/gr-osmosdr/lib/rtl/rtl_source_c.cc:468: error: 'RTLSDR_TUNER_R828D' was not declared in this scope >> >> Your rtl-sdr installation is out of date. >> >>> error, I can't follow the proven solution of "upgrade to gnuradio 3.7" as I expect that this would not be trivial, and in fact very complex, under FreeBSD. >> >> No need to update gnuradio, i keep all branches in sync to master. >> >> >> Best regards, >> Dimitri > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From 393775602 at qq.com Mon Feb 17 02:25:30 2014 From: 393775602 at qq.com (=?gb18030?B?MzkzNzc1NjAy?=) Date: Mon, 17 Feb 2014 10:25:30 +0800 Subject: receiving specturm range Message-ID: Hi. I just use the the RTL2832U and Rt820t dongle to scan the wireless and draw the specturm of what i get. But i find the data i calculate is never bigger than -46dbm also never smaller than -63dbm.Is that the dongle's receiving ability is just like that? By the way, here is how i test the dongle: 1?i turn on a basestaion 2?i used the gsm module to detect the power of basestaion nearby,i get about -20dbm as the biggest 3?i used the dongle which i set its working frequency to the frequency that basestaion used 4?i calculate the spectrum using the data return by dongle(honestly, i used the rtl_power to calculate) the result i calculate is never big than -46dbm,what a difference from the result from gsm module. So i wonder whether the dongle's receiving abllity is just ordinary or the way i calculate is wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From allan.healy121 at gmail.com Mon Feb 17 14:57:44 2014 From: allan.healy121 at gmail.com (Allan Healy) Date: Mon, 17 Feb 2014 14:57:44 +0000 Subject: MODE C decoding Message-ID: <437E7C0B-33E3-41C1-8893-3BFA2A933E69@gmail.com> Hi, My name is Allan an I am currently working on my final year project for college. The idea is to create a radar system that interprets MODE C interrogation signals and replies by aircraft and SSR and with this information determine where these airplanes are in your vicinity. The device I am using to receive these transmissions is a DVB-T dongle. I will have to create an algorithm that will use the ping of the above transmissions which I am aware of. My problem is that I am having difficulty understanding how I will decode the signal to read the altitude and differentiate between other aircraft transmitting on the 1090MHz frequency. Could anyone in this forum point me in some direction as to how to learn this? Also apologies if I am unclear. Regards Allan From zaitcev at kotori.zaitcev.us Mon Feb 17 15:31:37 2014 From: zaitcev at kotori.zaitcev.us (Pete Zaitcev) Date: Mon, 17 Feb 2014 08:31:37 -0700 Subject: MODE C decoding In-Reply-To: <437E7C0B-33E3-41C1-8893-3BFA2A933E69@gmail.com> References: <437E7C0B-33E3-41C1-8893-3BFA2A933E69@gmail.com> Message-ID: <20140217083137.48a4b920@guren.zaitcev.lan> On Mon, 17 Feb 2014 14:57:44 +0000 Allan Healy wrote: > My name is Allan an I am currently working on my final year project > for college. The idea is to create a radar system that interprets > MODE C interrogation signals and replies by aircraft and SSR and > with this information determine where these airplanes are in your vicinity. I never heard of anyone being able to do that so far. Mode S is easy and there's any number of 1090 Extended Squitter receivers and decoders out there, but Mode C relies on the illumination by the radar to trigger the transmission. Since you cannot know where the radar is pointing and when the impulse started (and sometimes not where the radar is located), you cannot link Mode C squitter with the particular primary target. You can receive Mode C with rtl_adsb and have a look at 56-bit packets, but they are completely useless for an independent ground station. Some people nowadays play with a concept of building a something like interferometer from 3 or 4 receivers, but nobody has succeeded thus far, as far as I know. -- Pete From allan.healy121 at gmail.com Mon Feb 17 15:46:20 2014 From: allan.healy121 at gmail.com (Allan Healy) Date: Mon, 17 Feb 2014 15:46:20 +0000 Subject: MODE C decoding In-Reply-To: <20140217083137.48a4b920@guren.zaitcev.lan> References: <437E7C0B-33E3-41C1-8893-3BFA2A933E69@gmail.com> <20140217083137.48a4b920@guren.zaitcev.lan> Message-ID: Hi Pete Thanks for the reply. Yeah I can see the MODE C transmissions with the rtl_adsb alright but I don?t know how to see the interrogation transmissions from an SSR. Like you said there are many decoders available for MODE S. Hopefully my supervisor will understand the gravitas of the project and will accept MODE S as a suitable solution. Still I will try do some more research. If I am successful I will provide my solution to this forum. Thanks again. Allan On 17 Feb 2014, at 15:31, Pete Zaitcev wrote: > On Mon, 17 Feb 2014 14:57:44 +0000 > Allan Healy wrote: > >> My name is Allan an I am currently working on my final year project >> for college. The idea is to create a radar system that interprets >> MODE C interrogation signals and replies by aircraft and SSR and >> with this information determine where these airplanes are in your vicinity. > > I never heard of anyone being able to do that so far. Mode S is easy > and there's any number of 1090 Extended Squitter receivers and decoders > out there, but Mode C relies on the illumination by the radar to > trigger the transmission. Since you cannot know where the radar > is pointing and when the impulse started (and sometimes not where > the radar is located), you cannot link Mode C squitter with the particular > primary target. > > You can receive Mode C with rtl_adsb and have a look at 56-bit packets, > but they are completely useless for an independent ground station. > > Some people nowadays play with a concept of building a something > like interferometer from 3 or 4 receivers, but nobody has succeeded > thus far, as far as I know. > > -- Pete From sylvain.azarian at gmail.com Mon Feb 17 16:11:03 2014 From: sylvain.azarian at gmail.com (Sylvain AZARIAN) Date: Mon, 17 Feb 2014 17:11:03 +0100 Subject: MODE C decoding In-Reply-To: References: <437E7C0B-33E3-41C1-8893-3BFA2A933E69@gmail.com> <20140217083137.48a4b920@guren.zaitcev.lan> Message-ID: Hi , just one comment : the interrogation is periodic and stable.. the request is transmitted by a rotating antenna turning at constant speed. If you can get the direct path to the interrogation system, you may estimate the round-trip time and then when the interrogation pulse is sent sylvain 2014-02-17 16:46 GMT+01:00 Allan Healy : > Hi Pete > > Thanks for the reply. Yeah I can see the MODE C transmissions with the > rtl_adsb alright but I don't know how to see the interrogation > transmissions from an SSR. Like you said there are many decoders available > for MODE S. Hopefully my supervisor will understand the gravitas of the > project and will accept MODE S as a suitable solution. Still I will try do > some more research. If I am successful I will provide my solution to this > forum. Thanks again. > > Allan > > On 17 Feb 2014, at 15:31, Pete Zaitcev wrote: > > > On Mon, 17 Feb 2014 14:57:44 +0000 > > Allan Healy wrote: > > > >> My name is Allan an I am currently working on my final year project > >> for college. The idea is to create a radar system that interprets > >> MODE C interrogation signals and replies by aircraft and SSR and > >> with this information determine where these airplanes are in your > vicinity. > > > > I never heard of anyone being able to do that so far. Mode S is easy > > and there's any number of 1090 Extended Squitter receivers and decoders > > out there, but Mode C relies on the illumination by the radar to > > trigger the transmission. Since you cannot know where the radar > > is pointing and when the impulse started (and sometimes not where > > the radar is located), you cannot link Mode C squitter with the > particular > > primary target. > > > > You can receive Mode C with rtl_adsb and have a look at 56-bit packets, > > but they are completely useless for an independent ground station. > > > > Some people nowadays play with a concept of building a something > > like interferometer from 3 or 4 receivers, but nobody has succeeded > > thus far, as far as I know. > > > > -- Pete > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From st at metafly.info Mon Feb 17 16:22:00 2014 From: st at metafly.info (Stefan Sydow) Date: Mon, 17 Feb 2014 17:22:00 +0100 Subject: MODE C decoding In-Reply-To: References: <437E7C0B-33E3-41C1-8893-3BFA2A933E69@gmail.com> <20140217083137.48a4b920@guren.zaitcev.lan> Message-ID: <53023728.5010503@metafly.info> Hi, as far as I know interrogation requests are send on 1030MHz with a higher bandwidth and a different modulation scheme. Stefan Am 17.02.2014 17:11, schrieb Sylvain AZARIAN: > Hi , > > just one comment : the interrogation is periodic and stable.. the request > is transmitted by a rotating antenna turning at constant speed. If you can > get the direct path to the interrogation system, you may estimate the > round-trip time and then when the interrogation pulse is sent > > sylvain > From sylvain.azarian at gmail.com Mon Feb 17 16:38:47 2014 From: sylvain.azarian at gmail.com (Sylvain AZARIAN) Date: Mon, 17 Feb 2014 17:38:47 +0100 Subject: MODE C decoding In-Reply-To: <53023728.5010503@metafly.info> References: <437E7C0B-33E3-41C1-8893-3BFA2A933E69@gmail.com> <20140217083137.48a4b920@guren.zaitcev.lan> <53023728.5010503@metafly.info> Message-ID: Yes, that's true.. but this does not avoid the round-trip measurement... 2014-02-17 17:22 GMT+01:00 Stefan Sydow : > Hi, > > as far as I know interrogation requests are send on 1030MHz with a > higher bandwidth and a different modulation scheme. > > Stefan > > Am 17.02.2014 17:11, schrieb Sylvain AZARIAN: > > Hi , > > > > just one comment : the interrogation is periodic and stable.. the request > > is transmitted by a rotating antenna turning at constant speed. If you > can > > get the direct path to the interrogation system, you may estimate the > > round-trip time and then when the interrogation pulse is sent > > > > sylvain > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allan.healy121 at gmail.com Mon Feb 17 16:45:20 2014 From: allan.healy121 at gmail.com (Allan Healy) Date: Mon, 17 Feb 2014 16:45:20 +0000 Subject: MODE C decoding In-Reply-To: <53023728.5010503@metafly.info> References: <437E7C0B-33E3-41C1-8893-3BFA2A933E69@gmail.com> <20140217083137.48a4b920@guren.zaitcev.lan> <53023728.5010503@metafly.info> Message-ID: Yeah that?s true. I am thinking if I could get the Automatic Gain Control of the transmission from the plane I might be able to give a really rough guesstimate where the plane is in a 2D axis. On 17 Feb 2014, at 16:22, Stefan Sydow wrote: > Hi, > > as far as I know interrogation requests are send on 1030MHz with a > higher bandwidth and a different modulation scheme. > > Stefan > > Am 17.02.2014 17:11, schrieb Sylvain AZARIAN: >> Hi , >> >> just one comment : the interrogation is periodic and stable.. the request >> is transmitted by a rotating antenna turning at constant speed. If you can >> get the direct path to the interrogation system, you may estimate the >> round-trip time and then when the interrogation pulse is sent >> >> sylvain >> > > From putaoshu at gmail.com Wed Feb 19 15:21:42 2014 From: putaoshu at gmail.com (Jiao Xianjun) Date: Wed, 19 Feb 2014 23:21:42 +0800 Subject: LTE-Cell-Scanner now support TD-LTE! Message-ID: Hi there, As LTE-Cell-Scanner doesn't support TDD mode: https://github.com/Evrytania/LTE-Cell-Scanner I fork LTE-Cell-Scanner and add TDD support to it: https://github.com/JiaoXianjun/LTE-Cell-Scanner (Not reviewed by James Peroulas, so it is just experimental currently.) It works fine with rtl-sdr E4k tuner dongle below 2.2GHz, but doesn't work in 2.5~2.7GHz even with external MMDS-LNB. Because the algorithm assumes analytic relationship between carrier and sampling frequency error. I write some matlab scripts (https://github.com/JiaoXianjun/rtl-sdr-LTE ) to separate carrier and sampling processing in algorithm. Aided by MMDS-LNB, the scripts can detect TDD&FDD LTE cell in 2.5~2.7GHz now! 12 LTE Cells information are decoded. 2 are FDD LTE, the rest are TD-LTE. Because here is China! (Partly because that TD-LTE is announed earier than FDD by government) Hope that in the future these features can be merged to original LTE-Cell-Scanner. Scanning results and video are attached. http://www.youtube.com/watch?v=4zRLgxzn4Pc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2014-02-19 21:45:11.png Type: image/png Size: 161040 bytes Desc: not available URL: From thierry.leconte at laposte.net Sun Feb 23 12:34:15 2014 From: thierry.leconte at laposte.net (Thierry Leconte) Date: Sun, 23 Feb 2014 13:34:15 +0100 Subject: acarsdec 2.0 with built-in rtl_sdr frontend Message-ID: <5309EAC7.9070909@laposte.net> Thanks to Andreas Reinhardt who have port my old acarsdec code to rtl_sdr (http://lists.osmocom.org/pipermail/osmocom-sdr/2013-July/000712.html) I gain interest back to acars decoding and decided to rewrite completely acarsdec and to add it some new features, in particular a rtl front end. So , I am please to announce the acarsdec 2.0 release : https://sourceforge.net/projects/acarsdec Acarsdec is an open source, multi-channels realtime ACARS decoder for Linux. It features : - up to four channels decoded simultaneously - multi-threaded - error detection AND correction (all one error corrected and some two errors) - input from sound file , alsa sound card or software defined radio (SRD) via a rtl dongle The 4 channels decoding is particularly useful with the rtl dongle. It allows to directly listen simultaneously to 4 different frequencies. Ie: acarsdec -r 0 131.525 131.725 131.825 Will decode acars on 3 frequencies with the rtl dongle number 0. try and enjoy Thierry Leconte From anders at lyes.dk Mon Feb 24 07:40:17 2014 From: anders at lyes.dk (Anders Lynge Esbensen) Date: Mon, 24 Feb 2014 08:40:17 +0100 Subject: RTL Z-Wave decoder Message-ID: <530AF761.8010309@lyes.dk> For those who are interested I wrote a Z-Wave frame decoder for the rtl-sdr, it can be found here: https://github.com/andersesbensen/rtl-zwave The frame decoder is able to decode Z-Wave 9.6/40 and 100 kbps frames. The frames are written in a pcap file format and piped to wireshark. /Anders From tim21484 at yahoo.com Tue Feb 25 05:14:25 2014 From: tim21484 at yahoo.com (Tim) Date: Tue, 25 Feb 2014 05:14:25 +0000 (UTC) Subject: =?utf-8?b?cnRsX3RjcA==?= problem or not? References: <20130516020708.GF27372@faith.oztechninja.com> Message-ID: Favati libero.it> writes: > > > Run 'vmstat 1' in a different terminal on the RPi while running > > stuff, and paste the first dozen lines? (You can just CTRL-C > > vmstat after this) i'm having this same problem. when connected directly to the PC, seems to be fine. when i'm running it on the pi, after a while has the exact same issue. did you find a solution? From mailman at lists.osmocom.org Tue Feb 25 05:41:12 2014 From: mailman at lists.osmocom.org (mailman at lists.osmocom.org) Date: Tue, 25 Feb 2014 06:41:12 +0100 Subject: Bounce action notification Message-ID: This is a Mailman mailing list bounce action notice: List: osmocom-sdr Member: luca.bongiorni1 at studenti.unimi.it Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman at lists.osmocom.org. -------------- next part -------------- An embedded message was scrubbed... From: Internet Mail Delivery Subject: Delivery Notification: Delivery has failed Date: Tue, 25 Feb 2014 06:38:27 +0100 (CET) Size: 8852 URL: From hoofdeigenwijs at gmail.com Thu Feb 27 22:20:55 2014 From: hoofdeigenwijs at gmail.com (Ben Z en de rest) Date: Thu, 27 Feb 2014 23:20:55 +0100 Subject: sdrangelove, make gives error Message-ID: Hi, I am trying to build sdrangelove on Ubuntu 12.04 LTS. I did manually install cmake to have the required newer version. I did install Qt 5.2 and had cmake run with cmake ../ -DCMAKE_PREFIX_PATH=/home/pe2bz/Qt/5.2.1/gcc/lib/cmake After that, running make fails with this error: [ 68%] Building CXX object CMakeFiles/sdrbase.dir/sdrbase_automoc.cpp.o Linking CXX shared library libsdrbase.so /home/pe2bz/Qt/5.2.1/gcc/lib/libQt5Core.so.5.2.1: could not read symbols: File in wrong format collect2: ld gaf exit-status 1 terug make[2]: *** [libsdrbase.so] Fout 1 make[1]: *** [CMakeFiles/sdrbase.dir/all] Fout 2 make: *** [all] Fout 2 I did a google search on the File in wrong format message but I can not find a solution related to libsdrbase.so Can anyone help me with this ? Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at scottcutler.net Fri Feb 28 07:42:14 2014 From: scott at scottcutler.net (Scott Cutler) Date: Thu, 27 Feb 2014 23:42:14 -0800 Subject: rtl-sdr licensing question Message-ID: Greetings, all-- A while back I asked some questions about licensing of the rtl-sdr libraries, especially with regard to use with non-GPL software. At the time, I was told that the ExtIO libraries were considered an acceptable use-case. My code has been in development, and for various reasons--the largest being the desire for transmit support--I have developed my own HW abstraction layer called SDRIO. At the moment, I support rtl-sdr, bladeRF, and Funcube Dongle devices via the abstraction layer. The layer will, of course, be GNU licensed and thus free for anyone to modify or extend. My intent is thus for SDRIO to live in the same niche as ExtIO and thus have the blessings of the developers. I'm aware that you cannot give legal advice; my hope is only that, if someone comes to me saying I violated the rtl-sdr license, that at least I can tell them that I've talked with the lead developers and that they've given me the same permissions as the ExtIO developers. I have placed the code here in case anyone wishes to look at the current state (though please note that the text of the licensing is not yet finished): https://github.com/spcutler/SDRIO/blob/master The SDRIO_RTLSDR module is quite thin and I hope does not give the impression that SDRIO is just supposed to be a wrapper. If you look at the other devices, you can see that they require more code and that the project as a whole is quite a bit more than a wrapper. Thank you for your time! -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailman at lists.osmocom.org Fri Feb 28 07:43:15 2014 From: mailman at lists.osmocom.org (mailman at lists.osmocom.org) Date: Fri, 28 Feb 2014 08:43:15 +0100 Subject: Bounce action notification Message-ID: This is a Mailman mailing list bounce action notice: List: osmocom-sdr Member: beroset at ieee.org Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman at lists.osmocom.org. -------------- next part -------------- An embedded message was scrubbed... From: Mail Delivery Subsystem Subject: Delivery Status Notification (Failure) Date: Fri, 28 Feb 2014 07:43:10 +0000 Size: 7154 URL: From scott at scottcutler.net Fri Feb 28 08:05:21 2014 From: scott at scottcutler.net (Scott Cutler) Date: Fri, 28 Feb 2014 00:05:21 -0800 Subject: rtl-sdr licensing question In-Reply-To: References: Message-ID: Sorry guys, the Github link I gave was invalid. I believe this should work: https://github.com/spcutler/SDRIO -Scott On Thu, Feb 27, 2014 at 11:42 PM, Scott Cutler wrote: > Greetings, all-- > A while back I asked some questions about licensing of the rtl-sdr > libraries, especially with regard to use with non-GPL software. At the > time, I was told that the ExtIO libraries were considered an acceptable > use-case. > > My code has been in development, and for various reasons--the largest > being the desire for transmit support--I have developed my own HW > abstraction layer called SDRIO. At the moment, I support rtl-sdr, bladeRF, > and Funcube Dongle devices via the abstraction layer. The layer will, of > course, be GNU licensed and thus free for anyone to modify or extend. > > My intent is thus for SDRIO to live in the same niche as ExtIO and thus > have the blessings of the developers. I'm aware that you cannot give legal > advice; my hope is only that, if someone comes to me saying I violated the > rtl-sdr license, that at least I can tell them that I've talked with the > lead developers and that they've given me the same permissions as the ExtIO > developers. > > I have placed the code here in case anyone wishes to look at the current > state (though please note that the text of the licensing is not yet > finished): > https://github.com/spcutler/SDRIO/blob/master > > The SDRIO_RTLSDR module is quite thin and I hope does not give the > impression that SDRIO is just supposed to be a wrapper. If you look at the > other devices, you can see that they require more code and that the project > as a whole is quite a bit more than a wrapper. > > Thank you for your time! > > -Scott > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.nielsen at shikadi.net Fri Feb 28 20:59:47 2014 From: a.nielsen at shikadi.net (Adam Nielsen) Date: Sat, 1 Mar 2014 06:59:47 +1000 Subject: rtl-sdr licensing question In-Reply-To: References: Message-ID: <20140301065947.721d7453@korath.teln.shikadi.net> > My code has been in development, and for various reasons--the largest > being the desire for transmit support--I have developed my own HW > abstraction layer called SDRIO. At the moment, I support rtl-sdr, > bladeRF, and Funcube Dongle devices via the abstraction layer. The > layer will, of course, be GNU licensed and thus free for anyone to > modify or extend. There are many GNU licences with differing terms, so this will depend on which GNU licence you select. If you choose LGPL for example, then what you propose isn't a problem. But if you choose GPL, I believe that what you want to achieve may not be permitted. > My intent is thus for SDRIO to live in the same niche as ExtIO and > thus have the blessings of the developers. I'm aware that you cannot > give legal advice; my hope is only that, if someone comes to me > saying I violated the rtl-sdr license, that at least I can tell them > that I've talked with the lead developers and that they've given me > the same permissions as the ExtIO developers. I'm not a developer on this project (nor a lawyer), but I will point out an entry from the GPL FAQ[1]: If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? Yes, because the software as it is actually run includes the library. This means that if you release your library under the GPL, then your entire program must also be released under the GPL. If you wanted to use your SDRIO system with a closed source program, you would need to release it under the LGPL. However since librtlsdr is released under the GPL, you don't have a choice here and must release any code using librtlsdr as GPL also. There is one possible way out, however. Since you are the developer, you are able to dual-licence your own code. This means you can dual licence SDRIO as both GPL (to keep librtlsdr happy) and some other more permissive licence, and use the other licence yourself to link it with your closed-source program. This means however that you would not be able to distribute your program with librtlsdr (because then the GPL licence would take precedence), just like ExtIO programs do not include open-source ExtIO modules and require users to install them separately. In other words, your program must be functional and usable without any of the GPL'd SDRIO modules present. Users can add these themselves to provide more functionality, but if you require any GPL'd SDRIO modules to be present in order for your program to be usable, then it is clear that the SDRIO system only exists to circumvent the requirements of the various licences and would be legally questionable. Perhaps you would consider releasing all your code under the GPL instead, for the benefit of everyone? Cheers, Adam. [1] http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL From scott at scottcutler.net Fri Feb 28 21:13:46 2014 From: scott at scottcutler.net (Scott Cutler) Date: Fri, 28 Feb 2014 13:13:46 -0800 Subject: rtl-sdr licensing question In-Reply-To: <20140301065947.721d7453@korath.teln.shikadi.net> References: <20140301065947.721d7453@korath.teln.shikadi.net> Message-ID: Thank you for the reply. The GPL-LGPL dual solution is one I had in mind and with your feedback sounds even more inviting. My program is in fact functional without the SDRIO drivers, reading recorded files instead of streaming from an SDR device. All of the core functionality is still there. And I do have the capability of distributing SDRIO separate from my program, so that should not be a problem either. Unfortunately, I cannot release the program as-is due to the use of a proprietary library (used with permission to incorporate, but not to distribute source). It may be that I can make a version without that library and I will strongly consider GPLing it in the future. In the meantime, I would like if others could use SDRIO with maximum flexibility (i.e., use it in programs that are not pure GPL). -Scott On Fri, Feb 28, 2014 at 12:59 PM, Adam Nielsen wrote: > > My code has been in development, and for various reasons--the largest > > being the desire for transmit support--I have developed my own HW > > abstraction layer called SDRIO. At the moment, I support rtl-sdr, > > bladeRF, and Funcube Dongle devices via the abstraction layer. The > > layer will, of course, be GNU licensed and thus free for anyone to > > modify or extend. > > There are many GNU licences with differing terms, so this will depend > on which GNU licence you select. If you choose LGPL for example, then > what you propose isn't a problem. But if you choose GPL, I believe that > what you want to achieve may not be permitted. > > > My intent is thus for SDRIO to live in the same niche as ExtIO and > > thus have the blessings of the developers. I'm aware that you cannot > > give legal advice; my hope is only that, if someone comes to me > > saying I violated the rtl-sdr license, that at least I can tell them > > that I've talked with the lead developers and that they've given me > > the same permissions as the ExtIO developers. > > I'm not a developer on this project (nor a lawyer), but I will point out > an entry from the GPL FAQ[1]: > > If a library is released under the GPL (not the LGPL), does that mean > that any software which uses it has to be under the GPL or a > GPL-compatible license? > > Yes, because the software as it is actually run includes the > library. > > This means that if you release your library under the GPL, then your > entire program must also be released under the GPL. If you wanted to > use your SDRIO system with a closed source program, you would need to > release it under the LGPL. > > However since librtlsdr is released under the GPL, you don't have a > choice here and must release any code using librtlsdr as GPL also. > > There is one possible way out, however. Since you are the developer, > you are able to dual-licence your own code. This means you can dual > licence SDRIO as both GPL (to keep librtlsdr happy) and some other more > permissive licence, and use the other licence yourself to link it with > your closed-source program. > > This means however that you would not be able to distribute your program > with librtlsdr (because then the GPL licence would take precedence), > just like ExtIO programs do not include open-source ExtIO modules and > require users to install them separately. > > In other words, your program must be functional and usable without any > of the GPL'd SDRIO modules present. Users can add these themselves to > provide more functionality, but if you require any GPL'd SDRIO modules > to be present in order for your program to be usable, then it is clear > that the SDRIO system only exists to circumvent the requirements of the > various licences and would be legally questionable. > > Perhaps you would consider releasing all your code under the GPL > instead, for the benefit of everyone? > > Cheers, > Adam. > > [1] http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Fri Feb 28 21:51:09 2014 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 28 Feb 2014 22:51:09 +0100 Subject: rtl-sdr licensing question In-Reply-To: References: Message-ID: Hi, First off: IANAL. Also this email doesn't consistute legal advice and also doesn't consitute a grant of right or any kind of approbation, it's just my current opinion, at this moment and is subject to change. Being windows stuff, I can't build it but I assume that the "drivers" once compiled create .dll or shared object files, theses have a pre-define plugin API and are dynamically loaded by the host app (for example listing all DLL in a "drivers" dir). A few things are clear : - The SDRIO_RTLSDR has to be distributed under GPL. (The source can be any license gpl compatible, but once built into a binary and linked to the lib, then it's _just_ GPL and must be distributed as such whatever other license was the source) - You cannot distribute the SDRIO_RTLSDR DLL bundled with any app using the SDRIO interface that's not also GPL. And mechanism like auto-download / auto-install after the fact would easily be considered circumvention mechanisms and thus not allowed either. The app and the driver must be distributed separately and if the user wants it, it has to install it manually after the fact. - The interface itself ( content of SDRIO directory, so essentially sdrio_ext.h ) doesn't really need a license. .h files that don't content inline functions are not considered copyrightable. - The interface can't be a simple "wrapper" against a GPL lib. It has to be generic and completely detached from any rtl-sdr specific stuff. Seems to be the case here and since you provide drivers for other hardware, that shouldn't be an issue. - Drivers must be loaded / detected dynamically, basically the host app (if not GPL) can't have any knowledge of rtl-sdr at all ... For the EXTIO case, you have all of the above _AND_ the interface was pre-existing which made it a no-brainer. Here's it's created after the fact but that shouldn't be an issue for this specific case. If the content of the SDRIO directory becomes filled with helpers to actually use SDRIO drivers, then it will need a license of its own and LGPL would probably be appropriate here or even BSD (and don't make that a library but more something to statically link in the target app). I find that dual-licensing makes things more tricky than needed so I would avoid that. (Because depending on build options or what had been effectively linked or not, or what it's bundled with, the effective license vary). Cheers, Sylvain From scott at scottcutler.net Fri Feb 28 22:15:12 2014 From: scott at scottcutler.net (Scott Cutler) Date: Fri, 28 Feb 2014 14:15:12 -0800 Subject: rtl-sdr licensing question In-Reply-To: References: Message-ID: Thank you for the detailed reply. At the moment, I believe SDRIO fulfills all of the requirements you detail. You are correct that the SDRIO drivers are individual DLLs that export the API defined in sdrio_ext.h, and that it it is the job of the client application to look for these files and load them dynamically. I only have one small question, which is the exact treatment of auto-install mechanisms. I was hoping to use a auto-downloader to make the installation process easier. Do you consider it problematic if I use the auto-downloader to grab the SDRIO installer and execute it (not individual drivers, but rather the installer as a whole)? It seems strange to me that there should be a difference between a user manually clicking a download link and running a program versus the program downloading automatically, but I understand that this is a gray area. At any rate, it is not a problem for me to keep the two distributions completely separated; it is just a slight extra burden on the end users. We want to make things as easy as possible and this is an extra step, but I am happy to go that route if it more clearly fits with the license. Thanks again, -Scott On Fri, Feb 28, 2014 at 1:51 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > > First off: IANAL. Also this email doesn't consistute legal advice and > also doesn't consitute a grant of right or any kind of approbation, > it's just my current opinion, at this moment and is subject to change. > > Being windows stuff, I can't build it but I assume that the "drivers" > once compiled create .dll or shared object files, theses have a > pre-define plugin API and are dynamically loaded by the host app (for > example listing all DLL in a "drivers" dir). > > A few things are clear : > > - The SDRIO_RTLSDR has to be distributed under GPL. (The source can > be any license gpl compatible, but once built into a binary and linked > to the lib, then it's _just_ GPL and must be distributed as such > whatever other license was the source) > - You cannot distribute the SDRIO_RTLSDR DLL bundled with any app > using the SDRIO interface that's not also GPL. And mechanism like > auto-download / auto-install after the fact would easily be considered > circumvention mechanisms and thus not allowed either. The app and the > driver must be distributed separately and if the user wants it, it has > to install it manually after the fact. > - The interface itself ( content of SDRIO directory, so essentially > sdrio_ext.h ) doesn't really need a license. .h files that don't > content inline functions are not considered copyrightable. > - The interface can't be a simple "wrapper" against a GPL lib. It has > to be generic and completely detached from any rtl-sdr specific stuff. > Seems to be the case here and since you provide drivers for other > hardware, that shouldn't be an issue. > - Drivers must be loaded / detected dynamically, basically the host > app (if not GPL) can't have any knowledge of rtl-sdr at all ... > > For the EXTIO case, you have all of the above _AND_ the interface was > pre-existing which made it a no-brainer. Here's it's created after the > fact but that shouldn't be an issue for this specific case. > > If the content of the SDRIO directory becomes filled with helpers to > actually use SDRIO drivers, then it will need a license of its own and > LGPL would probably be appropriate here or even BSD (and don't make > that a library but more something to statically link in the target > app). I find that dual-licensing makes things more tricky than needed > so I would avoid that. (Because depending on build options or what had > been effectively linked or not, or what it's bundled with, the > effective license vary). > > > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Fri Feb 28 22:21:07 2014 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 28 Feb 2014 23:21:07 +0100 Subject: rtl-sdr licensing question In-Reply-To: References:

Message-ID: Hi, > I only have one small question, which is the exact treatment of auto-install > mechanisms. I was hoping to use a auto-downloader to make the installation > process easier. Do you consider it problematic if I use the auto-downloader > to grab the SDRIO installer and execute it (not individual drivers, but > rather the installer as a whole)? Yes, it's a problem. > It seems strange to me that there should > be a difference between a user manually clicking a download link and running > a program versus the program downloading automatically, but I understand > that this is a gray area. If the process was automatic, there would effectively be no difference between shipping it with it directly and so this is clearly a circumvention mechanism by which you try to "work around" the GPL to achieve the same result as distributing both component as a whole. The entire point of the GPL is to give "an edge" / "an advantage" to software that are also GPL. Hence forcing the application to be less practical, more of a burden to the user if it's not GPL is a _design_goal_ ... Cheers, Sylvain From scott at scottcutler.net Fri Feb 28 22:23:24 2014 From: scott at scottcutler.net (Scott Cutler) Date: Fri, 28 Feb 2014 14:23:24 -0800 Subject: rtl-sdr licensing question In-Reply-To: References:

Message-ID: Fair enough. I will keep the distributions totally independent. Thanks again for the advice! -Scott On Fri, Feb 28, 2014 at 2:21 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > > I only have one small question, which is the exact treatment of > auto-install > > mechanisms. I was hoping to use a auto-downloader to make the > installation > > process easier. Do you consider it problematic if I use the > auto-downloader > > to grab the SDRIO installer and execute it (not individual drivers, but > > rather the installer as a whole)? > > Yes, it's a problem. > > > > It seems strange to me that there should > > be a difference between a user manually clicking a download link and > running > > a program versus the program downloading automatically, but I understand > > that this is a gray area. > > If the process was automatic, there would effectively be no difference > between shipping it with it directly and so this is clearly a > circumvention mechanism by which you try to "work around" the GPL to > achieve the same result as distributing both component as a whole. > > > The entire point of the GPL is to give "an edge" / "an advantage" to > software that are also GPL. Hence forcing the application to be less > practical, more of a burden to the user if it's not GPL is a > _design_goal_ ... > > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: