GNU Radio, One Step at a Time: May 2016

Tuesday, May 31, 2016

Re: [Discuss-gnuradio] Wideband Random Noise Cypherpunk Guerrilla Radio - Doc Req

On 5/29/16, Marcus Müller <marcus.mueller@ettus.com> wrote:
> If you spread it extremely wide and basically put the power level

Probably more like this than in your first larger paragraph.

Perhaps crafting arbitrarily fine random vertical divisions of a
spectrum into a very wide line of numerous bit positions, such lines
being known only to peers. To which they may apply essentially gain
hits ("power"), perhaps in parallel, to carry data. Looks like
random background noise to outside observers.

DRBG... I don't remember where this part came from, but the RF
spectra utilized, or [subset] within which data is hidden... may
itself be selected / generated / driven by a DRBG, for which shared
seeds and timing are needed to do at least the initial training
(subsequent rekeying of the RF noise could be done pursuant to
instructions, human or automatic, within the datastream).

Peers need not have elite hardware, lower cost yields lower achievable
datarate due to broader timing, less sensitivity, etc.

> what's up with the funny subject line? What's
> Cypherpunk Guerilla about any of this?

The paper I recall reading had a somewhat pirate / cypherpunk /
guerrilla / resistance / activist / journalist / military / "illegal"
communications tone / community / proposition to it... or at least
listed those as among the most likely uses.

More narrowly, upon hearing that both the RF, and data inside, are
encrypted, and that these novel noise systems are hard to find,
hard to shutdown, etc... various types of users in the US and
elsewhere, typically hams, concern themselves with legalities.
Though that side discussion is relavant, the users of these systems
are generally already aware of and obviously not concerned with
such things.

The paper may have even been posted here, but without an unaltered
raw copy of the list archives in mbox format available for download
for people to then load into local MUA's, it's really hard to search
for such text, links, and attachments. Such an archive would be
highly appreciated and useful :)

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How do I modify the xml files in the x310?

On 05/28/2016 02:27 PM, Swanson, Craig wrote:
> Marcus,
>
> Since I started about a year ago with understanding and using RFNoC, I
> have been only using the E310.
>
> Now I am starting to use the X310, and I have three questions.
>
>
> 1. I successfully executed the command
> uhd_image_loader --args="type=x300,addr=192.168.10.2"
> --fpga-path="~/uhd/fpga-src/usrp3/top/x300/build/usrp_x310_rfnoc_fpga_HGS.bit".
> But when I execute uhd_usrp_probe --args="addr=192.168.10.2"
> --init-only I get a segmentation fault. That is because I changed
> the NOC_ID. How do I update the X310 with my latest .xml files? I
> am assuming I need to copy over the .xml files to the X310 from my
> Home/gr-ettus/grc directory.

You don't need to copy anything to the device other than the bitfile.
Just edit the file locally and reinstall.

> 2.
> When I start using the JTAG Chipscope Xilinx USB cable, I am
> assuming I have to make sure my /lib/udev/rules.d/40-uhd-host.rules
> has a line for the X310. Where do I get this information?

