From laforge at gnumonks.org Wed Apr 11 20:22:08 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 11 Apr 2018 22:22:08 +0200 Subject: Save the Date: OsmoCon 2018 on October 18-19, 2018 Message-ID: <20180411202208.GD28162@nataraja> == OsmoCon 2018 == OsmoCon (Osmocom Conference) 2018 is the technical conference for Osmocom users, operators and developers! We are happy to announce the date of OsmoCon 2018. It has been scheduled on October 18 + 19, 2018 and will happen in Berlin, Germany. For the second time, the Osmocom Conference brings together users, operators and developers of the Osmocom Open Source cellular infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN and others. Join us for two days of presentations and discussions with the main developers behind Open Source Mobile Communications, as well as commercial and non-profit users of the Osmocom cellular infrastructure software. You can find some initial information in our wiki at http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018 which will be updated as more information becomes available. == Call for Participation == We're also at the same time announcing the Call for Participation and call on everyone with experiences to share around the Osmocom member projects to submit talks, workshops, discussions or other proposals. You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp We are particularly looking for contributions about: * updates on features/functionality/status of individual Osmocom projects * success stories on how Osmocom projects are deployed in practice * migration from OsmoNITB to the post-NITB architecture * tutorials / workshops on how to setup / analyze Osmocom projects * statistics, reporting, operations aspects of Osmocom projects * third-party open source utilities to be used with Osmocom projects Looking forward to meeting many existing and new Osmocom users at OsmCon this October! Regards, Harald Welte -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From minecraft2048 at gmail.com Wed Apr 18 13:39:37 2018 From: minecraft2048 at gmail.com (Ignatius Rivaldi) Date: Wed, 18 Apr 2018 23:39:37 +1000 Subject: Gnuradio >= 3.7.12.0 breaks gr-fosphor Message-ID: Hi, A QT API change in Gnuradio 3.17.12.0 : https://github.com/gnuradio/gnuradio/pull/1418 breaks modules that relies on QT windowing system, resulting in Template error on generated python file, resulting in this error when I try to run the generated python file: Executing: /usr/sbin/python2 -u /home/feanor/Development/SDR/top_block.py File "/home/feanor/Development/SDR/top_block.py", line 69 self.fosphor_qt_sink_c_2 = Template error: #set $win = 'self._%s_win'%$id ^ SyntaxError: invalid syntax >>> Done (return code 1) This also affects other modules that relies on QT: gr-inspector: https://github.com/gnuradio/gr-inspector/issues/2 Following the fix in this pull request for gr-inspector: https://github.com/gnuradio/gr-inspector/pull/21/commits/9d00bb83c155c84ee8cf6918607e751760ce07e9 by changing a line: 15c15 < $(gui_hint()($win)) --- > $(gui_hint() % $win) fixes the problem for gr-fosphor and make the flowgraph runnable again From 246tnt at gmail.com Wed Apr 18 15:26:47 2018 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 18 Apr 2018 17:26:47 +0200 Subject: Gnuradio >= 3.7.12.0 breaks gr-fosphor In-Reply-To: References: Message-ID: Yeah I saw that this morning, but unfortunately that then breaks it for anything < 3.7.12 .... Not sure wtf the guy doing that API change was thinking .... Still looking for a solution to support everything. On Wed, Apr 18, 2018 at 3:39 PM, Ignatius Rivaldi wrote: > Hi, > > A QT API change in Gnuradio 3.17.12.0 : > https://github.com/gnuradio/gnuradio/pull/1418 breaks modules that > relies on QT windowing system, resulting in Template error on > generated python file, resulting in this error when I try to run the > generated python file: > > > Executing: /usr/sbin/python2 -u /home/feanor/Development/SDR/top_block.py > > File "/home/feanor/Development/SDR/top_block.py", line 69 > self.fosphor_qt_sink_c_2 = Template error: #set $win = 'self._%s_win'%$id > ^ > SyntaxError: invalid syntax > >>>> Done (return code 1) > > > This also affects other modules that relies on QT: > > gr-inspector: https://github.com/gnuradio/gr-inspector/issues/2 > > Following the fix in this pull request for gr-inspector: > https://github.com/gnuradio/gr-inspector/pull/21/commits/9d00bb83c155c84ee8cf6918607e751760ce07e9 > by changing a line: > > 15c15 > < $(gui_hint()($win)) > --- >> $(gui_hint() % $win) > > fixes the problem for gr-fosphor and make the flowgraph runnable again From mueller at kit.edu Wed Apr 18 16:20:18 2018 From: mueller at kit.edu (=?utf-8?B?TcO8bGxlciwgTWFyY3VzIChDRUwp?=) Date: Wed, 18 Apr 2018 16:20:18 +0000 Subject: Gnuradio >= 3.7.12.0 breaks gr-fosphor In-Reply-To: References:

