From 72guitarist at gmail.com Fri Mar 1 09:57:24 2013 From: 72guitarist at gmail.com (=?ISO-8859-1?Q?Szil=E1rd_Jakab?=) Date: Fri, 1 Mar 2013 10:57:24 +0100 Subject: Question osmosdr driver R820T Message-ID: Dear developers! I would like to ask the driver for the R820T osdmocom rtlsdr tuner use of this IFGAIN conrtol was, and if his shirt, the GNU Radio source how to use it (I think python command) I'm a hardwer working towards, and it would be important that we have a value ifgain radio) thank you Jakab Szil?rd HUNGARY HA1003SWL -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steve-m.de Fri Mar 1 14:31:14 2013 From: steve at steve-m.de (Steve Markgraf) Date: Fri, 01 Mar 2013 15:31:14 +0100 Subject: Please add LEADTEK VID 0413:6f0f In-Reply-To: <20130228225332.M1947@unixservice.com.au> References: <20130228225332.M1947@unixservice.com.au> Message-ID: <5130BBB2.6080101@steve-m.de> Hi, On 01.03.2013 00:08, Alan Beard wrote: > Please add the LEADTEK "WinFast DTV DONGLE MINI D". > EAN code 710918 292751 Thanks, done. Regards, Steve From info at e-tom.de Fri Mar 1 14:51:37 2013 From: info at e-tom.de (Thomas Frisch) Date: Fri, 01 Mar 2013 15:51:37 +0100 Subject: New item for the "Known Apps" section of OSMOCOM rtl-sdr Message-ID: <5130C079.9050106@e-tom.de> Hello osmocom-sdr-Team, i spent some time to get familiar with GNU-Radio and RTL-SDR stuff and have implemented an decoder for the FS20 wireless home automation protocol. Maybe this is something for the "Known Apps" section in the OSMOCOM rtl-sdr wiki. Since i am a hardware/FPGA/RF guy, my programming skills are not the best, not at all in python, so i hope the code is not too scary. Name: rtl_sdr_FS20_decoder Type: gnuradio app Author: Thomas Frisch URL: https://github.com/eT0M/rtl_sdr_FS20_decoder.git My compliments to the whole OSMOCOM Team, you are doing a great job. regards Thomas From horiz0n at gmx.net Sun Mar 3 22:01:29 2013 From: horiz0n at gmx.net (Dimitri Stolnikov) Date: Sun, 03 Mar 2013 23:01:29 +0100 Subject: New item for the "Known Apps" section of OSMOCOM rtl-sdr In-Reply-To: <5130C079.9050106@e-tom.de> References: <5130C079.9050106@e-tom.de> Message-ID: Hi Thomas, thanks for sharing your work! Added it... Best regards, Dimitri From horiz0n at gmx.net Sun Mar 3 22:04:04 2013 From: horiz0n at gmx.net (Dimitri Stolnikov) Date: Sun, 03 Mar 2013 23:04:04 +0100 Subject: Question osmosdr driver R820T In-Reply-To: References: Message-ID: Hi Jakab, not sure i understand, can you rephrase please? Best regards, Dimitri On Fri, 01 Mar 2013 10:57:24 +0100, Szil?rd Jakab <72guitarist at gmail.com> wrote: > Dear developers! > I would like to ask the driver for the R820T osdmocom rtlsdr tuner use of > this IFGAIN conrtol was, and if his shirt, the GNU Radio source how to > use > it (I think python command) > > I'm a hardwer working towards, and it would be important that we have a > value ifgain radio) > > thank you > Jakab Szil?rd > HUNGARY > HA1003SWL From wjquyi at sina.com Mon Mar 4 15:40:45 2013 From: wjquyi at sina.com (wjquyi at sina.com) Date: Mon, 04 Mar 2013 23:40:45 +0800 Subject: the next OsmoSDR Message-ID: <20130304154045.BD2FA11700A1@webmail.sinamail.sina.com.cn> Hello,Christian When will you post the schematics and the firmware of the next OsmoSDR of 4MS/s ? I am intersted in them. How do I get them? best regards Yi Qu -------------- next part -------------- An HTML attachment was scrubbed... URL: From chas.g1rsk at ntlworld.com Thu Mar 7 11:55:01 2013 From: chas.g1rsk at ntlworld.com (Chas) Date: Thu, 7 Mar 2013 11:55:01 -0000 Subject: SDR rx Message-ID: <1324A76588784D999D82D92F03F5DB55@shack> Hi Guys. Any news on the V3 hardware board availability. Best regards. Chas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at windycitysdr.com Thu Mar 7 18:36:00 2013 From: martin at windycitysdr.com (Martin O'Shield) Date: Thu, 7 Mar 2013 12:36:00 -0600 Subject: SDR rx In-Reply-To: <1324A76588784D999D82D92F03F5DB55@shack> References: <1324A76588784D999D82D92F03F5DB55@shack> Message-ID: Chas, Great Question. Sincerely, Martin On Thu, Mar 7, 2013 at 5:55 AM, Chas wrote: > ** > Hi Guys. > Any news on the V3 hardware board availability. > Best regards. > Chas. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.goldenstein at gmail.com Thu Mar 7 20:12:22 2013 From: oliver.goldenstein at gmail.com (Oliver Goldenstein) Date: Thu, 7 Mar 2013 20:12:22 +0000 Subject: dump1090 - forked repo and added mysql support - some artwork Message-ID: HI All ! Many thanks Salvatore for that very impressive piece of software. I extended dump1090 to make use of a mysql database: http://dl6kbg.blogspot.de/2013/03/dump1090-with-mysql-support.html I will work on the code the next days to improve it for a more easy db setup. Some results and a description you may see here: http://dl6kbg.blogspot.de/2013/03/dump1090-with-mysql-support.html the forked repo is here: https://github.com/dl6kbg/dump1090 You need a mysql database called "dump1090" with a table "tracks". You may easily setup the db using the supplied script "tracks.sql" Username and password ist coded for now as mysql user: root mysql password: root. Run: ./dump1090 --mysql Have fun ! 73 Oliver DL6KBG -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwarren at pwarren.id.au Thu Mar 7 20:37:51 2013 From: pwarren at pwarren.id.au (Paul Warren) Date: Fri, 08 Mar 2013 07:37:51 +1100 Subject: dump1090 - forked repo and added mysql support - some artwork In-Reply-To: References: Message-ID: <5138FA9F.2040901@pwarren.id.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/03/13 07:12, Oliver Goldenstein wrote: > HI All ! > > Many thanks Salvatore for that very impressive piece of software. > > I extended dump1090 to make use of a mysql database: > > http://dl6kbg.blogspot.de/2013/03/dump1090-with-mysql-support.html > > I will work on the code the next days to improve it for a more easy > db setup. > > Some results and a description you may see here: > > http://dl6kbg.blogspot.de/2013/03/dump1090-with-mysql-support.html > > the forked repo is here: > > https://github.com/dl6kbg/dump1090 > > You need a mysql database called "dump1090" with a table "tracks". > You may easily setup the db using the supplied script "tracks.sql" > > Username and password ist coded for now as mysql user: root mysql > password: root. > > Run: ./dump1090 --mysql > > Have fun ! > > 73 Oliver DL6KBG Very nice Oliver! Something like this was on my todo list, so thanks for saving me the effort! Paul. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE4+psACgkQkwz3ZmaDjV6J8ACdEYzU3blTsMhyG0B+DfnYRP9F i3IAni8ya1dhk+JiDglzLKDYDG1fe8Ie =BhlL -----END PGP SIGNATURE----- From jsalsburg at bellsouth.net Thu Mar 7 23:30:28 2013 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Thu, 7 Mar 2013 17:30:28 -0600 Subject: the next level in Software Definition Message-ID: Gird you Grid for the next level in Software Definition. We are now stuck in Software Defined Radio (SDR). Next is Software Defined Instrumentation (SDI) with intriguing choices like the Vector Signal Transceiver (VST) for Device Testing. From peter at stuge.se Fri Mar 8 00:50:45 2013 From: peter at stuge.se (Peter Stuge) Date: Fri, 8 Mar 2013 01:50:45 +0100 Subject: dump1090 - forked repo and added mysql support - some artwork In-Reply-To: References: Message-ID: <20130308005045.11357.qmail@stuge.se> Good idea! Oliver Goldenstein wrote: > You may easily setup the db using the supplied script "tracks.sql" Please treat DDL like all the other source code. In particular, avoid storing DDL generated by a tool (maybe in particular by phpMyAdmin) under version control. Write DDL by hand, like the other source code, and store that under version control. Otherwise you will inevitably get lots of noise in the repository. For example because your web server PHP version changes. And of course the Erstellungszeit timestamp will be different whenever you ask phpMyAdmin to generate a new file the next time. That makes no sense. > Username and password ist coded for now as mysql user: root > mysql password: root. I suggest using the configuration files read by the client library to set a password, if any. I would suggest $USER as default username, and connecting without a password by default. If a password is needed, set it in one of the config files read by libmysqlclient. Oh, and I recommend everyone to use MariaDB instead of MySQL - the most competent MySQL developers left Oracle several years ago and work on MariaDB now. Drop-in replacement. https://mariadb.org/ //Peter From oliver.goldenstein at gmail.com Fri Mar 8 08:25:18 2013 From: oliver.goldenstein at gmail.com (Oliver Goldenstein) Date: Fri, 8 Mar 2013 08:25:18 +0000 Subject: dump1090 - forked repo and added mysql support - some artwork In-Reply-To: <20130308005045.11357.qmail@stuge.se> References: <20130308005045.11357.qmail@stuge.se> Message-ID: Hi Peter ! Many thanks for your helpful suggestions. > > Write DDL by hand, like the other source code, and store that under > version control. Otherwise you will inevitably get lots of noise in > the repository. > fixed that. I suggest using the configuration files read by the client library to > set a password, if any. I would suggest $USER as default username, > and connecting without a password by default. If a password is > needed, set it in one of the config files read by libmysqlclient. > will fix at over the weekend. > > Oh, and I recommend everyone to use MariaDB instead of MySQL - > the most competent MySQL developers left Oracle several years ago > and work on MariaDB now. Drop-in replacement. https://mariadb.org/ > to be honest i heard the first time of it. 73 Oliver DL6KBG -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Fri Mar 8 12:40:10 2013 From: peter at stuge.se (Peter Stuge) Date: Fri, 8 Mar 2013 13:40:10 +0100 Subject: dump1090 - forked repo and added mysql support - some artwork In-Reply-To: References: <20130308005045.11357.qmail@stuge.se> Message-ID: <20130308124010.3630.qmail@stuge.se> Oliver Goldenstein wrote: > > Oh, and I recommend everyone to use MariaDB instead of MySQL - > > the most competent MySQL developers left Oracle several years ago > > and work on MariaDB now. Drop-in replacement. https://mariadb.org/ > > to be honest i heard the first time of it. That's what Monty (whose daughter is My, in MySQL) is doing these days. They're a really great team doing awesome work. //Peter From limaunion at fibertel.com.ar Sat Mar 9 13:06:38 2013 From: limaunion at fibertel.com.ar (Limaunion) Date: Sat, 09 Mar 2013 10:06:38 -0300 Subject: dump1090 - forked repo and added mysql support - some artwork In-Reply-To: <20130308124010.3630.qmail@stuge.se> References: <20130308005045.11357.qmail@stuge.se> <20130308124010.3630.qmail@stuge.se> Message-ID: <513B33DE.1080108@fibertel.com.ar> On 03/08/2013 09:40 AM, Peter Stuge wrote: > Oliver Goldenstein wrote: >>> Oh, and I recommend everyone to use MariaDB instead of MySQL - >>> the most competent MySQL developers left Oracle several years ago >>> and work on MariaDB now. Drop-in replacement. https://mariadb.org/ >> >> to be honest i heard the first time of it. > > That's what Monty (whose daughter is My, in MySQL) is doing > these days. They're a really great team doing awesome work. > > > //Peter > > yes, and some distros have already started to switch from mysql to mariadb, like Fedora 19: http://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB#Summary http://lwn.net/Articles/534204/ From unizen01 at gmail.com Sat Mar 9 14:01:48 2013 From: unizen01 at gmail.com (Hemant Singh) Date: Sat, 9 Mar 2013 19:31:48 +0530 Subject: GSOC 2013 Message-ID: Hey all, Osmocom is such a great community with awesome projects. Why doesn't Osmocom apply for GSOC 2013? It's a really nice opportunity. - More students will come to know about osmocom thus greater visibility - Some great minds will work on the projects so it may lead to something more awesome - Osmocom community will get to mentor students which is a very important experience, because that is how one understands the problems of new developers Cheers, *Hemant * -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorenz at schlagseite.de Sun Mar 10 19:01:42 2013 From: lorenz at schlagseite.de (Lorenz Wiedemann) Date: Sun, 10 Mar 2013 20:01:42 +0100 Subject: rtl-sdr, SDRSharp under Ubuntu/mono, high CPU load - compared with GQRX In-Reply-To: References: Message-ID: <513CD896.9040709@schlagseite.de> Hello, I am running an RTL2832 USB stick (R820T tuner in it) and SDRSharp via Mono under Ubuntu 12.04 with a Pentium-M 1.5GHz and 1,5 GB RAM. SDRSharp With sample rates of 0.25M and 1.024M, I'm "suffering" from 100% CPU load and temperatures around 70?C - this can't be healthy for the laptop... Switching the waterfall off and speed etc. to minimum doesn't help very much. RDS is displayed fine, all functions seem to be OK. RAM space is not filled up (30%). Any advice for a "smoother" running on such an "old" machine...? http://superkuh.com/rtlsdr.html#sdrsharpappnote said "it can even run on my old 1.8Ghz P4 laptop". GQRX GQRX did run using the QtPro way as described in the wiki, but after recent update of GQRX the DC spike at centre frequency appeared (it wasn't there before), and massive stuttering of audio and the "OOOOOO"s in terminal window at a lot of different sample rates made the usage of GQRX worse. (right, this should be posted in a GQRX forum...) Anyway, did someone notice that GQRX update (ca. first days of march 2013) lead to problems ? thanks, Lorenz From oz9aec at gmail.com Sun Mar 10 19:59:12 2013 From: oz9aec at gmail.com (Alexandru Csete) Date: Sun, 10 Mar 2013 20:59:12 +0100 Subject: rtl-sdr, SDRSharp under Ubuntu/mono, high CPU load - compared with GQRX In-Reply-To: <513CD896.9040709@schlagseite.de> References: <513CD896.9040709@schlagseite.de> Message-ID: On Sun, Mar 10, 2013 at 8:01 PM, Lorenz Wiedemann wrote: > Hello, > > I am running an RTL2832 USB stick (R820T tuner in it) and SDRSharp via > Mono under Ubuntu 12.04 with a Pentium-M 1.5GHz and 1,5 GB RAM. > > SDRSharp > > With sample rates of 0.25M and 1.024M, I'm "suffering" from 100% CPU > load and temperatures around 70?C - this can't be healthy for the > laptop... Switching the waterfall off and speed etc. to minimum doesn't > help very much. RDS is displayed fine, all functions seem to be OK. RAM > space is not filled up (30%). > > Any advice for a "smoother" running on such an "old" machine...? > > http://superkuh.com/rtlsdr.html#sdrsharpappnote said "it can even run on > my old 1.8Ghz P4 laptop". > > GQRX > > GQRX did run using the QtPro way as described in the wiki, but after > recent update of GQRX the DC spike at centre frequency appeared (it > wasn't there before), and massive stuttering of audio and the "OOOOOO"s > in terminal window at a lot of different sample rates made the usage of > GQRX worse. (right, this should be posted in a GQRX forum...) > > Anyway, did someone notice that GQRX update (ca. first days of march > 2013) lead to problems ? I have added a new DC removal algorithm in February and it is disabled by default. You can enable it in the receiver under input controls. There have been changes to the way how devices are labeled and identified, so it may be a good idea to clear your configuration: rm ~/.config/gqrx/default.conf If there are still problems I hope you can help me find out which commit introduced problems. Alex From kainwen at gmail.com Mon Mar 11 14:36:20 2013 From: kainwen at gmail.com (kainwen) Date: Mon, 11 Mar 2013 22:36:20 +0800 Subject: ask for help : gr-osmosdr build failed Message-ID: <513DEBE4.9000205@gmail.com> Dear All, Thanks for reading my mail. when I do the last steps, I failed, I don't know why. git clone git://git.osmocom.org/gr-osmosdr cd gr-osmosdr/ mkdir build cd build/ cmake ../ make sudo make install sudo ldconfig I failed when I " make ". the make error is : /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc: In constructor 'osmosdr_source_c_impl::osmosdr_source_c_impl(const string&)': /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc:117:16: error: 'GR_OSMOSDR_VERSION' was not declared in this scope /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc:117:47: error: 'GR_OSMOSDR_LIBVER' was not declared in this scope make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/osmosdr_source_c_impl.cc.o] Error 1 make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 make: *** [all] Error 2 the cmake output is : -- Build type not specified: defaulting to release. -- Extracting version information from git describe... -- Configuring Boost C++ Libraries... -- checking for module 'gnuradio-iqbalance' -- package 'gnuradio-iqbalance' not found -- Found gnuradio-uhd: /usr/local/include, /usr/local/lib/libgnuradio-uhd.so -- Found gnuradio-fcd: /usr/local/include, /usr/local/lib/libgnuradio-fcd.so -- Will build with gnuradio iqbalance support. -- -- The build system will automatically enable all components. -- Use -DENABLE_DEFAULT=OFF to disable components by default. -- -- Configuring sysmocom OsmoSDR support... -- Dependency LIBOSMOSDR_FOUND = TRUE -- Enabling sysmocom OsmoSDR support. -- Override with -DENABLE_OSMOSDR=ON/OFF -- -- Configuring FunCube Dongle support... -- Dependency GNURADIO_FCD_FOUND = TRUE -- Enabling FunCube Dongle support. -- Override with -DENABLE_FCD=ON/OFF -- -- Configuring IQ File Source support... -- Dependency GNURADIO_CORE_FOUND = TRUE -- Enabling IQ File Source support. -- Override with -DENABLE_FILE=ON/OFF -- -- Configuring Osmocom RTLSDR support... -- Dependency LIBRTLSDR_FOUND = TRUE -- Enabling Osmocom RTLSDR support. -- Override with -DENABLE_RTL=ON/OFF -- -- Configuring RTLSDR TCP Client support... -- Dependency GNURADIO_CORE_FOUND = TRUE -- Enabling RTLSDR TCP Client support. -- Override with -DENABLE_RTL_TCP=ON/OFF -- -- Configuring Ettus UHD support... -- Dependency UHD_FOUND = TRUE -- Dependency GNURADIO_UHD_FOUND = TRUE -- Enabling Ettus UHD support. -- Override with -DENABLE_UHD=ON/OFF -- -- Configuring Osmocom MiriSDR support... -- Dependency LIBMIRISDR_FOUND = TRUE -- Enabling Osmocom MiriSDR support. -- Override with -DENABLE_MIRI=ON/OFF -- -- ###################################################### -- # gr-osmosdr enabled components -- ###################################################### -- * sysmocom OsmoSDR -- * FunCube Dongle -- * IQ File Source -- * Osmocom RTLSDR -- * RTLSDR TCP Client -- * Ettus UHD -- * Osmocom MiriSDR -- -- ###################################################### -- # gr-osmosdr disabled components -- ###################################################### -- -- Building for version: 1eb3af22 / 0.0.1git -- Using install prefix: /usr/local -- Configuring done -- Generating done -- Build files have been written to: /tmp/gr-osmosdr/build * * -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.nielsen at shikadi.net Mon Mar 11 20:09:30 2013 From: a.nielsen at shikadi.net (Adam Nielsen) Date: Tue, 12 Mar 2013 06:09:30 +1000 Subject: R820T register map available Message-ID: <513E39FA.2010700@shikadi.net> Hi all, One of the designers of the R820T tuner has recently been posting on the ultra-cheap-sdr group, and has kindly supplied a map of the R820T registers for private use only within the SDR community. He has asked that it not be posted on any website, but only be forwarded around privately. To that end, if anyone would like a copy of this spreadsheet and would be willing to likewise not publish it on the web, let me know off-list and I'll send it to you. There's not a huge amount in the way of explanations, but it lists all the registers and a very brief description of what they do. Cheers, Adam. From horiz0n at gmx.net Mon Mar 11 20:29:50 2013 From: horiz0n at gmx.net (Dimitri Stolnikov) Date: Mon, 11 Mar 2013 21:29:50 +0100 Subject: ask for help : gr-osmosdr build failed Message-ID: Hi, it seems you've triggered an issue recently introduced via gnuradio master: http://gnuradio.org/cgit/gnuradio.git/commit/?id=9297c84dfdae3002677f759ef2b38a877d2edc2c Their config.h basically overrides our build-time generated one which not only effectively disables every single source functionality but also causes the build error you experienced. I've just pushed a small workaround for that, please test it & report. One second issue i've noticed is that in your configuration every single option seems to be enabled, although not all dependencies have been detected. Usually a full configuration should look like in the attached file. Best regards, Dimitri I failed when I " make ". the make error is : /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc: In constructor ?osmosdr_source_c_impl::osmosdr_source_c_impl(const string&)?: /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc:117:16: error: ?GR_OSMOSDR_VERSION? was not declared in this scope /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc:117:47: error: ?GR_OSMOSDR_LIBVER? was not declared in this scope make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/osmosdr_source_c_impl.cc.o] Error 1 make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 make: *** [all] Error 2 the cmake output is : -- Build type not specified: defaulting to release. -- Extracting version information from git describe... -- Configuring Boost C++ Libraries... -- checking for module 'gnuradio-iqbalance' -- package 'gnuradio-iqbalance' not found -- Found gnuradio-uhd: /usr/local/include, /usr/local/lib/libgnuradio-uhd.so -- Found gnuradio-fcd: /usr/local/include, /usr/local/lib/libgnuradio-fcd.so -- Will build with gnuradio iqbalance support. -- -- The build system will automatically enable all components. -- Use -DENABLE_DEFAULT=OFF to disable components by default. -- -- Configuring sysmocom OsmoSDR support... -- Dependency LIBOSMOSDR_FOUND = TRUE -- Enabling sysmocom OsmoSDR support. -- Override with -DENABLE_OSMOSDR=ON/OFF -- -- Configuring FunCube Dongle support... -- Dependency GNURADIO_FCD_FOUND = TRUE -- Enabling FunCube Dongle support. -- Override with -DENABLE_FCD=ON/OFF -- -- Configuring IQ File Source support... -- Dependency GNURADIO_CORE_FOUND = TRUE -- Enabling IQ File Source support. -- Override with -DENABLE_FILE=ON/OFF -- -- Configuring Osmocom RTLSDR support... -- Dependency LIBRTLSDR_FOUND = TRUE -- Enabling Osmocom RTLSDR support. -- Override with -DENABLE_RTL=ON/OFF -- -- Configuring RTLSDR TCP Client support... -- Dependency GNURADIO_CORE_FOUND = TRUE -- Enabling RTLSDR TCP Client support. -- Override with -DENABLE_RTL_TCP=ON/OFF -- -- Configuring Ettus UHD support... -- Dependency UHD_FOUND = TRUE -- Dependency GNURADIO_UHD_FOUND = TRUE -- Enabling Ettus UHD support. -- Override with -DENABLE_UHD=ON/OFF -- -- Configuring Osmocom MiriSDR support... -- Dependency LIBMIRISDR_FOUND = TRUE -- Enabling Osmocom MiriSDR support. -- Override with -DENABLE_MIRI=ON/OFF -- -- ###################################################### -- # gr-osmosdr enabled components -- ###################################################### -- * sysmocom OsmoSDR -- * FunCube Dongle -- * IQ File Source -- * Osmocom RTLSDR -- * RTLSDR TCP Client -- * Ettus UHD -- * Osmocom MiriSDR -- -- ###################################################### -- # gr-osmosdr disabled components -- ###################################################### -- -- Building for version: 1eb3af22 / 0.0.1git -- Using install prefix: /usr/local -- Configuring done -- Generating done -- Build files have been written to: /tmp/gr-osmosdr/build * * -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cmake.txt URL: From oz9aec at gmail.com Mon Mar 11 22:21:26 2013 From: oz9aec at gmail.com (Alexandru Csete) Date: Mon, 11 Mar 2013 23:21:26 +0100 Subject: ask for help : gr-osmosdr build failed In-Reply-To: References: Message-ID: On Mon, Mar 11, 2013 at 9:29 PM, Dimitri Stolnikov wrote: > Hi, > > it seems you've triggered an issue recently introduced via gnuradio master: > > http://gnuradio.org/cgit/gnuradio.git/commit/?id=9297c84dfdae3002677f759ef2b38a877d2edc2c > > Their config.h basically overrides our build-time generated one which not > only effectively disables every single source functionality but also > causes the build error you experienced. > > I've just pushed a small workaround for that, please test it & report. > This issue drove me nuts earlier today but with the latest changes I can build again :-) Alex From kainwen at gmail.com Mon Mar 11 23:45:16 2013 From: kainwen at gmail.com (kainwen) Date: Tue, 12 Mar 2013 07:45:16 +0800 Subject: ask for help : gr-osmosdr build failed Message-ID: <513E6C8C.5050903@gmail.com> Dear All, Thanks for reading my mail. when I do the last steps, I failed, I don't know why. git clone git://git.osmocom.org/gr-osmosdr cd gr-osmosdr/ mkdir build cd build/ cmake ../ make sudo make install sudo ldconfig I failed when I " make ". the make error is : /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc: In constructor 'osmosdr_source_c_impl::osmosdr_source_c_impl(const string&)': /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc:117:16: error: 'GR_OSMOSDR_VERSION' was not declared in this scope /tmp/gr-osmosdr/lib/osmosdr_source_c_impl.cc:117:47: error: 'GR_OSMOSDR_LIBVER' was not declared in this scope make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/osmosdr_source_c_impl.cc.o] Error 1 make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 make: *** [all] Error 2 the cmake output is : -- Build type not specified: defaulting to release. -- Extracting version information from git describe... -- Configuring Boost C++ Libraries... -- checking for module 'gnuradio-iqbalance' -- package 'gnuradio-iqbalance' not found -- Found gnuradio-uhd: /usr/local/include, /usr/local/lib/libgnuradio-uhd.so -- Found gnuradio-fcd: /usr/local/include, /usr/local/lib/libgnuradio-fcd.so -- Will build with gnuradio iqbalance support. -- -- The build system will automatically enable all components. -- Use -DENABLE_DEFAULT=OFF to disable components by default. -- -- Configuring sysmocom OsmoSDR support... -- Dependency LIBOSMOSDR_FOUND = TRUE -- Enabling sysmocom OsmoSDR support. -- Override with -DENABLE_OSMOSDR=ON/OFF -- -- Configuring FunCube Dongle support... -- Dependency GNURADIO_FCD_FOUND = TRUE -- Enabling FunCube Dongle support. -- Override with -DENABLE_FCD=ON/OFF -- -- Configuring IQ File Source support... -- Dependency GNURADIO_CORE_FOUND = TRUE -- Enabling IQ File Source support. -- Override with -DENABLE_FILE=ON/OFF -- -- Configuring Osmocom RTLSDR support... -- Dependency LIBRTLSDR_FOUND = TRUE -- Enabling Osmocom RTLSDR support. -- Override with -DENABLE_RTL=ON/OFF -- -- Configuring RTLSDR TCP Client support... -- Dependency GNURADIO_CORE_FOUND = TRUE -- Enabling RTLSDR TCP Client support. -- Override with -DENABLE_RTL_TCP=ON/OFF -- -- Configuring Ettus UHD support... -- Dependency UHD_FOUND = TRUE -- Dependency GNURADIO_UHD_FOUND = TRUE -- Enabling Ettus UHD support. -- Override with -DENABLE_UHD=ON/OFF -- -- Configuring Osmocom MiriSDR support... -- Dependency LIBMIRISDR_FOUND = TRUE -- Enabling Osmocom MiriSDR support. -- Override with -DENABLE_MIRI=ON/OFF -- -- ###################################################### -- # gr-osmosdr enabled components -- ###################################################### -- * sysmocom OsmoSDR -- * FunCube Dongle -- * IQ File Source -- * Osmocom RTLSDR -- * RTLSDR TCP Client -- * Ettus UHD -- * Osmocom MiriSDR -- -- ###################################################### -- # gr-osmosdr disabled components -- ###################################################### -- -- Building for version: 1eb3af22 / 0.0.1git -- Using install prefix: /usr/local -- Configuring done -- Generating done -- Build files have been written to: /tmp/gr-osmosdr/build * * -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Tue Mar 12 05:58:24 2013 From: peter at stuge.se (Peter Stuge) Date: Tue, 12 Mar 2013 06:58:24 +0100 Subject: GSOC 2013 In-Reply-To: References: Message-ID: <20130312055824.30254.qmail@stuge.se> Hemant Singh wrote: > Why doesn't Osmocom apply for GSOC 2013? Because participating in GSOC requires significant amount of time for administration and mentoring. In my experience from a few other projects participating in GSOC it is unfortunately quite rare for students to really have success in hardware-related projects. > - Osmocom community will get to mentor students which is a very > important experience, because that is how one understands the > problems of new developers So far the community has grown with new developers who do not need very much mentoring in order to start contributing, and that of course saves everyone time. Nobody really has a lot of time to spare for mentoring, but anyone who is interested in starting to contribute can of course always try to get mentoring on the mailing lists and on IRC, also without GSOC. It's important to be self-sufficient though. Nobody will explain "the code" but somebody might well explain a specific detail if the right question is asked. //Peter From leif at sm5bsz.com Tue Mar 12 12:46:04 2013 From: leif at sm5bsz.com (Leif Asbrink) Date: Tue, 12 Mar 2013 13:46:04 +0100 Subject: R820T register map available In-Reply-To: <513E39FA.2010700@shikadi.net> References: <513E39FA.2010700@shikadi.net> Message-ID: <20130312134604.c19f3261.leif@sm5bsz.com> Hello Adam, Very interesting! Please send the document. I will not publish any part of it. Cheers Leif > One of the designers of the R820T tuner has recently been posting on the > ultra-cheap-sdr group, and has kindly supplied a map of the R820T registers > for private use only within the SDR community. He has asked that it not be > posted on any website, but only be forwarded around privately. > > To that end, if anyone would like a copy of this spreadsheet and would be > willing to likewise not publish it on the web, let me know off-list and I'll > send it to you. > > There's not a huge amount in the way of explanations, but it lists all the > registers and a very brief description of what they do. > > Cheers, > Adam. > From lorenz at schlagseite.de Wed Mar 13 17:47:44 2013 From: lorenz at schlagseite.de (Lorenz Wiedemann) Date: Wed, 13 Mar 2013 18:47:44 +0100 Subject: SDRSharp, E4000 USB dongle not working In-Reply-To: References: Message-ID: <5140BBC0.4050006@schlagseite.de> Hello, I am using two of the "usual" RTL2832-USB dongles, with Ubuntu 12.04. The one with the R820T tuner in it works with both GQRX and SDRSharp (although driving the laptop temperature beyond 60?C - P-Mobile 1,8 GHz, with SDRSharp/Mono only!). The one with E4000 tuner is only accepted by GQRX. SDRSharp says "Array index is out of range", although in the dropdown menu, for both dongles "RTL-SDR / USB" is displayed. Anyone got an idea ...? Lorenz From zn000h at gmail.com Fri Mar 15 00:01:33 2013 From: zn000h at gmail.com (Benedikt Heinz) Date: Fri, 15 Mar 2013 01:01:33 +0100 Subject: R820T vs. E4000 Message-ID: Hi everyone, although there are some comparisons between the R820T and the E4000 already [1, 2], I also did some tests with another use-case in mind. I'm working on a thing similar to RTLSDR-Scanner [3]. I want to monitor a large part of the spectrum continuously. So I compared the R820T with the E4000 using RTLSDR-Scanner w/ and w/o an antenna. My results are here: https://docs.google.com/folder/d/0ByDAKwyEiyx_XzZ5ZnpRV1VZWDQ/edit?usp=sharing There's much more spurs with the E4000 than w/ the R820T. According to [1, 2] one also would expect a better overall sensivity compared to the E4000. However, the GSM900 signals for example seem to be way better with the E4000 according to the RTLSDR-Scanner. Tuning to a certain channel w/ OsmoSDR Source in GNUradio gives about the same SNR - contrary to the RTLSDR-Scanner output. Can anyone explain this? Also, the DVB-T channel at 502MHz is quite weak in the R820T RTLSDR-Scanner output when compared to the E4000. I had a closer look at the lower limit of the channel in gnuradio. This can be seen in the 502MHz_*.png pictures. The E4000 produces a nice +20dB step while one can hardly see the channel in the R820T spectrum. I don't understand this as well. Is this AGC-related? Manually setting a fixed gain didn't really help though... Any explanations? Thank you! Best regards, Hunz [1] http://steve-m.de/projects/rtl-sdr/tuner_comparison/ [2] http://www.hamradioscience.com/rtl2832u-r820t-vs-rtl2832u-e4000/#more-1852 [3] https://github.com/EarToEarOak/RTLSDR-Scanner From sylvain.azarian at gmail.com Fri Mar 15 11:33:31 2013 From: sylvain.azarian at gmail.com (Sylvain AZARIAN) Date: Fri, 15 Mar 2013 12:33:31 +0100 Subject: R820T vs. E4000 In-Reply-To: References: Message-ID: Well, there can be lots of possible reasons... They are both direct conversion receivers, with local oscillator going from low vhf to high uhf band. We can expect lost of silicium bugs here : power level of the local oscillators frequency dependant, quadrature mismatch, mixers with conversion loss not constant etc. etc. honestly it is not easy to know; I guess this also depends on the part itself. My experience show that from one E4000 to another, the preamps can completely behave differently. On some units, when manually set to more than 17db, it works as an attenuator :-( the power level received decreases.... For me the most interesting plots were the "no antenna" ones, showing the LO leakage ;-) If I understood clearly your plots, you have at some places high power ghosts. Maybe you are close to powerful transmitters, but this is more probably a LO to RF isolation problem: the receiver receives himself... I usually play with the E4000, but I am waiting for some 820T to try. 2013/3/15 Benedikt Heinz > Hi everyone, > > although there are some comparisons between the R820T and the E4000 > already [1, 2], I also did some tests with another use-case in mind. > I'm working on a thing similar to RTLSDR-Scanner [3]. I want to > monitor a large part of the spectrum continuously. > So I compared the R820T with the E4000 using RTLSDR-Scanner w/ and w/o > an antenna. > My results are here: > > https://docs.google.com/folder/d/0ByDAKwyEiyx_XzZ5ZnpRV1VZWDQ/edit?usp=sharing > There's much more spurs with the E4000 than w/ the R820T. According to > [1, 2] one also would expect a better overall sensivity compared to > the E4000. > However, the GSM900 signals for example seem to be way better with the > E4000 according to the RTLSDR-Scanner. Tuning to a certain channel w/ > OsmoSDR Source in GNUradio gives about the same SNR - contrary to the > RTLSDR-Scanner output. Can anyone explain this? > Also, the DVB-T channel at 502MHz is quite weak in the R820T > RTLSDR-Scanner output when compared to the E4000. I had a closer look > at the lower limit of the channel in gnuradio. This can be seen in the > 502MHz_*.png pictures. The E4000 produces a nice +20dB step while one > can hardly see the channel in the R820T spectrum. I don't understand > this as well. Is this AGC-related? Manually setting a fixed gain > didn't really help though... > > Any explanations? > > Thank you! > > Best regards, > > Hunz > > [1] http://steve-m.de/projects/rtl-sdr/tuner_comparison/ > [2] > http://www.hamradioscience.com/rtl2832u-r820t-vs-rtl2832u-e4000/#more-1852 > [3] https://github.com/EarToEarOak/RTLSDR-Scanner > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zn000h at gmail.com Sat Mar 16 19:55:12 2013 From: zn000h at gmail.com (Benedikt Heinz) Date: Sat, 16 Mar 2013 20:55:12 +0100 Subject: R820T vs. E4000 In-Reply-To: References: Message-ID: 2013/3/15 Sylvain AZARIAN : > For me the most interesting plots were the "no antenna" ones, showing the LO > leakage ;-) If I understood clearly your plots, you have at some places high > power ghosts. Maybe you are close to powerful transmitters, but this is more > probably a LO to RF isolation problem: the receiver receives himself... I did two new measurements with the gain set to 20 in RTLSDR-Scanner. The files with the -gain20 in the filename [1] show the new results. There are more spikes from the R820T LOs now, but it's still less than with the E4000 I'd say. The good thing is that the DVB-T stations as well as some other signals can be found as expected now. 2013/3/16 Al : > I think you've run into a couple of issues, firstly it appears that the AGC > isn't fully disabled on the R820T (if you remove the aerial the noise floor > increases). It looks like gain=0 just was too little for the R820T. gain=20 seems to be a good start. Maybe exposing the gain-value in the regular UI would make sense? > Secondly RTLSDR-Scanner averages 2 chunks of bandwidth either side of the DC > point, these seem relatively quiet with an E4000 and FC0012 but I haven't > had chance to check the R820T yet. This tuner may have a very different > noise floor. I was wondering about adding a feature to allow the user to > pick their own segments (by terminating the aerial and looking at the noise > distribution). Ah, that's interesting. I was indeed wondering how you avoid the DC spike and my pathon skills are close to zero ;-) According to [2], the R820T doesn't use a Zero-IF, so there should be no DC-spike at all. > Has anyone had a chance to test 2 different dongles with the same tuner? > I'd be interested to know if it makes a difference to the noise floor, if > there is little change, I could vary the scan based on the tuner. I do have two E4000 and two R820T dongles, but I haven't yet compared the noise floor. I'm thinking about a per-dongle baseline file w/o an antenna for compensation. This approach should be more robust. Otherwise you need to shift the baseline spectrum according to the frequency error. Best regards, Hunz [1] https://docs.google.com/folder/d/0ByDAKwyEiyx_XzZ5ZnpRV1VZWDQ/edit?usp=sharing [2] http://lists.osmocom.org/pipermail/osmocom-sdr/2012-September/000253.html From zn000h at gmail.com Sat Mar 16 20:27:39 2013 From: zn000h at gmail.com (Benedikt Heinz) Date: Sat, 16 Mar 2013 21:27:39 +0100 Subject: [rtl-sdr] store frequency correction in eeprom? Message-ID: Some of you are probably using multiple dongles with alternating applications as well. Regarding the frequency correction, I put a sticker on each dongle and wrote the ppm value on it. However manually setting the value in each application is still annoying. So I used rtl_eeprom to write the value into the product-ID with the following format: "RTL%+dppm" resulting in sth. like this: RTL+87ppm I'm not sure if this is the best way to do it, but this approach works without changing librtlsdr. Another option might be storing the value in a non-used eeprom location and adding get/set functions to librtlsdr. Is it possible to write arbitrary values to unused eeprom locations without fucking up the realtek eeprom handling? Do you think this would be a better way? I'd like to hear your comments on this. It would be awesome if we could find a solution that many existing applications could incorporate. (Of course the ppm value still changes with temperature, but having a base value is still closer to the truth than 0ppm I'd say. I measured the offset directly after grabbing samples for 20 minutes at room-temperature and jitter is <1ppm.) Best regards, Hunz From alancorey at yahoo.com Sun Mar 17 02:21:39 2013 From: alancorey at yahoo.com (Alan Corey) Date: Sat, 16 Mar 2013 19:21:39 -0700 (PDT) Subject: [rtl-sdr] store frequency correction in eeprom? In-Reply-To: References: Message-ID: <1363486899.17854.YahooMailNeo@web161501.mail.bf1.yahoo.com> It sounds like a good idea, but there'd have to be some standardization.? Maybe it would gain in popularity to the point where they'd ship precalibrated but I doubt it because of the time involved. Of course different dongle types would have different addresses free, so you'd have to make up a table that had a pointer to the ppm data for each dongle type, and stick to it.? If Microsoft ever gets into the game they'll insist on redefining everything.? You could key the locations to the USB numbers. While you're at it it would be nice to use maybe at least a 16 bit value if possible.? I had mine all worked out to about 5 or 6 places then found I could only? store what might be an 8 bit integer.? SDR Sharp would only store mine as 102 instead of about 102.4567.? Since the correction is done in software there shouldn't be a limit on the size (data type) of the number. ? Alan ----- Radio Astronomy - the ultimate DX >________________________________ > From: Benedikt Heinz >To: osmocom-sdr at lists.osmocom.org >Sent: Saturday, March 16, 2013 4:27 PM >Subject: [rtl-sdr] store frequency correction in eeprom? > >Some of you are probably using multiple dongles with alternating >applications as well. >Regarding the frequency correction, I put a sticker on each dongle and >wrote the ppm value on it. >However manually setting the value in each application is still annoying. >So I used rtl_eeprom to write the value into the product-ID with the >following format: "RTL%+dppm" resulting in sth. like this: RTL+87ppm >I'm not sure if this is the best way to do it, but this approach works >without changing librtlsdr. >Another option might be storing the value in a non-used eeprom >location and adding get/set functions to librtlsdr. >Is it possible to write arbitrary values to unused eeprom locations >without fucking up the realtek eeprom handling? Do you think this >would be a better way? > >I'd like to hear your comments on this. >It would be awesome if we could find a solution that many existing >applications could incorporate. > >(Of course the ppm value still changes with temperature, but having a >base value is still closer to the truth than 0ppm I'd say. >I measured the offset directly after grabbing samples for 20 minutes >at room-temperature and jitter is <1ppm.) > >Best regards, > >Hunz > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alancorey at yahoo.com Sun Mar 17 14:48:49 2013 From: alancorey at yahoo.com (Alan Corey) Date: Sun, 17 Mar 2013 07:48:49 -0700 (PDT) Subject: Broadcast FM subcarrier decoding? Message-ID: <1363531729.94397.YahooMailNeo@web161504.mail.bf1.yahoo.com> This might be a better question for the Gnuradio list, but for years I've known that some broadcast FM stations actually transmit a second audio program which is somehow modulating a subcarrier in the main transmission.? It probably carries mostly elevator music type junk but is rumored to be commercial-free (a rare thing in the US!).? I remember seeing dedicated receivers advertised for this, but never actually bought one because I wasn't sure it was active in my area.? These date back to Lafayette Electronics days I think and ever since so 40 years or more. I've noticed (in SdrSharp) that on some FM stations I can see what look like they might be subcarriers on either side of the main signal.? Anyone decoded those? ? Alan ? ----- Radio Astronomy - the ultimate DX -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmocom at potophobia.net Sun Mar 17 15:34:04 2013 From: osmocom at potophobia.net (Ethan Trewhitt) Date: Sun, 17 Mar 2013 11:34:04 -0400 Subject: Broadcast FM subcarrier decoding? In-Reply-To: <1363531729.94397.YahooMailNeo@web161504.mail.bf1.yahoo.com> References: <1363531729.94397.YahooMailNeo@web161504.mail.bf1.yahoo.com> Message-ID: Alan, I believe the subcarriers you mention are the HDRadio sideband. I've tried decoding this band but have been unable so far - it seems that iBiquity holds their proprietary standards close and I guess the community hasn't yet figured out how to decode it. If anyone is aware of an approach to decoding HDRadio, I'd love to know. http://en.wikipedia.org/wiki/HD_Radio Ethan On Sun, Mar 17, 2013 at 10:48 AM, Alan Corey wrote: > This might be a better question for the Gnuradio list, but for years I've > known that some broadcast FM stations actually transmit a second audio > program which is somehow modulating a subcarrier in the main transmission. > It probably carries mostly elevator music type junk but is rumored to be > commercial-free (a rare thing in the US!). I remember seeing dedicated > receivers advertised for this, but never actually bought one because I > wasn't sure it was active in my area. These date back to Lafayette > Electronics days I think and ever since so 40 years or more. > > I've noticed (in SdrSharp) that on some FM stations I can see what look > like they might be subcarriers on either side of the main signal. Anyone > decoded those? > > Alan > > ----- > Radio Astronomy - the ultimate DX > -------------- next part -------------- An HTML attachment was scrubbed... URL: From al at eartoearoak.com Sun Mar 17 18:17:38 2013 From: al at eartoearoak.com (Al) Date: Sun, 17 Mar 2013 18:17:38 +0000 Subject: R820T vs. E4000 In-Reply-To: References: Message-ID: <514608C2.7030802@eartoearoak.com> Hi Hunz, I've just pushed some updated code up to GitHub, you can now set the gain in the preferences and tweak the scan settings. There's some info at http://eartoearoak.com/software/rtlsdr-scanner#tweaking A 250kHz offset seems to work well with my E4000, 140k with a FC0012 and 100k with a R820T. The FC0012 is the noisiest and the R820T is quietest. Hope it helps, Al On 17/03/2013 11:00, Benedikt Heinz wrote: >> For me the most interesting plots were the "no antenna" ones, showing the LO >> leakage ;-) If I understood clearly your plots, you have at some places high >> power ghosts. Maybe you are close to powerful transmitters, but this is more >> probably a LO to RF isolation problem: the receiver receives himself... > I did two new measurements with the gain set to 20 in RTLSDR-Scanner. > The files with the -gain20 in the filename [1] show the new results. > There are more spikes from the R820T LOs now, but it's still less than > with the E4000 I'd say. > The good thing is that the DVB-T stations as well as some other > signals can be found as expected now. > > 2013/3/16 Al : >> I think you've run into a couple of issues, firstly it appears that the AGC >> isn't fully disabled on the R820T (if you remove the aerial the noise floor >> increases). > It looks like gain=0 just was too little for the R820T. gain=20 seems > to be a good start. > Maybe exposing the gain-value in the regular UI would make sense? > >> Secondly RTLSDR-Scanner averages 2 chunks of bandwidth either side of the DC >> point, these seem relatively quiet with an E4000 and FC0012 but I haven't >> had chance to check the R820T yet. This tuner may have a very different >> noise floor. I was wondering about adding a feature to allow the user to >> pick their own segments (by terminating the aerial and looking at the noise >> distribution). > Ah, that's interesting. I was indeed wondering how you avoid the DC > spike and my pathon skills are close to zero ;-) > According to [2], the R820T doesn't use a Zero-IF, so there should be > no DC-spike at all. > >> Has anyone had a chance to test 2 different dongles with the same tuner? >> I'd be interested to know if it makes a difference to the noise floor, if >> there is little change, I could vary the scan based on the tuner. > I do have two E4000 and two R820T dongles, but I haven't yet compared > the noise floor. > I'm thinking about a per-dongle baseline file w/o an antenna for > compensation. This approach should be more robust. Otherwise you need > to shift the baseline spectrum according to the frequency error. > > Best regards, > > Hunz > > [1] https://docs.google.com/folder/d/0ByDAKwyEiyx_XzZ5ZnpRV1VZWDQ/edit?usp=sharing > [2] http://lists.osmocom.org/pipermail/osmocom-sdr/2012-September/000253.html > From cbs228 at gmail.com Sun Mar 17 20:44:50 2013 From: cbs228 at gmail.com (Colin Stagner) Date: Sun, 17 Mar 2013 15:44:50 -0500 Subject: rtl_fm scanning Message-ID: <51462B42.50301@gmail.com> I am also having the rtl_fm scanning bug which was first reported in http://lists.gnumonks.org/pipermail/osmocom-sdr/2013-February/000485.html The scanning mode in rtl_fm hangs during the re-tuning process. This makes it impossible to use rtl_fm in scanning mode. I am using Ubuntu 12.10 with libusb 2:1.0.12-2, the latest git master version of rtl-sdr, and an Elonics E4000 (Realtek, RTL2838UHIDIR). Here are the steps to reproduce: 1. Find some frequency FREQ_NOISE that is not in use, and some frequency FREQ_SIGNAL which is in use constantly (i.e., like a commercial FM station). Find an appropriate squelch value SQUELCH which will stop FREQ_NOISE but pass FREQ_SIGNAL. 2. rtl_fm -f ${FREQ_NOISE} -l ${SQUELCH}. The program should not pass any audio, but it will exit cleanly with ^C. 3. rtl_fm -f ${FREQ_SIGNAL} -l ${SQUELCH}. The program should pass audio and exit cleanly with ^C 4. rtl_fm -f ${FREQ_SIGNAL} -f ${FREQ_NOISE} -l 0. The scan will pause on the first channel and pass audio. 5. rtl_fm -f ${FREQ_NOISE} -f ${FREQ_SIGNAL} -l ${SQUELCH}. The program will not output any audio, even though the first frequency is squelched out and the scanning function should skip immediately to the second frequency. Additionally, it will not exit if sent a SIGINT with ^C, and it must be killed with a SIGKILL. I've made a stack trace of this behavior. The program hangs very consistently at the same location each time: http://pastebin.com/wzE09MCi Thread 1 (the USB buffer reading thread) hangs while waiting for the data_write mutex lock in rtl_fm.c:642. I presume the thread has exhausted its supply of data and isn't getting any more. Thread 2 is slightly more interesting, because it hangs during the libusb system calls within the tuning function rtlsdr_set_center_freq() in librtlsdr.c:796. My guess is that it's making a blocking call that never returns. Can anyone else reproduce this bug? From leif at sm5bsz.com Mon Mar 18 01:29:25 2013 From: leif at sm5bsz.com (Leif Asbrink) Date: Mon, 18 Mar 2013 02:29:25 +0100 Subject: R820T In-Reply-To: References: Message-ID: <20130318022925.b9250078.leif@sm5bsz.com> Hi All, When measuring the NF of dongles using this chip with traditional methods one gets very discouraging results. I need to turn up the noise source for NF to 17 dB before I see the desired 3dB increase in received noise power. Fortunately this is an artifact The NF is low, but there is some kind of noise controlled AGC somewhere. If I send one or two carriers into the dongle everything seems normal, but if I send a single carrier plus white noise into it, the intelligent "something" applies automastic gain control to keep the noise floor at a nearly unchanged level. The signal which is at a fixed level seems to decrease while the noise seems unchanged. This is not what we normally want in SDR. When looking at the code I just get confused. It is not obvious to me what gain control is involved. Presumably the RTL2832 chip has some clever algorithm for evaluating the noise floor and the output from that seems to be used for the R820T. I think that for SDR it would be better to disable all those things and allow the user to control gain manually. One of the good usages of RTL-SDR is to monitor the wideband noise floor of microwave systems. Measuring performance by measuring sun noise for example. That is not possible with the current implementation of the R820T. Is there anyone who could give a hint how to disable this feature? Regards Leif / SM5BSZ From jguthrie at brokersys.com Mon Mar 18 14:47:16 2013 From: jguthrie at brokersys.com (Jonathan Guthrie) Date: Mon, 18 Mar 2013 09:47:16 -0500 Subject: Broadcast FM subcarrier decoding? In-Reply-To: <1363531729.94397.YahooMailNeo@web161504.mail.bf1.yahoo.com> References: <1363531729.94397.YahooMailNeo@web161504.mail.bf1.yahoo.com> Message-ID: <514728F4.80000@brokersys.com> On 3/17/2013 9:48 AM, Alan Corey wrote: > This might be a better question for the Gnuradio list, but for years > I've known that some broadcast FM stations actually transmit a second > audio program which is somehow modulating a subcarrier in the main > transmission. It probably carries mostly elevator music type junk but > is rumored to be commercial-free (a rare thing in the US!). I > remember seeing dedicated receivers advertised for this, but never > actually bought one because I wasn't sure it was active in my area. > These date back to Lafayette Electronics days I think and ever since > so 40 years or more. > > I've noticed (in SdrSharp) that on some FM stations I can see what > look like they might be subcarriers on either side of the main > signal. Anyone decoded those? > > Alan > ----- > Radio Astronomy - the ultimate DX Many, if not most, FM stations US have subcarriers, if only to carry the stereo (L-R) signal and the bit that turns the "stereo" indication on. On the two SCA channels for alternate programming, you will find "elevator music," news broadcasts, audio books for the blind, and alternate language programming on them. Since they're usually done up as a subscription service, they don't have commercials. I've never decoded them, but I used to work at the transmitter site for an FM radio station. Our SCA's carried "ambient music" (for which I had to change the tape if one ran out) and some sort of agricultural news broadcast. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ranickels at gmail.com Mon Mar 18 15:31:16 2013 From: ranickels at gmail.com (Robert Nickels) Date: Mon, 18 Mar 2013 10:31:16 -0500 Subject: Broadcast FM subcarrier decoding? In-Reply-To: <5145F014.50303@comcast.net> References: <1363531729.94397.YahooMailNeo@web161504.mail.bf1.yahoo.com> <5145F014.50303@comcast.net> Message-ID: <51473344.102@gmail.com> On 3/17/2013 11:32 AM, Robert Nickels wrote: > On 3/17/2013 9:48 AM, Alan Corey wrote: >> I can see what look like they might be subcarriers on either side of >> the main signal. Anyone decoded those? > Hi Alan, Depending on where you live, there could be several subcarriers present in addition to the prominent 19 KHz stereo pilot. From your description I'm pretty sure you're referring to Sub Carrier Authorization (SCA) which has been mainly used for background music and an audio book reading service for the blind as well as other voice and data services. SCA uses 67 or 92 KHz subcarriers which can be seen on the composite FM signal. If you have a soundcard with sufficient bandwidth you can send the output of SDR# (in NBFM, 150 KHz mode) to another instance of SDR# *(sound card, DSB mode) using Virtual Audio Cable. My soundcard won't go high enough but here's a set of screen images from a system that can, where the various elements on the upper side of the FM channel center are annotated: http://img208.imageshack.us/img208/5922/fmspectrum.png Another subcarrier is used for RDS (Radio Data System) or RDBS in the US digital data channel which can easily seen at 57 KHz on stations utilizing this service. In the US The arithmetic sum of all multiplex subcarriers may not exceed 20% modulation and different rules apply than for the primary broadcast channel. 73, Bob W9RAN From alancorey at yahoo.com Tue Mar 19 03:07:43 2013 From: alancorey at yahoo.com (Alan Corey) Date: Mon, 18 Mar 2013 20:07:43 -0700 (PDT) Subject: Broadcast FM subcarrier decoding? In-Reply-To: <51473344.102@gmail.com> References: <1363531729.94397.YahooMailNeo@web161504.mail.bf1.yahoo.com> <5145F014.50303@comcast.net> <51473344.102@gmail.com> Message-ID: <1363662463.17927.YahooMailNeo@web161503.mail.bf1.yahoo.com> Yes, SCA is what I was thinking of.? I used to be an electronics technician in consumer electronics back in the 70s and this was on licensing exams, aside from seeing them in catalogs.? Being from a rural area it was just something I read about, I never actually saw one.? I had forgotten the L-R signal was on a 19 KHz subcarrier, I was looking for a 1.9 KHz, which makes no sense since it would be in the audio passband. If I run into it again I'll grab a screen shot, but what I was probably seeing was an overload condition on my poor little NooElec dongle.? There's a 2 meter repeater about 20 miles away, but line of sight.? When that keys up I see peaks all over the 2 MHz range that SDRSharp shows me for 2 meters, but they all go away when it unkeys.? The FM broadcast station I was thinking of is a little farther away but of course a lot more powerful.? When I look for them now I can't find them.? I remember checking one to see if it was 1.9 KHz away from the main peak, but it was several times that, maybe around 8 KHz. Enjoyed the QST article, my copy came about a week after my dongle.? I built one of the upconverter kits from Hayseed Hamfest, and it works, but it's deaf as a post.? Even on my 150 foot longwire I can only hear the stronger stations.? AM broadcast stations and the strong bible beaters are about it.? Tuning the HF ham bands, I've rarely heard hams and then only 1 side of each QSO. The SA612 data sheet I've got (Philips) is skimpy on specifics but I wonder about the oscillator injection level.? I've been trying to decide whether to put a pot in there to adjust or a dual gate mosfet broadband preamp on it.? It seems like the oscillator level should be close to the signal level.? I've got some BF998 FETs I was going to use because I can put a pot on the gate 2 voltage to control the gain. ? 73,? Alan,? AB1JX ? ----- Radio Astronomy - the ultimate DX >________________________________ > From: Robert Nickels >To: >Cc: osmocom-sdr at lists.osmocom.org >Sent: Monday, March 18, 2013 11:31 AM >Subject: Re: Broadcast FM subcarrier decoding? > >On 3/17/2013 11:32 AM, Robert Nickels wrote: >> On 3/17/2013 9:48 AM, Alan Corey wrote: >>> I can see what look like they might be subcarriers on either side of the main signal.? Anyone decoded those? >> >Hi Alan, > >Depending on where you live, there could be several subcarriers present in addition to the prominent 19 KHz stereo pilot.? From your description I'm pretty sure you're referring to Sub Carrier Authorization (SCA) which has been mainly used for background music and an audio book reading service for the blind as well as other voice and? data services.? SCA uses 67 or 92 KHz subcarriers which can be seen on the composite FM signal.? If you have a soundcard with sufficient bandwidth? you can send the output of SDR# (in NBFM, 150 KHz mode) to another instance of SDR# *(sound card, DSB mode) using Virtual Audio Cable.? ? My soundcard won't go high enough but here's a set of screen images from a system that can, where the various elements on the upper side of the FM channel center are annotated: http://img208.imageshack.us/img208/5922/fmspectrum.png > >Another subcarrier is used for RDS (Radio Data System) or RDBS in the US digital data channel which can easily seen at 57 KHz on stations utilizing this service.? In the US The arithmetic sum of all multiplex subcarriers may not exceed 20% modulation and different rules apply than for the primary broadcast channel. > >73, Bob W9RAN > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coinchon at yahoo.com Wed Mar 20 16:36:27 2013 From: coinchon at yahoo.com (Mathias Coinchon) Date: Wed, 20 Mar 2013 09:36:27 -0700 (PDT) Subject: Simple SDR transmitter Message-ID: <1363797387.14052.YahooMailNeo@web162106.mail.bf1.yahoo.com> Hello, You may be interest by this project from Tipok: http://tipok.org.ua/node/41 It's a simplified and low cost SDR transmission interface using an FX2 USB controller and an AD9957 modulator/DAC. Here he's using it to create a DAB digital radio transmission using CRC mmbtools DAB multiplexer/modulator. Mathias opendigitalradio.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From coinchon at yahoo.com Wed Mar 20 16:36:27 2013 From: coinchon at yahoo.com (Mathias Coinchon) Date: Wed, 20 Mar 2013 09:36:27 -0700 (PDT) Subject: Simple SDR transmitter Message-ID: <1363797387.14052.YahooMailNeo@web162106.mail.bf1.yahoo.com> Hello, You may be interest by this project from Tipok: http://tipok.org.ua/node/41 It's a simplified and low cost SDR transmission interface using an FX2 USB controller and an AD9957 modulator/DAC. Here he's using it to create a DAB digital radio transmission using CRC mmbtools DAB multiplexer/modulator. Mathias opendigitalradio.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From csvendsen2143 at gmail.com Mon Mar 25 17:10:26 2013 From: csvendsen2143 at gmail.com (Chris Svendsen) Date: Mon, 25 Mar 2013 13:10:26 -0400 Subject: RTL_TCP Commands Message-ID: Sending commands to RTL_TCP What format do the commands need to be in order to change the frequency of RTL_TCP. I have tried the following and the frequency will change but no to the frequency that is expected for example: This code : char SET_FREQUENCY[] ={0x01}; string Freq = string(SET_FREQUENCY,1)+"500000000"; answer = send(sConnect,Freq.c_str(),11,0); Changes the freq to this: client accepted! set freq 892350512 ll+, now 1 ll+, now 2 Any help would be greatly appreciated as i have been stuck on this for days. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steve-m.de Mon Mar 25 17:44:53 2013 From: steve at steve-m.de (Steve Markgraf) Date: Mon, 25 Mar 2013 18:44:53 +0100 Subject: RTL_TCP Commands In-Reply-To: References: Message-ID: <51508D15.3090000@steve-m.de> Hi, On 25.03.2013 18:10, Chris Svendsen wrote: > char SET_FREQUENCY[] ={0x01}; > string Freq = string(SET_FREQUENCY,1)+"500000000"; > answer = send(sConnect,Freq.c_str(),11,0); The "set frequency"-command of rtl_tcp expects an unsigned 32 bit integer in network byte order, not a string. Host implementation: http://cgit.osmocom.org/rtl-sdr/tree/src/rtl_tcp.c#n325 Client implementation: http://cgit.osmocom.org/gr-osmosdr/tree/lib/rtl_tcp/rtl_tcp_source_f.cc#n275 Regards, Steve From csvendsen2143 at gmail.com Tue Mar 26 13:50:27 2013 From: csvendsen2143 at gmail.com (Chris Svendsen) Date: Tue, 26 Mar 2013 09:50:27 -0400 Subject: RTL_TCP Commands Message-ID: Thank you all for the quick response. Unfortunately I'm still having some trouble. This is what I have so far ( Its a lil messy but just for testing it should work ) This is based on the Client implementation: http://cgit.osmocom.org/gr-osmosdr/tree/lib/rtl_tcp/rtl_tcp_source_f.cc#n275 #define COMM_SET_FREQ ((unsigned char) 0x01) struct command{ unsigned char cmd; unsigned int param; }; unsigned char cmds; int iFreq = 500000000; cmds = COMM_SET_FREQ; struct command cmd = {cmds, htonl(iFreq)}; answer = send(sConnect, (const char*)&cmd, sizeof(cmd), 0); and the response is : client accepted! set freq -858993635 ll+, now 1 ll+, now 2 ll+, now 3 I'm sure I'm missing something I just don't know what. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Tue Mar 26 14:10:53 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 26 Mar 2013 15:10:53 +0100 Subject: RTL_TCP Commands In-Reply-To: References: Message-ID: > I'm sure I'm missing something I just don't know what. __attribute__((packed)) Cheers, Sylvain From steve at steve-m.de Tue Mar 26 14:16:50 2013 From: steve at steve-m.de (Steve Markgraf) Date: Tue, 26 Mar 2013 15:16:50 +0100 Subject: RTL_TCP Commands In-Reply-To: References: Message-ID: <5151ADD2.2050303@steve-m.de> Hi, On 26.03.2013 14:50, Chris Svendsen wrote: > #define COMM_SET_FREQ ((unsigned char) 0x01) > struct command{ > unsigned char cmd; > unsigned int param; > }; > unsigned char cmds; > int iFreq = 500000000; > cmds = COMM_SET_FREQ; > struct command cmd = {cmds, htonl(iFreq)}; > > answer = send(sConnect, (const char*)&cmd, sizeof(cmd), 0); What's the sizeof(cmd), is it really 5? Seems like you're missing the __attribute__((packed)) to make sure the members of the struct are byte-aligned. Regards, Steve From csvendsen2143 at gmail.com Tue Mar 26 16:15:22 2013 From: csvendsen2143 at gmail.com (Chris Svendsen) Date: Tue, 26 Mar 2013 12:15:22 -0400 Subject: Fwd: RTL_TCP Commands In-Reply-To: References: Message-ID: Added the attribute packed struct command{ unsigned char cmd; unsigned int param; }__attribute__((packed)); The sizeof(cmd) is 8 it was also 8 before attrib packed was added. thanks ---------- Forwarded message ---------- From: Chris Svendsen Date: Mon, Mar 25, 2013 at 1:10 PM Subject: RTL_TCP Commands To: osmocom-sdr at lists.osmocom.org Sending commands to RTL_TCP What format do the commands need to be in order to change the frequency of RTL_TCP. I have tried the following and the frequency will change but no to the frequency that is expected for example: This code : char SET_FREQUENCY[] ={0x01}; string Freq = string(SET_FREQUENCY,1)+"500000000"; answer = send(sConnect,Freq.c_str(),11,0); Changes the freq to this: client accepted! set freq 892350512 ll+, now 1 ll+, now 2 Any help would be greatly appreciated as i have been stuck on this for days. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From csvendsen2143 at gmail.com Tue Mar 26 21:06:06 2013 From: csvendsen2143 at gmail.com (Chris Svendsen) Date: Tue, 26 Mar 2013 17:06:06 -0400 Subject: Fwd: RTL_TCP Commands In-Reply-To: References: Message-ID: Got it I was missing the below: #ifdef _WIN32 #define __attribute__(x) #pragma pack(push, 1) #ifdef _WIN32 #pragma pack(pop) #endif for now in the function i have int nFreq; #define COMM_SET_FREQ ((unsigned char) 0x01) #ifdef _WIN32 #define __attribute__(x) #pragma pack(push, 1) #endif struct command{ unsigned char cmd; unsigned int param; }__attribute__((packed)); #ifdef _WIN32 #pragma pack(pop) #endif void sendCommand(unsigned char cmds, unsigned int parami) { int left; int sent; int retr = 0; struct command cmd={cmds, htonl(parami)}; left=sizeof(cmd); while(left >0) { //start the funtion of winsock dll int answer; WSAData wsaData; WORD DLLVersion; DLLVersion = MAKEWORD(2,1); answer = WSAStartup(DLLVersion, &wsaData); SOCKADDR_IN addr; int addrlen = sizeof(addr); //setup socket SOCKET sConnect; // internet family of connection oriented socket sConnect = socket(AF_INET, SOCK_STREAM,NULL); //configure the strucket it addre addr.sin_addr.s_addr = inet_addr("127.0.0.1"); //Now we have to retype the faimly addr.sin_family = AF_INET; // set port google htons addr.sin_port = htons(1234); // no we have to type in the client should connect to tthe server connect(sConnect, (SOCKADDR*)&addr, sizeof(addr)); answer = send(sConnect, (char*)&cmd+(sizeof(cmd)-left), left, 0); cout << (char*)&cmd+(sizeof(cmd)-left) < Date: Mon, Mar 25, 2013 at 1:10 PM Subject: RTL_TCP Commands To: osmocom-sdr at lists.osmocom.org Sending commands to RTL_TCP What format do the commands need to be in order to change the frequency of RTL_TCP. I have tried the following and the frequency will change but no to the frequency that is expected for example: This code : char SET_FREQUENCY[] ={0x01}; string Freq = string(SET_FREQUENCY,1)+"500000000"; answer = send(sConnect,Freq.c_str(),11,0); Changes the freq to this: client accepted! set freq 892350512 ll+, now 1 ll+, now 2 Any help would be greatly appreciated as i have been stuck on this for days. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From csvendsen2143 at gmail.com Wed Mar 27 15:25:17 2013 From: csvendsen2143 at gmail.com (Chris Svendsen) Date: Wed, 27 Mar 2013 11:25:17 -0400 Subject: RTL_TCP Output Message-ID: I am attempting to write a program in c++ to transform the output of RTL_TCP to an audio device as nFM 12500 bandwidth. The problem is I have no idea where to even start could someone point me in the right direction to find out what format the out put of RTL_TCP is or where to find some documentation on how to even start converting it to audio. thanks for your time -------------- next part -------------- An HTML attachment was scrubbed... URL: From ranickel at comcast.net Sun Mar 17 16:32:20 2013 From: ranickel at comcast.net (Robert Nickels) Date: Sun, 17 Mar 2013 11:32:20 -0500 Subject: Broadcast FM subcarrier decoding? In-Reply-To: <1363531729.94397.YahooMailNeo@web161504.mail.bf1.yahoo.com> References: <1363531729.94397.YahooMailNeo@web161504.mail.bf1.yahoo.com> Message-ID: <5145F014.50303@comcast.net> On 3/17/2013 9:48 AM, Alan Corey wrote: > I can see what look like they might be subcarriers on either side of > the main signal. Anyone decoded those? Hi Alan, Depending on where you live, there could be several subcarriers present. From your description I'm pretty sure you're referring to Sub Carrier Authorization (SCA) which has been mainly used for background music and an audio book reading service for the blind as well as other voice and data services. SCA uses 67 or 92 KHz subcarriers which can be seen on the composite FM signal. If you have a soundcard with sufficient bandwidth you can send the output of SDR# (in NBFM, 150 KHz mode) to another instance of SDR# *(sound card, DSB mode) using Virtual Audio Cable. My soundcard won't go high enough but here's a set of screen images from a system that can, where the various elements on the upper side of the FM channel center are annotated: http://img208.imageshack.us/img208/5922/fmspectrum.png The RDS (Radio Data System) or RDBS in the US digital data channel is easily seen at 57 KHz, The level of all these subcarriers is much lower than the stereo pilot so you'll need a strong signal for decoding. 73, Bob W9RAN From alancorey at yahoo.com Thu Mar 28 02:19:40 2013 From: alancorey at yahoo.com (Alan Corey) Date: Wed, 27 Mar 2013 19:19:40 -0700 (PDT) Subject: Broadcast FM subcarrier decoding? In-Reply-To: <5145F014.50303@comcast.net> References: <1363531729.94397.YahooMailNeo@web161504.mail.bf1.yahoo.com> <5145F014.50303@comcast.net> Message-ID: <1364437180.35220.YahooMailNeo@web161502.mail.bf1.yahoo.com> SCA is what I was thinking of, but this sounds more like overload.? From my raw notes: ?If I tune to 88.500 MHz I see signals about 88.3367 and 88.662 The upper one is 162 KHz away, the lower one 163.? If I click on one I hear nothing. The same is true of WAMC(?) at 90.300 with 90.138 and 90.465 so 162 and 165. ----- I don't have a screen shot and I haven't seen it happen lately. ? Alan ----- Radio Astronomy - the ultimate DX ----- Original Message ----- > From: Robert Nickels > To: osmocom-sdr at lists.osmocom.org > Cc: > Sent: Sunday, March 17, 2013 12:32 PM > Subject: Re: Broadcast FM subcarrier decoding? > > On 3/17/2013 9:48 AM, Alan Corey wrote: >> I can see what look like they might be subcarriers on either side of the > main signal.? Anyone decoded those? > > Hi Alan, > > Depending on where you live, there could be several subcarriers present.? From > your description I'm pretty sure you're referring to Sub Carrier > Authorization (SCA) which has been mainly used for background music and an audio > book reading service for the blind as well as other voice and? data services.? > SCA uses 67 or 92 KHz subcarriers which can be seen on the composite FM signal.? > If you have a soundcard with sufficient bandwidth? you can send the output of > SDR# (in NBFM, 150 KHz mode) to another instance of SDR# *(sound card, DSB > mode)? using Virtual Audio Cable.? ? My soundcard won't go high enough but > here's a set of screen images from a system that can, where the various > elements on the upper side of the FM channel center are annotated: > http://img208.imageshack.us/img208/5922/fmspectrum.png > > The RDS (Radio Data System) or RDBS in the US digital data channel is easily > seen at 57 KHz,? The level of all these subcarriers is much lower than the > stereo pilot so you'll need a strong signal for decoding. > > 73, Bob W9RAN > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trillium2024 at gmail.com Thu Mar 28 13:53:24 2013 From: trillium2024 at gmail.com (Trillium 2024) Date: Thu, 28 Mar 2013 09:53:24 -0400 Subject: "ld: warning: could not create compact unwind for rtl_source_c::rtl_source_" while building gr-osmosdr Message-ID: Hello, Thank you for your great software! While building gr-osmosdr yesterday and the day before, I have been getting this new error while compiling. The compiler is gcc 4.7 under Os X 10.5.8 I'm also having unexplained crashes.. Applications that use the library are having issues. Here is the complete message. It occurs twice, Linking CXX shared library libgnuradio-osmosdr.dylib cd /Volumes/xyz/builds/osmocom/gr-osmosdr/build/lib && "/Applications/CMake 2.8-7.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/gnuradio-osmosdr.dir/link.txt --verbose=1 /opt/local/bin/i386-apple-darwin9-g++-mp-4.7 -O3 -DNDEBUG -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -dynamiclib -Wl,-headerpad_max_install_names -compatibility_version 0.0.1 -o libgnuradio-osmosdr.0.0.1git.dylib -install_name /Volumes/xyz/builds/osmocom/gr-osmosdr/build/lib/libgnuradio-osmosdr.0.0.1git.dylib CMakeFiles/gnuradio-osmosdr.dir/osmosdr_source_c_impl.cc.o CMakeFiles/gnuradio-osmosdr.dir/osmosdr_sink_c_impl.cc.o CMakeFiles/gnuradio-osmosdr.dir/osmosdr_ranges.cc.o CMakeFiles/gnuradio-osmosdr.dir/osmosdr_device.cc.o CMakeFiles/gnuradio-osmosdr.dir/file/file_source_c.cc.o CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o CMakeFiles/gnuradio-osmosdr.dir/rtl_tcp/rtl_tcp_source_f.cc.o CMakeFiles/gnuradio-osmosdr.dir/rtl_tcp/rtl_tcp_source_c.cc.o -L/opt/local/lib /opt/local/lib/libboost_thread-mt.dylib /opt/local/lib/libboost_system-mt.dylib /opt/local/lib/libgruel.dylib /opt/local/lib/libgnuradio-core.dylib /opt/local/lib/libgnuradio-core.dylib /opt/local/lib/librtlsdr.dylib /opt/local/lib/libgnuradio-core.dylib /opt/local/lib/librtlsdr.dylib ld: warning: could not create compact unwind for rtl_source_c::rtl_source_c(std::basic_string, std::allocator > const&): stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for rtl_source_c::rtl_source_c(std::basic_string, std::allocator > const&): stack subq instruction is too different from dwarf stack size ..... Then a few lines down, it happens a second time.. Linking CXX shared module _osmosdr_swig.so cd /Volumes/xyz/builds/osmocom/gr-osmosdr/build/swig && "/Applications/CMake 2.8-7.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/_osmosdr_swig.dir/link.txt --verbose=1 /opt/local/bin/i386-apple-darwin9-g++-mp-4.7 -O3 -DNDEBUG -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -bundle -Wl,-headerpad_max_install_names -o _osmosdr_swig.so CMakeFiles/_osmosdr_swig.dir/osmosdr_swigPYTHON_wrap.cxx.o -L/opt/local/lib /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib ../lib/libgnuradio-osmosdr.0.0.1git.dylib /opt/local/lib/libboost_thread-mt.dylib /opt/local/lib/libboost_system-mt.dylib /opt/local/lib/libgruel.dylib /opt/local/lib/libgnuradio-core.dylib /opt/local/lib/librtlsdr.dylib /opt/local/lib/libgnuradio-core.dylib /opt/local/lib/librtlsdr.dylib ld: warning: could not create compact unwind for swig::SwigPySequence_Ref, std::allocator > >::operator std::basic_string, std::allocator >() const: stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for swig::SwigPySequence_Ref::operator osmosdr::device_t() const: stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for swig::SwigPySequence_Ref, std::allocator >, std::basic_string, std::allocator > > >::operator std::pair, std::allocator >, std::basic_string, std::allocator > >() const: stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for swig::SwigPySequence_Ref::operator osmosdr::range_t() const: stack subq instruction is too different from dwarf stack size ??? From trillium2024 at gmail.com Thu Mar 28 18:53:34 2013 From: trillium2024 at gmail.com (Trillium 2024) Date: Thu, 28 Mar 2013 14:53:34 -0400 Subject: "ld: warning: could not create compact unwind for rtl_source_c::rtl_source_" while building gr-osmosdr Message-ID: Please disregard my previous posting. Setting the compiler flag "-march=native" eliminated the error messages. From jsalsburg at bellsouth.net Sun Mar 31 04:30:54 2013 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Sat, 30 Mar 2013 23:30:54 -0500 Subject: Breakthrough in DAQ In-Reply-To: References: Message-ID: This new technology will allow simultaneous monitoring of 8 dongles/receivers at 12 bits/500 KHz each for an attractive price of $150. http://www.mccdaq.com/usb-data-acquisition/USB-200-Series.aspx Jay Salsburg -------------- next part -------------- An HTML attachment was scrubbed... URL: