Re: wxgui GRC 3.7.13.5 MacOS 10.14.6
Hi Carlos - Just to make sure: When you do "port installed gnuradio" it turns back the 3.7.13.5 release with variants that include +wxgui ... yes? The GNU Radio ports do not by default install +wxgui; you have to do so manually: "sudo port install gnuradio +wxgui". If your GR is installed that way, please let me know & I'll reinstall mine to match & see if it works for me. I moved to QtGUI a long time ago ... - MLD On Sun, Feb 16, 2020 at 3:33 AM Carlos wrote: > As I remember wxgui is not in GRC 3.8 but I can’t move to 3.8 yet. I > installed GRC with Macports but I’m having problems running any wxgui sink. > Is there a way to get them working? Here’s one of the blocks. > > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/fftsink2.py", > line 31, in > from fftsink_gl import fft_sink_f, fft_sink_c > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/fftsink_gl.py", > line 27, in > import fft_window > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/fft_window.py", > line 33, in > import forms > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/forms/__init__.py", > line 36, in > from forms import \ > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/forms/forms.py", > line 64, in > class _form_base(pubsub, wx.BoxSizer): > TypeError: Error when calling the metaclass bases > multiple bases have instance lay-out conflict > > v/r, > > Carlos > -- Michael Dickens Ettus Research Technical Support Email: supp...@ettus.com Web: https://ettus.com/
Re: UHD and USRP1
Hi Michael, GR 3.3?! Wow, that *is* retro :) > Now I wanted to give it a try on W10 and a modern PC, but when I run a RX benchmark_rate test with latest UHD 3.15 but also 3.10 the command window gets filled up with DD messages and number of dropped samples is huge. That shouldn't happen. The maximum rates of the USRP1 should never even stress a modern PC. BTW, not even sure libusrp1 had indications for dropped samples. In fact, I remember the documentation back in the day of GR 3.4's gr-usrp said it would simply drop samples on multi-device reception until streams aligned. Don't remember whether that included any signalling. Anyway, I suspect USB strangeness under windows 10. Did you try UHD 3.15 on Linux? If you just set up a Ubuntu 19.10 system, the GNU Radio you can install directly through apt-get there will bring in UHD 3.15. I don't have a USRP1 at hand, so I can't test this :( Best regards, Marcus On 16.02.20 07:51, Michael Margaras wrote: > Hello All, > I have been using my USRP1 mainly on an older Linux PC with GNU radio 3.3 . > Now I wanted to give it a try on W10 and a modern PC, but when I run a RX > benchmark_rate test with latest UHD 3.15 but also 3.10 the command window > gets filled up with DD messages and number of dropped samples is huge. > > Have also tried the older UHD 3.005.004 on the same PC and there I am no > getting any dropped samples ! > > Anyway , with UHD 3.15 an 3.10, at the end of the test , the number of > dropped samples is huge but remarkably overflows are 0. > This happens at all sample rates but the number of dropped samples is > decreasing as the sample rates decreases but still remains huge even a lowest > sampling rate. > > On the other hand , on an older Dell D630 PC running Ubuntu 9.10 and GNU > Radio 3.3 (libusrp) no dropped samples or overflows have been observed up to > almost 8 MSPS. > > Please find benchmark_rate results of the W10 PC using UHD 3.10 at the end of > this message for 6MSPS , 2MSPS and 0.1875 MSPS. > BTW, master clock was modified to 48 MHz but same results have been observed > with the default 64 MHz clock. > > Is anybody successfully using USRP1 on W10 or Linux with latest UHD releases? > How can this dropped-samples issue be fixed? > > Any suggestion would be very welcome. > > Many thanks in advance ! > > Michael Margaras > SV1CAL > > > Below testing 6 MSPS , 2 MSPS and 0.1875 MSPS : > > > C:\Program Files\UHD\lib\uhd\examples>benchmark_rate --rx_rate 6e6 --rx_cpu > sc16 --rx_otw sc16 > Win32; Microsoft Visual C++ version 14.0; Boost_106000; > UHD_003.010.001.001-0-unknown > > > -- Loading firmware image: C:\Program > Files\UHD\share\uhd\images\usrp1_fw.ihx... done > *** Warning! *** > Benchmark results will be inaccurate on USRP1 due to insufficient features. > > Creating the usrp device with: ... > -- Opening a USRP1 device... > -- Loading FPGA image: C:\Program > Files\UHD\share\uhd\images\usrp1_fpga.rbf... done > -- Using FPGA clock rate of 48.00MHz... > Using Device: Single USRP: > Device: USRP1 Device > Mboard 0: USRP1 > RX Channel: 0 > RX DSP: 0 > RX Dboard: B > RX Subdev: TVRX > TX Channel: 0 > TX DSP: 0 > TX Dboard: A > TX Subdev: WBXv2 TX+GDB > > Setting device timestamp to 0... > Testing receive rate 6.00 Msps on 1 channels >
wxgui GRC 3.7.13.5 MacOS 10.14.6
As I remember wxgui is not in GRC 3.8 but I can’t move to 3.8 yet. I installed GRC with Macports but I’m having problems running any wxgui sink. Is there a way to get them working? Here’s one of the blocks. File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/fftsink2.py", line 31, in from fftsink_gl import fft_sink_f, fft_sink_c File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/fftsink_gl.py", line 27, in import fft_window File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/fft_window.py", line 33, in import forms File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/forms/__init__.py", line 36, in from forms import \ File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/forms/forms.py", line 64, in class _form_base(pubsub, wx.BoxSizer): TypeError: Error when calling the metaclass bases multiple bases have instance lay-out conflict v/r, Carlos
quantization noise demonstration ?
I wanted to demonstrate quantization noise (V_q^12/12/fs noise floor) with GNU Radio and somehow my demonstration is failing. I am trying http://jmfriedt.org/untitled.png (or http://jmfriedt.org/untitled.grc) following the chart of the Quantizer. Somehow I had already noticed that the Qt Freq Sync is displaying a spectral density (because keeping 1:N will not raise the noise floor by N as would be expected from aliasing), but here the noise is obviously quantized (see time domain) but the spectral density in the frequency domain does not show the impact of quantization. Is this expected ? Thanks, JM -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France
Re: UHD and USRP1
Michael, I still have my USRP1, and ran the same test w/ 3.14 and got the same results on Win10, dropped packets down to the minimum supported rate. Same test, same driver against the B200 works fine up to about 20MSps which appears to be my USB 3 chip's limit. For kicks I downloaded the same older version of UHD you had success with, and ran it without a problem up to 8 MSps. For "real" usage, the issue is similar... I just checked that the UHD_WBFM sample .grc file still works with the latest UHD drivers, etc, audio is fine (even if I kick up the samp_rate to 4MSps) though the same "D" dropped packets are reported. My VirtualBox installation needs to be updated, or I'd check in Linux as well. So I think it's a driver issue, though if it's really dropping packets or just reporting them dropped is a question for Ettus. Geof On Sun, Feb 16, 2020 at 11:52 AM Marcus Müller wrote: > Hi Michael, > > GR 3.3?! Wow, that *is* retro :) > > > Now I wanted to give it a try on W10 and a modern PC, but when I run a > RX benchmark_rate test with latest UHD 3.15 but also 3.10 the command > window gets filled up with DD messages and number of dropped samples > is huge. > > That shouldn't happen. The maximum rates of the USRP1 should never even > stress a modern PC. > > BTW, not even sure libusrp1 had indications for dropped samples. In > fact, I remember the documentation back in the day of GR 3.4's gr-usrp > said it would simply drop samples on multi-device reception until > streams aligned. Don't remember whether that included any signalling. > > Anyway, I suspect USB strangeness under windows 10. > > Did you try UHD 3.15 on Linux? If you just set up a Ubuntu 19.10 system, > the GNU Radio you can install directly through apt-get there will bring > in UHD 3.15. > I don't have a USRP1 at hand, so I can't test this :( > > Best regards, > Marcus > > On 16.02.20 07:51, Michael Margaras wrote: > > Hello All, > > I have been using my USRP1 mainly on an older Linux PC with GNU radio > 3.3 . > > Now I wanted to give it a try on W10 and a modern PC, but when I run a > RX benchmark_rate test with latest UHD 3.15 but also 3.10 the command > window gets filled up with DD messages and number of dropped samples is > huge. > > > > Have also tried the older UHD 3.005.004 on the same PC and there I am no > getting any dropped samples ! > > > > Anyway , with UHD 3.15 an 3.10, at the end of the test , the number of > dropped samples is huge but remarkably overflows are 0. > > This happens at all sample rates but the number of dropped samples is > decreasing as the sample rates decreases but still remains huge even a > lowest sampling rate. > > > > On the other hand , on an older Dell D630 PC running Ubuntu 9.10 and > GNU Radio 3.3 (libusrp) no dropped samples or overflows have been observed > up to almost 8 MSPS. > > > > Please find benchmark_rate results of the W10 PC using UHD 3.10 at the > end of this message for 6MSPS , 2MSPS and 0.1875 MSPS. > > BTW, master clock was modified to 48 MHz but same results have been > observed with the default 64 MHz clock. > > > > Is anybody successfully using USRP1 on W10 or Linux with latest UHD > releases? > > How can this dropped-samples issue be fixed? > > > > Any suggestion would be very welcome. > > > > Many thanks in advance ! > > > > Michael Margaras > > SV1CAL > > > > > > Below testing 6 MSPS , 2 MSPS and 0.1875 MSPS : > > > > > > C:\Program Files\UHD\lib\uhd\examples>benchmark_rate --rx_rate 6e6 > --rx_cpu sc16 --rx_otw sc16 > > Win32; Microsoft Visual C++ version 14.0; Boost_106000; > UHD_003.010.001.001-0-unknown > > > > > > -- Loading firmware image: C:\Program > Files\UHD\share\uhd\images\usrp1_fw.ihx... done > > *** Warning! *** > > Benchmark results will be inaccurate on USRP1 due to insufficient > features. > > > > Creating the usrp device with: ... > > -- Opening a USRP1 device... > > -- Loading FPGA image: C:\Program > Files\UHD\share\uhd\images\usrp1_fpga.rbf... done > > -- Using FPGA clock rate of 48.00MHz... > > Using Device: Single USRP: > > Device: USRP1 Device > > Mboard 0: USRP1 > > RX Channel: 0 > > RX DSP: 0 > > RX Dboard: B > > RX Subdev: TVRX > > TX Channel: 0 > > TX DSP: 0 > > TX Dboard: A > > TX Subdev: WBXv2 TX+GDB > > > > Setting device timestamp to 0... > > Testing receive rate 6.00 Msps on 1 channels > > >
Re: PSK-Demodulation
Hi Till, both symbol sync and CMA equalizer in the same flowgraph at 50 MS/s can be quite a load on the CPU. As first step, make sure UHD is not printing "U" or "O"s on your console. Other than that, not quite sure what you mean with "the change phaseshifter alternately hange"; could you elaborate? Also, the "PSK Demod" is in the Deprecated category for a reason: it randomly breaks. Don't use it, can't help you if you do :) Best regards, Marcus On 16.02.20 18:50, "Till Hülder" wrote: > Hello, > > i send frequency chrip signal with an usrp over a phaseshifter and > modulat with that an 2-PSK the signal, recieve the modulated signal in > the same usrp and anlayse it. > The change phaseshifter alternately hange between 0° and 180°. But i > don't get accurate results after demodulation. I attached my graph , > time diagramm and constallation diagramm (on top the RX and bottom TX). > > Can someone help me ? > Best regards, > Till > > > >
Re: Help with cubesats
Hi Andrew, I would encourage you to try using GNU Radio first on your host machine in order to become familiar with it's operation. Then once you have an understanding of it, you can easily deploy your application/flowgraph to a headless device like a raspberry pi. I'd suggest starting by going through the tutorials on the wiki https://wiki.gnuradio.org/index.php/Main_Page >From there, you can take an existing flowgraph and drop in a file sink to test it out. https://wiki.gnuradio.org/index.php/File_Sink Once you want to deploy it as a headless application, you can add in Parameter blocks to dynamically change the filename of the file sink, and switch your flowgraph from QT to "No GUI", and it can be ran from the command line. Regards, Nate Temple On Sun, Feb 16, 2020 at 12:02 PM Andrew Stamp wrote: > Hi Nate, > > Thank you for your reply. I was hoping to use this standalone, no screen. > Is that possible? > > Can you explain a file sink for me please? It will do 9600 ax.25 GMSK? > Sorry, still very new > > Thank you, > > Andy > > On Sat, Feb 15, 2020 at 11:24 PM Nate Temple > wrote: > >> Hi Andy, >> >> You'll probably want to use gr-satellites instead of direwolf. >> https://github.com/daniestevez/gr-satellites >> >> You can record a pass using GNU Radio using a File Sink. >> >> Regards, >> Nate Temple >> >> On Sat, Feb 15, 2020 at 6:01 PM Andrew Stamp wrote: >> >>> Hi, >>> >>> I’m looking for assistance with setting up a raspberry pi, with Direwolf >>> and gr-satellites, to receive and decode from the Phoenix cubesats being >>> deployed on February 17. Specifically, they will be ax.25, using GMSK. Is >>> it possible to use a raspberry pi to record the audio, and record the >>> waterfall? I was hoping to make this a stand-alone unit that I can upload >>> the information when available. It is a raspberry pi 3 b, with an RTL-SDR >>> dongle. I don’t have a screen on it. I am still very new, I have set up a >>> couple raspberry pi’s with Direwolf, and have set up a Windows 7 netbook >>> for RX WSPR. I would really appreciate any help. >>> >>> Thank you, >>> >>> -Andy, N2YQO >>> >>
Re: quantization noise demonstration ?
My mistake ... my noise level was far too high. Additionnally, the noise with amplitude lower than LSB must be added to a full-scale range sine wave to be dithered amongst the various quantization bins. If anyone is interested, I updated http://jmfriedt.org/quantization.pdf which (I believe) demonstrates the impact of quantization on the noise floor. JM -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France February 16, 2020 5:36 PM, "jmfriedt" wrote: > I wanted to demonstrate quantization noise (V_q^12/12/fs noise floor) > with GNU Radio and somehow my demonstration is failing. I am trying > http://jmfriedt.org/untitled.png (or http://jmfriedt.org/untitled.grc) > following the chart of the Quantizer. Somehow I had already noticed > that the Qt Freq Sync is displaying a spectral density (because keeping > 1:N will not raise the noise floor by N as would be expected from aliasing), > but here the noise is obviously quantized (see time domain) but the > spectral density in the frequency domain does not show the impact of > quantization. > Is this expected ? > > Thanks, JM > > -- > JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, > 25000 Besancon, France
[announcement] Release 3.7.14.0
Dearest most-enduring SDR community to ever roam the galaxy, the legacy 3.7 release series sees a bug fix release. We had to bump the maint version from 13 to 14, because we fundamentally changed the (pseudo) random number generation – which has the effect that pre-3.7.14.0 flowgraphs use different random scramblers and pilots, amongst other things. Find the release notes below. Cheers, Marcus # Release 3.7.14.0 ## Contributors * Chris * Christoph Mayer * Eric Johnson * gmazilla * Håkon Vågsether * Josh Morman * Marcus Müller * Martin Braun * Michael Dickens * rear1019 * Ron Economos * Ryan Volz * Sebastian Müller * Thomas Habets ## [3.7.14.0] - 2020-02-15 ### Fixed Project Scope - replace remaining calls to thread-unsafe `rand` with internal random generators gnuradio-runtime - don't give up on looking for configuration files if system directory doesn't exist - `get_tags_in_range` on delay blocks - premature tag pruning gr-blocks - 8 bit WAV file reading - `matrix_multiply` no longer wrongly converts complex float to double - Boost 1.70 compat gr-digital - UHD packet example: frame bit fixes - `additive_scrambler` count-based reset - `map_bb` buffer overflow, thread safety gr-dtv - falsely failing assert gr-fec - `cc_encoder`: constraint length > 8 grc - Ctrl-F unselects blocks (so that "d" doesn't disable them) ### Added gnuradio-runtime - XOROSHIRO128+-based PRNG gr-digital - `additive_scrambler` test gr-uhd - future UHD compat layer ### Changed Project Scope - COMPATIBILITY WARNING: Replaced non-threadsafe (s)rand with our own xoroshiro-based PRNG - Whole tree code reformatting gr-blocks - replaced reconfiguring selector with 3.8 backport gr-channels - removed unnecessary delay in selective fading model gr-digital - COMPATIBILITY: Change of random OFDM pilots - backport of 3.8 constellation changes gr-trellis - COMPATIBILITY: random interleaver: PRNG change -> different interleaver
[announcement] Release Candidate 3.8.1.0-rc1
Dear bravest FOSS SDR fellowship to ever been heard of in Middle-earth, it's a relief to be able share this release candidate with you: https://github.com/gnuradio/gnuradio/releases/tag/v3.8.1.0-rc1 This contains a lot of bug fixes when comparing it directly to 3.8.0.0; it's also home of a lot of interesting features and featurettes (see the release notes below). Please do test this release candidate for any failure to perform – be it in building on your favourite platform (is anyone still working on GR on NetBSD?), or in cooperating with your most important OOT module. If all goes well, we'll have a 3.8.1.0 release by the first week of March. Namárië, Marcus # Release Candidate 3.8.1.0-RC1 ## Contributors * Alba Mendez * Anders Kalør * Artem Pisarenko * Bastian Bloessl * Brennan Ashton * Chris * Clayton Smith * CMorin * Daniel Estévez * Davide Gerhard * Derek Kozel * duggabe * Glenn Richardson * Grant Cox * Gwenhael Goavec-Merou * Håkon Vågsether * Igor Freire * Jan Kraemer * japm48 * Josh Morman * karel * luz.paz * Marc L * Marcus Müller * Martin Braun * Michael Dickens * Michael Roe * Nathan West * Nicolas Cuervo * Philip Balister * rear1019 * RedStone002 * Ron Economos * Ryan Schutt * Ryan Volz * Sebastian Koslowski * Sebastian Müller * Sylvain Munaut * Terry May * Thomas Habets * Vasil Velichkov * Volker Schroer * wcampbell ## [3.8.1.0-rc1] - 2020-02-16 ### Changed Project Scope - clang-tidy improvements - Throw exceptions by value, catch by reference - `emplace_back` where applicable - `empty()` instead of `vector::size() == 0` ### Fixed Project scope - FindQwt paths - floatAlmostEqual unittest assert function wrongly passing on sequence types - Only require boost unittest when testing is enabled - FindLOG4CPP typo gnuradio-runtime - block gateway shadowed system port - Flaky message passing unit test contained timeout (not the test's job) - ctrlport/`rpcaggregator` & Co: removed storage of references to scope-lifetime objects - Sine table generation python was wrong - `get_tags_in_range` for delay < (end-start) - premature tag pruning gr_modtool - wrong use of `input` -> `raw_input` - allow empty argument list - testing - check for and deny TSB under Python - QA addition bugs gr-analog - clipping in FM receiver: remove superfluous gain - C++ generation for multiple blocks gr-audio - portaudio source: lock acquisition gr-blocks - broken `rotator` workaround gr-digital - `map_bb` buffer overflow - `map_bb` thread safety - `additive_scrambler `count based reset gr-fec - heap corruption in `async_decoder` - `cc_encoder` was broken for constraint lengths > 8 gr-fft - restore Boost 1.53 compat gr-qtgui - no longer requiring unnecessary key in `edit_box_msg` gr-uhd - fixed examples under Py3 - multichannel objects not populating channels GRC - several issues with YAML files - nested objects now properly populate namespaces - comments now included in block bounds calculation - Wiki documentation link removed from OOT blocks' docs tab - Dragging connections to auto-hide ports works now ### Added Project Scope - Codec2 development branch / future compat - Boost 1.71 compat - CI now checks for formatting gnuradio-runtime - dot graphs now contain message edges gr-uhd - UHD Filter API GRC - block affinity, buffer sizes available as advanced options for blocks - testing gnuradio-marcusmueller.pub Description: application/vnd.ms-publisher
Aw: Re: PSK-Demodulation
Hi Marcus, i do get an U as an output from the UHD . What can i do against this and what did this mean? My phaseshifter switch between 0° and 180° all time. I want to check if it is possible to implement a 2-PSK. What can i use instead of PSK Demod? Best regards, Till Gesendet: Sonntag, 16. Februar 2020 um 19:12 Uhr Von: "Marcus Müller" An: discuss-gnuradio@gnu.org Betreff: Re: PSK-Demodulation Hi Till, both symbol sync and CMA equalizer in the same flowgraph at 50 MS/s can be quite a load on the CPU. As first step, make sure UHD is not printing "U" or "O"s on your console. Other than that, not quite sure what you mean with "the change phaseshifter alternately hange"; could you elaborate? Also, the "PSK Demod" is in the Deprecated category for a reason: it randomly breaks. Don't use it, can't help you if you do :) Best regards, Marcus On 16.02.20 18:50, "Till Hülder" wrote: > Hello, > > i send frequency chrip signal with an usrp over a phaseshifter and > modulat with that an 2-PSK the signal, recieve the modulated signal in > the same usrp and anlayse it. > The change phaseshifter alternately hange between 0° and 180°. But i > don't get accurate results after demodulation. I attached my graph , > time diagramm and constallation diagramm (on top the RX and bottom TX). > > Can someone help me ? > Best regards, > Till > > > >
[VOLK] Release v2.2.0
Hi everyone, we have a new VOLK release v2.2.0! We want to thank all contributors. This release wouldn't have been possible without them. We're curious about VOLK users. Especially we'd like to learn about VOLK users who use VOLK outside GNU Radio. If you have ideas for VOLK enhancements, let us know. Start with an issue to discuss your idea. We'll be happy to see new features get merged into VOLK. The v2.1.0 release was rather large because we had a lot of backlog. We aim for more incremental releases in order to get new features out there. ### Highlights VOLK v2.2.0 updates our build tools and adds support functionality to make it easier to use VOLK in your projects. * Dropped Python 2 build support - Removed Python six module dependency * Use C11 aligned_alloc whenever possible - MacOS `posix_memalign` fall-back - MSVC `_aligned_malloc` fall-back * Add VOLK version in `volk_version.h` (included in `volk.h`) * Improved CMake code * Improved code with lots of refactoring and performance tweaks ### Contributors * Carles Fernandez * Gwenhael Goavec-Merou * Albin Stigo * Johannes Demel * Michael Dickens * Valerii Zapodovnikov * Vasil Velichkov * ghostop14 * rear1019 ### Changes * CMake - Fix detection of AVX and NEON - Fix for macOS - lib/CMakeLists: use __asm__ instead of asm for ARM tests - lib/CMakeLists: fix detection when compiler support NEON but nor neonv7 nor neonv8 - lib/CMakeLists.txt: use __VOLK_ASM instead of __asm__ - lib/CMakeLists.txt: let VOLK choose preferred neon version when both are supported - lib/CMakeLists.txt: simplify neon test support. Unset neon version if not supported - For attribute, change from clang to "clang but not MSC" * Readme - logo: Add logo at top of README.md * Build dependencies - python: Drop Python2 support - python: Reduce six usage - python: Move to Python3 syntax and modules - six: Remove build dependency on python six * Allocation - alloc: Use C11 aligned_alloc - alloc: Implement fall backs for C11 aligned_alloc - alloc: Fix for incomplete MSVC standard compliance - alloc: update to reflect alloc changes * Library usage - Fixup VolkConfigVersion - add volk_version.h * Refactoring - qa_utils.cc: fix always false expression - volk_prefs.c: check null realloc and use temporary pointer - volk_profile.cc: double assignment and return 0 - volk_32f_x2_pow_32f.h: do not need to _mm256_setzero_ps() - volk_8u_conv_k7_r2puppet_8u.h: d_polys[i] is positive - kernels: change one iteration for's to if's - kernels: get rid of some assignments - qa_utils.cc: actually throw something - qa_utils.cc: fix always true code - rotator: Refactor AVX kernels - rotator: Remove unnecessary variable - kernel: Refactor square_dist_scalar_mult - square_dist_scalar_mult: Speed-Up AVX, Add unaligned - square_dist_scalar_mult: refactor AVX2 kernel - kernel: create AVX2 meta intrinsics * CI - appveyor: Test with python 3.4 and 3.8 - appveyor: Add job names - appveyor: Make ctest more verbose * Performance - Improve performance of generic kernels with complex multiply - square_dist_scalar_mult: Add SSE version - Adds NEON versions of cos, sin and tan
Re: Help with cubesats
Hi Andrew, Shameless plug, but you can take a look at this repo https://gitlab.com/phorvath/smogcli2 to record samples with RTL-SDR and Raspberry PI. It is developed for the ATL-1 and SMOG-P satellites. It is a standalone application, samples at 1.6 or 2.0 maps, tracks the location of the satellite and starts recording if the elevation is above -2 degrees. When it is recording it compensates for Doppler and then downsamples to 50 ksps (or 62.2 ksps). You can process your recordings with gr-satellites or a GNURadio flow graph.. Miklos On Sun, Feb 16, 2020 at 3:00 AM Andrew Stamp wrote: > > Hi, > > I’m looking for assistance with setting up a raspberry pi, with Direwolf and > gr-satellites, to receive and decode from the Phoenix cubesats being deployed > on February 17. Specifically, they will be ax.25, using GMSK. Is it possible > to use a raspberry pi to record the audio, and record the waterfall? I was > hoping to make this a stand-alone unit that I can upload the information when > available. It is a raspberry pi 3 b, with an RTL-SDR dongle. I don’t have a > screen on it. I am still very new, I have set up a couple raspberry pi’s with > Direwolf, and have set up a Windows 7 netbook for RX WSPR. I would really > appreciate any help. > > Thank you, > > -Andy, N2YQO
gr-rftap for GNU Radio 3.8
hi, has anybody experience with porting the gr-rftap module to install it with pybombs under gnuradio 3.8? (https://github.com/rftap/gr-rftap ) I followed the example according https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide but there are too many open questions exactly which lines in the CMakeLists.txt files have to be removed or adapted. regards, Helmut