Message-ID: <1524068417.9532.1.camel@kit.edu> I hope my latest commit on gnuradio maint-3.7 fixes that; would someone be as nice as to try that? Sorry, this bug slipped my maintainer attention. Best regards, Marcus On Wed, 2018-04-18 at 17:26 +0200, Sylvain Munaut wrote: > Yeah I saw that this morning, but unfortunately that then breaks it > for anything < 3.7.12 .... > > Not sure wtf the guy doing that API change was thinking .... Still > looking for a solution to support everything. > > On Wed, Apr 18, 2018 at 3:39 PM, Ignatius Rivaldi > wrote: > > Hi, > > > > A QT API change in Gnuradio 3.17.12.0 : > > https://github.com/gnuradio/gnuradio/pull/1418 breaks modules that > > relies on QT windowing system, resulting in Template error on > > generated python file, resulting in this error when I try to run > > the > > generated python file: > > > > > > Executing: /usr/sbin/python2 -u > > /home/feanor/Development/SDR/top_block.py > > > > File "/home/feanor/Development/SDR/top_block.py", line 69 > > self.fosphor_qt_sink_c_2 = Template error: #set $win = > > 'self._%s_win'%$id > > ^ > > SyntaxError: invalid syntax > > > > > > > Done (return code 1) > > > > > > This also affects other modules that relies on QT: > > > > gr-inspector: https://github.com/gnuradio/gr-inspector/issues/2 > > > > Following the fix in this pull request for gr-inspector: > > https://github.com/gnuradio/gr-inspector/pull/21/commits/9d00bb83c1 > > 55c84ee8cf6918607e751760ce07e9 > > by changing a line: > > > > 15c15 > > < $(gui_hint()($win)) > > --- > > > $(gui_hint() % $win) > > > > fixes the problem for gr-fosphor and make the flowgraph runnable > > again From minecraft2048 at gmail.com Wed Apr 18 22:03:54 2018 From: minecraft2048 at gmail.com (Ignatius Rivaldi) Date: Thu, 19 Apr 2018 08:03:54 +1000 Subject: gr-fosphor is choppy at audio frequency Message-ID: Hi, I'm (ab)using gr-fosphor for audio spectrum visualization by using float to complex because it is the most colorful spectrum analyzer that I have. Unfortunately, for some reason gr-fosphor is choppy at 48 kHz, while it is smooth at rtl-sdr output, about 2 MSPS or so. Is there any FFT configuration setting like other spectrum analyzer to change how many FFT bins and the framerate? From jmihotek at yahoo.com Mon Apr 16 23:06:29 2018 From: jmihotek at yahoo.com (Jose Mihotek) Date: Mon, 16 Apr 2018 23:06:29 +0000 (UTC) Subject: windows GNU Radio error 12 Fatal failed to find rtlsdr device References: <930228427.1188802.1523919989208.ref@mail.yahoo.com> Message-ID: <930228427.1188802.1523919989208@mail.yahoo.com> All, ?I installed GNU Radio for windows on my machine running Windows 10.when I try to run GRC it comes back with: <<< Welcome to GNU Radio Companion 3.7.11.1 >>> Block paths: C:\Program Files\GNURadio-3.7\share\gnuradio\grc\blocks Loading: "C:\Users\JoseM\Documents\GNU\test w grc.grc">>> Done Generating: 'C:\\Users\\JoseM\\Documents\\GNU\\top_block.py' Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u C:\Users\JoseM\Documents\GNU\top_block.py Win32; Microsoft Visual C++ version 14.0; Boost_106000; UHD_003.010.001.001-0-unknown gr-osmosdr c653754d (0.1.5git) gnuradio 3.7.11.1built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf airspy redpitaya?Using device #0 Generic RTL2832U OEMusb_open error -12 FATAL: Failed to open rtlsdr device. Trying to fill up 1 missing channel(s) with null source(s).This is being done to prevent the application from crashingdue to gnuradio bug #528. Anybody have any idea how to fix this ?Thanks, Jose -------------- next part -------------- An HTML attachment was scrubbed... URL: From minecraft2048 at gmail.com Sat Apr 21 02:07:55 2018 From: minecraft2048 at gmail.com (Ignatius Rivaldi) Date: Sat, 21 Apr 2018 12:07:55 +1000 Subject: Bug: gr-osmoscom for USRP B210 have this weird center frequency signal while gr-UHD don't Message-ID: Hi, At first I reported this bug at Gqrx mailing list: https://groups.google.com/forum/#!topic/gqrx/pVea3JObMLw , then Csete mentioned that Gqrx uses gr-osmosdr source, while I'm using gr-uhd source. Then I tried it again using osmocom source, then that weird center frequency noise appears again. I've attached several screenshots and GRC flowchart that I used to reproduce this bug (it uses gr-fosphor). Maedhros_008.png is the screenshot of gr-fosphor displaying the correct UHD: USRP source, with all of FM broadcast radio visible, while Maedhros_011.png is the gr-fosphor showing the output of osmocom source, with this big ~2MHz spike at center frequency, and all of those FM broadcast radio are not visible. I'm using Arch Linux with gnuradio, gr-fosphor, and gr-osmosdr compiled from source using makepkg/pkgbuild system, and libuhd 3.10.2.0-3 -------------- next part -------------- A non-text attachment was scrubbed... Name: Maedhros_011.png Type: image/png Size: 305582 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Maedhros_008.png Type: image/png Size: 1569360 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.grc Type: application/octet-stream Size: 68051 bytes Desc: not available URL: From zvpunry at zvpunry.de Tue Apr 24 10:36:54 2018 From: zvpunry at zvpunry.de (Michael Loeffler) Date: Tue, 24 Apr 2018 12:36:54 +0200 Subject: Bug: gr-osmoscom for USRP B210 have this weird center frequency signal while gr-UHD don't In-Reply-To: References: Message-ID: Hello, try changing the parameter "Ch0: Bandwidth (Hz)" of your osmocom Source. Best regards, Michael From abgoyal at gmail.com Tue Apr 24 12:58:35 2018 From: abgoyal at gmail.com (Abhishek Goyal) Date: Tue, 24 Apr 2018 18:28:35 +0530 Subject: fl2k RGB buffer format Message-ID: I am trying to understand the layout of the RGB buffers sent to the fl2k over USB. From lines 755-820 in libosmo-fl2k.c I can see the RGB buffers are "serialized" in this order: g1,r1,b2,g2,b0,g0,r0,b1,b4,g4,r4,b5,r2,b3,g3,r3,r6,b7,g7,r7,g5,r5,b6,g6 (where r0 is the red component of first pixel, b3 is the blue component of fourth pixel, etc) What is this layout? Why does the chip expect the pixels to be sent in this order? -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Tue Apr 24 16:30:09 2018 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 24 Apr 2018 18:30:09 +0200 Subject: fl2k RGB buffer format In-Reply-To: References: Message-ID: Look at them as 32 bits words : g1,r1,b2,g2, b0,g0,r0,b1, b4,g4,r4,b5, r2,b3,g3,r3, r6,b7,g7,r7, g5,r5,b6,g6 Then imagine them being grouped 2 by two and read in reverse order : (probably because of endianness) b0,g0,r0,b1, g1,r1,b2,g2, r2,b3,g3,r3, b4,g4,r4,b5, g5,r5,b6,g6, r6,b7,g7,r7, Cheers, Sylvain From abgoyal at gmail.com Tue Apr 24 16:42:47 2018 From: abgoyal at gmail.com (Abhishek Goyal) Date: Tue, 24 Apr 2018 22:12:47 +0530 Subject: fl2k RGB buffer format In-Reply-To: References:

