[Discuss-gnuradio] How to play captured signal file
Thank you for reading this. I'm still unable to compile gr-osmosdr and a Gpoogle search shows that others have had to same problem but I haven't found any solutions. Following instructions I think I have captured signals from a local FM radio station. How do I play this captured file? I haven't compiled gnuradio yet because I want to include gr-osmosdr. -- Regards, Phil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to play captured signal file
On Sun, Jun 3, 2012 at 12:51 PM, Phil phil_...@bigpond.com wrote: Thank you for reading this. I'm still unable to compile gr-osmosdr and a Gpoogle search shows that others have had to same problem but I haven't found any solutions. Following instructions I think I have captured signals from a local FM radio station. How do I play this captured file? I haven't compiled gnuradio yet because I want to include gr-osmosdr. Phil, I think you misunderstand. You must have GNU Radio installed prior to compiling gr-osmosdr as gr-osmosdr uses the GNU Radio API. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-osmosdr compile problems
On Sun, Jun 3, 2012 at 6:42 AM, Phil phil_...@bigpond.com wrote: Thank you for reading this. I've progressed a little since I last wrote and have received my ezcap USB dongle. Unfortunately, I'm still having problems. Cmake produces the following, which seems to indicate that all is well: -- ## -- # gr-osmosdr enabled components -- ## -- * IQ File Source -- * Osmocom RTLSDR -- * RTLSDR TCP Client -- -- ## -- # gr-osmosdr disabled components -- ## -- * sysmocom OsmoSDR -- * FunCube Dongle -- * Ettus UHD -- -- Building for version: d56e18a1 / 0.0.1git -- Using install prefix: /usr/local -- Configuring done -- Generating done -- Build files have been written to: /usr/local/src/gr-osmosdr/build However, rtl library errors appear during the compiling stage as follows: [root@localhost build]# make Scanning dependencies of target gnuradio-osmosdr [ 4%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/osmosdr_source_c_impl.cc.o [ 8%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/osmosdr_sink_c_impl.cc.o [ 12%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/osmosdr_ranges.cc.o [ 16%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/osmosdr_device.cc.o [ 20%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/file/file_source_c.cc.o [ 25%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o /usr/local/src/gr-osmosdr/lib/rtl/rtl_source_c.cc: In member function ‘virtual osmosdr::freq_range_t rtl_source_c::get_freq_range(size_t)’: /usr/local/src/gr-osmosdr/lib/rtl/rtl_source_c.cc:342:10: error: use of enum ‘rtlsdr_tuner’ without previous declaration /usr/local/src/gr-osmosdr/lib/rtl/rtl_source_c.cc:342:29: error: invalid type in declaration before ‘=’ token /usr/local/src/gr-osmosdr/lib/rtl/rtl_source_c.cc:342:57: error: ‘rtlsdr_get_tuner_type’ was not declared in this scope /usr/local/src/gr-osmosdr/lib/rtl/rtl_source_c.cc:344:19: error: ‘RTLSDR_TUNER_E4000’ was not declared in this scope /usr/local/src/gr-osmosdr/lib/rtl/rtl_source_c.cc:347:26: error: ‘RTLSDR_TUNER_FC0012’ was not declared in this scope /usr/local/src/gr-osmosdr/lib/rtl/rtl_source_c.cc:349:26: error: ‘RTLSDR_TUNER_FC0013’ was not declared in this scope /usr/local/src/gr-osmosdr/lib/rtl/rtl_source_c.cc:351:26: error: ‘RTLSDR_TUNER_FC2580’ was not declared in this scope /usr/local/src/gr-osmosdr/lib/rtl/rtl_source_c.cc: In member function ‘virtual osmosdr::gain_range_t rtl_source_c::get_gain_range(size_t)’: /usr/local/src/gr-osmosdr/lib/rtl/rtl_source_c.cc:405:50: error: ‘rtlsdr_get_tuner_gains’ was not declared in this scope make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o] Error 1 make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 make: *** [all] Error 2 I tried to build as well yesterday and failed for me too - as I recall with the same error. I checked out the code again today and it fails too but with a different error, so the code is changing at the moment. You can go back to commit b2128bc86442148d87a7fe897a382c836baf8a67 which compiles fine for me, i.e. git checkout b2128bc Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about OpenBTS
Hello, I want to set up the OpenBTS, and I want to know which board is better, USRP1 or USRP2? Or any other suggestion? Thank you. -- Best regards, Pan, Luyuan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reorganization and restructuring on 3.6 (master) and 3.7 (next) branches
On Fri, May 11, 2012 at 10:37 PM, Andrew Davis glneolistm...@gmail.com wrote: free weekend I had one once! So any plans for the application specific top-level blocks ( noaa, pager, atsc )? I feel these could be moved to the CGRAN, or better yet there could be a separate top-level folder for projects like this and some of the GCRAN projects could be merged back into the main Gnuradio git for better maintenance. ( A lot still use USRP instead of UHD and even more still use autotools, this is giving me non-stop problems, I'm working on updating a few ) Never hurts to have some well working example projects showcasing Gnuradio! Andrew, We discussed this a bit on our last developers's call. I think your last point is one of the main reasons we won't move projects like gr-noaa or gr-pager out of GNU Radio. We want to keep some well-coded, working apps in the main source tree as references for people to use or look to. Second, CGRAN was built as a way around copyright issues of an FSF project. Since all code in GNU Radio must assign the copyright to it over to FSF, some projects wouldn't/couldn't do that, so CGRAN came about to solve it. That means that many of the projects there are not able to be moved back into GNU Radio. I'm afraid that with those, I don't see any way of avoiding bitrot issues unless someone is willing to take up the cause of maintaining them. As for a top-level apps directory in GNU Radio. I'm not opposed to it, but neither do I feel like it's important enough to move the current apps to something like that. If you have a really compelling argument for it, though, I'd like to listen. Tom On Thu, May 3, 2012 at 12:10 AM, Marcus D. Leech mle...@ripnet.com wrote: On 03/05/12 12:07 AM, Josh Blum wrote: Just another free weekend, and I will have VOLK capable of generating code to handle head and tail cases. I once heard tell of this mythical free weekend. I don't believe in it. It must be some kind of fairy tale. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG, current gr-howto structure and exception specifiers
On Fri, May 11, 2012 at 7:03 AM, Martin Braun martin.br...@kit.edu wrote: In the current state of gr-howto (which is also used in gr_modtool), the SWIG stuff is done pretty intelligently by using the header files as .i-files, which means there is no need to write a SWIG header for every block. One advantage of this was the possibility to add stuff in the .i-file which weren't in the .h-file; specifically, exception specifiers. Example (from gr-specest, specest_welch.i): snip GR_SWIG_BLOCK_MAGIC(specest,welch); specest_welch_sptr specest_make_welch(unsigned fft_len, int overlap, int ma_len, bool fft_shift, const std::vectorfloat window) throw(std::invalid_argument); // And so on . /snip If I don't declare the exception specifier, I can't catch the exception in Python. If I simply include specest_welch.h in specest_swig.i, I need to add the specifiers in the C++-code, which is not very popular (and I think not future-compatible, and gcc doesn't handle that well). Here's my question: is there a cool way to have SWIG know about the exceptions without having to write a .i-file for every block that uses exceptions? Can I 'tag' the source code in a way that gcc doesn't care, but SWIG does? Thanks for any nice ideas! MB Marin, With the restructuring of the code and implementation style in the up-coming version 3.7, we are moving in the same direction of just including .h files in the component's main swig .i file. For a very large majority of cases, there is no need for extra code in the .i file, so this reduces duplication and simplifies a lot. For those cases where a developer needs to add SWIG-specific things to an interface file, you can always edit it by hand and include everything required to make it work. I'm not practiced enough in SWIG to know this off the top of my head, but I should think that you could just include the header file and overwrite a specific case as needed. On the other hand, I thought all standard exceptions were passed properly through SWIG to Python already. I was under the impression that if you're header file declares that it throws, then you can catch it in Python. If that's not the case, then we should try to figure out an easy way to handle that. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using a MPSK Demodulator or 4QAM for oQPSK
On Sat, May 26, 2012 at 12:08 PM, Marius wishi...@googlemail.com wrote: Hi! I found a comment in the source code of the MPSK block, that it could be used for oQPSK demodulation. I think this block is very interesting implementation, however I'm not sure which parameters I should use for oQPSK. In the gr-ieee802_15_4 implementation from Thomas Schmid he uses a Quadrature Demod with an MM Clock Recovery where the parameters are: omega = self.sps gain_mu=0.03 mu=0.5 omega_relative_limit=0.0002 gain_omega = .25*gain_mu*gain_mu # critically damped This works just fine - with a Quadrature Demodulator. Can somebody suggest parameters for the MPSK Block, or give me some hints how I can calculate/test them at least? The MPSK block uses a Costas Loop for Demodulation, so the approach is quite different here. Also I wonder whether it's possible to use a 4QAM Demod, because practically a 4QAM mod produces the same wave-form like a QPSK. Practically at least ,) Best, Marius Marius, Take a look at the new implementations of the digital demodulators now in gr-digital/python/generic_mod_demod.py. We've split out the different functions from the mpsk receiver. You can adjust them a bit more easily now, and this might help you. Specifically, the recovery loops are now a bit more robust and take in a single loop bandwidth factor instead of trying to set alpha and beta. The result is more stable than before, in my experience. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] File sink file size mismatch problem.
On Wed, May 30, 2012 at 3:04 PM, Josh Stevens josh.stevens...@gmail.com wrote: Hello All, A couple of days ago i had installed a GNURadio digital image processing block that makes an image source and sink block available as displayed in the image below. Resource : https://github.com/a-w-s/GNURadio-DIP Flowgraph : http://i.imgur.com/1lJzD.png The output of the image source and the input to the image sink are floats only and nothing else. I tried to collect pixel information into a file sink and i am successful at that but the problem comes in when the size of the input file size is not the same as the size of the file sink output. The image is a basic black and white test image called lena.bmp whose file size is 65.0 KB. The link to which is also provided below , Resource to Image : https://www.google.com/search?q=lena+256+x+256hl=enprmd=imvnssource=lnmstbm=ischei=_G7GT7vkC4rs8wSG99SaBgsa=Xoi=mode_linkct=modecd=2sqi=2ved=0CD8Q_AUoAQbiw=1280bih=827 The file size of the received file (file sink) is 76.0 KB. The reason why I pay more attention to this is because i intend to calculate BER / Pixel Error Rate which would take into account a reference stream which in this case would be the file with the extra bits , and Image sink output ( or the demodulated output) . Please feel free to ask me any questions that one might have . Thanks and regards, Josh. Hi Josh, In general, when doing things like this, there is often some extra stuff that happens because the scheduler works on a per-chunk basis. So sometimes the size of what's been processed can be confused a bit, but if you're file is only so large, I wouldn't think this would happen. Also, 11 KB is a pretty substantial difference in file size. Do you know where your image is actually located in the output file? That is, what's the byte offset? (You could try to read this into Python with scipy or Matlab and do a correlation to see where in the file the image exists). I'm just trying to help determine if there's some initial fill or if the extra 11 KB are produced at the end of the file. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble with gnuradio and AMD32
On Fri, Jun 1, 2012 at 3:12 PM, Igor Volodin postmas...@myghost.name wrote:
Hello, all
My configuration:
Linux Xubuntu 12.04
AMD Athlon XP 2400
Linux ghost32 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:51:22 UTC 2012
i686 athlon i386 GNU/Linux
I am compiled latest version of gnuradio, and tried to run simple grc file:
http://superkuh.com/simplest.grc , and got following error:
(python:3350): GLib-GObject-CRITICAL **: g_param_spec_double: assertion
`default_value = minimum default_value = maximum' failed
(python:3350): GLib-GObject-CRITICAL **: g_object_class_install_property:
assertion `G_IS_PARAM_SPEC (pspec)' failed
(python:3350): GLib-GObject-WARNING **: g_object_notify: object class
`GdkScreenX11' has no property named `resolution'
Using Volk machine: generic
Traceback (most recent call last):
File ./top_block.py, line 131, in module
tb = top_block()
File ./top_block.py, line 79, in __init__
peak_hold=False,
File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/fftsink_gl.py,
line 89, in __init__
win=win,
File
/usr/local/lib/python2.7/dist-packages/gnuradio/blks2impl/logpwrfft.py,
line 57, in __init__
c2magsq = gr.complex_to_mag_squared(fft_size)
File
/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_general.py,
line 3838, in complex_to_mag_squared
return _gnuradio_core_general.complex_to_mag_squared(vlen)
RuntimeError: gr_block::set_alignment_multiple
[Inferior 1 (process 3350) exited with code 01]
Then I compiled the program with debugging symbols, and started in the
debugger:
(gdb) s
Single stepping until exit from function Py_Main,
which has no line number information.
0x0805e78b in main ()
(gdb) bt
#0 0x0805e78b in main ()
(gdb) l
11 // detail/sp_counted_base_gcc_x86.hpp - g++ on 486+ or AMD64
12 //
13 // Copyright (c) 2001, 2002, 2003 Peter Dimov and Multi Media Ltd.
14 // Copyright 2004-2005 Peter Dimov
15 //
16 // Distributed under the Boost Software License, Version 1.0. (See
17 // accompanying file LICENSE_1_0.txt or copy at
18 // http://www.boost.org/LICENSE_1_0.txt)
19 //
20 //
(gdb) n
Single stepping until exit from function main,
which has no line number information.
0x006b94d3 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
(gdb) l
21 // Lock-free algorithm by Alexander Terekhov
22 //
23 // Thanks to Ben Hitchings for the #weak + (#shared != 0)
24 // formulation
25 //
26
27 #include boost/detail/sp_typeinfo.hpp
28
29 namespace boost
30 {
(gdb) n
Single stepping until exit from function __libc_start_main,
which has no line number information.
[Inferior 1 (process 3367) exited with code 01]
My problem is like this:
http://lists.gnu.org/archive/html/discuss-gnuradio/2012-03/msg00294.html
Then i run volk_profile, and got this errors:
Using Volk machine: generic
RUN_VOLK_TESTS: volk_32fc_s32fc_rotatorpuppet_32fc_a
no architectures to test
RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
no architectures to test
RUN_VOLK_TESTS: volk_16ic_deinterleave_real_8i_a
no architectures to test
RUN_VOLK_TESTS: volk_16ic_deinterleave_16i_x2_a
no architectures to test
RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_32f_x2_a
no architectures to test
RUN_VOLK_TESTS: volk_16ic_deinterleave_real_16i_a
no architectures to test
RUN_VOLK_TESTS: volk_16ic_magnitude_16i_a
no architectures to test
RUN_VOLK_TESTS: volk_16ic_s32f_magnitude_32f_a
no architectures to test
RUN_VOLK_TESTS: volk_16i_s32f_convert_32f_a
no architectures to test
RUN_VOLK_TESTS: volk_16i_s32f_convert_32f_u
no architectures to test
RUN_VOLK_TESTS: volk_16i_convert_8i_a
no architectures to test
RUN_VOLK_TESTS: volk_16i_convert_8i_u
Best regards, Igor
Igor,
After running volk_profile, can you retry your GRC program? It looks
like what's happening is that because your processor is so old, there
are no Volk kernels available for it, so it only has the 'generic'
version to run at any time. If you open up $(HOME)/.volk/volk_config,
it should be filled with kernel generic' to tell the volk library
to only every run a generic kernel.
If that's still not working for you after volk_profile has run, then
something with that processor is confusing Volk. Otherwise, the bug in
the post you pointed towards with the volk_32fc_x2_multiply_32fc_a has
been fixed and the output of your GDB here isn't really telling me
anything. We'll have to look deeper.
Thanks,
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Issue with multiple transmitter threads in same program
On Fri, Jun 1, 2012 at 7:14 PM, Dhrubojyoti Roy
dhrubojyoti@gmail.com wrote:
Dear All,
I was experimenting with GNURadio to see if multiple transmitter threads can
exist in the same program. The following are my transmitter class
definitions (both are set to the same transmission parameters):
class my_trans(gr.top_block):
def __init__(self, mod_class, options):
gr.top_block.__init__(self)
# Get the modulation's bits_per_symbol
args = mod_class.extract_kwargs_from_options(options)
symbol_rate = options.bitrate / mod_class(**args).bits_per_symbol()
self.sink = uhd_transmitter(options.args, symbol_rate,
options.samples_per_symbol,
options.tx_freq, options.tx_gain,
options.spec, options.antenna,
options.verbose)
self.txpath = transmit_path(mod_class, options)
self.connect(self.txpath, self.sink)
class my_ret_trans(gr.top_block):
def __init__(self, mod_class, options):
gr.top_block.__init__(self)
# Get the modulation's bits_per_symbol
args = mod_class.extract_kwargs_from_options(options)
symbol_rate = options.bitrate / mod_class(**args).bits_per_symbol()
self.sink = uhd_transmitter(options.args, symbol_rate,
options.samples_per_symbol,
options.tx_freq, options.tx_gain,
options.spec, options.antenna,
options.verbose)
self.txpath = transmit_path(mod_class, options)
self.connect(self.txpath, self.sink)
However, the problem arises when I try to transmit using one of the
transmitters:
tb = my_trans(mods[options.modulation],options)
rtb = my_ret_trans(mods[options.modulation],options)
payload = struct.pack('!H', pktno 0x) +
struct.pack('!I',int('0x'+str[0:6],0))+struct.pack('!I',int('0x'+str[6:],0))
+ data
send_pkt(payload, dev_mac.replace(':',''))
send_pkt_rtb(payload, dev_mac.replace(':',''))
sys.stderr.write(\nSent pktno=%4d\n % (pktno))
Where the send functions are defined as:
def send_pkt(payload='', dev_mac = '', eof=False):
return tb.txpath.send_pkt(payload, dev_mac, eof)
def send_pkt_rtb(payload='', dev_mac = '', eof=False):
return rtb.txpath.send_pkt(payload, dev_mac, eof)
The program prints the following exception:
Sent pktno= 0
UFloating point exception
I have observed the same exception whenever rtb is called from any context
(including the receiver thread's callback function - not shown here). Does
it mean we are constrained to use at max one transmitter thread per process?
What prevents us from having multiple transmit chains, and why is the
exception a floating point exception?
Thanks and regards,
Dhrubo
Dhrubo,
It looks like you are never running the start() method on your
flowgraphs, which might be the problem.
Conceptually, you should be able to have multiple transmitters. If you
are trying to use the same UHD device and sending packets from two
different UHD sink blocks, that _might_ be a problem, but I don't
think so.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GLFSR transmission with BPSK Mod
On Mon, May 28, 2012 at 1:39 PM, Nazmul Islam mnis...@winlab.rutgers.edu wrote: Hello, I am trying to transmit a GLFSR sequence using bpsk (non-differential modulation). I am using gnuradio-companion to construct the blocks. My transmit path is is simply the following: GLFSR source - BPSK Mod (Non-differential) - USRP Sink. I am currently simulating the output of the GLFSR source and BPSK Mod source before connecting the blocks to USRP. I have attached the screenshot of the blocks and the corresponding grc file with the email. I have two questions: 1. How can I control the bit transmission rate of the GLFSR source? I want to transmit the GLFSR source at 3.5 Mbits/sec (500 kilo sequence per second with degree 3). The GLFSR block does not have any option for transmission rate. The UHD USRP sink has a option of sample rate. But I don't see how that will control the bit transmission rate of the GLFSR source. Hi Nazmul, In the computer, sample rate is meaningless. There is no concept of samples/seconds just operations per second. Without a rate-limiting device, the computer will process samples as quickly as possible. The USRP provides the real rate that samples will be running at since it clocks everything according the its clock and the interpolation/decimation rate you use. This then provides a rate limiting to the GNU Radio scheduler to keep the computer processing and generating samples at an appropriate rate. Simply put, if the USRP's UHD source block is processing samples, the scheduler will wait until it has room to accept another chunk of samples. 2. I can't understand the relation between the output of the GLFSR source with that of the PSK Mod. The GLFSR source is producing an expected output: 1110110..(repeat). But the BPSK Mod output is producing strange output in the following two ways: a) The length of the PSK Mod output is almost 8 times with respect to that of the GLFSR output. I am using 2 samples/symbol. Why is the PSK Mod creating so many output? The PSK Mod block thinks you are passing it bytes, which is then converts to bits. So every output of the GLFSR block is treated as 8 individual bits by the modulator. When running this on my machine, I get a 128x expansion factor between the two files. You have 8x for the byte-to-bit, 8x going from char to complex float, and 2x because sps=2. b) The PSK Mod is producing output with different complex values, e.g., 1.2, 0.95, 1.05, -0.2, -1.2, etc. I have 2 samples/symbol in the PSK mod block. Since the PSK Mod output length is not twice the output length of the GLSR block, how can I find which two samples correspond to which GLFSR bit? The PSK modulator will apply an RRC filter to the samples. An RRC filter is not a Nyquist filter, so it produces ISI, which is what is causing your values. If you pass this output through another equivalent RRC filter, you should see points right at +1 and -1. Feedback on any of these questions and the overall GRC block will be highly appreciated. Thanks, Nazmul Hope that clears things up. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] crashes, memory errors and valgrind
On Sat, Jun 2, 2012 at 5:50 AM, Patrick Strasser patrick.stras...@student.tugraz.at wrote: Hello list, I'm playing around with gqrx, an excellent example which great standalone software can be built with gnuradio. I'm running phirsch's rtlsdr fork, do not have a Funcube Dongle or USRP at hand, but rather a Terratex NOXON DAB stick - 25€ part does the trick fine enough for me ;-) I'm running a self-compiled gnuradio rev3.6.0 on my Debian testing amd64 machine. Sometime it crashes with messages like glibc detected *** gqrx: corrupted double-linked list. Firing up valgrind on it I find -besides several uninitialized variables- messages of the kind: ==31294== Invalid read of size 8 ==31294== at 0x4F782AC: float_dotprod_sse (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) [deleted some lines...] ==31294== Address 0x1a211ba8 is 440 bytes inside a block of size 447 alloc'd ==31294== at 0x402894D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==31294== by 0x4FB3C5E: malloc16Align (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) ==31294== by 0x4FB3CA9: calloc16Align (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) ==31294== by 0x4F75E27: gr_fir_fff_simd::set_taps(std::vectorfloat, std::allocatorfloat const) (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) [deleted some lines...] Full trace of that error below, I can provide a full trace of a run if needed. Usually the program runs stable, but occasionally it crashes. I played around with the internal bandwidth to get better FM reception - 75kHz is quite narrow for FM reception. This change seems to trigger the problems much faster. I hardly can change any parameters while running without a crash. I'm no expert, but it seems to me there is not enough memory allocated. Maybe an off-by-one error? Did anyone see things like that or used valgrind recently on gnuradio programs? What could I do to find out more about this problem? Regards Patrick - ==31294== Invalid read of size 8 ==31294== at 0x4F782AC: float_dotprod_sse (in /usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0) ==31294== by 0x4F8A27F: gr_rational_resampler_base_fff::general_work(int, std::vectorint, Patrick, It looks like you're problem is in the rational_resampler code. I wonder if there's something about the resampling rate being used that's causing something to go out of bounds here. Can you dig into the code and figure out what interpolation and decimation rates are being used? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Is it possible to have 2 TX x 1 RX MISO in GNU Radio
On Sat, 2 Jun 2012 17:47:50 -0400, Nick Iliev wrote: Hello, we have implemented a 2 TX x 1 RX MISO testbed with GNU Radio 3.4 and USRP1 . Both transmitters are using at 2.4GHz ( actually tx1 uses 2.401GHz and tx2 uses 2.403GHz ) , and are sending data ( BPSK modulated ) at the same time ( in the same time slot ). What is the frequency setting at the receiver side? Do you use two daughter boards at the receiver? If there's only one daughter board I think the receiver can only lock to one frequency and the transmitter of the different frequency might just create interferce. Also you should consider to compensate the possible frequency offset between tx and rx in real world. [1] I think you can use two daughter boards at the receiver and make them to receive signals from two frequencies, but that's not typical MIMO setup. IMHO setting up MIMO with USRP1 is not very easy. You need to make hardware modification to make two USRPs synchronize with one master device or an external clock. You can find some more info from [2]. [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#Why-is-there-always-a-frequency-offset-when-transmitting-from-one-USRP-to-another [2] http://gnuradio.org/redmine/projects/gnuradio/wiki/USRPClockingNotes Alick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RF and AD/DA
Dear everyone: Recently I have been doing my graduation design, wchich is the implemention of 802.11a ofdm PHY. My tutor required me to use FPGA so I implemented baseband OFDM modulation-demodulation using Virtex5 FPGA. My tutor decided not to use USRP because the RF bandwidth is too limited. Now I have to do up-conversion to 5.8GHz and I decided to use XCVR2450 board. Besides some configurations of the registers of MAX2829, such as bandsellect, divider ratio and so on, do I need to do anything else? Does AFC, AGC,eliminating dc offset and something like that need to be done in FPGA? I have been studying benchmark_tx and benchmark_rx for some time, but I don't find AFC or anyting like that. Any of your responses will be very appreciated.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] crashes, memory errors and valgrind
Hi Tom, Tom Rondeau wrote on 2012-06-03 17:12: On Sat, Jun 2, 2012 at 5:50 AM, Patrick Strasser Patrick, It looks like you're problem is in the rational_resampler code. I wonder if there's something about the resampling rate being used that's causing something to go out of bounds here. Can you dig into the code and figure out what interpolation and decimation rates are being used? Interpolation is 1, decimation is 2. I compiled GNU Radio branch v3.6.0 with $ cmake -DCMAKE_BUILD_TYPE=Debug .. which resulted in a compile with flags -g -O2 . I tried to track what's happening in gdb, in gr_fir_fff_simd::set_taps, but -O2 was not helping, a lot optimized out, loops unrolled. Full valgrind log in http://pastebin.com/7GCs3bWy regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser patrick dot strasser at tugraz dot at Student of Telematics, Graz Univ. of Technology, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QAM Mod and QAM Demod block in GRC
The python generic_demod.py block uses the constellation_receiver_cb block to do both some fine-tuning of the phase and the mapping to bits. It can be found at: gnuradio/gr-digital/lib/digital_constellation_receiver_cb.cc This in turn will use the decision_maker method of the constellation object to do the mapping which can be found in: gnuradio/gr-digital/lib/digital_constellation.cc What exactly are you trying to do? On Thu, May 31, 2012 at 8:12 PM, jiajue ou azalea.a...@yahoo.com.cn wrote: Hi Ben, What you mean is the qam blocks in gnuradio companion are implemented in Python only? If I want to get the complex symbols before they are demapped to bits, I should modify related python scripts? Thank you. Jia -Original Message- From: Ben Reynwar [mailto:b...@reynwar.net] Sent: Friday, June 01, 2012 12:39 AM To: jiajue ou; discuss-gnuradio Discussion Group Subject: Re: [Discuss-gnuradio] QAM Mod and QAM Demod block in GRC These blocks are implemented in python. Have a look at the following two files to start off with: gnuradio/gr-digital/python/qam.py gnuradio/gr-digital/python/generic_mod_demod.py Ben On Wed, May 30, 2012 at 11:41 PM, jiajue ou azalea.a...@yahoo.com.cn wrote: Hi all, I'm working on an experiment which needs to modify qam modulation block in gnuradio. But I cannot find the source C++ file the qam blocks use. e.g., OFDM demod block uses digital_ofdm_frame_sink in gnuradiobuild/gnuradio/gr-digital/lib. What about qam blocks? Thank you for your help! Best, jia ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to play captured signal file
On 03/06/12 21:20, Alexandru Csete wrote: Phil, I think you misunderstand. You must have GNU Radio installed prior to compiling gr-osmosdr as gr-osmosdr uses the GNU Radio API. Thank you Alex, I'm finding Gnuradio, and the way that it operates, a difficult subject to grasp. -- Regards, Phil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-osmosdr compile problems
On 03/06/12 21:41, Alexandru Csete wrote: I tried to build as well yesterday and failed for me too - as I recall with the same error. I checked out the code again today and it fails too but with a different error, so the code is changing at the moment. You can go back to commit b2128bc86442148d87a7fe897a382c836baf8a67 which compiles fine for me, i.e. git checkout b2128bc More hand holding I'm afraid Alex. Is this the correct git syntax? [root@localhost src (master)]# git checkout b2128bc git://git.osmocom.org/gr-osmosdr error: pathspec 'b2128bc' did not match any file(s) known to git. error: pathspec 'git:/git.osmocom.org/gr-osmosdr' did not match any file(s) known to git. -- Regards, Phil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question on DQPSK Modulation - issue with output
Hi Vahid, First I'd try using a much longer string of bits and see if that help. Second I'd find an example in gnuradio (gr-digital/python/qa_constellation.py should have a working dqpsk test) and then work from there. Thirdly if you want pi/4-dqpsk you won't be able to use the standard dqpsk_mod and dqpsk_demod, but will need to define a two-dimensional constellation and use the generic_mod and generic_demod blocks. The two-dimensional constellation would be defined something like: normal_qpsk_points = [blah, blah, blah, blah] rotated_qpsk_points = [blah, blah, blah, blah] two_d_points = [] for p in normal_qpsk_points: for q in rotated_qpsk_points: two_d_points += [p, q] pi4dqpsk_constellation = digital.constellation_calcdist(two_d_points, [], 4, 2) Cheers, Ben On Sat, Jun 2, 2012 at 4:20 PM, Vahid Behzadan vbehza...@yahoo.com wrote: Dear all, I am currently trying to implement a pi/4 dqpsk modulator and demodulator. I have tried two approaches, one uses the CQPSK.py (included in osmocom's TETRA project) and the other uses digital.qpsk.dqpsk_mod. Both of these approaches have failed to return the same string of bits after the process of modulations-demodulation. The input comes from a .dat file and is a string of bits (tried different sizes, from 2 bits to 32 bits), then the output of modulation is written to a sink.dat as gr_complex. This file is then fed to a demodulator which saves the output to a final.dat. I have attached important bits of the code which uses qpsk.dqpsk_mod/demod. I would greatly appreciate any advice. Also, could anyone please confirm that what I can achieve a --PI/4--DQPSK using the dqpsk_mod? Best Regards, Vahid --- Modulator: . . . sample_rate = options.sample_rate symbol_rate = 18000 sps = 2 IN = gr.file_source(gr.sizeof_gr_complex, options.input_file, repeat = False) #IN = (1,0,0,0,1,1,0,0) src = gr.vector_source_b (IN) MOD = digital.qpsk.dqpsk_mod( samples_per_symbol = sps, excess_bw=0.35, log=options.log, gray_coded=True, verbose=options.verbose) self.connect(src,MOD) OUT = gr.file_sink(gr.sizeof_gr_complex, options.output_file) self.sink1 = gr.vector_sink_f() self.sink2 = gr.vector_sink_f() real = gr.complex_to_real() imag = gr.complex_to_imag() self.connect(MOD,real) self.connect(MOD,imag) self.connect(real,self.sink1) self.connect(imag,self.sink2) self.connect(MOD,OUT) def print_data(self): print data in sink1 is: ,self.sink1.data() print data in sink2 is: ,self.sink2.data() . . . - Demodulator: sample_rate = options.sample_rate symbol_rate = 18000 sps = 2 # output rate will be 36,000 ntaps = 11 * sps new_sample_rate = symbol_rate * sps channel_taps = gr.firdes.low_pass(1.0, sample_rate, options.low_pass, options.low_pass * 0.1, gr.firdes.WIN_HANN) FILTER = gr.freq_xlating_fir_filter_ccf(1, channel_taps, options.calibration, sample_rate) IN = gr.file_source(gr.sizeof_gr_complex, options.input_file) #IN = (1,1,0,1,1,1,0,0) #src = gr.vector_source_b (IN) DEMOD = digital.qpsk.dqpsk_demod( samples_per_symbol = sps, excess_bw=0.35, gray_coded=True, log=options.log, verbose=options.verbose) OUT = gr.file_sink(gr.sizeof_char, options.output_file) self.sink1 = gr.vector_sink_b() r = float(sample_rate) / float(new_sample_rate) INTERPOLATOR = gr.fractional_interpolator_cc(0, r) self.connect(IN, FILTER, INTERPOLATOR, DEMOD, OUT) self.connect(DEMOD,self.sink1) def print_data(self): print data in sink1 is: ,self.sink1.data() -- View this message in context: http://old.nabble.com/Question-on-DQPSK-Modulation---issue-with-output-tp33950307p33950307.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Gnuradio compile errors
Almost there I think. It looks like I'm missing something to do with gr-udp. -- ## -- # Gnuradio enabled components -- ## -- * python-support -- * testing-support -- * volk -- * doxygen -- * gruel -- * gnuradio-core -- * gnuradio-companion -- * gr-atsc -- * gr-audio -- * gr-digital -- * gr-noaa -- * gr-pager -- * gr-qtgui -- * gr-trellis -- * gr-uhd -- * gr-utils -- * gr-video-sdl -- * gr-vocoder -- * gr-fcd -- * gr-wavelet -- * gr-wxgui -- -- ## -- # Gnuradio disabled components -- ## -- * gr-comedi -- * gr-shd -- /usr/local/src/gnuradio-3.6.0/gnuradio-core/src/lib/io/gr_udp_sink.cc: In constructor ‘gr_udp_sink::gr_udp_sink(size_t, const char*, short unsigned int, int, bool)’: /usr/local/src/gnuradio-3.6.0/gnuradio-core/src/lib/io/gr_udp_sink.cc:123:51: error: ‘optval_t’ was not declared in this scope make[2]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/io/gr_udp_sink.cc.o] Error 1 make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all] Error 2 make: *** [all] Error 2 -- Regards, Phil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio compile errors
/usr/local/src/gnuradio-3.6.0/gnuradio-core/src/lib/io/gr_udp_sink.cc: In constructor ‘gr_udp_sink::gr_udp_sink(size_t, const char*, short unsigned int, int, bool)’: /usr/local/src/gnuradio-3.6.0/gnuradio-core/src/lib/io/gr_udp_sink.cc:123:51: error: ‘optval_t’ was not declared in this scope make[2]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/io/gr_udp_sink.cc.o] Error 1 make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all] Error 2 make: *** [all] Error 2 Thats probably a simple fix away. But kind of unexpected. What OS? -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio compile errors
On 04/06/12 10:43, Josh Blum wrote: /usr/local/src/gnuradio-3.6.0/gnuradio-core/src/lib/io/gr_udp_sink.cc: In constructor ‘gr_udp_sink::gr_udp_sink(size_t, const char*, short unsigned int, int, bool)’: /usr/local/src/gnuradio-3.6.0/gnuradio-core/src/lib/io/gr_udp_sink.cc:123:51: error: ‘optval_t’ was not declared in this scope make[2]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/io/gr_udp_sink.cc.o] Error 1 make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all] Error 2 make: *** [all] Error 2 Thats probably a simple fix away. But kind of unexpected. What OS? Linux Josh. -- Regards, Phil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question on DQPSK Modulation - issue with output
On Sun, Jun 3, 2012 at 4:31 PM, Ben Reynwar b...@reynwar.net wrote: Hi Vahid, First I'd try using a much longer string of bits and see if that help. Second I'd find an example in gnuradio (gr-digital/python/qa_constellation.py should have a working dqpsk test) and then work from there. Thirdly if you want pi/4-dqpsk you won't be able to use the standard dqpsk_mod and dqpsk_demod, but will need to define a two-dimensional constellation and use the generic_mod and generic_demod blocks. The two-dimensional constellation would be defined something like: normal_qpsk_points = [blah, blah, blah, blah] rotated_qpsk_points = [blah, blah, blah, blah] two_d_points = [] for p in normal_qpsk_points: for q in rotated_qpsk_points: two_d_points += [p, q] pi4dqpsk_constellation = digital.constellation_calcdist(two_d_points, [], 4, 2) Just checked the code and it looks like multi-dimensional constellations aren't supported yet by generic_mod and generic_demod. Another way might be to edit digital.constellation_receiver_cb so that it shifts the phase back and forth by pi/4. Cheers, Ben On Sat, Jun 2, 2012 at 4:20 PM, Vahid Behzadan vbehza...@yahoo.com wrote: Dear all, I am currently trying to implement a pi/4 dqpsk modulator and demodulator. I have tried two approaches, one uses the CQPSK.py (included in osmocom's TETRA project) and the other uses digital.qpsk.dqpsk_mod. Both of these approaches have failed to return the same string of bits after the process of modulations-demodulation. The input comes from a .dat file and is a string of bits (tried different sizes, from 2 bits to 32 bits), then the output of modulation is written to a sink.dat as gr_complex. This file is then fed to a demodulator which saves the output to a final.dat. I have attached important bits of the code which uses qpsk.dqpsk_mod/demod. I would greatly appreciate any advice. Also, could anyone please confirm that what I can achieve a --PI/4--DQPSK using the dqpsk_mod? Best Regards, Vahid --- Modulator: . . . sample_rate = options.sample_rate symbol_rate = 18000 sps = 2 IN = gr.file_source(gr.sizeof_gr_complex, options.input_file, repeat = False) #IN = (1,0,0,0,1,1,0,0) src = gr.vector_source_b (IN) MOD = digital.qpsk.dqpsk_mod( samples_per_symbol = sps, excess_bw=0.35, log=options.log, gray_coded=True, verbose=options.verbose) self.connect(src,MOD) OUT = gr.file_sink(gr.sizeof_gr_complex, options.output_file) self.sink1 = gr.vector_sink_f() self.sink2 = gr.vector_sink_f() real = gr.complex_to_real() imag = gr.complex_to_imag() self.connect(MOD,real) self.connect(MOD,imag) self.connect(real,self.sink1) self.connect(imag,self.sink2) self.connect(MOD,OUT) def print_data(self): print data in sink1 is: ,self.sink1.data() print data in sink2 is: ,self.sink2.data() . . . - Demodulator: sample_rate = options.sample_rate symbol_rate = 18000 sps = 2 # output rate will be 36,000 ntaps = 11 * sps new_sample_rate = symbol_rate * sps channel_taps = gr.firdes.low_pass(1.0, sample_rate, options.low_pass, options.low_pass * 0.1, gr.firdes.WIN_HANN) FILTER = gr.freq_xlating_fir_filter_ccf(1, channel_taps, options.calibration, sample_rate) IN = gr.file_source(gr.sizeof_gr_complex, options.input_file) #IN = (1,1,0,1,1,1,0,0) #src = gr.vector_source_b (IN) DEMOD = digital.qpsk.dqpsk_demod( samples_per_symbol = sps, excess_bw=0.35, gray_coded=True, log=options.log, verbose=options.verbose) OUT = gr.file_sink(gr.sizeof_char, options.output_file) self.sink1 = gr.vector_sink_b() r = float(sample_rate) / float(new_sample_rate) INTERPOLATOR = gr.fractional_interpolator_cc(0, r) self.connect(IN, FILTER, INTERPOLATOR, DEMOD, OUT) self.connect(DEMOD,self.sink1) def print_data(self): print data in sink1 is: ,self.sink1.data() -- View this message in context: http://old.nabble.com/Question-on-DQPSK-Modulation---issue-with-output-tp33950307p33950307.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio compile errors
On 03/06/12 08:54 PM, Phil wrote: On 04/06/12 10:43, Josh Blum wrote: /usr/local/src/gnuradio-3.6.0/gnuradio-core/src/lib/io/gr_udp_sink.cc: In constructor ‘gr_udp_sink::gr_udp_sink(size_t, const char*, short unsigned int, int, bool)’: /usr/local/src/gnuradio-3.6.0/gnuradio-core/src/lib/io/gr_udp_sink.cc:123:51: error: ‘optval_t’ was not declared in this scope make[2]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/io/gr_udp_sink.cc.o] Error 1 make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all] Error 2 make: *** [all] Error 2 Thats probably a simple fix away. But kind of unexpected. What OS? Linux Josh. Phil, I'm pretty sure that Josh was asking about which particular flavour of the dozen or so popular Linux distributions you're using. It matters. Different distributions use different file-system layouts, store header files in different locations, and have different sets of standard packages installed. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio compile errors
On 04/06/12 12:49, Marcus D. Leech wrote: Phil, I'm pretty sure that Josh was asking about which particular flavour of the dozen or so popular Linux distributions you're using. It matters. Different distributions use different file-system layouts, store header files in different locations, and have different sets of standard packages installed. Ok Marcus, it's Mageia 2, a fork off Mandriva. -- Regards, Phil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-osmosdr compile problems
On Mon, Jun 4, 2012 at 1:24 AM, Phil phil_...@bigpond.com wrote: On 03/06/12 21:41, Alexandru Csete wrote: I tried to build as well yesterday and failed for me too - as I recall with the same error. I checked out the code again today and it fails too but with a different error, so the code is changing at the moment. You can go back to commit b2128bc86442148d87a7fe897a382c836baf8a67 which compiles fine for me, i.e. git checkout b2128bc More hand holding I'm afraid Alex. Is this the correct git syntax? [root@localhost src (master)]# git checkout b2128bc git://git.osmocom.org/gr-osmosdr error: pathspec 'b2128bc' did not match any file(s) known to git. error: pathspec 'git:/git.osmocom.org/gr-osmosdr' did not match any file(s) known to git. First you make a clone git clone git:/git.osmocom.org/gr-osmosdr (I assumed you already had that), then you change into the gr-osmosdr directory and do git checkout b2128bc Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