Use the .rules file shipped with UHD (it's in utils/).

> 3.
> When executing a flowgraph, is the X310 more like the E310 or the
> B210? In other words, do I need to have a Device3 with a Device
> Address: type=x300? That is like the E310. For the usrp source and
> sink, do I need to have a Device Address with the ethernet address?

You need a device3 block with type=x300, yes. In that case, you won't
use a USRP source/sink.

>
> Is there a location in the user's manual that addresses these questions
> for the X310?

There's a couple of examples in gr-ettus.

>
> Thanks,
> Craig
>
> *Craig F. Swanson*
> */Research Engineer II
> /*
> */Information and Communications Laboratory/*
> */Communications, Systems, and Spectrum Division/*
> /Georgia Tech Research Institute/
> /Room 560
> 250 14th St NW
> /
> /Atlanta, GA 30318/
> /Cell: 770.298.9156/
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Build installation on Ubuntu

Mark,

what, exactly, is you are trying to do?
Here's a couple of commands that I would expect do what you're asking:

$ pybombs install <package>
$ pybombs remove <package>
$ pybombs inv

All have the --help switch you can append.

M

On 05/29/2016 08:12 PM, Mark Napier wrote:
> So tried cleaning yet again, reinstalling recipes, and running init
> again. This time it finished. Everything is working out of a sandbox.
>
> This is like macports: a monumental labor of love by many talented
> programmers. I'm sure it will get more stable with time.
>
> Would still very much like to know how to make the other commands in
> pybombs work: the OOT modules and managing the ones already installed.
>
> Cheers,
>
> Mark Napier
>
>
> On Sun, May 29, 2016 at 10:24 AM, Mark Napier <napierdmark@gmail.com
> <mailto:napierdmark@gmail.com>> wrote:
>
> Hello the camp,
>
> I'm struggling with an installation on Ubuntu 16.04. Note that
> apt-get does install a working GNUradio stack and UHD works with a
> USRP2. However, my goal is to install a build environment.
>
> For my 1st effort I used git to clone the uhd driver directory and
> was able to get a clean build from the source and the make test all
> worked correctly. After make install uhd_usrp_probe finds the
> USRP2. However, on connecting a GRC uhd source to waterfall sink
> the run fails. The problem is that the UHD driver is newer than the
> apt-get installation of gnuradio so the two are incompatible. Also,
> the gnuradio install doesn't seem to have the source for a build
> environment either.
>
> So next effort is to try to use pybombs to install into a prefix
> directory. Having all the source and being able to modify it and
> run in a local sandbox is exactly what I'm after. Used apt-get to
> remove uhd and gnuradio. But I'm finding pybombs difficult to use.
>
> After a few emails from Martin at Ettus and a great deal of
> tinkering with permissions I can do the following:
>
> $ pybombs recipes add gr-recipes
> git+https://github.com/gnuradio/gr-recipes.git
> $ pybombs recipes add gr-etcetera
> git+https://github.com/gnuradio/gr-etcetera.git
> $ pybombs prefix init ~/gnuradio/src/prefix -R gnuradio-default
>
> This will init my prefix directory and start the installation and
> compile of a sandbox. However, it doesn't finish. It get to
> bladeRF and aborts with "Unable to fetch recipe bladeRF". Whats
> *much* more frustrating is that I can't get any other form of a
> pybombs command line to run and give me information about the prefix
> install. I just get the "usage" statement. And the init won't run
> after the first time, I get a:
>
> PyBombs.prefix - ERROR - Ignoring. A prefix already exists in
> `/home/napierm/gnuradio/src/prefix'
>
> So if I run:
>
> rm -rf gnuradio/src/prefix/*
> rm -rf gnuradio/src/prefix/.*
>
> Then I can start over. PyBOMBS is supposed to be able to show what
> is installed and manage/add modules. Any ideas what to try next?
>
> Thank you very much in advance,
>
> Mark Napier
>
>
>
>
> _______________________________________________
> 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] Meetup May 31st in Blacksburg, VA

Hi all -

The GNU Radio meetup at Philip's has kicked off - come join us if you are in the Blacksburg area!

Cheers,
Ben

Sent from my mobile.

On May 23, 2016 4:55 PM, "Ben Hilburn" <bhilburn@gnuradio.org> wrote:

Hi all -

Next Tuesday, May 31st, Philip Balister will host a GNU Radio meetup at his house in conjunction with the Wireless @ VT Symposium, which also takes place next week. Come join us for beer, food, and great company.

Because it is hosted at his house, we will not be sending the location out publicly. If you are interested in attending, please RSVP directly to Philip (CC'd on this e-mail), and he will send you directions.

We hope to see you there!

http://gnuradio.org/events/meetup-at-wvt-2016/

Cheers,
Ben

[Discuss-gnuradio] GNURadio autmatic gain adjustment

Hi,

In my GNURadio program I need to determine the correct gain in order to
fully utilize the dynamic range of the A/D converter of the Ettus USRP x310.
I currently have implemented a automatic function for this using the
probe samples block and make sure that values stays just within -1 > +1.
I.e I check the distribution and make sure a certain percentage of the
values doesnt go above a threshold value.
However the values seems to have a dependence on sample rates, how
should I think here? Anyone else that have implemented this using the
probe block, what was your method?

Best regards
Simon

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FSK modulation/demodulation for Universal Access Transceiver

Could someone explain me how should I design my receiver ?

I don't know nothing about clock recovery or pulse shaping. I've used an oscilloscope in the time domain to look at my Tx side and I can clearly see the FSK modulation. But when I look on Rx side with QT GUI sink, the signal is somehow deformed.

I don't want you to do the work for me but, i'd like to know precisely what is missing in my flowgraph.

Thanks you and have a nice day!

2016-05-26 15:05 GMT-04:00 Marcus Müller <marcus.mueller@ettus.com>:

Hi Olivier,

thanks for the reply! Ah, I was confusing UAT and ADS-B then, sorry!

You should really be sending this email to the discuss-gnuradio@gnu.org list - with the graphs attached, it's much easier for the others to help!
Just a question: the time_dom.png indeed looks like there's something wrong. Is the upper signal display TX, the lower display RX? In that case, make sure you have proper pulse shaping enabled. This looks like you have samples_per_symbol=1. Also, yes, it's a good idea not to drive frontends with their maximum amplitude, but that can easily remedied with a multiply_const block with e.g. 0.7.

Best regards,
Marcus

PS: Amazing project!
On 26.05.2016 18:32, Olivier Goyette wrote:
Thank you for your reply.

I'm aware of gr-air-modes but the thing is that UAT and ADS-B are not working on the same medium. UAT is using 978 MHz carrier and ADS-B is using 1090 MHz. ADS-B messages for UAT are not using the same message format so, i'll need to interpret them using another format, that's why i'm starting from zero.

Concerning RX and TX for time and frequency domain, by looking at the time domain at TX, there seem to be clipping?? How do I fix it ? I've tried to play with the gain but it doesn't seem to be working..
2016-05-26 11:59 GMT-04:00 Marcus Müller <marcus.mueller@ettus.com>:
Hi Olivier!

Nice to meet you.
So, first off, a hint: GRC has a "screen capture" menu / toolbar button that lets you just export your GRC canvas, so you don't have to make a screenshot of your whole dual-desktop screen (by the way, cropping that would have worked, too ;) ).

UAT == ADS-B transmitter, right? Have you seen [1], and are you aware of Nick Foster's gr-air-modes, an ADS-B receiver?

So, we'd love to help you, but "only gibberish" is hardly a good error description. Does the RX signal in time domain look OK, or is there very little amplitude, or values close to 1, indicating clipping? What about frequency domain, does the RX signal resemble the TX signal?

Then: UHD specifically tells you there is something wrong with how you've configured things. You will need to fix that first.

Best regards,
Marcus

[1] https://www.youtube.com/watch?v=NSLqRXyxiBo

On 26.05.2016 17:03, Olivier Goyette wrote:
Hi everyone,

I'm currently doing an internship at school and i'm working with USRP N210 and GNUradio. It's been a month since I began working with these 2 tools, so excuse me if I may sound noob, but I really need some help. I've been asked to start thinking about developing an UAT for civil aviation. I've read a ton of standards and papers concerning this new technology, so I won't relate it all over here, but the main thing about it is that it uses FSK mod/demod for the information to be transmitted and received.

I'm currently stuck on a problem that's been haunting me for the last 2 weeks and that's why i'm asking for your guidance. When I run the mod/demod on simulation(attached #1), everything works fine. I'm sending abcdefghijklmopqr and on the receiving side i got the same thing. Now the problem is that when i'm trying to send it via the USRP with a cable between RX and TX(attached #2), i only get gibberish on the receiving side !

What have I done wrong ? I don't get why it's not working.

Thank you for your time, your help will be more than welcome

Olivier
_______________________________________________  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] Example CMakeLists for dial_tone.cc

On 28/05/2016 23:35, Louis Brown wrote:
> Does anyone have an example CMakeLists.txt to build something very simple like dial_tone.cc? I DON'T want to do this in the GR source tree, rather just have simple ~/dial_tone containing the single *.cc and CmakeLists.txt. I have learned enough c++ now to work through the guided tutorials, but the build environment is still somewhat overwhelming, so I want to start basic and work my way up.

Well, its not a CMakeLists.txt, but:

g++ -o dial_tone dial_tone.cc -lgnuradio-audio -lgnuradio-analog -lgnuradio-runtime -lboost_system-mt

--
Red to red, black to black, switch it on, but stand well back.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Decode Frequency Modulated Signal

Hello Franz, hello Marcus, hello list!

Thanks for your answers!

Yes, Marcus, after decoding the signal with quadrature demod the "long
period" is a 1 and the "short period" is a 0. (Although it is not really
a period. More like period/2.) Maybe you are right with your assumption
that this is just a FSK within a FSK.

You can find the GRC flowgraph I used to extract the waveform from the
last mail in the appended image. The signal was recorded with a 4MHz
sample rate at a frequency around 170MHz. I also know that the baudrate
of this signal is 2400.

I will try to make the double FSK setup to work. Whether is using
quadrature demod, WBFM demod, or something like this. However, if there
is any best practice on how to decode a signal like this, I'm happy if
you tell me how. ;)

Best regards
Gerhard

On 05/29/2016 10:24 AM, Franz Dworschak wrote:
> Hi Gerhard,
>
> I see no demodulation in your pictures, it seems you just filtered the
> signal. I would need some background information.
> What is the sample rate and the input signal frequency. If the sample
> rate is much higher, just measure the pulse length by measuring the
> amplitude and use a comparator.
> Or you can use the WBFM demodulator or you place your frequency band on
> the edge of a filter for demodulation.
> There are many possibilites, so I would need more information.
>
> Regards
> Franz
>
> Am 28.05.2016 um 21:21 schrieb Gerhard:
>> Hello!
>>
>> I want to decode a signal that slightly varies in Frequency. Therefore I
>> used "Quadrature Demod" block. After this, its waveform looks like the
>> appended image "baudline-waveform.jpg". Although it's a bit fuzzy I
>> already can decode it with my eyes. Have a look at the appended picture
>> "decoded-signal.jpg".
>>
>> My Questions:
>> * How do I decode the signal to ones and zeros?
>> * Is the signal O.K. the way I demodulated it, or is it to fuzzy?
>>
>> Any help is appreciated!
>>
>>
>> Cheers
>> Gerhard
>>
>>
>>
>>
>> _______________________________________________
>> 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] Testing 'noblock' Class

I created a noblock C++ class and asked for QA tests to be created. I see that the _qa files exist for both .h and .cc files. But, when I run 'make test' I only see the tests for the actual blocks (sync in this case). If I run ./lib/test-MyOTT then I see the output of my noblock test, but the assert() calls don't cause a failure. Am I doing something wrong?

Thank you!

-Dave

[Discuss-gnuradio] Gnu Radio Profiling Questions

Hello.

I built gnu radio using the cmake -DENABLE_PERFORMANCE_COUNTERS=True on Ubuntu 14.04.4 32-bit. I then did a 'sudo make install'.

When I run gr-ctrlport-monitor I get the following error:

e@ubuntu:~$ gr-ctrlport-monitor
Traceback (most recent call last):
File "/usr/local/bin/gr-ctrlport-monitor", line 28, in <module>
from gnuradio.ctrlport.GrDataPlotter import *
File "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GrDataPlotter.py", line 26, in <module>
from gnuradio.ctrlport.GNURadio import ControlPort
ImportError: No module named GNURadio

Is there a good Wiki page on setting up profiling?

Y-

Re: [Discuss-gnuradio] accumulate spectrum

Thanks a lot Lou and Marcus,

Lou -> I tried your spectrum.grc file with my data file instead of your

cosine + gaussian noise and it works. The "integrate" block is really the one I was looking for!

Now ideally I'd like to save only ONE spectrum instead of "animations" How to achieve this (e.g. I would save a spectrum integrated over 30s)?

Also I'd like to display the frequencies in the x axis and not the time in (ms) as you did.

Maybe I can write my own python scripts to plot the data. I tried to use the scripts in gr-utils such as plot_data but I don't know exactly how to use it (the options...), would you have an example?

Marcus -> Thanks for your explanations for the sample rates

Many thanks again for your great help!

Adellain

Re: [Discuss-gnuradio] accumulate spectrum

Never mind, ignore that. Still seems to be working strangely.

madengr wrote
> So if I swap positions of the "throttle" and "vector to stream", and
> setting throttle for rate of 30 and 1024 items, then it works fine. It
> seems the throttle has to be immediately after the file source, otherwise
> it gets fouled up.
> Lou
>

--
View this message in context: http://gnuradio.4.n7.nabble.com/accumulate-spectrum-tp60256p60276.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] FSK transmitter and receiver

Hi all !

I've been lately trying to develop an FSK transmitter and receiver following the instructions on this site : https://nccgroup.github.io/RFTM/

1st of all, I receive the following runtimeerror when I insert the "Clock Recovery MM" block and I don't know why?? :

Using Volk machine: avx_64_mmx_orc
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Traceback (most recent call last):
File "/home/lassena/Documents/top_block.py", line 204, in <module>
    main()
File "/home/lassena/Documents/top_block.py", line 198, in main
    tb = top_block_cls()
File "/home/lassena/Documents/top_block.py", line 128, in __init__
    self.digital_clock_recovery_mm_xx_0 = digital.clock_recovery_mm_ff(0.06, 0.01, 0, 0.1, 0.01)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/digital/digital_swig.py", line 1209, in make
    return _digital_swig.clock_recovery_mm_ff_make(*args, **kwargs)
RuntimeError: clock rate must be > 0

>>> Done (return code -9)

2nd of all, I followed each step correctly for the receiver side given on the website I mentioned earlier using my parameters, but I can't seem to get the same output when I visualize the data using Baudline. This is done when I plug the file sink just after the quadrature demod block. I actually got a cable between Tx and Rx for my test and I'm using USRP N210.

I left my grc file attached if you'd like to give it a try and help me with it. I would really appreciate it.

And again, thank you for your time and your help

Olivier

Re: [Discuss-gnuradio] accumulate spectrum

So if I swap positions of the "throttle" and "vector to stream", and setting
throttle for rate of 30 and 1024 items, then it works fine. It seems the
throttle has to be immediately after the file source, otherwise it gets
fouled up.
Lou

madengr wrote
> Try this:
>
> https://www.dropbox.com/s/7xsg4arx5h3gvah/spectrum.grc?dl=0
>
> The integrate with decimation is what you want. Starting at 32 ksps with
> a 1024 length FFT length yields 31.25 vector/sec. Then an integrate with
> decimation by 32 averages down to 0.98 vector/sec.
>
> However when I try reading those back from the file, I'm not getting the 1
> ksps I should be getting. I have to set that throttle at 8000 to get the
> proper update rate.
>
> Lou

--
View this message in context: http://gnuradio.4.n7.nabble.com/accumulate-spectrum-tp60256p60275.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

Re: [Discuss-gnuradio] accumulate spectrum

If you are working off a file source, then you should be able to use the
"head" block to limit the number of samples read from the file. For
example, if you want to average 32 spectrums of length 1024, then you need
32*1024 samples in the "head".

Sorry, no idea how to change the default time plot.

I have some example python code here that plots. Just read the file into a
numpy array, then matplotlib.

https://www.dropbox.com/s/qur7rbxl3cpktjr/wwvb.py?dl=0
https://www.dropbox.com/s/bs4bw2ue6hp5xq3/wwvb.grc?dl=0

Lou

Adellain TSIAHINA wrote
> Now ideally I'd like to save only ONE spectrum instead of "animations" How
> to achieve this (e.g. I would save a spectrum integrated over 30s)?
>
> Also I'd like to display the frequencies in the x axis and not the time in
> (ms) as you did.
>
> Maybe I can write my own python scripts to plot the data. I tried to use
> the scripts in gr-utils such as plot_data but I don't know exactly how to
> use it (the options...), would you have an example?

--
View this message in context: http://gnuradio.4.n7.nabble.com/accumulate-spectrum-tp60256p60274.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

Re: [Discuss-gnuradio] accumulate spectrum

But the throttle should roughly slow it down to a real-time rate. The top
half of my grc file updates about 1 spectrum/second via a throttle, and
writes those vectors to disk. If I read back the the file also through a
throttle, it should have about the same rate, but it's much slower. Note to
disable the top half when running the bottom half.
Lou

Marcus Müller-3 wrote
> Furthermore, and this also is something very often misunderstood, throttle
> doesn't do anything with the samples. Really! It only copies them from in-
> to output. Nothing changes. And just as you can't tell the difference
> between a file that was downloaded with a fast internet connection and the
> same file downloaded through the slowest connection on earth, the sample
> file doesn't contain any difference whether you've used throttle or not.
> GNU Radio works by trying to be the fastest signal processing "pipe"
> possible. Throttle is really just as if someone deliberately stepped on
> and of a hose just to regulate the average amount of stuff going through.

--
View this message in context: http://gnuradio.4.n7.nabble.com/accumulate-spectrum-tp60256p60273.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

Re: [Discuss-gnuradio] accumulate spectrum

Yes, but I have a throttle after that file source, so it should be updating
about 1 vector/second (each vector is 1024 samples). It's happening about
1/8 that speed, so something does not seem quite right.
Lou

Marcus D. Leech wrote
> Files don't have any inherent sample-rate. Regardless of what rate they
> were recorded at. Gnu Radio has no real "sense" of sample rate,
> and will process samples as fast as it can. The only place where
> sample rate is "real" with respect to actual real-time is at the "edges"
> when the "edges" are controlled by actual hardware with an actual
> real-time-relative sample-rate.

--
View this message in context: http://gnuradio.4.n7.nabble.com/accumulate-spectrum-tp60256p60270.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

Re: [Discuss-gnuradio] simple_ra and Ubuntu 16.04 LTS

On 31/05/16 07:40, Marcus Müller wrote:

That shouldn't be necessary. If I remember correctly, my automated test builds based on PyBOMBS go through without installing an old version of SWIG.
Hence, we'd be interested in where things fail on your machine with swig3.
Best regards,
Marcus
Am 31. Mai 2016 01:53:54 MESZ, schrieb John Shields <sla1nte2001@gmail.com>:
On 30/05/16 22:29, Marcus D. Leech wrote:
On 05/30/2016 06:27 PM, John Shields wrote:

oops, it was not simple_ra that I tried to re-compile against the new GNURadio etc., it was gr-ra_blocks.

Sorry,

John

Which is a pre-req for simple_ra
_______________________________________________  Discuss-gnuradio mailing list  Discuss-gnuradio@gnu.org  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio  
Thanks Marcus,
                        16.04 comes with swig 3.0 so I removed that and installed swig 2.0 and it seems to work.

                             Kind Regards,

                                   John
  Discuss-gnuradio mailing list  Discuss-gnuradio@gnu.org  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio  
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Marcus, Here is the full trace - again this was with gr-ra-blocks and swig 3.0. When, with your advice, I swapped it out for swig 2.0 , everything worked. Also, as mentioned in the previous e-mail, GNURadio (using your script) did work correctly even with swig 3.0 john@i7Ubuntu:~/gr-ra_blocks/trunk$ cmake . -- The CXX compiler identification is GNU 5.3.1 -- The C compiler identification is GNU 5.3.1 -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Build type not specified: defaulting to release. -- Boost version: 1.58.0 -- Found the following Boost libraries: -- filesystem -- system -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1") Checking for GNU Radio Module: RUNTIME * INCLUDES=/usr/local/include * LIBS=/usr/local/lib/libgnuradio-runtime.so;/usr/local/lib/libgnuradio-pmt.so GNURADIO_RUNTIME_FOUND = TRUE Checking for GNU Radio Module: BLOCKS * INCLUDES=/usr/local/include * LIBS=/usr/local/lib/libgnuradio-blocks.so;/usr/local/lib/libgnuradio-runtime.so;/usr/local/lib/libgnuradio-pmt.so GNURADIO_BLOCKS_FOUND = TRUE CMake Warning (dev) at /usr/local/lib/cmake/gnuradio/GrTest.cmake:45 (get_target_property): Policy CMP0026 is not set: Disallow use of the LOCATION target property. Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The LOCATION property should not be read from target "test-ra_blocks". Use the target name directly with add_custom_command, or use the generator expression $<TARGET_FILE>, as appropriate. Call Stack (most recent call first): lib/CMakeLists.txt:71 (GR_ADD_TEST) This warning is for project developers. Use -Wno-dev to suppress it. -- -- Checking for module SWIG -- Command "/usr/bin/swig2.0 -swiglib" failed with output: -- Found SWIG version 2.0.12. -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.11+") -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found suitable version "2.7.11+", minimum required is "2") -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11") -- Configuring done -- Generating done -- Build files have been written to: /home/john/gr-ra_blocks/trunk john@i7Ubuntu:~/gr-ra_blocks/trunk$ make Scanning dependencies of target gnuradio-ra_blocks [ 4%] Building CXX object lib/CMakeFiles/gnuradio-ra_blocks.dir/slicer_impl.cc.o [ 8%] Building CXX object lib/CMakeFiles/gnuradio-ra_blocks.dir/vector_power_impl.cc.o [ 12%] Building CXX object lib/CMakeFiles/gnuradio-ra_blocks.dir/synch_folder_impl.cc.o [ 16%] Building CXX object lib/CMakeFiles/gnuradio-ra_blocks.dir/synch_detect_impl.cc.o [ 20%] Building CXX object lib/CMakeFiles/gnuradio-ra_blocks.dir/synch_clock_impl.cc.o [ 24%] Linking CXX shared library libgnuradio-ra_blocks.so [ 24%] Built target gnuradio-ra_blocks Scanning dependencies of target test-ra_blocks [ 28%] Building CXX object lib/CMakeFiles/test-ra_blocks.dir/test_ra_blocks.cc.o [ 32%] Building CXX object lib/CMakeFiles/test-ra_blocks.dir/qa_ra_blocks.cc.o [ 36%] Linking CXX executable test-ra_blocks [ 36%] Built target test-ra_blocks Scanning dependencies of target ra_blocks_swig_swig_doc [ 36%] Built target ra_blocks_swig_swig_doc Scanning dependencies of target _ra_blocks_swig_swig_tag [ 40%] Building CXX object swig/CMakeFiles/_ra_blocks_swig_swig_tag.dir/_ra_blocks_swig_swig_tag.cpp.o [ 44%] Linking CXX executable _ra_blocks_swig_swig_tag [ 44%] Built target _ra_blocks_swig_swig_tag [ 48%] Generating ra_blocks_swig.tag Scanning dependencies of target ra_blocks_swig_swig_2d0df [ 52%] Building CXX object swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/ra_blocks_swig_swig_2d0df.cpp.o [ 56%] Linking CXX executable ra_blocks_swig_swig_2d0df Swig source /bin/sh: 1: /usr/bin/swig2.0: not found swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/build.make:134: recipe for target 'swig/ra_blocks_swig_swig_2d0df' failed make[2]: *** [swig/ra_blocks_swig_swig_2d0df] Error 127 make[2]: *** Deleting file 'swig/ra_blocks_swig_swig_2d0df' CMakeFiles/Makefile2:274: recipe for target 'swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/all' failed make[1]: *** [swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/all] Error 2 Makefile:138: recipe for target 'all' failed make: *** [all] Error 2 john@i7Ubuntu:~/gr-ra_blocks/trunk$

Re: [Discuss-gnuradio] simple_ra and Ubuntu 16.04 LTS

That shouldn't be necessary. If I remember correctly, my automated test builds based on PyBOMBS go through without installing an old version of SWIG.
Hence, we'd be interested in where things fail on your machine with swig3.
Best regards,
Marcus

Am 31. Mai 2016 01:53:54 MESZ, schrieb John Shields <sla1nte2001@gmail.com>:

On 30/05/16 22:29, Marcus D. Leech wrote:
On 05/30/2016 06:27 PM, John Shields wrote:

oops, it was not simple_ra that I tried to re-compile against the new GNURadio etc., it was gr-ra_blocks.

Sorry,

John

Which is a pre-req for simple_ra
_______________________________________________  Discuss-gnuradio mailing list  Discuss-gnuradio@gnu.org  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio  
Thanks Marcus,
                        16.04 comes with swig 3.0 so I removed that and installed swig 2.0 and it seems to work.

                             Kind Regards,

                                   John
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Discuss-gnuradio] accumulate spectrum

This cannot be stressed enough. What GNU Radio processes is nothing but series of numbers. Just like these numbers don't have a physical unit (lest you interpret them as physically significant), the don't have a rate.
Furthermore, and this also is something very often misunderstood, throttle doesn't do anything with the samples. Really! It only copies them from in- to output. Nothing changes. And just as you can't tell the difference between a file that was downloaded with a fast internet connection and the same file downloaded through the slowest connection on earth, the sample file doesn't contain any difference whether you've used throttle or not. GNU Radio works by trying to be the fastest signal processing "pipe" possible. Throttle is really just as if someone deliberately stepped on and of a hose just to regulate the average amount of stuff going through.

This principle, GNU Radio not caring/knowing about sampling rates or any other aspect that doesn't concern the mathematical nature of these samples, is really inherent to the way GNU Radio does DSP.

For example, take the Signal Source. You'd say "that block has a sample rate parameter, so it does something different depending in the rate!", but that would actually misunderstand the fact that the sample rate parameter is, together with the frequency parameter, only used to calculate how much of a full oscillation to advance /per sample/. For example, a Signal Source with
Sample rate=100e3
Signal frequency=25
Will produce an oscillation with a period of 400 samples. That's *identical* in every aspect to what the same source does with
Sample rate=40
Signal frequency=0.01

I hope that cleared things up a bit
Best regards
Marcus

Am 31. Mai 2016 04:37:12 MESZ, schrieb "Marcus D. Leech" <mleech@ripnet.com>:

On 05/30/2016 09:19 PM, madengr wrote:
Try this:

https://www.dropbox.com/s/7xsg4arx5h3gvah/spectrum.grc?dl=0

The integrate with decimation is what you want. Starting at 32 ksps with a
1024 length FFT length yields 31.25 vector/sec. Then an integrate with
decimation by 32 averages down to 0.98 vector/sec.

However when I try reading those back from the file, I'm not getting the 1
ksps I should be getting. I have to set that throttle at 8000 to get the
proper update rate.

Lou
Files don't have any inherent sample-rate. Regardless of what rate they
were recorded at. Gnu Radio has no real "sense" of sample rate,
and will process samples as fast as it can. The only place where
sample rate is "real" with respect to actual real-time is at the "edges"
when the "edges" are controlled by actual hardware with an actual
real-time-relative sample-rate.

If you read data from a file, Gnu Radio will vacuum it out just as fast
as it can.

Adellain TSIAHINA wrote
Dear All,

I'm new to Gnu Radio. I looked carefully to the doc and tutorials but
could
not find any simple answer to my problem.
I have a radio signal from which I'm able to visualize the FFT in GNU
Radio
Companion.
Now I would like to save the FFT (more exactly the magnitude squared, or
the spectrum) accumulated over a given period of time (the average over
time) into a file.

I found the following blocks in GRC that seem to be helpful:
- stream to vector
- FFT
- complex to mag
- file sink

However I did not manage to save any accumulated spectrum...

Any help (eg a woking example) would be very welcome!

Thanks in advance.

Adellain

Discuss-gnuradio mailing list
Discuss-gnuradio@
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

--
View this message in context: http://gnuradio.4.n7.nabble.com/accumulate-spectrum-tp60256p60265.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

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Monday, May 30, 2016

Re: [Discuss-gnuradio] accumulate spectrum

On 05/30/2016 09:19 PM, madengr wrote:
> Try this:
>
> https://www.dropbox.com/s/7xsg4arx5h3gvah/spectrum.grc?dl=0
>
> The integrate with decimation is what you want. Starting at 32 ksps with a
> 1024 length FFT length yields 31.25 vector/sec. Then an integrate with
> decimation by 32 averages down to 0.98 vector/sec.
>
> However when I try reading those back from the file, I'm not getting the 1
> ksps I should be getting. I have to set that throttle at 8000 to get the
> proper update rate.
>
> Lou
Files don't have any inherent sample-rate. Regardless of what rate they
were recorded at. Gnu Radio has no real "sense" of sample rate,
and will process samples as fast as it can. The only place where
sample rate is "real" with respect to actual real-time is at the "edges"
when the "edges" are controlled by actual hardware with an actual
real-time-relative sample-rate.

If you read data from a file, Gnu Radio will vacuum it out just as fast
as it can.

>
>
> Adellain TSIAHINA wrote
>> Dear All,
>>
>> I'm new to Gnu Radio. I looked carefully to the doc and tutorials but
>> could
>> not find any simple answer to my problem.
>> I have a radio signal from which I'm able to visualize the FFT in GNU
>> Radio
>> Companion.
>> Now I would like to save the FFT (more exactly the magnitude squared, or
>> the spectrum) accumulated over a given period of time (the average over
>> time) into a file.
>>
>> I found the following blocks in GRC that seem to be helpful:
>> - stream to vector
>> - FFT
>> - complex to mag
>> - file sink
>>
>> However I did not manage to save any accumulated spectrum...
>>
>> Any help (eg a woking example) would be very welcome!
>>
>> Thanks in advance.
>>
>> Adellain
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> --
> View this message in context: http://gnuradio.4.n7.nabble.com/accumulate-spectrum-tp60256p60265.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] accumulate spectrum

Try this:

https://www.dropbox.com/s/7xsg4arx5h3gvah/spectrum.grc?dl=0

The integrate with decimation is what you want. Starting at 32 ksps with a
1024 length FFT length yields 31.25 vector/sec. Then an integrate with
decimation by 32 averages down to 0.98 vector/sec.

However when I try reading those back from the file, I'm not getting the 1
ksps I should be getting. I have to set that throttle at 8000 to get the
proper update rate.

Lou

Adellain TSIAHINA wrote
> Dear All,
>
> I'm new to Gnu Radio. I looked carefully to the doc and tutorials but
> could
> not find any simple answer to my problem.
> I have a radio signal from which I'm able to visualize the FFT in GNU
> Radio
> Companion.
> Now I would like to save the FFT (more exactly the magnitude squared, or
> the spectrum) accumulated over a given period of time (the average over
> time) into a file.
>
> I found the following blocks in GRC that seem to be helpful:
> - stream to vector
> - FFT
> - complex to mag
> - file sink
>
> However I did not manage to save any accumulated spectrum...
>
> Any help (eg a woking example) would be very welcome!
>
> Thanks in advance.
>
> Adellain
>
> _______________________________________________
> Discuss-gnuradio mailing list

> Discuss-gnuradio@

> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

--
View this message in context: http://gnuradio.4.n7.nabble.com/accumulate-spectrum-tp60256p60265.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

Re: [Discuss-gnuradio] simple_ra and Ubuntu 16.04 LTS

On 30/05/16 22:29, Marcus D. Leech wrote:

On 05/30/2016 06:27 PM, John Shields wrote:

oops, it was not simple_ra that I tried to re-compile against the new GNURadio etc., it was gr-ra_blocks.

Sorry,

John

Which is a pre-req for simple_ra
_______________________________________________  Discuss-gnuradio mailing list  Discuss-gnuradio@gnu.org  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio  

Thanks Marcus,
                        16.04 comes with swig 3.0 so I removed that and installed swig 2.0 and it seems to work.

                             Kind Regards,

                                   John

Re: [Discuss-gnuradio] simple_ra and Ubuntu 16.04 LTS

On 05/30/2016 06:27 PM, John Shields wrote:

oops, it was not simple_ra that I tried to re-compile against the new GNURadio etc., it was gr-ra_blocks.

Sorry,

John

Which is a pre-req for simple_ra

Re: [Discuss-gnuradio] simple_ra and Ubuntu 16.04 LTS

On 30/05/16 22:05, John Shields wrote:

Hi,
   Since I moved from 14.04 LTS to 15.10 a couple of weeks ago, I have been experiencing segmentation faults on i965_dri (graphics rendering).

   In order to (hopefully) move away from this issue, yesterday I upgraded to 16.04 LTS and rebuilt GNURadio (3.7.9.2) and UHD using Marcus' script - only new
   issue thrown up was:

      Checking for package python-wxgtk2.8
      Failed to find package 'python-wxgtk2.8' in known package repositories
      SOME THINGS MAY NOT BUILD AS A RESULT

       (16.04 appears to have 3.0 version )

   I have seen this sort of diagnostic before on (Failed to find package 'libzmq1-dev' in known package repositories) but things seemed to work OK so continued.

   I can get into GRC etc.

   I decided that I should re-compile simple_ra gr-ra_blocks and followed the instructions I usually do: cd/trunk; cmake . ; make etc.

   at the cmake level, I got the following warnings:

     GNURADIO_BLOCKS_FOUND = TRUE
     CMake Warning (dev) at /usr/local/lib/cmake/gnuradio/GrTest.cmake:45 (get_target_property):
     Policy CMP0026 is not set: Disallow use of the LOCATION target property.
     Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy
     command to set the policy and suppress this warning.

     The LOCATION property should not be read from target "test-ra_blocks". Use
     the target name directly with add_custom_command, or use the generator
     expression $<TARGET_FILE>, as appropriate.

     Call Stack (most recent call first):
     lib/CMakeLists.txt:71 (GR_ADD_TEST)
     This warning is for project developers. Use -Wno-dev to suppress it.

      --
      -- Checking for module SWIG
      -- Command "/usr/bin/swig2.0 -swiglib" failed with output:

      -- Found SWIG version 2.0.12.
      -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.11+")
      -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found suitable version "2.7.11+", minimum required is "2")
      -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11")
      -- Configuring done
      -- Generating done
      -- Build files have been written to: /home/john/gr-ra_blocks/trunk

    when I did a make, I got:

       [ 48%] Generating ra_blocks_swig.tag
       Scanning dependencies of target ra_blocks_swig_swig_2d0df
       [ 52%] Building CXX object swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/ra_blocks_swig_swig_2d0df.cpp.o
       [ 56%] Linking CXX executable ra_blocks_swig_swig_2d0df
      Swig source
      /bin/sh: 1: /usr/bin/swig2.0: not found
      swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/build.make:134: recipe for target 'swig/ra_blocks_swig_swig_2d0df' failed
      make[2]: *** [swig/ra_blocks_swig_swig_2d0df] Error 127
      make[2]: *** Deleting file 'swig/ra_blocks_swig_swig_2d0df'
      CMakeFiles/Makefile2:274: recipe for target 'swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/all' failed
      make[1]: *** [swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/all] Error 2
      Makefile:138: recipe for target 'all' failed
      make: *** [all] Error 2

   I wonder if I have made an error some way along, but cannot imagine what.

   Any ideas?

          Kind Regards,

                 John

oops, it was not simple_ra that I tried to re-compile against the new GNURadio etc., it was gr-ra_blocks.

Sorry,

John

[Discuss-gnuradio] simple_ra and Ubuntu 16.04 LTS

Hi,
Since I moved from 14.04 LTS to 15.10 a couple of weeks ago, I have
been experiencing segmentation faults on i965_dri (graphics rendering).

In order to (hopefully) move away from this issue, yesterday I
upgraded to 16.04 LTS and rebuilt GNURadio (3.7.9.2) and UHD using
Marcus' script - only new
issue thrown up was:

Checking for package python-wxgtk2.8
Failed to find package 'python-wxgtk2.8' in known package
repositories
SOME THINGS MAY NOT BUILD AS A RESULT

(16.04 appears to have 3.0 version )

I have seen this sort of diagnostic before on (Failed to find
package 'libzmq1-dev' in known package repositories) but things seemed
to work OK so continued.

I can get into GRC etc.

I decided that I should re-compile simple_ra and followed the
instructions I usually do: cd/trunk; cmake . ; make etc.

at the cmake level, I got the following warnings:

GNURADIO_BLOCKS_FOUND = TRUE
CMake Warning (dev) at
/usr/local/lib/cmake/gnuradio/GrTest.cmake:45 (get_target_property):
Policy CMP0026 is not set: Disallow use of the LOCATION target
property.
Run "cmake --help-policy CMP0026" for policy details. Use the
cmake_policy
command to set the policy and suppress this warning.

The LOCATION property should not be read from target
"test-ra_blocks". Use
the target name directly with add_custom_command, or use the generator
expression $<TARGET_FILE>, as appropriate.

Call Stack (most recent call first):
lib/CMakeLists.txt:71 (GR_ADD_TEST)
This warning is for project developers. Use -Wno-dev to suppress it.

--
-- Checking for module SWIG
-- Command "/usr/bin/swig2.0 -swiglib" failed with output:

-- Found SWIG version 2.0.12.
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so
(found version "2.7.11+")
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so
(found suitable version "2.7.11+", minimum required is "2")
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.11")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/john/gr-ra_blocks/trunk

when I did a make, I got:

[ 48%] Generating ra_blocks_swig.tag
Scanning dependencies of target ra_blocks_swig_swig_2d0df
[ 52%] Building CXX object
swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/ra_blocks_swig_swig_2d0df.cpp.o
[ 56%] Linking CXX executable ra_blocks_swig_swig_2d0df
Swig source
/bin/sh: 1: /usr/bin/swig2.0: not found
swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/build.make:134:
recipe for target 'swig/ra_blocks_swig_swig_2d0df' failed
make[2]: *** [swig/ra_blocks_swig_swig_2d0df] Error 127
make[2]: *** Deleting file 'swig/ra_blocks_swig_swig_2d0df'
CMakeFiles/Makefile2:274: recipe for target
'swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/all' failed
make[1]: *** [swig/CMakeFiles/ra_blocks_swig_swig_2d0df.dir/all]
Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

I wonder if I have made an error some way along, but cannot imagine
what.

Any ideas?

Kind Regards,

John

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Saving signal file in GNU radio

Hi Hais,

kindly guide me how can i save the received signal in GNU radio software

Have you gone through the tutorials on http://tutorials.gnuradio.org ? Like I said, use the "file sink". It's really not that hard if you just get started with these tutorials!

what should be the format of received signal file so that it can be imported in matlab for signal analysis..??

That one is asked quite frequently; here's the answer:
To cite [1]:

All files are in pure binary format. Just bits. That's it. A floating point data stream is saved as 32 bits in the file, one after the other. A complex signal has 32 bits for the real part and 32 bits for the imaginary part. Reading back a complex number means reading in 32 bits, saving that to the real part of a complex data structure, and then reading in the next 32 bits as the imaginary part of the data structure. And just keep reading the data.

Take a look at the Octave and Python files in gr-utils for reading in data using Octave and Python's Scipy module.

So, just go ahead and look at the read_something.m files in [2]. they contain matlab code.

Best regards,
Marcus

[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-file_sink-How-can-I-read-files-produced-by-a-file-sink
[2] https://github.com/gnuradio/gnuradio/tree/master/gr-utils/octave

On 30.05.2016 19:59, Haris Tanveer wrote:

i am using USRP n-210 to receive signals.
kindly guide me how can i save the received signal in GNU radio software and what should be the format of received signal file so that it can be imported in matlab for signal analysis..??
_______________________________________________  Discuss-gnuradio mailing list  Discuss-gnuradio@gnu.org  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio  

[Discuss-gnuradio] Saving signal file in GNU radio

i am using USRP n-210 to receive signals.

kindly guide me how can i save the received signal in GNU radio software and what should be the format of received signal file so that it can be imported in matlab for signal analysis..??

Re: [Discuss-gnuradio] OFDM IFFT calculate

Ah, forgot to actually cite one thing:

On 30.05.2016 14:49, Marcus Müller wrote:

I can't find its' implementation in anywhere so that I can't understand what happen in this function.
A DFT is performed, by calling the fftwf_execute function of the FFTw library, which really, just executes a fast DFT.

And because "DFT" is not totally unambiguous (because there are different normalization conventions out there), if you care for the actual formula, it's on
http://www.fftw.org/doc/The-1d-Discrete-Fourier-Transform-_0028DFT_0029.html#The-1d-Discrete-Fourier-Transform-_0028DFT_0029
i.e. the backwards (inverse) n-point FFT is really just plain, old, boring, textbook

No normalization.

Best regards,
Marcus

Re: [Discuss-gnuradio] OFDM IFFT calculate

Hi SangHyuk

On 30.05.2016 14:25, SangHyuk Kim wrote:

Hi all,

The file, /gr-fft/lib/fft_vcc_fftw.cc(http://goo.gl/X8WNPh),

No need to use URL shorteners in Emails.
Why are you using a revision of that file from 2012? That is not what you should do. Select "branch: Master" from the drop-down menu; you should be looking at
http://gnuradio.org/redmine/projects/gnuradio/repository/entry/gr-fft/lib/fft_vcc_fftw.cc?rev=master .
Reading versions of code that no-one uses anymore doesn't help you !

> I can understand how get inputs to 'd_fft', but I don't know about d_fft->execute() that compute the fft.

So, here's how you approach something like this: Find out what "d_fft" is. For that, you often need to look in the .h file to your .cc.

There you'll find out which class type d_fft has.

Find that type's definition.

Or, you could just go to

and search for "execute" in the search box. That'll tell you the classes that have a method called "execute", and you can access the documentation to these.

I can't find its' implementation in anywhere so that I can't understand what happen in this function.

A DFT is performed, by calling the fftwf_execute function of the FFTw library, which really, just executes a fast DFT.

Best regards,
Marcus

[Discuss-gnuradio] accumulate spectrum

Dear All,

I'm new to Gnu Radio. I looked carefully to the doc and tutorials but could not find any simple answer to my problem.

I have a radio signal from which I'm able to visualize the FFT in GNU Radio Companion.

Now I would like to save the FFT (more exactly the magnitude squared, or the spectrum) accumulated over a given period of time (the average over time) into a file.

I found the following blocks in GRC that seem to be helpful:

- stream to vector

- FFT

- complex to mag

- file sink

However I did not manage to save any accumulated spectrum...

Any help (eg a woking example) would be very welcome!

Thanks in advance.

Adellain

[Discuss-gnuradio] OFDM IFFT calculate

Hi all,

The file, /gr-fft/lib/fft_vcc_fftw.cc(http://goo.gl/X8WNPh), changes domain from frequency to time using IFFT(Inverse-Fast-Fourier-Transform).

It takes parallel subcarriers in frequency-domain (it is defined 'in' in the file) and converts it into time-domain(it is defined 'out').

I can understand how get inputs to 'd_fft', but I don't know about d_fft->execute() that compute the fft.

I can't find its' implementation in anywhere so that I can't understand what happen in this function.

Could anyone tell me how compute the fft in the function ?

Thanks.

Re: [Discuss-gnuradio] [PyBOMBS] Need your help!

I'm going through the code that calls python at build time.
Is this a fresh, clean Antergos, or did you manually install different
versions of python through something that is not pacman?

Best regards,
Marcus

On 30.05.2016 14:07, Marcus Müller wrote:
> Hi Ravi,
>
> On 30.05.2016 14:04, Ravi Sharan wrote:
>> Hi Marcus,
>>
>> I had already installed python2 before running pybombs on my PC. I
>> have just rechecked installing gnuradio with sudo privileges and it
>> seems to be picking the python2 version correctly.
> That's a bug. The GNU Radio build system should always use python2.
> Still: can you get a log of when you're not doing this with root
> privileges and it fails?
>
> Best regards,
> Marcus

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [PyBOMBS] Need your help!

Hi Ravi,

On 30.05.2016 14:04, Ravi Sharan wrote:
> Hi Marcus,
>
> I had already installed python2 before running pybombs on my PC. I
> have just rechecked installing gnuradio with sudo privileges and it
> seems to be picking the python2 version correctly.
That's a bug. The GNU Radio build system should always use python2.
Still: can you get a log of when you're not doing this with root
privileges and it fails?

Best regards,
Marcus

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [PyBOMBS] Need your help!

Hi Marcus,

I had already installed python2 before running pybombs on my PC. I
have just rechecked installing gnuradio with sudo privileges and it
seems to be picking the python2 version correctly.

P.S. I was replying to Martin's mail dated
http://lists.gnu.org/archive/html/discuss-gnuradio/2016-05/msg00242.html.
Hence, the subject line :)

Thank you,
Ravi

On Mon, May 30, 2016 at 4:40 PM, Ravi Sharan
<bhagavathula.ravisharan@gmail.com> wrote:
> Hi,
>
> Today, I have tried installing gnuradio on Antergos (Arch Linux based
> distro) using pybombs. Antergos ships Python3 as it's default python version
> and Cheetah seems to be incompatible with Python3. The build fails due to
> the unmet dependency of Cheetah template engine.
> The successful builds on Ubuntu 16.04 reported in this thread are because
> Ubuntu 16.04 claims to be shipping Python3.5.1 as it's default Python
> version, but it still has a good support for Python2.7.x.
>
> This issue of replacing Cheetah is slightly discussed at [1].
>
> Cheers,
> Ravi
>
> [1] - https://github.com/gnuradio/gnuradio/pull/303

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [PyBOMBS] Need your help!

Hi Ravi,

The build fails due to the unmet dependency of Cheetah template engine.

exactly that's why we depend on Python2 packages in python.lwr:

category: baseline  inherit: autoconf  satisfy:    deb: python2.7 && python-dev    rpm: python-devel >= 2.7    cmd: python --version >= 2.7    pacman: python2 >= 2.7    port: python27 >= 2.7  vars:    config_opt: --enable-shared

Notice the pacman line! So, if GNU Radio is currently building, you should have an install python2. If you don't, there's a bug in dependency checking.

I'd expect all our build scripts to explicitely specify that the python2 executable should be used. If you can give an actual bug report of where exactly building fails, this is probably something that's fixable.

Also, you said "need your help!", but then didn't ask a question or what exactly we should be helping you with :) So if I didn't hit the spot here, please explain what it is that you need help with.

Best regards,
Marcus

On 30.05.2016 13:10, Ravi Sharan wrote:

Hi,

Today, I have tried installing gnuradio on Antergos (Arch Linux based distro) using pybombs. Antergos ships Python3 as it's default python version and Cheetah seems to be incompatible with Python3. The build fails due to the unmet dependency of Cheetah template engine.

The successful builds on Ubuntu 16.04 reported in this thread are because Ubuntu 16.04 claims to be shipping Python3.5.1 as it's default Python version, but it still has a good support for Python2.7.x.

This issue of replacing Cheetah is slightly discussed at [1].

Cheers,

Ravi

[1] - https://github.com/gnuradio/gnuradio/pull/303
_______________________________________________  Discuss-gnuradio mailing list  Discuss-gnuradio@gnu.org  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio  

Re: [Discuss-gnuradio] [PyBOMBS] Need your help!

Hi Ravi,

The build fails due to the unmet dependency of Cheetah template engine.

exactly that's why we depend on Python2 packages in python.lwr:

category: baseline  inherit: autoconf  satisfy:    deb: python2.7 && python-dev    rpm: python-devel >= 2.7    cmd: python --version >= 2.7    pacman: python2 >= 2.7    port: python27 >= 2.7  vars:    config_opt: --enable-shared

On 30.05.2016 13:10, Ravi Sharan wrote:

Hi,

Today, I have tried installing gnuradio on Antergos (Arch Linux based distro) using pybombs. Antergos ships Python3 as it's default python version and Cheetah seems to be incompatible with Python3. The build fails due to the unmet dependency of Cheetah template engine.

The successful builds on Ubuntu 16.04 reported in this thread are because Ubuntu 16.04 claims to be shipping Python3.5.1 as it's default Python version, but it still has a good support for Python2.7.x.

This issue of replacing Cheetah is slightly discussed at [1].

Cheers,

Ravi

[1] - https://github.com/gnuradio/gnuradio/pull/303
_______________________________________________  Discuss-gnuradio mailing list  Discuss-gnuradio@gnu.org  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio  

Re: [Discuss-gnuradio] [PyBOMBS] Need your help!

Hi,

Today, I have tried installing gnuradio on Antergos (Arch Linux based distro) using pybombs. Antergos ships Python3 as it's default python version and Cheetah seems to be incompatible with Python3. The build fails due to the unmet dependency of Cheetah template engine.

The successful builds on Ubuntu 16.04 reported in this thread are because Ubuntu 16.04 claims to be shipping Python3.5.1 as it's default Python version, but it still has a good support for Python2.7.x.

This issue of replacing Cheetah is slightly discussed at [1].

Cheers,

Ravi

[1] - https://github.com/gnuradio/gnuradio/pull/303

Sunday, May 29, 2016

Re: [Discuss-gnuradio] use of CCSDS 27 encode/decode

Hi Ekko,

CCSDS27 is really old. In fact, it was really just discussed hours ago to remove it from future versions of GNU Radio; so if you feel like it might not be the right FEC for your application, feel encouraged to use other stuff!
However, there's two things happening to your source:

1. Four byte offset:
From the decoder documentation:

This block is designed for continuous data streaming, not packetized data. The first 32 bits out will be zeroes, with the output delayed four bytes from the corresponding inputs.

2. half your bits are interepreted as erased bits. For that, decoding performance is not half bad:

The input is a stream of (possibly noise corrupted) floating point values nominally spanning [-1.0, 1.0], representing the encoded channel symbols 0 (-1.0) and 1 (1.0), with erased symbols at 0.0.

But you're feeding it 0 and 1 instead of -1 and 1 ! So, use a scale=2 in your char_to_float, and add_const -1

Best regards,
Marcus

On 30.05.2016 05:58, Ekko wrote:

hello all

i want to use CCSDS 27 encode/decode ,so i write a grc to test these two block without hardware,

but i got he dest data is not same with the source data,

so is there some wrong in my grc.

these is the source file and dest file in my grcand my grc file

thank you

--Ekko
_______________________________________________  Discuss-gnuradio mailing list  Discuss-gnuradio@gnu.org  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio  

[Discuss-gnuradio] use of CCSDS 27 encode/decode

==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!==>Hello E310,SDR! It's Your World!!
��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��==>c�llo��0,SD�! It's��r ��

hello all

i want to use CCSDS 27 encode/decode ,so i write a grc to test these two block without hardware,

but i got he dest data is not same with the source data,

so is there some wrong in my grc.

these is the source file and dest file in my grcand my grc file

thank you

--Ekko