Message-ID: ah....that does clarify it. Thanks! And thanks for making this wonderful new sdr tx! On Tue, Apr 24, 2018 at 10:00 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > Look at them as 32 bits words : > > g1,r1,b2,g2, > b0,g0,r0,b1, > b4,g4,r4,b5, > r2,b3,g3,r3, > r6,b7,g7,r7, > g5,r5,b6,g6 > > Then imagine them being grouped 2 by two and read in reverse order : > (probably because of endianness) > > b0,g0,r0,b1, > g1,r1,b2,g2, > r2,b3,g3,r3, > b4,g4,r4,b5, > g5,r5,b6,g6, > r6,b7,g7,r7, > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: From riccardorossi92 at icloud.com Tue Apr 24 20:28:42 2018 From: riccardorossi92 at icloud.com (Riccardo Rossi) Date: Tue, 24 Apr 2018 22:28:42 +0200 Subject: osmo-fl2k Message-ID: Hi, i want to ask you which screen do you use in the picture in the website and also if this https://www.amazon.it/dp/B019DUI17Q/ref=cm_sw_r_wa_api_i_on53AbMBGRVYA has the correct chip Thank you Riccardo Rossi -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at kit.edu Wed Apr 25 07:38:51 2018 From: mueller at kit.edu (=?utf-8?B?TcO8bGxlciwgTWFyY3VzIChDRUwp?=) Date: Wed, 25 Apr 2018 07:38:51 +0000 Subject: Whether a specific device has the right chip inside / screens on the VGA adapter (was: osmo-fl2k) In-Reply-To: References: Message-ID: <1524641931.6972.136.camel@kit.edu> Hi Riccardo, not quite sure what you're asking here: > Hi, i want to ask you which screen do you use in the picture in the website which of the pictures? Generally, to "abuse" your VGA adapter as transmitter part of an SDR, you'd attach no screen at all, but an antenna. Or, you don't, because you put your receiver so close that it's in reactive near field, and don't risk problems with spectrum regulations (which will generally not favor doing things like transmitting unfiltered waveforms with a lot of harmonics). > and also if this https://www.amazon.it/dp/B019DUI17Q/ref=cm_sw_r_wa_api_i_on53AbMBGRVYA has the correct chip I'd guess, that, since it fits the rather extensive description on the wiki page, yes, but noone here has any chance to know that any better than you do. You can only order and try, or you could also just buy one where you can download a manual that specifies the chipset, or a windows driver (and then just skim the driver package's content for FL2000). What would of course be cool is that if you ordered this dongle, and verified it works with osmo-fl2k, then you could add a link to the https://osmocom.org/projects/osmo-fl2k/wiki page to a new page "known to work devices" with a table that contains that. Now, on the other hand, Amazon marketplace links are not really there for eternity ? they are prone to disappearing without any notice, or to be superseeded by sellers offering different products with the same picture. Nota bene that your product page explicitly says that there's only 5 of these in stock. I do believe that table would be helpful, but just probably not for some more or less sketchy amazon marketplace offer like the one you've found (there's really hundreds of these, and we shouldn't be seeing an email asking for compatibility of every single one), ebay or aliexpress etc sources; all you can say about these is exactly what is written on the wiki page: If it does 1920x1080, doesn't support MAC and does USB3 and costs less than 20?, it's probably compatible. If you can find a local seller (yours is somewhere in Shenzhen! This isn't amazon selling you stuff, it's some small trader in China.) that you trust to have a reasonable source and will offer the device for longer than their small one-time-buy stock allows, that would be more helpful. Best regards, Marcus -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6582 bytes Desc: not available URL: From freefuel at gmail.com Wed Apr 25 22:30:29 2018 From: freefuel at gmail.com (Justin Kelly) Date: Wed, 25 Apr 2018 22:30:29 +0000 Subject: can we do Quadrature pairs? Message-ID: can the USB to VGA adapter output quadrature I and Q pairs via the red and blue channels? with maybe using green as a configurable local oscillator. -Justin -- --Evil people do evil things, how is irrelevant. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Thu Apr 26 05:44:35 2018 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 26 Apr 2018 07:44:35 +0200 Subject: can we do Quadrature pairs? In-Reply-To: References: Message-ID: > can the USB to VGA adapter output quadrature I and Q pairs via the red and > blue channels? with maybe using green as a configurable local oscillator. Sure, we thought about that. But : - IQ modulator chips are not cheap and you'd need to low pass I/Q before injecting them there. - The LO range would be quite restricted because for a LO you want a clean signal (no hamonics, or as litte as possible, and as little jitter as possible) so you'd have to use a freq way lower than the sampling rate and filter it. But then you have like ... 0 - 35M LO, not super useful. Using an IQ mod with built in LO and control it via I2C is much more viable ... but more expensive (several times the price of the vga dongle in the first place) Cheers, Sylvain From mueller at kit.edu Thu Apr 26 08:09:10 2018 From: mueller at kit.edu (=?utf-8?B?TcO8bGxlciwgTWFyY3VzIChDRUwp?=) Date: Thu, 26 Apr 2018 08:09:10 +0000 Subject: can we do Quadrature pairs? In-Reply-To: References:

