[Discuss-gnuradio] R: On the "right" approach for developing applications to be run on an E310

[Maurizio Crozzoli]

Da: Marcus Müller-3 [via GnuRadio] [mailto:ml-node+s4n55906...@n7.nabble.com]
Inviato: mercoledì 9 settembre 2015 11:38
A: Crozzoli Maurizio
Oggetto: Re: On the "right" approach for developing applications to be run on 
an E310

GRC is a flowgraph design tool. You wouldn't run it on the E310 (especially as 
it is a graphical tool).
It can generate headless flow graphs set up by python programs that you can 
copy over to the E310 -- that's the usage of GRC I'd recommend in this case.

Your answer is clear.
Just one detail: what is exactly a "headless flow graph"?
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone 
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla 
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate 
ricevuto questo documento per errore siete cortesemente pregati di darne 
immediata comunicazione al mittente e di provvedere alla sua distruzione, 
Grazie.

This e-mail and any attachments is confidential and may contain privileged 
information intended for the addressee(s) only. Dissemination, copying, 
printing or use by anybody else is unauthorised. If you are not the intended 
recipient, please delete this message and any attachments and advise the sender 
by return e-mail, Thanks.

[rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non è 
necessario.



logo Ambiente_foglia2.jpg (928 bytes) 





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/R-On-the-right-approach-for-developing-applications-to-be-run-on-an-E310-tp55907.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] On the "right" approach for developing applications to be run on an E310

[Maurizio Crozzoli]

And what about the new RFNoC and GRC to be run on an E310?

>From Ettus site we are told that "RFNoC has been integrated into UHD for our
third generation USRP SDRs (X300-series, E300-series, and future devices)".
Furthermore Ettus site shows some examples where RFNoC blocks are used under
GRC, which is a GUI environment (but they are run on an X series HW...).

So the new question is: what is the right methodology to make designs under
GRC to be run under an E310? What about initial testing steps (especially if
you want to use RFNoc)?

About RFNoC I could imagine a step-wise approache where I prepare the Python
with GRC (where the RFNoC OOT modules are installed) and then I run it on
the E310 (where the RFNoC non-default FPGA configuration is installed). But
what about testing such design? "If your flow graph doesn't use graphical
sinks" how can you test your design? The only way out I can think of is to
rely on data saved to file to be analysed in a post-processing step.

Needless to say that comments are welcome...

TIA!

BR,
Maurizio.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/On-the-right-approach-for-developing-applications-to-be-run-on-an-E310-tp55779p55905.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] On the "right" approach for developing applications to be run on an E310

[Marcus Müller]

Hi Maurizio,

> And what about the new RFNoC and GRC to be run on an E310?
these are two different aspects:
GRC is a flowgraph /design/ tool. You wouldn't run it on the E310
(especially as it is a graphical tool).
It can generate headless flow graphs set up by python programs that you
can copy over to the E310 -- that's the usage of GRC I'd recommend in
this case.

You can use gr-ettus to design flow graphs even if the PC you use for
design doesn't have access to a USRP at all -- the USRP/RFNoC is needed
at run time only.

>  The only way out I can think of is to
> rely on data saved to file to be analysed in a post-processing step.
To be honest, yes, that is the problem with embedded devices. They are
limited in the ways you can interact with them and with the computation
happening on them.
A very software design driven approach would be to design good unit
tests, that you would first verify with simulated signals on your host
computer, and use them to understand the workings of your USRP.

If you limit yourself to low rates (go for < 1MS/s for a start), you
might also be able to build a flow graph that uses e.g. a ZMQ sink to
send the processed data to your host PC, where another flow graph takes
care of visualization.

Greetings,
Marcus


On 09.09.2015 11:30, Maurizio Crozzoli wrote:
> And what about the new RFNoC and GRC to be run on an E310?
>
> From Ettus site we are told that "RFNoC has been integrated into UHD for our
> third generation USRP SDRs (X300-series, E300-series, and future devices)".
> Furthermore Ettus site shows some examples where RFNoC blocks are used under
> GRC, which is a GUI environment (but they are run on an X series HW...).
>
> So the new question is: what is the right methodology to make designs under
> GRC to be run under an E310? What about initial testing steps (especially if
> you want to use RFNoc)?
>
> About RFNoC I could imagine a step-wise approache where I prepare the Python
> with GRC (where the RFNoC OOT modules are installed) and then I run it on
> the E310 (where the RFNoC non-default FPGA configuration is installed). But
> what about testing such design? "If your flow graph doesn't use graphical
> sinks" how can you test your design? The only way out I can think of is to
> rely on data saved to file to be analysed in a post-processing step.
>
> Needless to say that comments are welcome...
>
> TIA!
>
> BR,
> Maurizio.
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/On-the-right-approach-for-developing-applications-to-be-run-on-an-E310-tp55779p55905.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] Display Problem with QT GUI Vector Sink

[Simon Biehl]

Hi Marcus,

thanks for your detailed reply. I built your test case, which shows the 
same huge delays of ~2 minutes.
Surprisingly, changing the vector size to 1024 elements (=4096 bytes) 
yielded a much better result with delays going down to about 3 seconds.
Nevertheless I think I'll stick to to the workaround of using 'Vector to 
Stream' combined with a time sink, as this gives me the best 
responsiveness.
Performance counters and Thrift seem promising methods to further 
analyze this behavior, but as of now the idea of having to recompile and 
reinstall gnuradio isn't very tempting.


Thanks again for your help,
best regards,
Simon

Am 2015-09-07 13:18, schrieb Marcus Müller:

Hi Simon,

Is it possible, that the way my music_cf function is outputting the
data, might cause some trouble?

181 floats isn't really a "round" itemsize, and since GNU Radio can 
only

build buffers that are multiple of 4KB (==4096B), I assume that you get
a large buffer (probably 4096 items of size 181*sizeof(float) each).
That per se is not a problem (maybe a loss of a few MB of RAM, but who
cares in this day and age?); but things get large, and as you can see,
latency can be pretty high. I remember seeing this a while back, when I
was trying large (as in 50dBbin) FFTs with the vector sink; I kind of
assumed visualizing a vector that is a couple of thousand times larger
than my screen had pixels in x-direction would have been what 
introduced

