[Discuss-gnuradio] git clone failure
I'm seeing a certificate error when I run: git clone --recursive http://git.gnuradio.org/git/gnuradio.git The error is: fatal: unable to access 'https://git.gnuradio.org/git/gnuradio.git/': SSL: certificate subject name (gnuradio.org) does not match target host name ' git.gnuradio.org' This is the recommended way to clone according to the wiki: https://wiki.gnuradio.org/index.php/Download But my guess is these instructions are stale, and github is now the official home of the repo. Do these instructions need to be updated, or am I doing something wrong? -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] choosing hardware for demos, ham purposes
Daniel, Philip Ballister got in touch with me and thought some of the following material might help you out: https://www.researchgate.net/publication/304346578_Open-Source_SDR_on_Embedded_Platforms Now to address some of your specific requests: The only thing I know of that covers 3.5 MHz up to 2.4 GHz, full duplex, for a reasonable price, is the LimeSDR. That said, other names come to mind for this class of usage, including Ettus B200 series, HackRF One, Airspy R2, and the bladeRF. Each of these doesn't meet some aspect of what you want. Either the low end of the frequency range can't be reached (B200, Airspy, bladeRF), or the device isn't full duplex (Airspy has half-duplex T/R capabilities). I'm not sure what clock stability effect you're concerned with (frequency accuracy when tuning?), but this shouldn't be a problem with any of the above. If it is, the beauty of SDR is that you can correct for these kinds of things in software. There are likely carrier recovery / PLL tricks that should easily make sure the signal you demodulate is nicely down at zero IF, but of course the technique depends specifically on the modulation you're working with. As for PAs, I've happily used Minicircuits components in the past. Some models that come to mind after two seconds on their website are: LZY-22+, ZHL-20W-13SW+, ZHL-100W-272+, and this is based on your frequency ranges. Note however that these aren't typically considered portable, as they all have sizable heatsinks and fans, and weigh several pounds. Also, some of these have significant output power overhead beyond your requirements, and use various power voltages, so that's something to consider. If it was me and I was taking the show on the road, I'd get a 4U or 6U 19" rackmount chassis I can roll around, like the kind for audiovisual equipment (Gator, SKB RotoRacks, etc.), and get plates / trays that fit this very standard form factor to mount stuff like PAs, SDR, and DC PSUs. Matching PSUs with PAs and desired frequency ranges will be an engineering trade-off you'll have to consider. Plug 120VAC into a power strip in the chassis that's connected to the DC PSUs, and jack a laptop into the USB connector that hangs out of the back to connect to the SDR and do demos, it's that simple :-) Just my $0.02 -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bug Report
Thanks for the quick reply, Derek. Of course, the github! I was looking on the redmine site. If it's is only for the python qa code, removing the scipy dependency there might be nice. Would you recommend I file this issue on the Github tracker? On Wed, Jan 25, 2017 at 3:58 PM, Derek Kozel <derek.ko...@ettus.com> wrote: > Hello Raj, > > Bugs are tracked on the GitHub Issues system. > https://github.com/gnuradio/gnuradio/issues > > Looking at the build guide there is no mention of scipy so that should get > updated as needed. Also the pybombs recipes do not install scipy by default > for GNU Radio. > > Given that scipy isn't needed for the functionality, only the test, it may > be nice to try and remove that dependency from the tests. > > Thanks for the report! > Derek > > On Wed, Jan 25, 2017 at 12:47 PM, Raj Bhattacharjea <ra...@gatech.edu> > wrote: > >> I can't find a public bug tracker (is there one?), so here's a report. >> >> GNURadio maint branch as of today (509330cfb6ad5b8b8787ba069b96ee35c5ac9c2d) >> on a fresh Ubuntu 16.04 install with gr-fec enabled fails the "make test" >> on all "qa_polar_*" tests. Upon looking into it with ctest -V, either the >> qa code or the polar module itself has a python dependency on scipy's >> optimization / rootfinding algorithms. However, the cmake process never >> checks for scipy, as far as I can tell. >> >> How to reproduce: >> Get a fresh Ubuntu 16.04 insall going >> Install the prereqs to make gr-fec work >> Build gnuradio and run "make test" to watch the failure >> Use ctest -V -R polar_decoder_sc (for example) to see that scipy imports >> failing are the cause of the problem >> >> Workaround: install scipy (apt-get install python-scipy on Ubuntu) >> >> Proposed fix: >> If gr-fec is enabled, cmake should check for scipy as a dependency. Sorry >> I don't have time to contribute a patch. >> >> -- >> Raj Bhattacharjea, PhD >> Georgia Tech Research Institute >> Information and Communications Laboratory >> http://www.prism.gatech.edu/~rb288/ >> 404.407.6622 <(404)%20407-6622> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Bug Report
I can't find a public bug tracker (is there one?), so here's a report. GNURadio maint branch as of today (509330cfb6ad5b8b8787ba069b96ee35c5ac9c2d) on a fresh Ubuntu 16.04 install with gr-fec enabled fails the "make test" on all "qa_polar_*" tests. Upon looking into it with ctest -V, either the qa code or the polar module itself has a python dependency on scipy's optimization / rootfinding algorithms. However, the cmake process never checks for scipy, as far as I can tell. How to reproduce: Get a fresh Ubuntu 16.04 insall going Install the prereqs to make gr-fec work Build gnuradio and run "make test" to watch the failure Use ctest -V -R polar_decoder_sc (for example) to see that scipy imports failing are the cause of the problem Workaround: install scipy (apt-get install python-scipy on Ubuntu) Proposed fix: If gr-fec is enabled, cmake should check for scipy as a dependency. Sorry I don't have time to contribute a patch. -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu/GRC Update
Here is a tip that might save you next time. If you have built everything from source (git clone blah && cd blah && mkdir build && cd build && cmake .. && make && sudo make install), then keep your build directories around (where you ran cmake ..), i.e., don't delete them. Then what you can do after an OS update is go through the stuff you installed in reverse order, and run "make uninstall" in each build directory. That will cleanly uninstall whatever old versions were broken by the update. Better yet, do this BEFORE the OS update. By "reverse order", I mean uninstall gnuradio out-of-tree modules, then gnuradio itself, then UHD. This clears your system of all the old stuff that is linked against libraries that no longer exist after the update. After cleaning out the cruft, you do a forward pass where you update the code (git pull), delete the old build directory, and do the build process again. This time go in order starting with UHD, then gnuradio, then gnuradio out-of-tree modules. You might find the cmake step nags about dependencies or some features are disabled, but this is usually a matter of running a few "apt-get install" commands to get the new dependencies. Finally, what I described is not the #1 "preferred" method; that would probably involve pybombs. I don't use that method so I can't say anymore about it, other than to point you in that direction. -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Channel model - the identity channel
Thanks for the hints for where to look and why this happens from a code perspective. I don't think it makes sense from a semantic perspective (if the user says taps=1, she should get the unity gain delay free channel) but I'm guessing "patches are welcome" is the appropriate response to this minor usability issue. On Tuesday, June 28, 2016, Andrej Rode <m...@andrejro.de> wrote: > Hey Raj, > > > introduces a delay that can be corrected by applying the taps [0,0,0,1]. > > See the attached flowgraph that subtracts the signals before and after > > the channel model; if you let taps = 1, the two signals don't cancel. If > > you use taps = [0,0,0,1], they do. > > The delay you are seeing is introduced by the fractional_resapmler > inside the channel_model block. The FIR filter inside the fractional > resampler needs to build up and therefore introduces a initial delay of > three samples. > > If you want to know more about the insides of the channel model I > suggest you look at the sources [0][1] yourself. > > Greetings, > Andrej > > [0] ./gr-channels/lib/channel_model_impl.cc > [1] ./gr-channels/lib/channel_model_impl.h > > -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Channel model - the identity channel
Consider the identity channel that passes through it's input to its output. This is an idealization of a very short run of high quality cable between synchronized systems. Using GNURadio's channels_channel_model, I expect that the following provides the identity channel: Noise voltage: 0 Frequency offset: 0 Epsilon: 1 Taps: 1 That says add no noise, simulate no timing or carrier offset, and simulate a channel impulse response that is a single impulse with amplitude 1. However, I find that using such a channel model block introduces a delay that can be corrected by applying the taps [0,0,0,1]. See the attached flowgraph that subtracts the signals before and after the channel model; if you let taps = 1, the two signals don't cancel. If you use taps = [0,0,0,1], they do. Anyone know why this occurs? For my purposes, such a channel model is a stand-in that is ideal for now, but general enough to allow modeling of channel effects when I'm ready. -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622 identity_channel_model.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio hdmi
The same flow graph and the same SDR hardware with the same settings and same drivers should produce the same results (if samples are not being dropped by the host computer or something else). That said, I've seen weird things like this pop up due to variations in the driver versions for the hardware between an embedded and desktop device. To figure out what's going on specifically, we'd have to see your flowgraph here to see if people can help. Also, providing GNU Radio version numbers and how you installed from source (git master some day in the past, git release tag checkout, release tarball, etc.) on both the Odroid and the netbook would help. Also maybe provide a link the the Odroid Forum discussion for some context? -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [VOLK] VOLK website license
The VOLK website claims it's contents are licensed under "Creative Commons Attribution-NoDerivs 4.0 International", however, the license link actually takes you to the text of the "Attribution-NonCommercial-NoDerivatives 4.0 International". These are different licenses and the difference is whether the license allows others to use the content for commercial purposes. I was trying to cite a copy of the VOLK logo when I came across this. I hope the VOLK website maintainer watches this list and clarifies which license the site is under. -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] A basic question about writing OOT modules
I've seen messages like this pop up when GNURadio isn't installed where CMake is expecting it to be. For me, this has happened when different components are installed in different ways, i.e., I installed GNURadio from your distro repos (apt-get etc.) and tried to build and OOT module from source (git clone, cmake, etc). I can't recall the exact fix but it involves passing additional options to cmake. The hint cmake gives you is to set *Gnuradio_DIR* to something that contains the cmake config file for gnuradio. See if you can find that on your system and set the environment variable when you call cmake : *Gnuradio_DIR=/usr/local/lib/blah/whatever cmake ..* -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ZeroMQ and Polar test failures on maint
All, I've just checked out and built gnuradio 3.7.9.1 (maint branch) from git today, and "make test" gives me the following failures: The following tests FAILED: 81 - qa_polar_decoder_sc_systematic (Failed) 82 - qa_polar_decoder_sc_list (Failed) 84 - qa_polar_encoder (Failed) 87 - qa_polar_encoder_systematic (Failed) 88 - qa_polar_decoder_sc (Failed) 205 - qa_zeromq_pushpull (Failed) 206 - qa_zeromq_pub (Failed) 207 - qa_zeromq_pubsub (Failed) 208 - qa_zeromq_reqrep (Failed) I'm on Xubuntu 14.04, Linux 3.13.0, x86_64 arch with dual Xeons, and gcc 4.8.4. Other relevant details are in the attached cmake output. I've seen the zeromq errors for quite a while when building versions of GNUradio, but polar FEC seems to be a newer feature and the tests are not passing. I always ignored the zeromq failures, but now that the list of failures has grown, I'm thinking I should figure this out. Any clues for how to debug these failures? I don't know how the test infrastructure works, how can I run a single test at a time? Can I run them in valgrind or gdb? Can I increase the verbosity of the testing so I have more than a binary Pass/Fail output? -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622 -- Build type not specified: defaulting to release. -- Build type set to Release. -- Extracting version information from git describe... -- Compiler Version: cc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Compiler Flags: /usr/bin/cc:::-O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized /usr/bin/c++:::-O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -- ADDING PERF COUNTERS -- Building Static Libraries: OFF -- Boost version: 1.54.0 -- Found the following Boost libraries: -- date_time -- program_options -- filesystem -- system -- thread -- -- Checking for module SWIG -- Found SWIG version 2.0.11. -- -- The build system will automatically enable all components. -- Use -DENABLE_DEFAULT=OFF to disable components by default. -- -- Configuring python-support support... -- Dependency PYTHONLIBS_FOUND = TRUE -- Dependency SWIG_FOUND = TRUE -- Dependency SWIG_VERSION_CHECK = TRUE -- Enabling python-support support. -- Override with -DENABLE_PYTHON=ON/OFF -- -- Configuring testing-support support... -- Dependency CPPUNIT_FOUND = TRUE -- Enabling testing-support support. -- Override with -DENABLE_TESTING=ON/OFF -- -- Configuring VOLK support... -- Build type set to Release. -- Extracting version information from git describe... -- -- Python checking for python >= 2.5 -- Python checking for python >= 2.5 - found -- -- Python checking for Cheetah >= 2.0.0 -- Python checking for Cheetah >= 2.0.0 - found -- Boost version: 1.54.0 -- Found the following Boost libraries: -- filesystem -- system -- unit_test_framework -- program_options -- QA Testing is enabled. -- Modify using: -DENABLE_TESTING=ON/OFF -- Compiler name: GNU -- x86* CPU detected -- CPU width is 64 bits, Overruled arch 32 -- Available architectures: generic;64;3dnow;abm;popcount;mmx;fma;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx;avx2 -- Available machines: generic_orc;sse2_64_mmx_orc;sse3_64_orc;ssse3_64_orc;sse4_a_64_orc;sse4_1_64_orc;sse4_2_64_orc;avx_64_mmx_orc;avx2_64_mmx_orc -- BUILD TYPE = RELEASE -- Base cflags = -O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -- BUILD INFO ::: generic_orc ::: GNU ::: -O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -- BUILD INFO ::: sse2_64_mmx_orc ::: GNU ::: -O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64 -mmmx -msse -msse2 -- BUILD INFO ::: sse3_64_orc ::: GNU ::: -O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64 -mmmx -msse -msse2 -msse3 -- BUILD INFO ::: ssse3_64_orc ::: GNU ::: -O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3 -- BUILD INFO ::: sse4_a_64_orc ::: GNU ::: -O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64 -mmmx -msse -msse2 -msse3 -msse4a -mpopcnt -- BUILD INFO ::: sse4_1_64_orc ::: GNU ::: -O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -- BUILD INFO ::: sse4_2_64_orc ::: GNU ::: -O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mpopcnt -- BUILD INFO ::: avx_64_mmx_orc ::: GNU ::: -O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall -Wno-un