Message-ID: <1524730149.20313.41.camel@kit.edu> Felix and I had been thinking about similar things; we've been more thinking of using the extra DAC channel to generate a low frequency oscillator with a limited frequency range, which one could use with a programmable PLL/synth chip to get a sufficiently clean / low-harmonic LO at frequencies that we care about. Regarding cost of IQ modulators: yep, not cheap, but let's face it: this would give one several dozen MHz of baseband bandwidth, and even if we spent a Euro for every MHz of bandwidth we get to make this a viable quadrature mixer architecture, we'd still be off relatively cheap ? and would have something to let students measure, calibrate, improve etc for months. Best regards, Marcus On Thu, 2018-04-26 at 07:44 +0200, Sylvain Munaut wrote: > > can the USB to VGA adapter output quadrature I and Q pairs via the > > red and > > blue channels? with maybe using green as a configurable local > > oscillator. > > Sure, we thought about that. But : > > - IQ modulator chips are not cheap and you'd need to low pass I/Q > before injecting them there. > - The LO range would be quite restricted because for a LO you want a > clean signal (no hamonics, or as litte as possible, and as little > jitter as possible) so you'd have to use a freq way lower than the > sampling rate and filter it. But then you have like ... 0 - 35M LO, > not super useful. > Using an IQ mod with built in LO and control it via I2C is much > more viable ... but more expensive (several times the price of the > vga > dongle in the first place) > > > Cheers, > > Sylvain -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6582 bytes Desc: not available URL: From abgoyal at gmail.com Thu Apr 26 13:27:08 2018 From: abgoyal at gmail.com (Abhishek) Date: Thu, 26 Apr 2018 18:57:08 +0530 Subject: can we do Quadrature pairs? In-Reply-To: <1524730149.20313.41.camel@kit.edu> References: <1524730149.20313.41.camel@kit.edu> Message-ID: Analog has some nice I/Q modulators with internal LO listed for ~7$ http://www.analog.com/en/products/rf-microwave/iq-modulators-demodulators/iq-modulators-with-integrated-lo.html From mailinglists at dc7ia.eu Thu Apr 26 17:56:01 2018 From: mailinglists at dc7ia.eu (DC7IA) Date: Thu, 26 Apr 2018 19:56:01 +0200 Subject: [osmo-fl2k] can't receive anything Message-ID: Hi there, I've set up osmo-fl2k yesterday and since then I'm trying to get WBFM or GSM working, but I cannot receive anything. Software does not give me any errors, so I don't know where to look for the problem. Maybe I should note that I'm only able to use USB 2.0 on my Thinkpad T400, could that make trouble as it is a USB 3.0 device? -- *73 Joshua Hoffmann DC7IA | KK4RVI * stellv. AJW-Referent im Distrikt O (S?d-Westfalen) AJW-Seite des Distriktes Diese E-Mailadresse ist ausschlie?lich f?r Mailinglisten E-Mails. Normale E-Mails an DC7IA at DARC.de senden, da sie andernfalls nicht rechtzeitig gelesen werden. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From Ian.Lowe at QuorumCyber.com Wed Apr 25 21:00:34 2018 From: Ian.Lowe at QuorumCyber.com (Ian Lowe) Date: Wed, 25 Apr 2018 21:00:34 +0000 Subject: Building on Mac OS? reference platform? Message-ID: <1564BAC8-D50B-4D3D-9601-9021ABA13094@contoso.com> Hi folks, I tried building the code on Mac, and it threw a bag full of errors. Does anyone have a working mechanism/script to build on Mac, if not, what was the reference platform? What was this built on? I. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Thu Apr 26 18:20:35 2018 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 26 Apr 2018 20:20:35 +0200 Subject: [osmo-fl2k] can't receive anything In-Reply-To: References: Message-ID: Hi, > Maybe I should note that I'm only able to use USB 2.0 on my Thinkpad T400, > could that make trouble as it is a USB 3.0 device? Yeah ... the data rate required are _way_ above what USB2 can provide. Cheers, Sylvain From dave at bewaar.me Thu Apr 26 18:52:56 2018 From: dave at bewaar.me (Dave Olsthoorn) Date: Thu, 26 Apr 2018 20:52:56 +0200 Subject: [PATCH] Make sdrangelove friendly for packaging Message-ID: <20180426185256.16068-1-dave@bewaar.me> This patch makes sdrangelove able to install through 'make install' and also makes the plugin manager able to load from a specific directory like /usr/lib64/sdrangelove/plugins while sdrangelove is inside /usr/bin. To load plugins from a specific directory start cmake with '-DSDRANGELOVE_PLUGIN_DIR:PATH=/path/to/plugin/directory' and compile, to make installing even more easy 'make install' installs the plugins in the specified directory. Signed-off-by: Dave Olsthoorn --- CMakeLists.txt | 24 ++++++++++++++++++++++++ plugins/channel/nfm/CMakeLists.txt | 6 +++++- plugins/channel/tcpsrc/CMakeLists.txt | 5 +++++ plugins/channel/tetra/CMakeLists.txt | 4 ++++ plugins/samplesource/gnuradio/CMakeLists.txt | 4 ++++ plugins/samplesource/osmosdr/CMakeLists.txt | 4 ++++ plugins/samplesource/rtlsdr/CMakeLists.txt | 4 ++++ sdrbase/plugin/pluginmanager.cpp | 13 ++++++++++++- 8 files changed, 62 insertions(+), 2 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 72ce30e..b0d38d5 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -21,6 +21,10 @@ find_package(PkgConfig) find_package(FFTW3F) find_package(FFTS) +IF(DEFINED SDRANGELOVE_PLUGIN_DIR) + add_definitions( -DSDRANGELOVE_PLUGIN_DIR=\"${SDRANGELOVE_PLUGIN_DIR}\") +ENDIF() + IF(CMAKE_SYSTEM_PROCESSOR MATCHES "x86_64|AMD64|x86") SET(USE_SIMD "SSE2" CACHE STRING "Use SIMD instructions") @@ -250,6 +254,19 @@ target_link_libraries(sdrbase ${LIBUSB_LIBRARIES} ) +if(UNIX) +# we only the version the library under unix systems +set_target_properties(sdrbase PROPERTIES + VERSION 0.0.0 + SOVERSION 0 +) + +# and only install in lib or lib64 under unix systems +install(TARGETS sdrbase + LIBRARY DESTINATION lib${LIB_SUFFIX} +) +endif(UNIX) + if(LIBFFTS_FOUND) target_link_libraries(sdrbase ${LIBFFTS_LIBRARIES}) else(LIBFFTS_FOUND) @@ -308,6 +325,13 @@ target_link_libraries(sdrangelove ${OPENGL_LIBRARIES} ) +if(UNIX) +# only install in bin when we are on unix +install(TARGETS sdrangelove + RUNTIME DESTINATION bin +) +endif(UNIX) + if(WIN32) set_target_properties(sdrangelove PROPERTIES LINK_FLAGS_DEBUG "/SUBSYSTEM:CONSOLE") set_target_properties(sdrangelove PROPERTIES COMPILE_DEFINITIONS_DEBUG "_CONSOLE") diff --git a/plugins/channel/nfm/CMakeLists.txt b/plugins/channel/nfm/CMakeLists.txt index feeb891..7abfe56 100644 --- a/plugins/channel/nfm/CMakeLists.txt +++ b/plugins/channel/nfm/CMakeLists.txt @@ -44,4 +44,8 @@ target_link_libraries(demodnfm sdrbase ) -qt5_use_modules(demodnfm Core Widgets OpenGL Multimedia) \ No newline at end of file +if(DEFINED SDRANGELOVE_PLUGIN_DIR) + install(TARGETS demodnfm DESTINATION ${SDRANGELOVE_PLUGIN_DIR}) +endif() + +qt5_use_modules(demodnfm Core Widgets OpenGL Multimedia) diff --git a/plugins/channel/tcpsrc/CMakeLists.txt b/plugins/channel/tcpsrc/CMakeLists.txt index df7c4d4..6ea431b 100644 --- a/plugins/channel/tcpsrc/CMakeLists.txt +++ b/plugins/channel/tcpsrc/CMakeLists.txt @@ -44,4 +44,9 @@ target_link_libraries(demodtcpsrc sdrbase ) +if(DEFINED SDRANGELOVE_PLUGIN_DIR) + install(TARGETS demodtcpsrc DESTINATION ${SDRANGELOVE_PLUGIN_DIR}) +endif() + + qt5_use_modules(demodtcpsrc Core Widgets OpenGL Network) diff --git a/plugins/channel/tetra/CMakeLists.txt b/plugins/channel/tetra/CMakeLists.txt index f46c2bb..6cec401 100644 --- a/plugins/channel/tetra/CMakeLists.txt +++ b/plugins/channel/tetra/CMakeLists.txt @@ -44,4 +44,8 @@ target_link_libraries(demodtetra sdrbase ) +if(DEFINED SDRANGELOVE_PLUGIN_DIR) + install(TARGETS demodtetra DESTINATION ${SDRANGELOVE_PLUGIN_DIR}) +endif() + qt5_use_modules(demodtetra Core Widgets OpenGL Multimedia) diff --git a/plugins/samplesource/gnuradio/CMakeLists.txt b/plugins/samplesource/gnuradio/CMakeLists.txt index 0e08608..7dfa2dd 100644 --- a/plugins/samplesource/gnuradio/CMakeLists.txt +++ b/plugins/samplesource/gnuradio/CMakeLists.txt @@ -82,6 +82,10 @@ target_link_libraries(inputgnuradio sdrbase ) +if(DEFINED SDRANGELOVE_PLUGIN_DIR) + install(TARGETS inputgnuradio DESTINATION ${SDRANGELOVE_PLUGIN_DIR}) +endif() + qt5_use_modules(inputgnuradio Core Widgets OpenGL Multimedia) endif(Boost_FOUND AND GNURADIO_RUNTIME_FOUND AND GNURADIO_OSMOSDR_FOUND) diff --git a/plugins/samplesource/osmosdr/CMakeLists.txt b/plugins/samplesource/osmosdr/CMakeLists.txt index 9dc9705..5648277 100644 --- a/plugins/samplesource/osmosdr/CMakeLists.txt +++ b/plugins/samplesource/osmosdr/CMakeLists.txt @@ -51,4 +51,8 @@ target_link_libraries(inputosmosdr sdrbase ) +if(DEFINED SDRANGELOVE_PLUGIN_DIR) + install(TARGETS inputosmosdr DESTINATION ${SDRANGELOVE_PLUGIN_DIR}) +endif() + qt5_use_modules(inputosmosdr Core Widgets OpenGL Multimedia) diff --git a/plugins/samplesource/rtlsdr/CMakeLists.txt b/plugins/samplesource/rtlsdr/CMakeLists.txt index 35c4081..d7c78c6 100644 --- a/plugins/samplesource/rtlsdr/CMakeLists.txt +++ b/plugins/samplesource/rtlsdr/CMakeLists.txt @@ -47,4 +47,8 @@ target_link_libraries(inputrtlsdr sdrbase ) +if(DEFINED SDRANGELOVE_PLUGIN_DIR) + install(TARGETS inputrtlsdr DESTINATION ${SDRANGELOVE_PLUGIN_DIR}) +endif() + qt5_use_modules(inputrtlsdr Core Widgets OpenGL Multimedia) diff --git a/sdrbase/plugin/pluginmanager.cpp b/sdrbase/plugin/pluginmanager.cpp index 325fb8b..1c19388 100644 --- a/sdrbase/plugin/pluginmanager.cpp +++ b/sdrbase/plugin/pluginmanager.cpp @@ -8,6 +8,17 @@ #include "dsp/dspengine.h" #include "dsp/samplesource/samplesource.h" +/** + * Binaries are often placed in /usr/bin and plugins in /usr/lib* somewhere + * + * This ifdef and define is for packaging purposes so we can override the plugin directory + * since the plugins are not in the directory or the higher directories than where the binary + * exists. The original configuration is still the fallback. + */ +#ifndef SDRANGELOVE_PLUGIN_DIR +#define SDRANGELOVE_PLUGIN_DIR QApplication::instance()->applicationDirPath() +#endif + PluginManager::PluginManager(MainWindow* mainWindow, DSPEngine* dspEngine, QObject* parent) : QObject(parent), m_pluginAPI(this, mainWindow, dspEngine), @@ -25,7 +36,7 @@ PluginManager::~PluginManager() void PluginManager::loadPlugins() { - QDir pluginsDir = QDir(QApplication::instance()->applicationDirPath()); + QDir pluginsDir = QDir(SDRANGELOVE_PLUGIN_DIR); loadPlugins(pluginsDir); -- 2.14.3 From freefuel at gmail.com Thu Apr 26 18:53:18 2018 From: freefuel at gmail.com (Justin Kelly) Date: Thu, 26 Apr 2018 18:53:18 +0000 Subject: have you tried using a powered USB HUB? Message-ID: Hi Joshua, have you tried your experiment with a powered USB hub? I've found a number of times that a powered hub can solve mystery problems with USB devices. Cheers! -Justin N2TOH ---------- Forwarded message ---------- From: DC7IA To: osmocom-sdr at lists.osmocom.org Cc: Bcc: Date: Thu, 26 Apr 2018 19:56:01 +0200 Subject: [osmo-fl2k] can't receive anything Hi there, I've set up osmo-fl2k yesterday and since then I'm trying to get WBFM or GSM working, but I cannot receive anything. Software does not give me any errors, so I don't know where to look for the problem. Maybe I should note that I'm only able to use USB 2.0 on my Thinkpad T400, could that make trouble as it is a USB 3.0 device? -- *73 Joshua Hoffmann DC7IA | KK4RVI * stellv. AJW-Referent im Distrikt O (S?d-Westfalen) AJW-Seite des Distriktes Diese E-Mailadresse ist ausschlie?lich f?r Mailinglisten E-Mails. Normale E-Mails an DC7IA at DARC.de senden, da sie andernfalls nicht rechtzeitig gelesen werden. -- --Evil people do evil things, how is irrelevant. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steve-m.de Thu Apr 26 22:20:02 2018 From: steve at steve-m.de (steve at steve-m.de) Date: Fri, 27 Apr 2018 00:20:02 +0200 Subject: Building on Mac OS? reference platform? In-Reply-To: <1564BAC8-D50B-4D3D-9601-9021ABA13094@contoso.com> References: <1564BAC8-D50B-4D3D-9601-9021ABA13094@contoso.com> Message-ID: Hi Ian, On 2018-04-25 23:00, Ian Lowe wrote: > I tried building the code on Mac, and it threw a bag full of errors. This should be fixed now, there was a similar issue in rtl_test reported in our bugtracker. Can you verify that it builds with OS X? > Does anyone have a working mechanism/script to build on Mac, if not, > what was the reference platform? What was this built on? In my case Ubuntu 18.04, but any Linux-distro with recent Kernel and libusb should work fine. Regards, Steve From mueller at kit.edu Fri Apr 27 11:34:31 2018 From: mueller at kit.edu (=?utf-8?B?TcO8bGxlciwgTWFyY3VzIChDRUwp?=) Date: Fri, 27 Apr 2018 11:34:31 +0000 Subject: fl2k: Versioning? Message-ID: <1524828869.13740.12.camel@kit.edu> Hi everyone, hi especially Steve, I'm in the process of making a distro package for fl2k for sharing and inclusion in my bootable Fedora sticks; as a version, I'd use 0.0.0.1- githash, but I think that's an understatement, because it looks to me like fl2k was officially released at OsmoCon. Now, I'm not the author, and I'd hate to be the one to define today's git head as version 1, or something like that, but I honestly think that it's worth encouraging tagging of a release (as it would make it easy to refer to things like "hey, that used to work with 1.0.2.1, but broke in 1.0.3.1", or include it with other software etc). Would it be very annoying to kindly request that you add a version tag, and to even brazenly recommend semver.org as versioning scheme? Thanks, and I'm having great fun with this, Marcus From mueller at kit.edu Fri Apr 27 14:31:23 2018 From: mueller at kit.edu (=?utf-8?B?TcO8bGxlciwgTWFyY3VzIChDRUwp?=) Date: Fri, 27 Apr 2018 14:31:23 +0000 Subject: Preliminary Fedora Packages (was: fl2k: Versioning?) In-Reply-To: <1524828869.13740.12.camel@kit.edu> References: <1524828869.13740.12.camel@kit.edu> Message-ID: <1524839482.13740.20.camel@kit.edu> I've decided to go with a package version of 0.0.0.0_DATEgitSHORTHASH so as to avoid conflict with whatever you decide to come up with (which really, really is your business). And whoever would like Fedora 26,27,28,rawhide packages (my CentOS/RedHat/EPEL 7 build broke because things): https://copr.fedorainfracloud.org/coprs/marcusmueller/osmo-fl2k/ Note that I'm not trying to be "official upstream", so as usual, please make sure this package contains what you really want. For now, it seems to do what is needed to make fl2k_test etc. work, and installs the library as well as the udev rules that make the dongle belong to group "fl2k". Maybe I should be splitting things into libfl2k and fl2k-utils and fl2k-filesystem or something to separate libs, executables and udev rules. Best regards, Marcus On Fri, 2018-04-27 at 11:34 +0000, M?ller, Marcus (CEL) wrote: > Hi everyone, hi especially Steve, > > I'm in the process of making a distro package for fl2k for sharing > and > inclusion in my bootable Fedora sticks; as a version, I'd use > 0.0.0.1- > githash, but I think that's an understatement, because it looks to me > like fl2k was officially released at OsmoCon. > > Now, I'm not the author, and I'd hate to be the one to define today's > git head as version 1, or something like that, but I honestly think > that it's worth encouraging tagging of a release (as it would make it > easy to refer to things like "hey, that used to work with 1.0.2.1, > but > broke in 1.0.3.1", or include it with other software etc). > > Would it be very annoying to kindly request that you add a version > tag, > and to even brazenly recommend semver.org as versioning scheme? > > > Thanks, and I'm having great fun with this, > > Marcus From 246tnt at gmail.com Fri Apr 27 17:15:00 2018 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 27 Apr 2018 19:15:00 +0200 Subject: gr-fosphor is choppy at audio frequency In-Reply-To: References: Message-ID: > I'm (ab)using gr-fosphor for audio spectrum visualization by using > float to complex because it is the most colorful spectrum analyzer > that I have. Unfortunately, for some reason gr-fosphor is choppy at 48 > kHz, while it is smooth at rtl-sdr output, about 2 MSPS or so. Is > there any FFT configuration setting like other spectrum analyzer to > change how many FFT bins and the framerate? No, FFT size is fixed to 1024 and the frame rate is dictated by the sample rate since all data is processed. And to cope with high rate, fosphor is designed to run by "batch" of samples and so it needs to accumulate at least 16 (IIRC) * 1024 samples before it can start computations. but of course at audio frequencies, this make it choppy. What you can do is artifically increase the sample rate by using overlapping windows. So you feed in samples[0...1023] then samples[256:1023+256] then samples [512:1023+512] and so on ... You need a custom block to do that ... Cheers, Sylvain From laforge at gnumonks.org Sat Apr 28 12:53:57 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 28 Apr 2018 14:53:57 +0200 Subject: Building on Mac OS? reference platform? In-Reply-To: <1564BAC8-D50B-4D3D-9601-9021ABA13094@contoso.com> References: <1564BAC8-D50B-4D3D-9601-9021ABA13094@contoso.com> Message-ID: <20180428125356.GG10358@nataraja> Dear Ian, On Wed, Apr 25, 2018 at 09:00:34PM +0000, Ian Lowe wrote: > I tried building the code on Mac, and it threw a bag full of errors. A good bug report always includes a verbatim copy of any compile errors. Feel free to post it here or to create an issue in the respective osmocom.org redmine sub-project > what was the reference platform? Almost all Osmocom developers primarily develop on various flavors of Linux. Ubuntu or Debian are typically a safe choice. > What was this built on? It would greatly help if you would even specify what "this" is. Osmocom is a large project with many sub-projects. Even the SDR related projects discussed here are a few to choose from... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat Apr 28 12:56:43 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 28 Apr 2018 14:56:43 +0200 Subject: Preliminary Fedora Packages (was: fl2k: Versioning?) In-Reply-To: <1524839482.13740.20.camel@kit.edu> References: <1524828869.13740.12.camel@kit.edu> <1524839482.13740.20.camel@kit.edu> Message-ID: <20180428125643.GH10358@nataraja> On Fri, Apr 27, 2018 at 02:31:23PM +0000, M?ller, Marcus (CEL) wrote: > I've decided to go with a package version of 0.0.0.0_DATEgitSHORTHASH > so as to avoid conflict with whatever you decide to come up with (which > really, really is your business). FYI: Debian went for "0.1.0+20180423git9e79bde" as can be seen at https://packages.debian.org/sid/osmo-fl2k I agree that at least some initial version talk should be put into the osmo-fl2k repository. But that's of course up to steve-m. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ian at fatalbutnotserious.co.uk Sat Apr 28 16:53:18 2018 From: ian at fatalbutnotserious.co.uk (ian) Date: Sat, 28 Apr 2018 17:53:18 +0100 Subject: Building on Mac OS? reference platform? In-Reply-To: References: <1564BAC8-D50B-4D3D-9601-9021ABA13094@contoso.com> Message-ID: <9511051C-6EC5-409F-934F-E49EC69E78A6@fatalbutnotserious.co.uk> Thanks Steve - I can confirm that with a fresh clone of the code, I am now able to build osmo_fl2k quite happily on MacOS High Sierra (10.13.4). I may switch across to my Ubuntu 18.04 laptop just to stay on the well beaten track. Thanks! Ian. > On 26 Apr 2018, at 23:20, steve at steve-m.de wrote: > > Hi Ian, > > On 2018-04-25 23:00, Ian Lowe wrote: >> I tried building the code on Mac, and it threw a bag full of errors. > > This should be fixed now, there was a similar issue in rtl_test reported > in our bugtracker. Can you verify that it builds with OS X? > >> Does anyone have a working mechanism/script to build on Mac, if not, >> what was the reference platform? What was this built on? > > In my case Ubuntu 18.04, but any Linux-distro with recent Kernel and libusb > should work fine. > > Regards, > Steve > From steve at steve-m.de Sat Apr 28 20:29:17 2018 From: steve at steve-m.de (Steve Markgraf) Date: Sat, 28 Apr 2018 22:29:17 +0200 Subject: fl2k: Versioning? In-Reply-To: <1524828869.13740.12.camel@kit.edu> References: <1524828869.13740.12.camel@kit.edu> Message-ID: <7fd379ef-258d-d7a4-5c14-c180bf44b04d@steve-m.de> Hi Marcus, On 27.04.2018 13:34, M?ller, Marcus (CEL) wrote: > Now, I'm not the author, and I'd hate to be the one to define today's > git head as version 1, or something like that, but I honestly think > that it's worth encouraging tagging of a release (as it would make it > easy to refer to things like "hey, that used to work with 1.0.2.1, but > broke in 1.0.3.1", or include it with other software etc). > > Would it be very annoying to kindly request that you add a version tag, > and to even brazenly recommend semver.org as versioning scheme? Actually the cmake Version module was already in place and set to version 0.1git - it just didn't work properly because an initial tag was missing. As Debian and SuSe already used 0.1.0 as version, I've now tagged a 0.1.1 release and advanced to 0.1git again. The version module now seems to work as expected, I now get "Version: v0.1.1-1-g2ff7". Best Regards, Steve From mueller at kit.edu Sun Apr 29 10:09:19 2018 From: mueller at kit.edu (=?utf-8?B?TcO8bGxlciwgTWFyY3VzIChDRUwp?=) Date: Sun, 29 Apr 2018 10:09:19 +0000 Subject: fl2k: Versioning? In-Reply-To: <7fd379ef-258d-d7a4-5c14-c180bf44b04d@steve-m.de> References: <1524828869.13740.12.camel@kit.edu> <7fd379ef-258d-d7a4-5c14-c180bf44b04d@steve-m.de> Message-ID: <1524996558.20313.69.camel@kit.edu> Hi Steve, oh, I've been missing that :) will advance the git commit pointer, and fix versioning tomorrow. Thanks for all the cool work! Best regards, Marcus On Sat, 2018-04-28 at 22:29 +0200, Steve Markgraf wrote: > Hi Marcus, > > On 27.04.2018 13:34, M?ller, Marcus (CEL) wrote: > > Now, I'm not the author, and I'd hate to be the one to define > > today's > > git head as version 1, or something like that, but I honestly think > > that it's worth encouraging tagging of a release (as it would make > > it > > easy to refer to things like "hey, that used to work with 1.0.2.1, > > but > > broke in 1.0.3.1", or include it with other software etc). > > > > Would it be very annoying to kindly request that you add a version > > tag, > > and to even brazenly recommend semver.org as versioning scheme? > > Actually the cmake Version module was already in place and set to > version 0.1git - it just didn't work properly because an initial tag > was > missing. As Debian and SuSe already used 0.1.0 as version, I've now > tagged a 0.1.1 release and advanced to 0.1git again. The version > module > now seems to work as expected, I now get "Version: v0.1.1-1-g2ff7". > > Best Regards, > Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6582 bytes Desc: not available URL: From matthias at mpb.li Mon Apr 30 18:22:48 2018 From: matthias at mpb.li (=?UTF-8?Q?Matthias_Br=c3=a4ndli?=) Date: Mon, 30 Apr 2018 20:22:48 +0200 Subject: IQ interleaved samples for osmo-fl2k Message-ID: <517a2fa7-3d0a-1480-e155-89a40e66d73f@mpb.li> Hi all, I just wanted to let you know I am working on adding interleaved IQ support (to red and green DAC). Haven't had time to test it yet. http://git.mpb.li/git/osmo-fl2k/commit/?id=db70e939c8b1e8ab19d1baef5c98c7ab68c61a53 Is anybody else working on this? For contributions, do you prefer patch files? Best regards and thanks for this development! mpb