the latency, so I didn't look into it.

Attempt of building a test case, which might solve your issue, but is
vastly bad design (because it just copies twice):

music_cf->vector_to_stream->stream_to_vector->qt_vector_sink

Could you try that?

Next step, because this might be interesting: If you have both
performance counters enabled and Thrift/gr-controlport, you could have 
a

look at the ctrlport performance monitor, which would tell you things
like the average buffer fill, average work() run time, and variance of
these numbers.

Best regards,
Marcus


On 07.09.2015 12:44, gnura...@simonbiehl.de wrote:

The example is running without errors.
Is it possible, that the way my music_cf function is outputting the
data, might cause some trouble?

Simon

Am 2015-09-04 21:45, schrieb Martin Braun:
There's an example for the vector sink, which doesn't seem to have 
that

issue. Can you confirm that? It's in gr-qtgui/examples.

M

PS: I had to locally fix the example, maybe you need to do that to, 
the

actual vector sink block was missing.

On 04.09.2015 01:57, gnura...@simonbiehl.de wrote:

Hi Martin,

averaging is disabled. Any further ideas?

Best regards,
Simon

Am 2015-09-03 18:49, schrieb Martin Braun:

The vector sink has an averaging option, is that on?

M
On 03.09.2015 02:25, gnura...@simonbiehl.de wrote:

Dear all,

I built an angle-of-arrival system using four Ettus USRP2. I'm
facing a
problem when trying to display a vector containing the calculated
MUSIC-Spectrum using a “QT GUI Vector Sink”. The vector sink won't
display any data for the first two minutes, and then it is
starting to
show very old values. When I use the block “Vector to Stream” and 
a

simple “QT GUI Time Sink” instead, the values are displayed
immediately
without delay.

The block “music_cf” feeding the vector sink is a sync_decimator,
generating one vector of 181 elements for every 1000 input
samples. I've
provided a shortened version of my c++ code in the attachment,
without
the actual mathematics.

What could be the reason for this huge delay when using the “QT 
GUI

Vector Sink”? Is it a buffering problem?

Best regards,
Simon

Block Diagram:
http://fs1.directupload.net/images/150903/7cnqbzup.png


___
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



___
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] GRCon15 statistics

[Tom Rondeau]

On Wed, Sep 9, 2015 at 9:28 AM, Michael Dickens 
wrote:

> Hi Francisco - I'm not sure we can definitely say how many people helped
> out; we sort of ebbed and flowed as necessary to make it work. There were
> another 2-6 of us meeting weekly (and emailing regularly) for
> organizational purposes; some more often than others. We had 15-20
> volunteers to help with registration, setup, posters, booths, etc... Some
> of the sponsors (e.g., Ettus & DRS) helped out in various ways that were
> not required of them, sort of as volunteers. Then there were the caterers &
> venue folks, and the sponsors had their own helpers internal to each's
> respective company. So, just guessing from the above numbers I'd say
> something like 30-35 people had their hands in making sure GRCon15 came off
> smoothly. Hope this helps! - MLD
>
> On Tue, Sep 8, 2015, at 07:05 PM, Francisco Albani wrote:
>
> I'm curious about how many people assisted to the all the annual
> conferences, specially to the last one. And maybe there are more
> interesting statistics to know.
>
>
Also,because I wanted to give the people that helped out credit:

http://www.trondeau.com/grcon15-organizing-committee/

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

[Discuss-gnuradio] problems with setting up RFNoC environment within PyBombs

[Jason Matusiak]

I have set up RFNoC environments in the past, but I am trying to embrace
pybombs and am attempting to setup an environment now using that
approach instead.  

I see on the rfnoc:-GettingStarted WiKi page, that it can't be done
directly using pybombs. So here are the steps I //attempted// to take,
but appear to have not done correctly.

*cd ~
*git clone git://github.com/gnuradio/pybombs
*cd pybombs/
*./pybombs config
**Use the defaults except that I turned on DOXygen as well as did a
forcepkgs=uhd (per the rfnoc wiki)
*./pybombs install gnuradio
*drink coffee and twiddle thumbs
*cd src
*git clone https://github.com/EttusResearch/uhd.git
*git checkout rfnoc-devel
*git submodule init
*git submodule update
*cd ~/pybombs
*./pybombs install gr-ettus (this last statement per the rfnoc wiki
again)

And here is where it fails with the error:
Settled on prefix: /home/jason/target
Initializing environmental variables...
Loading recipes ...
/home/jason/target
Installing packages:
* gr-ettus
Installing from source: gr-ettus
Cloning into 'gr-ettus'...
remote: Counting objects: 833, done.
remote: Total 833 (delta 0), reused 0 (delta 0), pack-reused 833
Receiving objects: 100% (833/833), 297.17 KiB | 0 bytes/s, done.
Resolving deltas: 100% (572/572), done.
Checking connectivity... done.
 
CC=gcc CXX=g++ cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
-DCMAKE_INSTALL_PREFIX=/home/jason/target $config_opt

Configuring: (100%)
[==]
Configuration failed. Re-trying with higher verbosity.
make: *** No targets specified and no makefile found.  Stop.
Build failed. See output above for error messages.


So I am curious where I am going wrong. Does anyone have the working
steps for getting an rfnoc development environment setup using the
PyBombs infrastructure?  Maybe I needed to install UHD and gr-ettus
somewhere else in the pybombs structure?

Thanks!

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

Re: [Discuss-gnuradio] GRCon15 statistics

[Michael Dickens]

Hi Francisco - I'm not sure we can definitely say how many people helped
out; we sort of ebbed and flowed as necessary to make it work. There
were another 2-6 of us meeting weekly (and emailing regularly) for
organizational purposes; some more often than others. We had 15-20
volunteers to help with registration, setup, posters, booths, etc...
Some of the sponsors (e.g., Ettus & DRS) helped out in various ways that
were not required of them, sort of as volunteers. Then there were the
caterers & venue folks, and the sponsors had their own helpers internal
to each's respective company. So, just guessing from the above numbers
I'd say something like 30-35 people had their hands in making sure
GRCon15 came off smoothly. Hope this helps! - MLD

