Re: [Discuss-gnuradio] Porting new hardware to GNURadio
On Wed, Apr 25, 2012 at 05:37:16PM -0400, Getz, Robin wrote: > Which brings me to the question: > > We already have Linux IIO drivers[8] for all the parts on the board > (including > the ADCs[9] and DACs[10]), and are just trying to determine how (if at all) > this fits within the GNU Radio framework. Hi Robin, if you have the drivers, it should be a cakewalk to add sink/source blocks. > When I looked at things (which wasn't very long) - I didn't see much in terms > of native / real time connections to a platform which was running Linux > (PCIe, other other bus). Did I miss something? What exactly do you mean? The standard GNU Radio source comes with (real time capable) drivers for all the Ettus stuff (via UHD), Funcube Dongle, soundcards and more (see also http://gnuradio.org/redmine/projects/gnuradio/wiki/Hardware), plus there's 3rd-party stuff like Balint's drivers for RTL2832 TV tuners available on the webs. These things connect to the PC via USB or GigE. I'm not sure if that's what you were looking for, though. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpuuE0vpWPZt.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] benchmark_tx.py BPSK Signal Details
Hello all, I want to know how I could possibly find out the complete details about the BPSK-Signal generated by the benchmark_tx.py GNU Radio script. Should I look at the code and at which file respectively? Thanks in advance. -Sebastian- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] CMake build problem
Hi, I'm running debian unstable on a AMD64 platform and am running into a problem which starts right at the top of the build process for a newly checkout gnuradio version from git. Below is output from running cmake: [snip] -- Performing Test HAVE_WARN_ALL -- Performing Test HAVE_WARN_ALL - Success -- Performing Test HAVE_WARN_NO_UNINITIALIZED -- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success -- Found PythonLibs: optimized;/usr/lib/python3.2/config/libpython3.2.so;debug;/usr/lib/python3.2/config/libpython3.2.so (found version "2.7.3rc2") -- Found SWIG: /usr/bin/swig2.0 (found version "2.0.4") [snip] So it found that /usr/bin/python is version 2.7.3rc2, but it decides to use version 3.2 to link against. This makes the build process rather sad later on! (Lots of link failures) To get around this I changed in CMakeLists.txt find_package(PythonLibs) to be find_package(PythonLibs 2.7.3) But obviously that'll only work for people running 2.7.3! (I've not played with cmake before now, so there might be a simple way to fix it) I'm running cmake version 2.8.7. However the build process goes further this time, but now breaks with: [ 49%] Built target _runtime_swig_doc_tag [ 49%] Generating doxygen xml for runtime_swig_doc docs [ 49%] Generating runtime_swig_doc.i [ 49%] Generating doxygen xml for general_swig_doc docs [ 49%] Generating general_swig_doc.i [ 49%] Generating doxygen xml for gengen_swig_doc docs [ 49%] Generating gengen_swig_doc.i XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying. XML parsing error with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i. giving up. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying. XML parsing error with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i. giving up. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying. XML parsing error with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i. giving up. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying. XML parsing problem with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, retrying. XML parsing error with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i. giving up. XML parsing error with file /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i. giving up. Traceback (most recent call last): File "/home/matt/gnuradio/docs/doxygen/swig_doc.py", line 294, in make_swig_interface_file(di, swigdocfilename, custom_output=custom_output) File "/home/matt/gnuradio/docs/doxygen/swig_doc.py", line 222, in make_swig_interface_file make_func = di.get_member(make_name(block.name()), DoxyFunction) File "/home/matt/gnuradio/docs/doxygen/doxyxml/base.py", line 157, in get_member raise member() doxyxml.base.Duplicate make[2]: *** [gnuradio-core/src/lib/swig/gengen_swig_doc.i] Error 1 make[1]: *** [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] Error 2 make: *** [all] Error 2 Which I don't know where to start to fix! However I can tell you that the file its looking for, /home/./swig/gengen_swig_doc.i doesn't exist, but I don't know what should have created it. Thanks, Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Porting new hardware to GNURadio
On Thu 26 Apr 2012 03:19, Martin Braun pondered: > On Wed, Apr 25, 2012 at 05:37:16PM -0400, Getz, Robin wrote: > > Which brings me to the question: > > > > We already have Linux IIO drivers[8] for all the parts on the board > > (including the ADCs[9] and DACs[10]), and are just trying to determine > > how (if at all) this fits within the GNU Radio framework. > > Hi Robin, > > if you have the drivers, it should be a cakewalk to add sink/source > blocks. Are there pointers for doing that? Looks like: http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide ? Is there a "golden" reference to look at? (I assume gr-howto-write-a-block-3.6.0.tar.gz should have everything we need?) > > When I looked at things (which wasn't very long) - I didn't see much in > > terms of native / real time connections to a platform which was running > > Linux (PCIe, other other bus). Did I miss something? > > What exactly do you mean? The standard GNU Radio source comes with (real > time capable) drivers for all the Ettus stuff (via UHD), Funcube Dongle, > soundcards and more (see also > http://gnuradio.org/redmine/projects/gnuradio/wiki/Hardware), Yeah, that's what I was missing. If it supports Comedi - it should support IIO without many issues. SLOCDirectory SLOC-by-Language (Sorted) 387 gr-comedi cpp=376,python=11 If that's all that's necessary - it shouldn't take much time at all... > plus there's > 3rd-party stuff like Balint's drivers for RTL2832 TV tuners available on > the webs. These things connect to the PC via USB or GigE. > > I'm not sure if that's what you were looking for, though. Close - although it appears we need to extend our FSF copyright assignments before we get too busy. Thanks -Robin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Post-facto waterfall plots
Does anyone have any gnuplot scripts or Octave macros for producing a waterfall plot from pre-recorded complex-float data? -- Marcus Leech 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] Porting new hardware to GNURadio
On Thu, Apr 26, 2012 at 07:38, Getz, Robin wrote: > Is there a "golden" reference to look at? (I assume > gr-howto-write-a-block-3.6.0.tar.gz > should have everything we need?) This will give you the "canonical" format for writing your own out-of-tree installable GNU Radio blocks. A hardware source block would have no input ports, one or more output ports for whatever streams your device generates, and a work function that wraps calls to your existing sample-based I/O library for your device. The main purpose of the work function would be to retrieve samples from the device and put them into the block output buffer, and some housekeeping to tell the GNU Radio runtime what you've done. You'd also need write any needed setter/getter functions to perform configuration of your source block either at initialization or during runtime. > ...although it appears we need to extend our FSF copyright assignments > before we get too busy. This isn't needed to develop your own distributed GNU Radio blocks; you only need comply with the GPLv3 license terms of GNU Radio. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] benchmark_tx.py BPSK Signal Details
On Thu, 26 Apr 2012 10:05:41 +0200, Sebastian Döring wrote:
> Hello all,
>
> I want to know how I could possibly find out the complete details about
> the BPSK-Signal generated by the benchmark_tx.py GNU Radio script.
> Should I look at the code and at which file respectively?
>
> Thanks in advance.
>
> -Sebastian-
>
I assume you are talking about the benchmark_tx.py under narrowband/
directory. With my (limited) experience with it, I can tell that it
depends on code in transmit_path.py under the same directory. The
packets related function can be found at gr-digital/python/{pkt.py and
packet_utils.py}. As with the modulation, it utilizes the code in
gr-digital/python/generic_mod_demod.py. So have a look at these files
you will get some more information about how the blocks are connected.
When you want to know the implementation/algorithm of blocks, you will
need to look into the C++ code (under lib/ and include/ directory).
Besides, the benchmark_tx.py script has a option '--log', which can be
used to dump the output data of some blocks into files. You can then use
Octave/Matlab to read these data files and play with them(by plotting,
etc). To read the data files into Octave vectors you can use functions
described here.[1]
[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Octave
--
alick
Fedora 16 (Verne) user
https://fedoraproject.org/wiki/User:Alick
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Porting new hardware to GNURadio
On Thu 26 Apr 2012 10:58, Johnathan Corgan pondered: > On Thu, Apr 26, 2012 at 07:38, Getz, Robin wrote: > > Is there a "golden" reference to look at? (I assume > > gr-howto-write-a-block-3.6.0.tar.gz > > should have everything we need?) > > This will give you the "canonical" format for writing your own > out-of-tree installable GNU Radio blocks. And what is preferred? I always think in-tree is better - but that's just me. > A hardware source block would have no input ports, one or more output > ports for whatever streams your device generates, and a work function > that wraps calls to your existing sample-based I/O library for your > device. The main purpose of the work function would be to retrieve > samples from the device and put them into the block output buffer, and > some housekeeping to tell the GNU Radio runtime what you've done. What is the widest band device (MSPS) that GNURadio can keep up with in real time? With this card - we are limited in memory bandwidth (vs a desktop), and Cortex A9 isn't bad - but it's no Intel CPU in terms of floating point performance... Who actually manages the location of the buffer? If GNURadio mmaps the location (rather than malloc), it will save a memcpy in the work function. What's the format that GNURadio wants (16-bit fixed? float? other?) We can make the format converter in the HDL, to decrease the load on the processor. > You'd also need write any needed setter/getter functions to perform > configuration of your source block either at initialization or during > runtime. There are lots of potential settings (Tx/Rx modulator frequencies, ADC/DAC sample rates, sync, MIMO config, etc) - I'm assuming some of those configuration knobs are exposed to the python interface in a standard manner across hardware? > > ...although it appears we need to extend our FSF copyright assignments > > before we get too busy. > > This isn't needed to develop your own distributed GNU Radio blocks; > you only need comply with the GPLv3 license terms of GNU Radio. Right - but I would think that it would be better to have things in tree? With all the FSF packages that we have contributed to in the past (gcc, binutils, gdb, etc) without a FSF copyright assignment - the package maintainer would not accept patches. I believe that is what is indicated here: http://gnuradio.org/redmine/projects/gnuradio/wiki/Development#Whats-this-Copyright-Assignment Thanks -Robin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmit and receive suing GMSK
You should use FFT sink with complex input, so its direct from uhd source with only throttle in between. But the FFT you attached seems to indicate you have no signal into the receiver. Make sure they're on the same RF frequency, and adjust gains appropriate for the path loss between transmitter and receiver. I am sure the packet encoder/decoder has some overhead, because its adding preamble, access_code, and crc. It means the thruput should be less than your actual over-the-air bitrate. If you are sending audio, then you might be better served by one of the audio encoders, such as the stuff under Vocoders category. On Wed, Apr 25, 2012 at 9:08 PM, Jamie Wo wrote: > > > On Thu, Apr 26, 2012 at 5:12 AM, wayne roberts wrote: > > Hi Wayne, > > Thanks for your reply. My responses are: > > > >> I was messing with the same thing myself. >> >> First off, i'm not sure the packet decoder outputs in a real-time fashion >> to drive an audio sink. Try a scope sink to see how often the packet >> decoder output updates: is there a better way? >> > > > I am not sure the real-time fashion to drive an audio sink either, but > there should be a way to support it, I guess. I ran the flow graph and saw > the update time interval from a scope sink is 3 - 5s . Is this too long? > Do you know what does this update time mean? > > > On the GMSK demodulator side, I would think its best to observe the signal >> going into the demodulator, from uhd rx source. To see it in time domain, >> you can use Quadrature Demod -> throttle -> scope sink, making sure signal >> is centered at 0 and is reasonable distortion free. To be sure what its >> supposed to look like, you can put on the transmitter side Quadrature Demod >> -> throttle -> scope sink on the output of GMSK modulator. >> >> And of course you can put an FFT sink right on the UHD source to see it >> in frequency domain. On the transmitter side, to UHD sink, I have found >> the GMSK modulator outputs signal level near the maximum, meaning some >> transient peaks could cause clipping on USRP transmitter, so it might be >> prudent to put a multiply const (with 0.99 or so) just before going to UHD >> sink. >> > > I used Quadrature Demod -> throttle -> scope sink on the receiver side to > see the signal going into the GSMK demod after uhd source. Also I > used Quadrature Demod -> throttle -> scope sink after the output of GMSK > mod. The time and frequency domain outputs are attached. Theoretically, > these two output should be similar or the same, However, they are quite > different after travelling over the air. Can you see any problems from the > figures? > > Thanks, > > Jamie > > >> >> On Wed, Apr 25, 2012 at 1:41 AM, Jamie Wo wrote: >> >>> Hi all, >>> >>> I am currently working on tranmiting and receiving data using 2 >>> USRPN210s. I got some ideas from here and did this task using GMSK in GRC. >>> >>> The transmit side: File source --> Packet encoder --> GMSK Mod --> UHD >>> sink. >>> The receiver side: UHD source --> GMSK Demod --> Packet decoder --> File >>> sink. >>> >>> Data in file source can be received by the receiver. However, I am not >>> sure whether the data has been received correctly. Does anyone know how to >>> test it ? >>> >>> My method is to use wav source and audio sink like this: >>> >>> The transmit side: Wav source --> Packet encoder --> GMSK Mod --> UHD >>> sink. >>> The receiver side: UHD source --> GMSK Demod --> Packet decoder --> >>> Audio sink. (samp_rate 48K). >>> >>> I think if the sound received on the receiver is the same as the wav >>> file, the data may be correctly received. However, after I tried this, the >>> sound received was disjointedly, not as smooth as the wav source, and >>> "audio underrun" happened sometimes. >>> >>> However, when I put all the blocks in one flow graph without UHD like >>> this: >>> wav source --> Packet encoder --> GMSK Mod --> GMSK Demod --> packet >>> decoder --> audio sink.(samp_rate 48K), it works very well. >>> >>> Does anyone meet the same problem or know how to solve it? Is my way to >>> test how to receive correctly right? >>> >>> To do what I want, is there any other blocks that need to be added in >>> the GRC? >>> >>> Please give me some guidance. >>> >>> Thanks in advance. >>> >>> Jamie >>> >>> ___ >>> 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] USRP: is performance degradation of PSK OK?
On Wed, 25 Apr 2012 12:01:33 +0800, Alick Zhao wrote: > On Tue, 24 Apr 2012 07:52:09 -0700, Nick Foster wrote: > >> >> Alick, >> >> You will have to instrument your flowgraph in order to find out. Add file >> sinks to different stages in the transmitter and receiver to verify that >> the data looks as expected. You can use MATLAB or Octave to visualize the >> data. There are scripts in gnuradio-core/src/utils which will aid you in >> loading sample data into MATLAB. Verify that the frequency offset is within >> bounds and being handled appropriately. Verify that clock recovery is >> keeping a lock on the incoming data. >> >> --n I also make some plots with the logged data. I can see that consecutive 1000 points of data after freq_recov or time_recov are distributed around the unit circle. I think the freq/time recovery may not work well. Given static indoor environment, the coherence time should be long. I'd expect that the constellation points after timing recovery should stay around two certain points for some thousands of samples. Is it so? If the problem is with the recovery loop, I wonder how I can adjust the parameters of the loop. I have read Tom's post about loop gain values[1]. It seems that damping factor (0.707) should not be changed, and loop bw is somewhere around pi/100 to 2*pi/100. So I find little change can be done. By plotting data directly output by usrp source I find that the constellation points are disperse too. But I think it is due to lack of synchronization between tx/rx. Am I wrong about this? [1] http://www.trondeau.com/blog/2011/8/13/control-loop-gain-values.html -- alick Fedora 16 (Verne) user https://fedoraproject.org/wiki/User:Alick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Porting new hardware to GNURadio
On Thu, Apr 26, 2012 at 08:31, Getz, Robin wrote: > On Thu 26 Apr 2012 10:58, Johnathan Corgan pondered: >> This will give you the "canonical" format for writing your own >> out-of-tree installable GNU Radio blocks. > > And what is preferred? I always think in-tree is better - but that's just me. If you are not planning to contribute your code to the GNU Radio project, the out-of-tree build system allows you to maintain your source code independently of GNU Radio, in its own version control system, and allows you to distribute said code in an optimal fashion. In addition, the build process is much faster. You can even use OS supplied binary development packages in lieu of compiling GNU Radio. If you are planning to offer your code for inclusion into GNU Radio proper, it's still much easier to get it written and debugged on its own, then convert it to the in-tree, top-level component form. One thing to consider, though is that in order for the code maintainers (Tom and I) to be able to manage inclusion of new hardware support into the project, we need to be able to test locally in our labs. This involves providing the hardware either on a long-term loan or donating it to the project. >> A hardware source block would have no input ports, one or more output >> ports for whatever streams your device generates, and a work function >> that wraps calls to your existing sample-based I/O library for your >> device. The main purpose of the work function would be to retrieve >> samples from the device and put them into the block output buffer, and >> some housekeeping to tell the GNU Radio runtime what you've done. > > What is the widest band device (MSPS) that GNURadio can keep up with in real > time? With this card - we are limited in memory bandwidth (vs a desktop), and > Cortex A9 isn't bad - but it's no Intel CPU in terms of floating point > performance... There are way too many variables here to answer your question accurately. GNU Radio routinely handles 25 Msps I/Q plus DSP with mid-range desktop x86 systems. The greatest variable is not so much the sample rate but what you're doing with it. Others on the list may chime in with their own unique applications and the performance they are achieving. > Who actually manages the location of the buffer? If GNURadio mmaps the > location (rather than malloc), it will save a memcpy in the work function. Yes, the work function is provided a mmaped buffer which you can directly DMA into if your hardware supports that. > What's the format that GNURadio wants (16-bit fixed? float? other?) We can > make the format converter in the HDL, to decrease the load on the processor. Inside GNU Radio, the majority of the blocks are designed to operate on single-precision, floating-point samples. Usually, the over-the-wire format is optimized the bandwidth of the transport in use, which means fixed-point samples and conversion on the host. You can instead transport floats to gain CPU performance at the expense of transport bandwidth/sample rate. > There are lots of potential settings (Tx/Rx modulator frequencies, ADC/DAC > sample rates, sync, MIMO config, etc) - I'm assuming some of those > configuration knobs are exposed to the python interface in a standard manner > across hardware? No, we don't have a device abstraction layer at this level. It's a nice idea and many have suggested it, but it's been an open issue for SDR in general for a long time. So you are free to implement whatever function calls are needed to twiddle the hardware the right way, and there is a standard way (via SWIG) that these functions get exported to the Python API. >> This isn't needed to develop your own distributed GNU Radio blocks; >> you only need comply with the GPLv3 license terms of GNU Radio. > > Right - but I would think that it would be better to have things in tree? For the reasons above, we have to think about how generally available the hardware is, whether we ourselves can test with that hardware, etc. But in-tree is definitely better for your users, as they get the drivers "for free" when they install GNU Radio. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CMake build problem
On Thu, Apr 26, 2012 at 7:30 AM, wrote: > > Hi, > > I'm running debian unstable on a AMD64 platform and am running into a > problem which starts right at the top of the build process for a newly > checkout gnuradio version from git. > > Below is output from running cmake: > > [snip] > -- Performing Test HAVE_WARN_ALL > -- Performing Test HAVE_WARN_ALL - Success > -- Performing Test HAVE_WARN_NO_UNINITIALIZED > -- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success > -- Found PythonLibs: > optimized;/usr/lib/python3.2/config/libpython3.2.so;debug;/usr/lib/python3.2/config/libpython3.2.so > (found version "2.7.3rc2") > -- Found SWIG: /usr/bin/swig2.0 (found version "2.0.4") > [snip] > > So it found that /usr/bin/python is version 2.7.3rc2, but it decides > to use version 3.2 to link against. This makes the build process > rather sad later on! (Lots of link failures) > > To get around this I changed in CMakeLists.txt > > find_package(PythonLibs) > > to be > > find_package(PythonLibs 2.7.3) > > But obviously that'll only work for people running 2.7.3! (I've not > played with cmake before now, so there might be a simple way to fix > it) > > I'm running cmake version 2.8.7. Yes, GNU Radio does not work with Python 3, yet. We will have to make sure it checks that the Python version is less than 3. > However the build process goes further this time, but now breaks with: > > [ 49%] Built target _runtime_swig_doc_tag > [ 49%] Generating doxygen xml for runtime_swig_doc docs > [ 49%] Generating runtime_swig_doc.i > [ 49%] Generating doxygen xml for general_swig_doc docs > [ 49%] Generating general_swig_doc.i > [ 49%] Generating doxygen xml for gengen_swig_doc docs > [ 49%] Generating gengen_swig_doc.i > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing error with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i. > giving up. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing error with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i. > giving up. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing error with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i. > giving up. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing problem with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i, > retrying. > XML parsing error with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i. > giving up. > XML parsing error with file > /home/matt/gnuradio/20120426/gnuradio-core/src/lib/swig/gengen_swig_doc.i. > giving up. > Traceback (most recent call last): > File "/home/matt/gnuradio/docs/doxygen/swig_doc.py", line 294, in > make_swig_interface_file(di, swigdocfilename, custom_output=custom_output) > File "/home/matt/gnuradio/docs/doxygen/swig_doc.py", line 222, in > make_swig_interface_file > make_func = di.get_member(make_name(block.name()), DoxyFunction) > File "/home/matt/gnuradio/docs/doxygen/
Re: [Discuss-gnuradio] Post-facto waterfall plots
On Thu, Apr 26, 2012 at 10:58 AM, Marcus D. Leech wrote: > Does anyone have any gnuplot scripts or Octave macros for producing a > waterfall plot from pre-recorded complex-float data? > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org With Scipy and Matplotlib installed for Python, you can use the gr_plot_psd_c/f utility with the '-S' option to get a waterfall plot. Just a warning, Matplotlib puts the frequency on the y-axis and time on the x-axis. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmit and receive suing GMSK
On Thu, Apr 26, 2012 at 12:08 AM, Jamie Wo wrote: > > > On Thu, Apr 26, 2012 at 5:12 AM, wayne roberts > wrote: > > Hi Wayne, > > Thanks for your reply. My responses are: > > >> >> I was messing with the same thing myself. >> >> First off, i'm not sure the packet decoder outputs in a real-time fashion >> to drive an audio sink. Try a scope sink to see how often the packet >> decoder output updates: is there a better way? > > > > I am not sure the real-time fashion to drive an audio sink either, but > there should be a way to support it, I guess. I ran the flow graph and saw > the update time interval from a scope sink is 3 - 5s . Is this too long? Do > you know what does this update time mean? Yes, these run in "real-time." If they didn't, you wouldn't be properly able to transmit or receive on an actual piece of hardware. >> On the GMSK demodulator side, I would think its best to observe the signal >> going into the demodulator, from uhd rx source. To see it in time domain, >> you can use Quadrature Demod -> throttle -> scope sink, making sure signal >> is centered at 0 and is reasonable distortion free. To be sure what its >> supposed to look like, you can put on the transmitter side Quadrature Demod >> -> throttle -> scope sink on the output of GMSK modulator. >> >> And of course you can put an FFT sink right on the UHD source to see it in >> frequency domain. On the transmitter side, to UHD sink, I have found the >> GMSK modulator outputs signal level near the maximum, meaning some transient >> peaks could cause clipping on USRP transmitter, so it might be prudent to >> put a multiply const (with 0.99 or so) just before going to UHD sink. > > > I used Quadrature Demod -> throttle -> scope sink on the receiver side to > see the signal going into the GSMK demod after uhd source. Also I > used Quadrature Demod -> throttle -> scope sink after the output of GMSK > mod. The time and frequency domain outputs are attached. Theoretically, > these two output should be similar or the same, However, they are quite > different after travelling over the air. Can you see any problems from the > figures? Don't use a throttle when you have a block that's already setting the rate of your flowgraph. The USRP receiver is controlling that. Having two rate-controllers in there is at best not needed and at worst actually screwing up your receiver. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CMake build problem
Tom Rondeau writes: > On Thu, Apr 26, 2012 at 7:30 AM, wrote: > > > > Hi, > > > > I'm running debian unstable on a AMD64 platform and am running into a > > problem which starts right at the top of the build process for a newly > > checkout gnuradio version from git. > > > > Below is output from running cmake: > > > > [snip] > > -- Performing Test HAVE_WARN_ALL > > -- Performing Test HAVE_WARN_ALL - Success > > -- Performing Test HAVE_WARN_NO_UNINITIALIZED > > -- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success > > -- Found PythonLibs: > > optimized;/usr/lib/python3.2/config/libpython3.2.so;debug;/usr/lib/python3.2/config/libpython3.2.so > > (found version "2.7.3rc2") > > -- Found SWIG: /usr/bin/swig2.0 (found version "2.0.4") > > [snip] > > > > So it found that /usr/bin/python is version 2.7.3rc2, but it decides > > to use version 3.2 to link against. This makes the build process > > rather sad later on! (Lots of link failures) > > > > To get around this I changed in CMakeLists.txt > > > > find_package(PythonLibs) > > > > to be > > > > find_package(PythonLibs 2.7.3) > > > > But obviously that'll only work for people running 2.7.3! (I've not > > played with cmake before now, so there might be a simple way to fix > > it) > > > > I'm running cmake version 2.8.7. > > Yes, GNU Radio does not work with Python 3, yet. We will have to make > sure it checks that the Python version is less than 3. Getting it to try and link with the default version of python on the system would also be good. > > > However the build process goes further this time, but now breaks with: > > > > [ 49%] Built target _runtime_swig_doc_tag > > [ 49%] Generating doxygen xml for runtime_swig_doc docs > > [ 49%] Generating runtime_swig_doc.i > > [ 49%] Generating doxygen xml for general_swig_doc docs > > [ 49%] Generating general_swig_doc.i > > [ 49%] Generating doxygen xml for gengen_swig_doc docs > > [ 49%] Generating gengen_swig_doc.i [snip] > > raise member() > > doxyxml.base.Duplicate > > make[2]: *** [gnuradio-core/src/lib/swig/gengen_swig_doc.i] Error 1 > > make[1]: *** > > [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] > > Error 2 > > make: *** [all] Error 2 > > > > > > > > Which I don't know where to start to fix! However I can tell you that > > the file its looking for, /home/./swig/gengen_swig_doc.i doesn't > > exist, but I don't know what should have created it. > > > > > > Thanks, > > > > Matt > > I'm assuming you are running a parallel make? Try just running "make" > with no options and see if that works. This looks like a bug that > we've had for a while that only shows up on occasion and when running > large parallel makes. It generally goes away when you run make again. > We thought we had squashed this one, but it seems to becoming more of > a problem again. > > In the future, you can try something like "make -j8 -k". That will > finish everything it can, even if there are errors with the doc > generation. You can then run "make" after that to capture the rest of > it. > > Tom Yes, I'd been doing a make -j. Rerunning with just 'make' doesn't appear to work - it fell over agaon in the same place. So I created a new build directory, ran cmake in the new directory and then make (with no -j) and it still fails with the above error for gengen_swig_doc.i Thanks, Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CMake build problem
Can you try setting the PYTHON_* variables to the desired setting? Here is a screenshot of said variables: http://i.imgur.com/kr99Q.jpg -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CMake build problem
If I set the CMakeList.txt back to how it used to be and in a new directory re-run cmake, then I get: py_exe /usr/bin/python py_inc /usr/include/python2.7 py_lib /usr/lib/python3.2/config/libpython3.2.so (Which is an interesting mix!) If I now change the py_lib variable to be /u/l/python2.7/c/libpython2.7.so (/usr/bin/python is a sym link to python2.7) and re-generate the make files, it compiles the same way that my modified CMakelist.txt file (i.e. it fails when it gets to gengen_swig_doc.i) so it certainly gets around the python problem. Thanks, Matt Josh Blum writes: > Can you try setting the PYTHON_* variables to the desired setting? > > Here is a screenshot of said variables: http://i.imgur.com/kr99Q.jpg > > -josh > > ___ > 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] Problem with USRP PSK modulation
Hello Vivian, I was able to solve the problem. The encoder and decoder blocks seem to only work with certain modulation blocks. You should try changing your modulation type to GMSK. We have being able to transmit text and picture files with this set up. Sam On Wed, Apr 25, 2012 at 7:14 AM, Vivian Paola Triana Galeano < motis1232...@gmail.com> wrote: > > Hi Samuel! > > I haven't solved it yet. I tried to set center frequency with a slider to > vary a little bit the frequency of the receiver, but it didn't work. > Have you solved the problem? > > Thanks! > > Vivian Triana > > > > 2012/4/19 Samuel Ibarra > >> Hello Vivian, >> >> I have also had this problem, but I haven't being able to solve it. Could >> you please let me know if your able to solve it? I would greatly appreciate >> your help. >> >> Sam >> >> On Thu, Apr 19, 2012 at 7:41 AM, Vivian Paola Triana Galeano < >> motis1232...@gmail.com> wrote: >> >>> I'm using non-differential modulation. But I used differential before >>> and it didn't work neither. I think my problem is with the sample rate that >>> I have to set in UHD_USRP Sink and Source Blocks. I try to send a wav file >>> that has maximum frequency of 12kHz so I set the sample rate at 28kHz, >>> however it didn't. I need understand what the sample rate refers to. >>> >>> Thansks in advance for helping me! >>> >>> >>> >>> 2012/4/19 Tom Rondeau >>> On Wed, Apr 18, 2012 at 11:32 AM, Vivian Paola Triana Galeano wrote: > I'm working with USRP1 daughterboard RFX 2400 MHz. > The configuration of the parameter in UHD_USRP block is sample rate= 1MHz > Center freq=2.4GHz. Vivian, Are you using differential or non-differential modulation? Over the air, the phase ambiguity at the receiver does not get worked out, so it will only work if you use differentially encoded symbols. Tom > 2012/4/18 Edmar Candeia Gurjao >> >> Hi Vivian, >> >> give us details about your set up, like what USRP you are using, >> daughterboads and frequency of transmission, >> >> Edmar >> >> 2012/4/18 Vivian Paola Triana Galeano : >> > >> > I think my problem has something to do with the parameters of the USRP. >> > >> > I try to send a file modulated with BPSK. So I build a graph like this >> > : >> > >> > File source -> Packet Encoder -> PBSK MOD -> PBSK DEMOD -> Packet >> > Decoder -> >> > File sink >> > >> > >> > >> > and i really get the correct output file with thee right constellation. >> > >> > If I put a USRP source and USRP sink into graph, I don't receive >> > anything. >> > I hope anyone can help me. Thanks >> > >> > >> > ___ >> > Discuss-gnuradio mailing list >> > Discuss-gnuradio@gnu.org >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > >> >> >> >> -- >> --- >> Edmar Candeia Gurjão >> Universidade Federal de Campina Grande. >> 1 574 387 0195 >> http://ecandeia.dee.ufcg.edu.br > > > > ___ > 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] Transmit and receive suing GMSK
Hi Tom, Thanks for your reply. It works. I met another strange problem. When I use Wav file source --> audio sink, I can hear the sound in the wav file clearly. However, when I want to hear the file and transmit it using UHD sink at the same time, audio underrun "aUaU" occur. The flow graph is like: Wav file source --> Package Encoder --> GMSK Mod --> UHD sink. --> Audio sink Do you know what is the problem? Jamie On Fri, Apr 27, 2012 at 3:53 AM, Tom Rondeau wrote: > On Thu, Apr 26, 2012 at 12:08 AM, Jamie Wo > wrote: > > > > > > On Thu, Apr 26, 2012 at 5:12 AM, wayne roberts > > wrote: > > > > Hi Wayne, > > > > Thanks for your reply. My responses are: > > > > > >> > >> I was messing with the same thing myself. > >> > >> First off, i'm not sure the packet decoder outputs in a real-time > fashion > >> to drive an audio sink. Try a scope sink to see how often the packet > >> decoder output updates: is there a better way? > > > > > > > > I am not sure the real-time fashion to drive an audio sink either, but > > there should be a way to support it, I guess. I ran the flow graph and > saw > > the update time interval from a scope sink is 3 - 5s . Is this too long? > Do > > you know what does this update time mean? > > Yes, these run in "real-time." If they didn't, you wouldn't be > properly able to transmit or receive on an actual piece of hardware. > > >> On the GMSK demodulator side, I would think its best to observe the > signal > >> going into the demodulator, from uhd rx source. To see it in time > domain, > >> you can use Quadrature Demod -> throttle -> scope sink, making sure > signal > >> is centered at 0 and is reasonable distortion free. To be sure what its > >> supposed to look like, you can put on the transmitter side Quadrature > Demod > >> -> throttle -> scope sink on the output of GMSK modulator. > >> > >> And of course you can put an FFT sink right on the UHD source to see it > in > >> frequency domain. On the transmitter side, to UHD sink, I have found > the > >> GMSK modulator outputs signal level near the maximum, meaning some > transient > >> peaks could cause clipping on USRP transmitter, so it might be prudent > to > >> put a multiply const (with 0.99 or so) just before going to UHD sink. > > > > > > I used Quadrature Demod -> throttle -> scope sink on the receiver side to > > see the signal going into the GSMK demod after uhd source. Also I > > used Quadrature Demod -> throttle -> scope sink after the output of GMSK > > mod. The time and frequency domain outputs are attached. Theoretically, > > these two output should be similar or the same, However, they are quite > > different after travelling over the air. Can you see any problems from > the > > figures? > > Don't use a throttle when you have a block that's already setting the > rate of your flowgraph. The USRP receiver is controlling that. Having > two rate-controllers in there is at best not needed and at worst > actually screwing up your receiver. > > Tom > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
