Re: [Discuss-gnuradio] GNURadio runtime not found? (Ubuntu 14.04)
gnuradio-runtime definitely exists in GR 3.7. Nathan was probably thinking about gnuradio-core, which has been deprecated. Usually this issue is solved by setting PKG_CONFIG_PATH to the directory that contains gnuradio-runtime.pc Ron On 4/9/2014 10:57 PM, Jordan Johnson wrote: Interesting. I never had this issue building in Arch Linux with 3.7. I'm using the Stable branch: https://github.com/kit-cel/gr-drm/tree/stable On Wed, Apr 9, 2014 at 10:46 PM, West, Nathan n...@ostatemail.okstate.edu mailto:n...@ostatemail.okstate.edu wrote: On Thu, Apr 10, 2014 at 12:40 AM, Jordan Johnson jwllmjohn...@gmail.com mailto:jwllmjohn...@gmail.com wrote: So, first thing's first: GNR version: 3.7.2.1 (from apt) Ubuntu ver. 14.04 cmake ver: 2.8 ...Now, I attempting to build gr-drm and it spits out this error on cmake ../ -- checking for module 'gnuradio-runtime' -- package 'gnuradio-runtime' not found * INCLUDES=GNURADIO_RUNTIME_INCLUDE_DIRS-NOTFOUND * LIBS=GNURADIO_RUNTIME_LIBRARIES-NOTFOUND -- Could NOT find GNURADIO_RUNTIME (missing: GNURADIO_RUNTIME_LIBRARIES GNURADIO_RUNTIME_INCLUDE_DIRS) GNURADIO_RUNTIME_FOUND = FALSE CMake Error at /usr/share/cmake-2.8/Modules/FindGnuradio.cmake:81 (message): Required GNU Radio Component: RUNTIME missing! Call Stack (most recent call first): /usr/share/cmake-2.8/Modules/FindGnuradio.cmake:89 (GR_MODULE) CMakeLists.txt:104 (find_package) -- Configuring incomplete, errors occurred! ___ TL;DR: Trying to build module but it cannot find gnuradio, nor gnuradio-ruintime and fails. Install prefix is /lib (?) GNURadio also appears to be missing the FindGnuradio cmake files ax well. GNURadio itself works just fine. Any pointers on what's going on? gnuradio-runtime does not exist in 3.7. Basically this module isn't compatible with 3.7, you'll have to either update the module or use GNU Radio 3.6x ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Swig error with add_item_tag
Hey Jay, please make sure to provide GR version number for questions like this, and point us to the exact source file and line number that's causing the trouble. As for your error: On 04/09/2014 08:34 PM, Jay Radcliffe wrote: self.add_item_tag(0, nitems_written + index_start - self.block_size, self._burst_tag_symbol, gr.pmt.PMT_T, gr.pmt.PMT_F) File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py, line 5172, in block__add_item_tag return _runtime_swig.block_gateway_sptr_block__add_item_tag(self, *args) NotImplementedError: Wrong number or type of arguments for overloaded function 'block_gateway_sptr_block__add_item_tag'. Possible C/C++ prototypes are: gr::block_gateway::block__add_item_tag(unsigned int,gr::tag_t const ) gr::block_gateway::block__add_item_tag(unsigned int,uint64_t,pmt::pmt_t const ,pmt::pmt_t const ,pmt::pmt_t const ) Python/SWIG is picky with overloading and types. You could try adding a tag_t instead: t = gr.tag_t() t.offset = tag_sample_index t.key = self._burst_tag_symbol etc... self.add_item_tag(0, t) That said, your code should work. tag_sample_index isn't a double, by any chance? M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re the spectrum estimation toolbox
On 04/10/2014 12:12 AM, Ruecan wrote: Hello GR, I have multiple questions re the gr-specest toolbox: 1/ Is there any MTM estimator block for GRC Yes! 2/ Can anyone explain to me the figures in https://www.cgran.org/wiki/SpecEst related to Cyclostationarity-Based Modulation Classification. I am actually confused aren't they inverted (QPSK and BPSK) because it is in the QPSK that you find components on the Im. axis not in the BPSK. Any explanations is well appreciated. This is not IQ, it's frequency and symbol rate on the axes. 3/ The README file talks about how to tune the update rate (sample_rate / block_len) however I tried to decrease it to almost 15, sample rate = 32k and block_len = 2048 and even I tried to have an FFT size 256, I always get the plot stuck and is hardly updating. No zoom is possible after I run the estimator. And after I run that, I cannot Pause nor close. I just have to kill the process. Am I missing something or some tuning. Not sure here, but I know guys at CEL have been working to update the toolbox to 3.7, maybe that'll fix it. Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio runtime not found? (Ubuntu 14.04)
On 04/10/2014 07:40 AM, Jordan Johnson wrote: So, first thing's first: *GNR version:* 3.7.2.1 (from apt) *Ubuntu ver.* 14.04 *cmake ver:* 2.8 ...Now, I attempting to build gr-drm and it spits out this error on cmake ../ / -- checking for module 'gnuradio-runtime' -- package 'gnuradio-runtime' not found * INCLUDES=GNURADIO_RUNTIME_INCLUDE_DIRS-NOTFOUND * LIBS=GNURADIO_RUNTIME_LIBRARIES-NOTFOUND -- Could NOT find GNURADIO_RUNTIME (missing: GNURADIO_RUNTIME_LIBRARIES GNURADIO_RUNTIME_INCLUDE_DIRS) GNURADIO_RUNTIME_FOUND = FALSE CMake Error at /usr/share/cmake-2.8/Modules/FindGnuradio.cmake:81 (message): Required GNU Radio Component: RUNTIME missing! Call Stack (most recent call first): /usr/share/cmake-2.8/Modules/FindGnuradio.cmake:89 (GR_MODULE) CMakeLists.txt:104 (find_package) -- Configuring incomplete, errors occurred!/ ___ *TL;DR:* Trying to build module but it cannot find gnuradio, nor gnuradio-ruintime and fails. Install prefix is /lib (?) Is it /lib or /usr/lib? I guess the latter. Can you confirm all the .so files are in the right place? I.e. libgnuradio-runtime.so? Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio runtime not found? (Ubuntu 14.04)
Built from source and the problem seems solved. Oddly enough, this whole out-of-tree cmake issues seem to be common from what Google results showed me. On Thu, Apr 10, 2014 at 12:03 AM, Ron Economos w...@comcast.net wrote: gnuradio-runtime definitely exists in GR 3.7. Nathan was probably thinking about gnuradio-core, which has been deprecated. Usually this issue is solved by setting PKG_CONFIG_PATH to the directory that contains gnuradio-runtime.pc Ron On 4/9/2014 10:57 PM, Jordan Johnson wrote: Interesting. I never had this issue building in Arch Linux with 3.7. I'm using the Stable branch: https://github.com/kit-cel/gr-drm/tree/stable On Wed, Apr 9, 2014 at 10:46 PM, West, Nathan n...@ostatemail.okstate.edu wrote: On Thu, Apr 10, 2014 at 12:40 AM, Jordan Johnson jwllmjohn...@gmail.com wrote: So, first thing's first: GNR version: 3.7.2.1 (from apt) Ubuntu ver. 14.04 cmake ver: 2.8 ...Now, I attempting to build gr-drm and it spits out this error on cmake ../ -- checking for module 'gnuradio-runtime' -- package 'gnuradio-runtime' not found * INCLUDES=GNURADIO_RUNTIME_INCLUDE_DIRS-NOTFOUND * LIBS=GNURADIO_RUNTIME_LIBRARIES-NOTFOUND -- Could NOT find GNURADIO_RUNTIME (missing: GNURADIO_RUNTIME_LIBRARIES GNURADIO_RUNTIME_INCLUDE_DIRS) GNURADIO_RUNTIME_FOUND = FALSE CMake Error at /usr/share/cmake-2.8/Modules/FindGnuradio.cmake:81 (message): Required GNU Radio Component: RUNTIME missing! Call Stack (most recent call first): /usr/share/cmake-2.8/Modules/FindGnuradio.cmake:89 (GR_MODULE) CMakeLists.txt:104 (find_package) -- Configuring incomplete, errors occurred! ___ TL;DR: Trying to build module but it cannot find gnuradio, nor gnuradio-ruintime and fails. Install prefix is /lib (?) GNURadio also appears to be missing the FindGnuradio cmake files ax well. GNURadio itself works just fine. Any pointers on what's going on? gnuradio-runtime does not exist in 3.7. Basically this module isn't compatible with 3.7, you'll have to either update the module or use GNU Radio 3.6x ___ 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 runtime not found? (Ubuntu 14.04)
On Thu, Apr 10, 2014 at 7:40 AM, Jordan Johnson jwllmjohn...@gmail.com wrote: So, first thing's first: GNR version: 3.7.2.1 (from apt) Ubuntu ver. 14.04 cmake ver: 2.8 ...Now, I attempting to build gr-drm and it spits out this error on cmake ../ -- checking for module 'gnuradio-runtime' -- package 'gnuradio-runtime' not found * INCLUDES=GNURADIO_RUNTIME_INCLUDE_DIRS-NOTFOUND * LIBS=GNURADIO_RUNTIME_LIBRARIES-NOTFOUND -- Could NOT find GNURADIO_RUNTIME (missing: GNURADIO_RUNTIME_LIBRARIES GNURADIO_RUNTIME_INCLUDE_DIRS) GNURADIO_RUNTIME_FOUND = FALSE CMake Error at /usr/share/cmake-2.8/Modules/FindGnuradio.cmake:81 (message): Required GNU Radio Component: RUNTIME missing! Call Stack (most recent call first): /usr/share/cmake-2.8/Modules/FindGnuradio.cmake:89 (GR_MODULE) CMakeLists.txt:104 (find_package) Have you installed the gnuradio-dev package as well? (needed if you compile against the libraries) Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BER and OFDM
Hi, Some time ago I also tested this ofdm_loopback file and i figure out that is good to use additional noise source (simulate the channel but also add AWGN). I don't know if this is a proper way of simulating OFDM Tx/Rx but it can be some hint. Best regards, Piotr Potocki 2014-04-09 9:52 GMT+02:00 Martin Braun martin.br...@ettus.com: On 04/08/2014 02:43 PM, MegaDuzera wrote: I already tried the new blocks The BER results are wrong, it gives me a value of 0.0 Units always With an Eb/N0 of 30 dB, that's what I'd expect. For other cases, I don't think your setup works, because of the packet-based nature of the OFDM transceiver (what happens if the demod doesn't find a packet?). Martin ___ 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] Fwd: Problem with getting clear FM signals using the usrp e110
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Yassine,
Please don't be disappointed.
Honestly, it's a little unfair: You demand graphical + signal
processing performance from an embedded device.
People often do this, and I usually like to explain the following:
This embedded device has, for the ease of use, a graphical interface.
This doesn't make it a substitute for a PC. It is not a weak PC. If
you wanted that, you would have bought an old PC and a b100.
It is a powerful embedded device. It's intended purpose is of course a
demonstration of capabilities (like showing the spectrum of a signal),
but foremost it is meant to be used as a remote device doing its
signal processing on its own, without a user sitting in front of it.
Example?
You wouldn't want to install a PC with a screen at every GSM tower.
You'd like to have a small box with a network interface that you can
access remotely to install your new signal processing routines. It is
nice if it has a screen port so a technician might check stuff when
he's at the tower. However, that's not the main feature of that box.
So basically, you're asking a lot for a device that uses a small wall
wart as power supply -- it's not a substitute for a signal processing
workstation but a device where you can test and deploy the algorithms
you develop on a PC comfortably.
Greetings,
Marcus
On 10.04.2014 12:27, Abouda Yassine wrote:
Thank you all for your responses.I tried to follow your
instructions and I did a lot of experiments to make the fm_receiver
work.I have come to some conclusions,the USRP E110 is really not
that powerful,I frankly say that I am disappointed.According to my
personal experiments the maximum sample rate for the fm_receiver
was 1M and I matched between the different blocks to get a clear
sound at the end.But,when I move the mouse the sound gets
interrupted until I stop moving and when I add an FFT sink it makes
it worse.So, I believe that I reached here the limits of the RAM
ressources I think,and this proves that the USRP E110 is not
powerful or maybe not dedicated for these applications(I am using
the BASIC RX and TX daughterboards).Plz do not hesitate to correct
me if I was misjudging the device because I am a newbie here !!
Yassine
2014-04-09 14:55 GMT+02:00 Robert McGwier rwmcgw...@gmail.com:
First 100k is insufficient sample rate from the E110. An FM
station has 150 kHz total swing (+/- 75 kHz) so the frequency
range of your E110 complex output is 100 kHz and is therefore
insufficient for the entire modulation. You then feed the 100k
sample per second signal into the FM block where you have
informed it you will be sending 500 kHz (quadrature rate) and
then with no decimation at all, you send the 500 kHz sample
rate detected audio to a sound block where you've told it to
expect 96 kHz audio.
[image: \left [ 0.9 \left [ \frac{A+B}{2} + \frac{A-B}{2}\sin4\pi
f_pt \right ] + 0.1\sin2\pi f_pt \right ] \times
75~\mathrm{kHz}]
is the instantaneous frequency of an FM stereo broadcast signal
where A is the left channel, B is the right channel and fp is the
pilot tone frequency (19 kHz).
Consider matching sample rates between these blocks as the
software defined radio equivalent of impedance matching between
analog circuits in one view of it.
Bob
On Wed, Apr 9, 2014 at 7:40 AM, Mike Jameson m...@scanoo.com
wrote:
Here are some pointers for you:
- Firstly, your screenshot shows the error message saying that
the RX frequency is not valid. I'd recommend using a WBX
daughterboard, however the BasicRX should still work with
strong FM signals with aliasing if that is what you are using.
- The samp_rate is set to 100e3. It should be the master clock
rate of the e110 divided by an even number such as 64e6/256
(250e3). - The quadrature rate in the WBFM receive block should
be set to samp_rate (250e3) and the Audio decimation should be
set to 5. - The audio sink sample rate should be set to
samp_rate/audio_decim (250e3/5=50e3). 50e3 is as close to the
wanted audio sample rate of 48e3 that you are going to get
without using one of the resampler blocks.
Mike
-- Mike Jameson M0MIK BSc MIET Email: m...@scanoo.com Web:
http://scanoo.com
-- Forwarded message -- From: Abouda Yassine
abouda21yass...@gmail.com Date: Wed, Apr 9, 2014 at 12:09 PM
Subject: Re: [Discuss-gnuradio] Problem with getting clear FM
signals using the usrp e110 To: Mike Jameson m...@scanoo.com
hi Mike,
thx for offering help.I enclosed both a picture of the fm
receiver and the grc file(because i'm using the embedded
gnuradio version on the usrpe 110),so it might not open
correctly to you.I will be waiting for your answer.
2014-04-09 11:47 GMT+02:00 Mike Jameson m...@scanoo.com:
Abouda,
If you attach your GRC file to your reply I'll take a look at
it for you. It sounds like a sample rate mis-match going on
somewhere.
Mike
-- Mike Jameson
Re: [Discuss-gnuradio] GNURadio runtime not found? (Ubuntu 14.04)
On Thursday, April 10, 2014, Ron Economos w...@comcast.net wrote: gnuradio-runtime definitely exists in GR 3.7. Nathan was probably thinking about gnuradio-core, which has been deprecated. Agh! Yes, apparently I need more more sleep. Apologies for the misinformation , Jordan. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Problem with getting clear FM signals using the usrp e110
On 04/10/2014 06:27 AM, Abouda Yassine wrote:
Thank you all for your responses.I tried to follow your instructions
and I did a lot of experiments to make the fm_receiver work.I have
come to some conclusions,the USRP E110 is really not that powerful,I
frankly say that I am disappointed.According to my personal
experiments the maximum sample rate for the fm_receiver was 1M and I
matched between the different blocks to get a clear sound at the
end.But,when I move the mouse the sound gets interrupted until I stop
moving and when I add an FFT sink it makes it worse.So, I believe that
I reached here the limits of the RAM ressources I think,and this
proves that the USRP E110 is not powerful or maybe not dedicated for
these applications(I am using the BASIC RX and TX daughterboards).Plz
do not hesitate to correct me if I was misjudging the device because I
am a newbie here !!
Yassine
The E1xx series are NOT a PC in a wierd box.
They're embedded platforms for embedded applications involving SDR.
The on-board CPU isn't in the same league as most desktop multi-core
processors, and even though it runs an embedded Linux, it's not just
a tiny desktop machine. The intended use for these platforms has always
been that heavy-lifting signal processing would happen on the FPGA,
so most users of this platform are adept at implementing algorithms on
the FPGA, with the CPU largely acting in a supervisory role.
Now, it turns out that there are some applications where most of the
signal processing will fit on the embedded CPU. There are ports,
for example, of OpenBTS to the E1xx series.
But asking it to do signal processing *and* GUI user-interface work at
the same time is asking a *lot* of that single-core ARM CPU.
2014-04-09 14:55 GMT+02:00 Robert McGwier rwmcgw...@gmail.com
mailto:rwmcgw...@gmail.com:
First 100k is insufficient sample rate from the E110. An FM
station has 150 kHz total swing (+/- 75 kHz) so the frequency
range of your E110 complex output is 100 kHz and is therefore
insufficient for the entire modulation. You then feed the 100k
sample per second signal into the FM block where you have informed
it you will be sending 500 kHz (quadrature rate) and then with no
decimation at all, you send the 500 kHz sample rate detected
audio to a sound block where you've told it to expect 96 kHz audio.
\left [ 0.9 \left [ \frac{A+B}{2} + \frac{A-B}{2}\sin4\pi f_pt
\right ] + 0.1\sin2\pi f_pt \right ] \times 75~\mathrm{kHz}
is the instantaneous frequency of an FM stereo broadcast signal
where A is the left channel, B is the right channel and fp is the
pilot tone frequency (19 kHz).
Consider matching sample rates between these blocks as the
software defined radio equivalent of impedance matching between
analog circuits in one view of it.
Bob
On Wed, Apr 9, 2014 at 7:40 AM, Mike Jameson m...@scanoo.com
mailto:m...@scanoo.com wrote:
Here are some pointers for you:
- Firstly, your screenshot shows the error message saying that
the RX frequency is not valid. I'd recommend using a WBX
daughterboard, however the BasicRX should still work with
strong FM signals with aliasing if that is what you are using.
- The samp_rate is set to 100e3. It should be the master
clock rate of the e110 divided by an even number such as
64e6/256 (250e3).
- The quadrature rate in the WBFM receive block should be set
to samp_rate (250e3) and the Audio decimation should be set to 5.
- The audio sink sample rate should be set to
samp_rate/audio_decim (250e3/5=50e3). 50e3 is as close to the
wanted audio sample rate of 48e3 that you are going to get
without using one of the resampler blocks.
Mike
--
Mike Jameson M0MIK BSc MIET
Email: m...@scanoo.com mailto:m...@scanoo.com
Web: http://scanoo.com
-- Forwarded message --
From: *Abouda Yassine* abouda21yass...@gmail.com
mailto:abouda21yass...@gmail.com
Date: Wed, Apr 9, 2014 at 12:09 PM
Subject: Re: [Discuss-gnuradio] Problem with getting clear FM
signals using the usrp e110
To: Mike Jameson m...@scanoo.com mailto:m...@scanoo.com
hi Mike,
thx for offering help.I enclosed both a picture of the fm
receiver and the grc file(because i'm using the embedded
gnuradio version on the usrpe 110),so it might not open
correctly to you.I will be waiting for your answer.
2014-04-09 11:47 GMT+02:00 Mike Jameson m...@scanoo.com
mailto:m...@scanoo.com:
Abouda,
If you attach your GRC file to your reply I'll take a look
at it for you. It sounds like a sample rate mis-match
going on somewhere.
Mike
--
Mike Jameson M0MIK BSc
Re: [Discuss-gnuradio] Mixing two signals for Radar application.
Thank you Marcus and the others for your inputs, I created the flow almost from scratch taking into consideration your words and I came up to this aspect. Here they are: http://imageshack.com/a/img855/7555/7qcr.png(flow) http://imageshack.com/a/img542/9189/5jxl.png (FFT output) I added delays to simulate targets. I didn't manage to see any Doppler shit this time either. What am I doing wrong? Thank you for your time. Dimitris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GnuRadio / Ettus Consultants?
I hope this isn't bad form for the lists, but this skill set is proving difficult to find through other channels. Is there a good place to find people with GnuRadio / UHD / Ettus hardware experience? And if you are available for consulting, please contact me! I'm looking for multiple persons with a full range of experience, from anyone who knows how to write a (shell of a) custom block (Seriously. Hello students and hobbyists!), to persons able to write custom Verilog for the E100 platform. Thanks! --Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Denver Area Meetup?
Is anyone doing a GnuRadio / SDR meetup in the Denver Area? If not, is anyone in the area interested? First beer is on me. :-) --Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Installing UHD and GR373 on Mint13
On Wed, Apr 9, 2014 at 3:42 PM, Robert Light robert.li...@gmx.de wrote: Hi, I am trying to install UHD and GR373 on Linux Mint13. I follow http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNURadio_Linux When I run: sudo apt-get install -t precise uhd I get an error: uhd : Depends: libboost-all-dev but it is not going to be installed apt-cache policy libboost-all-dev libboost-all-dev: Installed: (none) Candidate: 1.48.0.2 Version table: 1.48.0.2 0 500 http://archive.ubuntu.com/ubuntu/ precise/universe amd64 Packages apt-cache policy libboost-dev libboost-dev: Installed: (none) Candidate: 1.48.0.2 Version table: 1.48.0.2 0 500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages sudo apt-get install libboost-dev libboost-dev : Depends: libboost1.46-dev but it is not going to be installed So now it is a problem, as gnuradio373 will disable components as libboost1.46 is known as bad. And why libboost1.48-dev depends on libboost1.46-dev It looks like Mint 13 has libboost1.48, which is ok. But I cannot install libboost-all-dev and then cannot install UHD. How to solve the problem ? Linux Edge 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Sorry, Robert, this sounds like something to do with your setup and possibly Mint that would be really hard for us to debug externally. My one suggestion is to try and use PyBOMBS to install GNU Radio: http://gnuradio.org/redmine/projects/pybombs/wiki With luck, it will just install its own version of Boost at version 1.53, but I'm afraid your OS might be in a state with various versions of Boost that could confuse the PyBOMBS build system. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re the spectrum estimation toolbox
On 04/10/2014 05:54 PM, Martin Braun wrote: Not sure here, but I know guys at CEL have been working to update the toolbox to 3.7, maybe that'll fix it. When this gets updated to 3.7, it's a good candidate for including on the GNU Radio DVD. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] New GRC behavior request for comment
In my latest push to the master branch, I've added a feature update from Sebastian Koslowksi for GRC. Previously, every change to an edit box in a GRC Properties box would cause GRC to reevaluate the entire application to tell you if your entry was right or wrong. If wrong, it would show up immediately in red and turn black when it was correct. This seems fine, but I've run into two major issues with that behavior. First, certain changes would cause errors that would change the focus in the dialog box. So you would then have to re-click the edit box to enter what you wanted to in the first place. The second problem was that you could find yourself in the midst of typing a Python function, like, say, editing a filter definition, that would incur a huge calculation only because you weren't finished typing. GRC immediately tries to run the calculation and causes everything to freeze. Both very annoying when they happen to you. Sebastian's tweak is to change from on-change to remove-focus. Basically, now, when you edit a field, the field label turns blue to indicate a change, but it doesn't try to run anything until you've removed the focus by tabbing to or clicking on another box in the properties list. It then evaluates it and produces any error messages. I personally like this new method a lot. The downside is that if you aren't paying attention, you might enter the wrong thing and hit ok or enter only to find out then that you made an error and will have to reopen the properties box to fix it. I see the upside to this behavior as beneficial to this downside. But I think that Sebastian and I would appreciate thoughts on this or alternative ways to handle things. Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New GRC behavior request for comment
On Thu, Apr 10, 2014 at 03:55:53PM -0400, Tom Rondeau wrote: I personally like this new method a lot. I like the sound of it. Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New GRC behavior request for comment
On 4/10/14 3:55 PM, Tom Rondeau wrote: I personally like this new method a lot. The downside is that if you aren't paying attention, you might enter the wrong thing and hit ok or enter only to find out then that you made an error and will have to reopen the properties box to fix it. In general, I like it too, but I see your point about not paying attention, as I'm a hunt n peck two-finger typist, and am often looking down at the keyboard instead of at the screen. How hard would it be to pop up a bother box if you attempt to enter with outstanding parameter error(s). Give you a chance to confirm or cancel the enter, because you may want to deliberately enter something that's wrong now but will be fixed later (for instance a variable name that you haven't created yet). @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Swig error with add_item_tag
On Wed, Apr 09, 2014 at 12:34:59PM -0600, Jay Radcliffe wrote: jay@ironfist:~/tpms-master/src$ ../src/extract_bursts.py ~jay/ping_903.020m_0.400m_20140403_00z_rtlsdr.cfile 19.6 T: -256, 0 handler caught exception: Wrong number or type of arguments for overloaded function 'block_gateway_sptr_block__add_item_tag'. Short answer: It's a bug in TPMS's extract_bursts.py. Try this diff: - block_abs = numpy.abs(block_spectrum) + block_abs = numpy.abs(block_spectrum[2:-1]) Long answer: There are two problems, and the change above is a workaround for both. The first problem is that the burst detection algorithm fails on your particular capture file because the DC offset in your file is high. So instead of detecting six separate bursts within your file, it detects one long burst consisting of the entire file. The change above causes the algorithm to completely ignore narrow signals (narrower than 3/256 of your capture bandwidth) centered at 0 Hz. I'm going to suggest this change to Jared because DC offset is a very common defect in SDR captures. However, it is a trade-off. In cases where a capture file does not suffer from DC offset, this change could cause the algorithm to overlook narrow, well-centered signals. The second problem is that there is a bug that causes a negative number to be passed as an argument that is supposed to be an unsigned integer. I think this only happens when a burst is detected right at the start of the input file, so the above change avoids the problem. It's just a workaround, not a bug fix. Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New GRC behavior request for comment
On 04/10/2014 04:13 PM, Ed Criscuolo wrote: How hard would it be to pop up a bother box if you attempt to enter with outstanding parameter error(s). Give you a chance to confirm or cancel the enter, because you may want to deliberately enter something that's wrong now but will be fixed later (for instance a variable name that you haven't created yet). I certainly like the evaluate when you leave the box paradigm, but I'm also the kind of developer who will enter a variable name, etc, that hasn't actually been created yet. -- 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] Swig error with add_item_tag
Much appreciated. Jared and I caught the negative number last night. It then did exactly what you described, finding one huge burst. I am working with him on some of the fsk demod tools he is working on. As far as your other message: I would love to take your course. I know you are giving it at Black Hat, but I am also teaching a class those four days there. Are there any other times you are giving it? One of the frustrations I am having is there is very little out there on demodulation. You can find lots of stuff on finding signals and identifying them. That part I have a decent grip on. post-demodulation I fail at. Much of it is I know what I need to do, but don't know how to make the blocks/write the code to do it. How much of your course focuses on the demodulation side of things? My fear is that 80% of the courses are on the parts I am comfortable with. My co-worker (Don Weber) took the course, and he is just as lost as I am on this. Thanks, Jay Jay Radcliffe Twitter: @jradcliffe02 E-Mail: jay.radcli...@gmail.com LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02 On Thu, Apr 10, 2014 at 4:50 PM, Michael Ossmann m...@ossmann.com wrote: On Wed, Apr 09, 2014 at 12:34:59PM -0600, Jay Radcliffe wrote: jay@ironfist:~/tpms-master/src$ ../src/extract_bursts.py ~jay/ping_903.020m_0.400m_20140403_00z_rtlsdr.cfile 19.6 T: -256, 0 handler caught exception: Wrong number or type of arguments for overloaded function 'block_gateway_sptr_block__add_item_tag'. Short answer: It's a bug in TPMS's extract_bursts.py. Try this diff: - block_abs = numpy.abs(block_spectrum) + block_abs = numpy.abs(block_spectrum[2:-1]) Long answer: There are two problems, and the change above is a workaround for both. The first problem is that the burst detection algorithm fails on your particular capture file because the DC offset in your file is high. So instead of detecting six separate bursts within your file, it detects one long burst consisting of the entire file. The change above causes the algorithm to completely ignore narrow signals (narrower than 3/256 of your capture bandwidth) centered at 0 Hz. I'm going to suggest this change to Jared because DC offset is a very common defect in SDR captures. However, it is a trade-off. In cases where a capture file does not suffer from DC offset, this change could cause the algorithm to overlook narrow, well-centered signals. The second problem is that there is a bug that causes a negative number to be passed as an argument that is supposed to be an unsigned integer. I think this only happens when a burst is detected right at the start of the input file, so the above change avoids the problem. It's just a workaround, not a bug fix. Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New GRC behavior request for comment
I think this change might be breaking a few things. If anyone else can check, please let me know if I'm nuts: I am running v3.7.4git-95-g24191d86 on Ubuntu 13.10 x64. In GRC, when I try to change the type associated with a block via the select box, it changes (and the text turns blue), but when I close the parameter window, nothing actually changes. I also saw similar behavior with combo boxes. In that case, selecting an option did not take, but overwriting it did. Very Respectfully, Dan CaJacob On Thu, Apr 10, 2014 at 7:00 PM, Marcus D. Leech mle...@ripnet.com wrote: On 04/10/2014 04:13 PM, Ed Criscuolo wrote: How hard would it be to pop up a bother box if you attempt to enter with outstanding parameter error(s). Give you a chance to confirm or cancel the enter, because you may want to deliberately enter something that's wrong now but will be fixed later (for instance a variable name that you haven't created yet). I certainly like the evaluate when you leave the box paradigm, but I'm also the kind of developer who will enter a variable name, etc, that hasn't actually been created yet. -- 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ASK demodulation help
I tried using the MM clock recovery block as suggested and I have a little fidelity problem. I added two screenshot links below which show the problem. I would say 70% of the time the recovered data is fine but for some reason it's sometimes badly distorted. By looking at it, the input signal looks always about the same. Is there something obviously wrong in what I'm doing? ASK demodulation GRC https://drive.google.com/file/d/0B_ApAHfP4naZaE5WRUJHWUtHUEU/edit?usp=sharing Signal in and out of Clock recovery block https://drive.google.com/file/d/0B_ApAHfP4naZY3Ryblp3cFlrdGs/edit?usp=sharing On Wed, Apr 9, 2014 at 5:27 PM, John Malsbury john.malsb...@ettus.comwrote: I don't know if I would call it overkill. It is just one of several methods you can use to achieve synchronization. Other options for synchronization include correlate and sync (probably needs modification), or possible the polyphase resync. Others on the list would have more expertise on these blocks. In my experience 10 samples per symbol seems to work well with MM. I've heard very high samp/sym (ie. 20) can cause problems, but I haven't seen this myself. The amplitude going into MM should be as close as possible to +/- 1.0, which is why you want the scaling functions before this block. The AGC block assures you're working with something constant amplitude for demodulation. -John On Wed, Apr 9, 2014 at 2:04 PM, Francois Gervais francoisgerv...@gmail.com wrote: Thanks guys for the information, I looked a little about the MM recovery block but it seemed to me like and advance algorithm, overkill for what I'm trying to achieve. I'm I mistaken? If I'm using the MM clock recovery block what is the quality of input signal I should aim to avoid translation errors? Should my signal be filtered with a really narrow band and should I allow more harmonics in to the signal is more square? Can the input signal have too much sample per bit? Right now I'm at 16. Is more better? Is it better to have more amplitude? Thanks On Wed, Apr 9, 2014 at 4:31 PM, John Malsbury john.malsb...@ettus.comwrote: Depending on various factors the implementation may vary, but you could probably start with a chain that looks something like this: I/q source - filter - AGC - AM demod (complex to mag) - scaling for am depth - mm clock recovery - slicer - do something with the data Other, more advanced implementations might use correlation for synchronization. -John On Wed, Apr 9, 2014 at 1:27 PM, Francois Gervais francoisgerv...@gmail.com wrote: Hi, I'm new to gnu radio and I'm trying to demodulate a 125kpbs ASK signal from a device I have, as a first project. I'm using RTL-SDR as the input device. I'm slowly getting there. I receive the signal, at 2Msample/s, I low-pass filter it to 300khz, I send it through the AM demodulation block and then through the DC blocker. From there I have my signal and it looks fine i.e I could retrieve the information manually by looking at it. Now I think the goal is to somehow synchronize with the bits and re-sample to get 1 sample per bit. This could then be sent to a file. Is that it? At first glance I'm thinking I should have a PLL which ouputs a clock at about 250khz (twice the bit rate) and synchronize the rising edge with every bit transitioning from 0 to 1 so unless I receive only ones ou zeros I should be quite in sync. Then I could toggle a sample every falling edge of the clock which should be at about the middle of the bit. Is this a viable solution? Can it be done with gnuradio? Other alternatives? Thanks ___ 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