On Tue, Sep 8, 2015, at 07:05 PM, Francisco Albani wrote:
> I'm curious about how many people assisted to the all the annual
> conferences, specially to the last one. And maybe there are more
> interesting statistics to know.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problems with setting up RFNoC environment within PyBombs

[Jason Matusiak]

> So I am curious where I am going wrong. Does anyone have the working
> steps for getting an rfnoc development environment setup using the
> PyBombs infrastructure? Maybe I needed to install UHD and gr-ettus
> somewhere else in the pybombs structure?

Well, I found at least one issue... I forgot to mkdir build && cd build
&& cmake ../ && make && sudo make install from withing the
pybombs/src/uhd directory.  Once I did that, I was able to run ./pybombs
install gr-ettus and not have it error out.

Is there a way to test that this new gnuradio instantiation is working
okay (as opposed to my originally hand-built source version I did before
pybombs)?

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

Re: [Discuss-gnuradio] Volk: __cpuid_count() for MSVC

[Tom Rondeau]

On Mon, Sep 7, 2015 at 10:31 AM, Gisle Vanem  wrote:

> I noticed since last time (a year ago) I tried building
> Volk using MSVC v16, the volk_cpu.tmp.c now uses the
> gcc-centric function '__cpuid_count()' which MSVC doesn't
> have.
>
> I'm not really sure if the below patch is correct. But I
> assume (from looking at gcc 5.1's source) that the ECX should
> be loaded with the 'count' value. So could it be patched into
> something like this?
>
> --- a/volk/tmpl/volk_cpu.tmpl.c  2015-09-01 13:52:53
> +++ b/volk_cpu.tmpl.c 2015-09-07 13:44:25
> @@ -71,8 +71,16 @@
>
>  static inline unsigned int cpuid_count_x86_bit(unsigned int level,
> unsigned int count, unsigned int reg, unsigned int bit) {
>  #if defined(VOLK_CPU_x86)
> +#if defined(_MSC_VER) && defined(HAVE_INTRIN_H)
> +  int regs[4];
> +  __cpuidex(regs, level, count);
> +#elif defined(__GNUC__)
>  unsigned int regs[4];
>  __cpuid_count(level, count, regs[0],  regs[1],  regs[2], regs[3]);
> +#else
> +  #error No __cpuid()!
> +#endif
>  return regs[reg] >> bit & 0x01;
>  #else
>  return 0;
>
>
> ---
>
> Just to let you know.
>
> The docs on MSVC's __cpuidex() is here:
>   https://msdn.microsoft.com/en-us/library/vstudio/hskdteyh(v=vs.100).aspx
>
> --
> --gv


Thanks,  Gisle. Can you post an issue on the VOLK issue tracker?

https://github.com/gnuradio/volk/issues

That's the best place to have these conversations and make sure that it's
seen and not lost in email.

Thanks again!

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

Re: [Discuss-gnuradio] USRP Structure

[Chris Kuethe]

This isn't a relevant concern for general purpose / experimental
hardware like bladerf, hackrf, or usrp hanging off a PC. They're
intended to be user programmable. If someone roots your box, they can
replace your FPGA image, usb, or microcontroller firmware ... but to
what end? The platform is already wide open.

If you're shipping a product, your regulatory agencies are going to
ask you some questions about what you've done to ensure that your
equipment only operates in its intended manner. I don't feel like
writing a big rant about trying to lock down a general purpose
machine. Instead, let me just point you at a whitepaper on secure
booting the Zynq. After that, you should read about how ChromeOS (or
other mobile platforms) do secure boot and ensure application
integrity.

I bet if you offered Ettus or Corgan a barrel of money they might be
interested in building a secure booted E310. Actually, if you offered
me a barrel of money, I'd be all over that project...

http://www.xilinx.com/support/documentation/white_papers/wp426-zynq-7000-secure-boot.pdf


On Wed, Sep 9, 2015 at 11:51 AM, Logan Wu  wrote:
> Hello,
>
> Recently I read a paper on cognitive radio security (Secure
> reconfiguration of software-defined radio). It highlights that the
> operating system of cognitive radio node may be compromised as the
> malware can exploit software vulnerabilities. I am wondering if the FPGA
> and firmware are part of the OS? And can they be compromised during
> runtime by malware?
>
> Thank you,
> Logan
>
> --
> Posted via http://www.ruby-forum.com/.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

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

Re: [Discuss-gnuradio] 回复: gnuradio error

[Michael Dickens]

Please reply on-list for the best assistance; not to me or any specific
responder personally.

OK; so you're using a B200, and you're getting USB errors. Have you
tried different cables? Have you tried different computers / different
OSs or different OS versions? Anything else beyond the error you
encountered that might help provide some clues? Does this error happen
every time you execute any UHD application such as "uhd_usrp_probe"? Or,
is it on some specific applications? - MLD

On Wed, Sep 9, 2015, at 09:29 PM, 18740449846 wrote:
> i  am using  usrp b200
>
>  原始邮件 
>> Hi cdl - Which USRP are you using? USRP1, B200, B210? Might make a
>> difference ... - MLD
>>
>> On Wed, Sep 9, 2015, at 12:22 PM, cdl wrote:
>>> i am using uhd model in gnuradio,usrp_sink and usrp_source to do a
>>> loopback sysrem and i connect the usrp tx and rx withRF feeder
>>> line,when i exe the grc ,i got the output UHD Error: the receiver
>>> packet handler caught an exception. runtimeerror:usb rx6 transfer
>>> status:LIBUSB_TRANSFER_ERROR UHD source block got error code 0xf i
>>> wants to konw how tp solve this problem I am using
>>> https://github.com/anastas/gr-cdma/tree/master/apps cdma_txrx.grc
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Installation Error

[Michael Dickens]

Hi Rama/Dave - I can't say -why- the error is happening, but the error
is because for some reason the llibusb1 library is not being included in
the linking. This might be because the libusb1 library has been updated
since the last time GNU Radio was built; or, it might be for other
reasons too; not always easy to know or tell. Anyway, I'd say that the
most reliable way to get over this issue is to "rm -rf" the whole build
directory & redo the whole cmake command, make, and make install from
scratch. On most systems this will be pretty fast, so it's generally not
a big deal. Hope this helps! - MLD

On Wed, Sep 9, 2015, at 05:02 PM, Rama V wrote:
> I have uninstalled GNU Radio from /gnuradio/build directory because of
> an error and I wish to reinstall it. But when I try to do that from
> the same directory by using 'sudo make install', I keep getting an
> error as
>
> [ 97%] Built target pygen_gr_fcd_swig_ecb11 [ 98%] Built target
> pygen_gr_fcd_python_fcd_37821 Linking CXX executable fcd_nfm_rx 
> ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to
> `libusb_free_config_descriptor' ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to
> `libusb_get_config_descriptor' ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to `libusb_open' 
> ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to
> `libusb_detach_kernel_driver' ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to `libusb_get_device_list' 
> ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to `libusb_control_transfer'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_exit' ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined
> reference to `libusb_free_device_list' ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to `libusb_cancel_transfer' 
> ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to `libusb_free_transfer' 
> ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to `libusb_submit_transfer' 
> ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to `libusb_interrupt_transfer'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_get_device_descriptor' ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to `libusb_claim_interface' 
> ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to `libusb_handle_events' 
> ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to
> `libusb_handle_events_completed' ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to `libusb_close' 
> ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to
> `libusb_kernel_driver_active' ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to `libusb_release_interface'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_get_bus_number' ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0:
> undefined reference to `libusb_init' ../../lib/libgnuradio-fcd-
> 3.7.8git.so.0.0.0: undefined reference to `libusb_get_device_address'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_alloc_transfer' ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0:
> undefined reference to `libusb_get_active_config_descriptor' collect2:
> error: ld returned 1 exit status make[2]: *** [gr-
> fcd/examples/c++/fcd_nfm_rx] Error 1 make[1]: *** [gr-
> fcd/examples/c++/CMakeFiles/fcd_nfm_rx.dir/all] Error 2 make: ***
> [all] Error 2
>
> Please help as to what I can do. I am in the middle of my experiment.
> Any suggestions will be kindly helpful.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis

[Nowlan, Sean]

I'm trying to demodulate a CPFSK signal using the Viterbi algorithm. The 
gr-trellis module seems to have most of the components I'll need, but I'm 
having trouble figuring out how to wrangle my problem into the FSM format. 
Basically, I have a binary CPFSK signal with a modulation index, h=25/3. 
Following the guidance of [1] section 3.3-2, I know that for CPM with rational 
h=m/p, (here, m=25 and p=3), with m odd, I have 2p=6 phase states. I worked out 
the phase trajectories and took them modulo 2*pi to get this set of terminal 
phase states: {0, pi/3, 2*pi/3, pi, 4*pi/3, 5*pi/3}.

I'm trying to understand the FSM format in gr-trellis, and how to build my FSM. 
If you consider the set of terminal phase states above as being zero-indexed, 
the phase transitions should go according to the "Next state" mapping of the 
FSM file format below. I've added my comments as to my understanding of the 
format. Please correct me if I'm wrong.

FSM file:
2 6 2   # 2 possible input symbols // 6 possible FSM states // 2 possible 
output symbols

# Next state mapping
5 1  # if in state 0 and a 0 is received, go to state 5, else (1 is 
received, and) go to state 1
0 2  # if in state 1 and a 0 is received, go to state 0, else go to 
state 2
1 3  # ...
2 4
3 5
4 0

# Output symbol mapping
[...]

I'm having trouble understanding how to define the output symbol mapping. Is 
there a plain-language interpretation like the one I spelled out for Next state 
mapping in my comments above?

Thanks!
Sean

[1] Proakis & Salehi, Digital Communications, 5ed.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: GNU Radio Installation Error

[Rama V]

Anyone. Kindly help with the above error.

Regards,
Dave
On Sep 9, 2015 4:46 PM, "Rama V"  wrote:

> Hello,
> I have uninstalled GNU Radio from /gnuradio/build directory because of an
> error and I wish to reinstall it. But when I try to do that from the same
> directory by using 'sudo make install', I keep getting an error as
>
> [ 97%] Built target pygen_gr_fcd_swig_ecb11
> [ 98%] Built target pygen_gr_fcd_python_fcd_37821
> Linking CXX executable fcd_nfm_rx
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_free_config_descriptor'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_get_config_descriptor'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_open'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_detach_kernel_driver'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_get_device_list'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_control_transfer'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_exit'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_free_device_list'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_cancel_transfer'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_free_transfer'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_submit_transfer'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_interrupt_transfer'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_get_device_descriptor'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_claim_interface'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_handle_events'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_handle_events_completed'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_close'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_kernel_driver_active'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_release_interface'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_get_bus_number'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_init'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_get_device_address'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_alloc_transfer'
> ../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
> `libusb_get_active_config_descriptor'
> collect2: error: ld returned 1 exit status
> make[2]: *** [gr-fcd/examples/c++/fcd_nfm_rx] Error 1
> make[1]: *** [gr-fcd/examples/c++/CMakeFiles/fcd_nfm_rx.dir/all] Error 2
> make: *** [all] Error 2
>
>  Please help as to what I can do. I am in the middle of my experiment. Any
> suggestions will be kindly helpful.
>
> Thanks,
> Dave
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRCon15 attendees

[Michael Dickens]

We're discussing what can be released & Tom will reply with that info.
It will not include email addresses, names, or affiliations; it will
probably be just # of registrations because we also can't accurately say
the # who attended any given day. Anyway, more from him once he gets
there. - MLD

On Wed, Sep 9, 2015, at 03:20 PM, Sylvain Munaut wrote:
> > I’m also curious about the cross-section of people who attended. Would it be
> > possible to post a list of names, and affiliations, of the registered
> > attendees? (Email addresses would be useful too, but you/they may prefer not
> > to do that).
> 
> How about do none of the above ...

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

Re: [Discuss-gnuradio] USRP Structure

[Marcus D. Leech]

On 09/09/2015 08:24 PM, Chris Kuethe wrote:

This isn't a relevant concern for general purpose / experimental
hardware like bladerf, hackrf, or usrp hanging off a PC. They're
intended to be user programmable. If someone roots your box, they can
replace your FPGA image, usb, or microcontroller firmware ... but to
what end? The platform is already wide open.

If you're shipping a product, your regulatory agencies are going to
ask you some questions about what you've done to ensure that your
equipment only operates in its intended manner. I don't feel like
writing a big rant about trying to lock down a general purpose
machine. Instead, let me just point you at a whitepaper on secure
booting the Zynq. After that, you should read about how ChromeOS (or
other mobile platforms) do secure boot and ensure application
integrity.

I bet if you offered Ettus or Corgan a barrel of money they might be
interested in building a secure booted E310. Actually, if you offered
me a barrel of money, I'd be all over that project...

http://www.xilinx.com/support/documentation/white_papers/wp426-zynq-7000-secure-boot.pdf


I will comment, having been involved in the whole TPM thing in the IETF, 
and in private research, that since there's no way to guarantee correctness,
  no amount of digitally-signing chains of stuff-we-can't-trust is 
going to help you.  If you think that you have achieved "security" that 
way, against
  an adversary who has the device in his/her hands, then you are in a 
state of sin.  Cryptography cannot help you here.  You're running up against
  the halting problem.  A machine that "attests" at time (t) that it is 
notionally "secure" could be notionally cracked all to heck at time(t+1).


Until *significant* swaths of software can be automatically "proven to 
be correct", then none of this "layered attestation" nonsense makes any 
sense.


IMHO, of course, etc, etc, etc.



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

[Discuss-gnuradio] Display the values of Frequency, Amplitude, FFT

[Julio Héctor Aguilar Renteria]

Hi All,

As I can display the values of Frequency, Amplitude, FFT, of uhd_ff.grc in
WX GUI Text Box.

Thanks you

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

Re: [Discuss-gnuradio] GRCon15 statistics

[Philip Balister]

On 09/09/2015 02:22 PM, Francisco Albani wrote:
> Oops!
> 
> I may have misused the word 'assisted'. I wished to mean 'attended' (I'm
> expecting a number around 200).

English is a tricky language.

Even better, how about a graph of attendance at each GRCon?

Philip

> 
> Sorry and thanks!
> 
> 2015-09-09 11:22 GMT-03:00 Tom Rondeau :
> 
>> On Wed, Sep 9, 2015 at 9:28 AM, Michael Dickens >> wrote:
>>
>>> Hi Francisco - I'm not sure we can definitely say how many people helped
>>> out; we sort of ebbed and flowed as necessary to make it work. There were
>>> another 2-6 of us meeting weekly (and emailing regularly) for
>>> organizational purposes; some more often than others. We had 15-20
>>> volunteers to help with registration, setup, posters, booths, etc... Some
>>> of the sponsors (e.g., Ettus & DRS) helped out in various ways that were
>>> not required of them, sort of as volunteers. Then there were the caterers &
>>> venue folks, and the sponsors had their own helpers internal to each's
>>> respective company. So, just guessing from the above numbers I'd say
>>> something like 30-35 people had their hands in making sure GRCon15 came off
>>> smoothly. Hope this helps! - MLD
>>>
>>> On Tue, Sep 8, 2015, at 07:05 PM, Francisco Albani wrote:
>>>
>>> I'm curious about how many people assisted to the all the annual
>>> conferences, specially to the last one. And maybe there are more
>>> interesting statistics to know.
>>>
>>>
>> Also,because I wanted to give the people that helped out credit:
>>
>> http://www.trondeau.com/grcon15-organizing-committee/
>>
>> Tom
>>
>>
>> ___
>> 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

[Discuss-gnuradio] GRCon15 attendees

[Richard Prestage]

Hi Tom -

I'm also curious about the cross-section of people who attended. Would it be 
possible to post a list of names, and affiliations, of the registered 
attendees? (Email addresses would be useful too, but you/they may prefer not to 
do that).

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

Re: [Discuss-gnuradio] [USRP] tracking the transmission/receiving process

[Logan Wu]

Hi Jeff,

Thank you for the suggestions. I'll look into the codes under "cores" 
directory.

Logan

-- 
Posted via http://www.ruby-forum.com/.

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

[Discuss-gnuradio] making local filter with more than "noutput_items" output length

[ratnesh kumbhkar]

Hi all,
I am trying to make an out-of-tree module using sync block. In which I want
to make a local filter, i.e. output of this filter is not connected to an
output port, but to be stored in a local variable.

int  ShortPNcorr_impl::work(int noutput_items,
gr_vector_const_void_star _items,
gr_vector_void_star _items)
{
const gr_complex *in = (const gr_complex *) input_items[0];
gr_complex *out = (gr_complex *) output_items[0];
gr_complex *tcorr = (gr_complex *) output_items[1];
int *flag = (int *) output_items[2]; // this is calculated
based on local filter

std::vector short_corr(noutput_items+history());
gr_complex *corr = (gr_complex *) &(short_corr[0]);

..


d_Shfilter->filter(noutput_items+*X*, in, corr);
// Where X>0
// d_Shfilter is *fft_filter_ccc* filter of length 40
(number of taps)
// Since I am saving a history of length 320, I am assuming
that input buffer has atleast noutput_items+319 values available

..
 }

I think that filter requires *corr*  to be a pointer to the vector (similar
to 'in' or 'out'), and that is what I am trying to do. But this  results in
an unstable operation and whenever I choose X>250, I get "double free or
corruption" error. Can someone explain this? Is my understanding of
"history" wrong?

Thanks

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

Re: [Discuss-gnuradio] USRP Structure

[mleech]

 

Since most SDRs out there have fully reconfigurable-by-the-end-user FPGA
and firmware images, I don't think the notion of "compromise"
 has much meaning in this context, further because access to the devices
is freely available to ordinary user-level processes, they can ask the
radio to do whatever they want. 

Most SDRs that we discuss here are used in R, and only a very few in
"services" where type-acceptance is required. Presumably, in the
fullness of time, getting type acceptance would require the integrator
to demonstrate some kind of "protection" for the radio. But SDRs as we
know them here are just "dumb" components. It's a bit like asking a
mixer or RF amplifier or synthesizer to "tamper-proof itself". 

My personal opinion is that asking general-purpose hardware to enforce
some arbitrary notion of regulatory compliance in this area is silly,
unproductive, and ultimately doomed to failure, quite apart from the
wide-reaching implications for the industry in general. 

My "day job" is at a company where we "tamper proof" software on
general-purpose computers at the behest of the Media Industry. It
amounts to building perpetual-motion machines--it cannot be done in the
strictest theoretical sense. In a practical sense, you can keep the 
casually-curious out of your "stack", but you cannot protect against the
determined--they have infinite access to the hardware and software, and
will eventually find a way around any "safeguards" you put in place. So,
in the first instance, the "lockdown" software is utterly unnecessary,
and in the second instance, it is woefully inadequate... 

On 2015-09-09 14:51, Logan Wu wrote: 

> Hello,
> 
> Recently I read a paper on cognitive radio security (Secure
> reconfiguration of software-defined radio). It highlights that the
> operating system of cognitive radio node may be compromised as the
> malware can exploit software vulnerabilities. I am wondering if the FPGA
> and firmware are part of the OS? And can they be compromised during
> runtime by malware?
> 
> Thank you,
> Logan
 ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problems with setting up RFNoC environment within PyBombs

[Martin Braun]

On 09.09.2015 08:38, Jason Matusiak wrote:
>> So I am curious where I am going wrong. Does anyone have the working
>> steps for getting an rfnoc development environment setup using the
>> PyBombs infrastructure? Maybe I needed to install UHD and gr-ettus
>> somewhere else in the pybombs structure?
> 
> Well, I found at least one issue... I forgot to mkdir build && cd build
> && cmake ../ && make && sudo make install from withing the
> pybombs/src/uhd directory.  Once I did that, I was able to run ./pybombs
> install gr-ettus and not have it error out.
> 
> Is there a way to test that this new gnuradio instantiation is working
> okay (as opposed to my originally hand-built source version I did before
> pybombs)?

Jason,

PyBOMBS + RFNoC is a bit iffy, you need to manually edit the uhd.lwr
file to have it build the rfnoc-devel branch. Then, it *should* work,
but I'll admit I haven't tested it myself.

M


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

[Discuss-gnuradio] USRP Structure

[Logan Wu]

Hello,

Recently I read a paper on cognitive radio security (Secure
reconfiguration of software-defined radio). It highlights that the
operating system of cognitive radio node may be compromised as the
malware can exploit software vulnerabilities. I am wondering if the FPGA
and firmware are part of the OS? And can they be compromised during
runtime by malware?

Thank you,
Logan

-- 
Posted via http://www.ruby-forum.com/.

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

[Discuss-gnuradio] GNU Radio Installation Error

[Rama V]

Hello all,
I have uninstalled GNU Radio from /gnuradio/build directory because of an
error and I wish to reinstall it. But when I try to do that from the same
directory by using 'sudo make install', I keep getting an error as

[ 97%] Built target pygen_gr_fcd_swig_ecb11
[ 98%] Built target pygen_gr_fcd_python_fcd_37821
Linking CXX executable fcd_nfm_rx
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_free_config_descriptor'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_get_config_descriptor'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_open'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_detach_kernel_driver'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_get_device_list'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_control_transfer'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_exit'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_free_device_list'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_cancel_transfer'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_free_transfer'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_submit_transfer'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_interrupt_transfer'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_get_device_descriptor'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_claim_interface'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_handle_events'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_handle_events_completed'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_close'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_kernel_driver_active'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_release_interface'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_get_bus_number'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_init'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_get_device_address'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_alloc_transfer'
../../lib/libgnuradio-fcd-3.7.8git.so.0.0.0: undefined reference to
`libusb_get_active_config_descriptor'
collect2: error: ld returned 1 exit status
make[2]: *** [gr-fcd/examples/c++/fcd_nfm_rx] Error 1
make[1]: *** [gr-fcd/examples/c++/CMakeFiles/fcd_nfm_rx.dir/all] Error 2
make: *** [all] Error 2

 Please help as to what I can do. I am in the middle of my experiment. Any
suggestions will be kindly helpful.

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

Re: [Discuss-gnuradio] Constellation Objects & Messages

[Tom Rondeau]

On Fri, Sep 4, 2015 at 9:46 AM, Tudor Wolff  wrote:

> Hi,
>
> I'm using the gr-digital constellation decoder block in GRC
> (digital_constellation_decoder_cb) with constellation objects such as
> digital.constellation_qpsk(), etc.
>
> I want to modify the block such that it accepts a message and from
> that message the block can infer which constellation object to use. This
> will all be done in the message handler function. So for example:
>
> std::string message = pmt::symbol_to_string(msg);
>
> if(strcmp(message, "BPSK") == 0)
>   d_constellation = constellation_bpsk();
> else if(strcmp(message, "QPSK") == 0)
>   d_constellation = constellation_qpsk();
> ...etc
>
> Any ideas on how to set d_constellation as one of these objects?
>
> It is to operate in an OFDM receiver whereby the header of a packet
> transmission is decoded and from that, information about the payload
> constellation can be acquired. (802.11)
>
> Thanks


It sounds like you know what you are doing. What's the actual problem
you're having here?

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

[Discuss-gnuradio] gnuradio error

[cdl]

i am using uhd model in gnuradio,usrp_sink and usrp_source to do a loopback 
sysrem
and i connect the usrp tx and rx withRF feeder line,when i exe the grc ,i got 
the output 
UHD Error:
the receiver packet handler caught an exception.
runtimeerror:usb rx6 transfer status:LIBUSB_TRANSFER_ERROR
UHD source block got error code 0xf
i wants to konw how tp solve this problem


I am using https://github.com/anastas/gr-cdma/tree/master/apps cdma_txrx.grc___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRCon15 statistics

[Francisco Albani]

Oops!

I may have misused the word 'assisted'. I wished to mean 'attended' (I'm
expecting a number around 200).

Sorry and thanks!

2015-09-09 11:22 GMT-03:00 Tom Rondeau :

> On Wed, Sep 9, 2015 at 9:28 AM, Michael Dickens  > wrote:
>
>> Hi Francisco - I'm not sure we can definitely say how many people helped
>> out; we sort of ebbed and flowed as necessary to make it work. There were
>> another 2-6 of us meeting weekly (and emailing regularly) for
>> organizational purposes; some more often than others. We had 15-20
>> volunteers to help with registration, setup, posters, booths, etc... Some
>> of the sponsors (e.g., Ettus & DRS) helped out in various ways that were
>> not required of them, sort of as volunteers. Then there were the caterers &
>> venue folks, and the sponsors had their own helpers internal to each's
>> respective company. So, just guessing from the above numbers I'd say
>> something like 30-35 people had their hands in making sure GRCon15 came off
>> smoothly. Hope this helps! - MLD
>>
>> On Tue, Sep 8, 2015, at 07:05 PM, Francisco Albani wrote:
>>
>> I'm curious about how many people assisted to the all the annual
>> conferences, specially to the last one. And maybe there are more
>> interesting statistics to know.
>>
>>
> Also,because I wanted to give the people that helped out credit:
>
> http://www.trondeau.com/grcon15-organizing-committee/
>
> Tom
>
>
> ___
> 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] How to calculate BER in different modulations with OFDM using GNURadio Companion

[ANTONIO TAMAYO]

Hello,

 I'm doing my College final project about gnuradio companion. I have to
calculate the BER with OFDM using different modulations to the subcarriers.
After that, I have to do a graphic with the BER numbers. The configuration
I use is in the images attached.
Specifically, I have to send an image and after that I have to calculate
the BER. Also, I need to send an random vector and calculate the BER in the
same way as with the image. The image that I send in the example is called
"imagen" and it's attached in this email.

When I'm using GRC to calculate BER I always have the same problem. First I
try to simulate without introducing any noise and get a BER data. Then I
try to introduce AWGN noise and the BER data is the same. Clearly I'm
making a mistake, but I'm not able to identify what it is. In view of the
configuration used, someone could tell me which are my mistakes?


Also, I would like to know how to configure the block Channel Model
correctly.

Thank you all.


Sistema_OFDM_Pruebas.grc
Description: Binary data


Sistema_OFDM_Pruebas1.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ctrlport_probe2_x with gr-ctrlport-monitor in the absence of samples

[Tom Rondeau]

On Thu, Sep 3, 2015 at 7:17 AM, Eric Statzer  wrote:

> I'm attempting to use ctrlport_probe2_x and gr-ctrlport-monitor to probe
> points in a bursty flowgraph.  When I place a ctrlport_probe2_x probe
> somewhere in the part of my flowgraph that process samples only upon
> reception of a burst, gr-ctrlport-monitor doesn't fully initialize
> (populate its list of controlport "knobs") until after all
> ctrlport_probe2_x blocks have performed at least one call to work().
> Furthermore, the gr-ctrlport-monitor GUI is only responsive to user input
> if all ctrlport_probe2_x blocks in the flowgraph are regularly making calls
> to work() (i.e. gr-ctrlport-monitor query latency becomes equal to the time
> that elapses between processing individual bursts), so if for some reason
> bursts ever stop trickling to one of the probes, gr-ctrlport-monitor
> becomes unresponsive to user input.
>
> The gr-ctrlport-monitor behavior can be recreated with any simple
> flowgraph that contains a ctrlport_probe2_x that will never (or
> infrequently) make a call to work, such as: random_pdu ->
> pdu_to_tagged_stream -> ctrlport_probe2_b, where the "generate" port of the
> random_pdu block is left unconnected.  Attempting to connect
> gr-ctrlport-monitor to this flowgraph will cause gr-ctrlport-monitor to be
> unresponsive (have to kill it) almost immediately after the GUI is
> displayed.
>
> I wasn't sure if this is a limitation of ctrlport_probe2_x or
> gr-ctrlport-monitor, but I wanted to see if t was was possible to make the
> combination play nicely together when applied to a bursty flowgraph.
>
> Relevant system info:
>   GNU Radio 3.7.8
>   Thrift 0.9.2
>   Ubuntu 15.04
>
> Thanks in advance,
> Eric
>

Eric,

Have you tried increasing the number of threads in the thrift server? Try
making/modifying ~/.gnuradio/thrift.conf with:

[thrift]
nthreads = 10 (or some number greater than the number of probe blocks you
have)

(and make sure you have set "[ControlPort] config=~/.gnuradio/thrift.conf"
so it gets picked up.)

I'm wondering if it's just blocking on all endpoints in a single thread
right now before allowing any of them to return.

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

Re: [Discuss-gnuradio] Meta file time stamp

[Tom Rondeau]

On Wed, Sep 2, 2015 at 3:51 PM, Daniel Marlow  wrote:

> Dear All,
>
>   We are experiencing unexpected behavior with the time stamps in the meta
> file headers.   It
> appears that in cases where the flowgraph experiences data drops, the
> timestamp is properly
> updated.   However, in cases, where the flowgraph hits the maximum segment
> size (4 MB in our case),
> the calculation of timestamp is done in such a way that appears to neglect
> a decimation factor
> in one of our  blocks (keep_1_in_n). Details can be found below.   Any
> suggestions as to what's
> going on or what to do about it would be most appreciated.
>
> Sincerely,
> Dan Marlow
>
> Details:
>
>OS: Ubuntu 15.04 (GNU/Linux 3.19.0-26-generic x86_64)
>
>H/W:  Ettus B210 with GPSDO,
>  Intel(R) Core(TM) i5-4430 CPU @ 3.00GHz 8GB memory USB3
>
> gnuradio:  3.7.8
>
> Flowgraph:   This is provided to give an idea of what we are doing.  It is
> close to what we
>  are using, but not exact, since we edited the output
> generated by GRC.
>
>
>
>
> The actual top_block we are running is attached below.
>
>
>
>
> Results:  gr_read_file_metadata test09.dat > headers.txt
>


Yeah, I think I can see this as a problem. It's getting the sample rate
from the UHD device as a tag, but that doesn't know that the sample rate
has been changed through the flowgraph.

Can you open an issue on the gnuradio.org issue tracker to remind me about
this?

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

Re: [Discuss-gnuradio] [USRP] tracking the transmission/receiving process

[Martin Braun]

On 08.09.2015 15:41, Logan Wu wrote:
> Hello,
> 
> I've been tracking the source code to figure out the procedure of
> transmission/receiving. All I've found out is that the parameters (e.g.
> freq, gain, etc.) are stored in a property tree, and messages are
> inserted to the tail of queue. But how does the transmitter/receiver
> (daughter board) know when to transmit/receive? Specifically, which file
> in UHD host code does the job of notifying the hardware to
> transmit/receive?

I'm not sure if this answers your question, but it's the send() call
that initiates a transmit from the host side. This does a bunch of
things, depending on the device, but mainly starts sending data packets
to the USRP, and once they hit the radio, they're automatically sent.

On the rx, side, you do an issue_stream_cmd() and that will tell the
radio to start sending data to the host. The recv() call then picks up
the data from the host-local buffer.

If you have more specific questions, don't hesitate to drop them here!

Cheers,
Martin


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

Re: [Discuss-gnuradio] Meta file time stamp

[Daniel Marlow]

On Sep 9, 2015, at 12:46 PM, Tom Rondeau wrote:

> On Wed, Sep 2, 2015 at 3:51 PM, Daniel Marlow  wrote:
> Dear All,
> 
>   We are experiencing unexpected behavior with the time stamps in the meta 
> file headers.   It
> appears that in cases where the flowgraph experiences data drops, the 
> timestamp is properly
> updated.   However, in cases, where the flowgraph hits the maximum segment 
> size (4 MB in our case),
> the calculation of timestamp is done in such a way that appears to neglect a 
> decimation factor
> in one of our  blocks (keep_1_in_n). Details can be found below.   Any 
> suggestions as to what's
> going on or what to do about it would be most appreciated.
> 
> Sincerely,
> Dan Marlow
> 
> Details:
> 
>OS: Ubuntu 15.04 (GNU/Linux 3.19.0-26-generic x86_64)
> 
>H/W:  Ettus B210 with GPSDO,
>  Intel(R) Core(TM) i5-4430 CPU @ 3.00GHz 8GB memory USB3
> 
> gnuradio:  3.7.8
> 
> Flowgraph:   This is provided to give an idea of what we are doing.  It is 
> close to what we
>  are using, but not exact, since we edited the output 
> generated by GRC.
> 
> 
> 
> 
> The actual top_block we are running is attached below.
> 
> 
> 
> 
> Results:  gr_read_file_metadata test09.dat > headers.txt
> 
> 
> Yeah, I think I can see this as a problem. It's getting the sample rate from 
> the UHD device as a tag, but that doesn't know that the sample rate has been 
> changed through the flowgraph.
> 
> Can you open an issue on the gnuradio.org issue tracker to remind me about 
> this?
> 
> Tom
> 

Hi Tom,

   Thanks for getting back to me.   I had attempted to post an update to this, 
but something went wrong
with my mail client and it didn't go out.   

   Anyway, we figured out the problem. In a nutshell, we did not understand 
the meaning of 
the "relative rate change parameter" in the calling sequence for the meta file 
sink block.   That
is (obviously in hindsight) the way in which the system learns about decimation 
factors that
come in between the UHD and the file sink.   In particular, if there is a stage 
that decimates by N, 
the relative rate change parameter should be set to 1/N.

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

Re: [Discuss-gnuradio] gnuradio error

[Michael Dickens]

Hi cdl - Which USRP are you using? USRP1, B200, B210? Might make a
difference ... - MLD

On Wed, Sep 9, 2015, at 12:22 PM, cdl wrote:
> i am using uhd model in gnuradio,usrp_sink and usrp_source to do a
> loopback sysrem and i connect the usrp tx and rx withRF feeder
> line,when i exe the grc ,i got the output UHD Error: the receiver
> packet handler caught an exception. runtimeerror:usb rx6 transfer
> status:LIBUSB_TRANSFER_ERROR UHD source block got error code 0xf i
> wants to konw how tp solve this problem I am using
> https://github.com/anastas/gr-cdma/tree/master/apps cdma_txrx.grc
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Database Connection through GRC Blocks

[Richard Bell]

Hello everyone,

I'm trying to create a source and sink block which will connect to a
database to fetch and put data. The interface to the database is created
using shared libraries (.so files) that were defined by someone else, not
us. I have included the header file in my OOT module, which contains all
the interfaces, inside the include folder of the module.

I tried looking for possible solutions and many times it was mentioned to
use "target_link_libraries" in CMakeLists.txt file. Could anyone let me
know how and where it should be included, because I've had no success
getting this to work?

Note : The code gets compiled and installed fine, but there is this
exception after executing on gnuradio-companion.

Traceback (most recent call last):
File "/xxx/x/.py", line 754, in 
tb = ()
File "/xxx/x/.py", line 617, in __init__
self._src_0 = x._src("127.0.0.1", 1234, "Username", "password")
AttributeError: 'module' object has no attribute '_src'


Thank you,
Rich
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRCon15 attendees

[Sylvain Munaut]

> I’m also curious about the cross-section of people who attended. Would it be
> possible to post a list of names, and affiliations, of the registered
> attendees? (Email addresses would be useful too, but you/they may prefer not
> to do that).

How about do none of the above ...


Cheers,

   Sylvain

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