From willcode4 at gmail.com Tue Jul 3 12:17:22 2018 From: willcode4 at gmail.com (Jeff Long) Date: Tue, 3 Jul 2018 08:17:22 -0400 Subject: willcode/gr-osmosdr sdrplay2 requires API 2.13 Message-ID: For anyone using the willcode/gr-osmosdr sdrplay2 branch, the SDRplay API/SDK version 2.13 is now required. Previously, any 2.X version would work. There was a change to a function signature in 2.13, and since there aren't a lot of users of this branch, I decided not to sprinkle ifdefs around the code. Thanks to krippendorf for the fix. From alain.carlucci at gmail.com Mon Jul 9 16:35:15 2018 From: alain.carlucci at gmail.com (Alain Carlucci) Date: Mon, 9 Jul 2018 18:35:15 +0200 Subject: [patch] performance improvement in gr-osmosdr (hackrf) Message-ID: <20180709163515.2f2shkvwvswnl4lc@raspberry> Hi, I have submitted a pull request on Github[1] which improves the performance of the hackrf source. With this patch the conversion int8_t -> float is done in realtime instead of looking up values in the "_lut" lookup table. In this way the compiler is able to generate AVX/SSE code (-O3 -march=native) to perform the conversion. In [2] you can find a benchmark to show the differences. Using -Ofast (or -O3) and -march=native I get ~2.8x using an Intel i7 (4th gen) and 3.1x on a Core i5 (6th gen). Gqrx with the patched library can play a WFM radio without any interruption even with just 3 buffers (option="hackrf=0,buffers=3"). Best regards, Alain [1] https://github.com/osmocom/gr-osmosdr/pull/14 [2] https://gist.github.com/carpikes/cad029c338605f70d9f687aeee447db4 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From lucas at teske.com.br Tue Jul 10 08:05:26 2018 From: lucas at teske.com.br (Lucas Teske) Date: Tue, 10 Jul 2018 05:05:26 -0300 Subject: [patch] performance improvement in gr-osmosdr (hackrf) In-Reply-To: <20180709163515.2f2shkvwvswnl4lc@raspberry> References: <20180709163515.2f2shkvwvswnl4lc@raspberry> Message-ID: I would say, just remember that gr-osmosdr is not intended only to x86, but also for ARM and other archs that does not even have SIMD. Also there are some x86 nowadays that does not have AVX code. The LUT solution is the "generic" one that works average on all platforms (calculate on the fly for any arch that does not have SIMD conversion will make a great performance loss). Lucas Em 09/07/2018 13:35, Alain Carlucci escreveu: > Hi, > > I have submitted a pull request on Github[1] which improves the > performance of the hackrf source. With this patch the conversion > int8_t -> float is done in realtime instead of looking up values in > the "_lut" lookup table. > In this way the compiler is able to generate AVX/SSE code (-O3 > -march=native) to perform the conversion. > > In [2] you can find a benchmark to show the differences. > Using -Ofast (or -O3) and -march=native I get ~2.8x using an > Intel i7 (4th gen) and 3.1x on a Core i5 (6th gen). > > Gqrx with the patched library can play a WFM radio without any > interruption even with just 3 buffers (option="hackrf=0,buffers=3"). > > Best regards, > Alain > > [1] https://github.com/osmocom/gr-osmosdr/pull/14 > [2] https://gist.github.com/carpikes/cad029c338605f70d9f687aeee447db4 -- Lucas Teske Teske Virtual System GPG: BD29 7EF3 4CCB EB61 B790 06C3 351A 8000 DEAD CE11 GPG: 4A90 974B ACE0 A9A6 AF09 B3B1 6C39 C1C1 6A9D A7BE GPG: BD09 9175 6DE8 37F4 08D3 B296 DE7A 51C3 87C9 27EE -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From laforge at gnumonks.org Wed Jul 11 17:05:57 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 11 Jul 2018 19:05:57 +0200 Subject: [patch] performance improvement in gr-osmosdr (hackrf) In-Reply-To: References: <20180709163515.2f2shkvwvswnl4lc@raspberry> Message-ID: <20180711170557.GE3266@nataraja> Hi Lucase, On Tue, Jul 10, 2018 at 05:05:26AM -0300, Lucas Teske wrote: > I would say, just remember that gr-osmosdr is not intended only to x86, > but also for ARM and other archs that does not even have SIMD. Also > there are some x86 nowadays that does not have AVX code. The LUT > solution is the "generic" one that works average on all platforms > (calculate on the fly for any arch that does not have SIMD conversion > will make a great performance loss). I agree with the above statement. Having compile-time flags is not a solution, as most people will just use a distribution package - and distributions will have to compile the most general and non-cpu-specific code. The proper approach for this kind of problem is to have run-time CPU feature detection and then use the most optimal code for the given CPU. This is what we're e.g. dong in osmo-trx. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Wed Jul 11 20:03:04 2018 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 11 Jul 2018 22:03:04 +0200 Subject: [patch] performance improvement in gr-osmosdr (hackrf) In-Reply-To: <20180711170557.GE3266@nataraja> References: <20180709163515.2f2shkvwvswnl4lc@raspberry> <20180711170557.GE3266@nataraja> Message-ID: GNUradio has the whole VOLK infrastructure in place to provide generic code + optimized code per architecture + run time selection and even benchmarking to select the fastest version. So I would suggest just using the volk_8i_s32f_convert_32 kernel and be done with it. If some current code is faster than the current volk implementations available, then a second patch can be submitted to volk to add this arch specific implementation and allow it to be used. Cheers, Sylvain From kukabu at gmail.com Mon Jul 16 04:08:54 2018 From: kukabu at gmail.com (Michael Tatarinov) Date: Mon, 16 Jul 2018 08:08:54 +0400 Subject: bias-T issue with rtl-sdr Message-ID: Hello I submitted a pull request on Github[1] which fixes bug with bias-T power. The bias-T voltage was staying on after rtl tools ended. This is dangerous and can lead to damage device. [1] https://github.com/steve-m/librtlsdr/pull/47 From frank_lists at superlogical.ch Wed Jul 25 09:50:48 2018 From: frank_lists at superlogical.ch (Frank Werner-Krippendorf) Date: Wed, 25 Jul 2018 11:50:48 +0200 Subject: SDRPlay patch no merge? Message-ID: <902AB18E-899B-4FE9-88AF-FA7B2F474FDD@superlogical.ch> Hi I just wanted to ask if there is something wrong with http://lists.osmocom.org/pipermail/osmocom-sdr/2018-June/001801.html ? The patch is tested and I think it is better to have some working code in the repo instead of 3 year old incompatible & incomplete stuff that will confuse people!? Best regares Frank, HB9FXQ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bahocheche at yahoo.com Sun Jul 29 16:13:59 2018 From: bahocheche at yahoo.com (baha sagar) Date: Sun, 29 Jul 2018 16:13:59 +0000 (UTC) Subject: issues with osmo-trx-lms with LimeSDR References: <1273908839.431072.1532880839016.ref@mail.yahoo.com> Message-ID: <1273908839.431072.1532880839016@mail.yahoo.com> Hello? I'm trying to get the osmo-trx-lms to work with my LimeSDR. the setup is the latest version of LimeSDR and osmo-trx built from source with the command (./configure --with-lms) .? I can see the device through LimeUtil but when I try the command it fails with the following error Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in and supported by CPU Sun Jul 29 07:01:27 2018 DLGLOBAL <0002> telnet_interface.c:104 telnet at 127.0.0.1 4237 Sun Jul 29 07:01:27 2018 DLCTRL <0009> control_if.c:887 CTRL at 127.0.0.1 4236 Config Settings Log Level? 3 Device args? TRX Base Port? 5700 TRX Address? 127.0.0.1 GSM BTS Address? 127.0.0.1 Channels? 1 Tx Samples-per-Symbol? 4 Rx Samples-per-Symbol? 4 EDGE support? 0 Reference? 0 C0 Filler Table? 1 Multi-Carrier? 0 Tuning offset? 0 RSSI to dBm offset? 0 Swap channels? 0 Tx Antennas? 'BAND1? Rx Antennas? ?LNAW? Setting SCHED_RR priority(18) Sun Jul 29 07:01:27 2018 DMAIN <0000> osmo-trx.cpp:379 [tid=140014553808704] Config: Setting SCHED_RR failed I tried using the configuration file from the osmo-trx git url and the below file as well. both gave the same result. https://osmocom.org/attachments/3219/limesdr.cfg1 Any ideas? Thanks Bahaeddin Sagar -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Jul 31 10:56:54 2018 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 31 Jul 2018 12:56:54 +0200 Subject: issues with osmo-trx-lms with LimeSDR In-Reply-To: <1273908839.431072.1532880839016@mail.yahoo.com> References: <1273908839.431072.1532880839016.ref@mail.yahoo.com> <1273908839.431072.1532880839016@mail.yahoo.com> Message-ID: <20180731105654.GE6762@nataraja> Hi Baja, this questions is better discussed at openbsc at lists.osmocom.org, where we discuss the GSM stack related projects. The osmocom-sdr mailing list is for osmo-sdr, rtl-sdr, osmo-fl2k, gr-osmosdr and related projects. On Sun, Jul 29, 2018 at 04:13:59PM +0000, baha sagar wrote: > Setting SCHED_RR priority(18) > Sun Jul 29 07:01:27 2018 DMAIN <0000> osmo-trx.cpp:379 [tid=140014553808704] Config: Setting SCHED_RR failed It is a permission problem. You need to be root to set a SCHED_RR priorirty. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)