[Discuss-gnuradio] RFNoC FPGA Image Downloading

[Greg Rendon]

Hi all,

I am attempting to use RFNoC on an e312.
I am using a clean install from the latest Ubuntu 16.04 image in a VM as a
host.
I am following the guide at
https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
.

In section 6.3 when I run uhd_images_downloader the script selects the
e3xx_e310_fpga_default-g1c568e6.zip images file due to this being listed in
_MANIFEST_CONTENTS at the bottom of the script, despite the _UHD_VERSION
being listed as 4.0.0.rfnoc-devel-638-g93e5ff8a.  Additionally I cannot
find an images file with this UHD version in
http://files.ettus.com/binaries/images/ as the guide suggests nor anywhere
in files.ettus.com.  The result is that I have no FPGA images in my image
directory that contain rfnoc-devel in the filename.

Does someone know where this images file resides, or how to access the UHD
git repo that would correspond to the latest available images file, or how
to compile the correct image?
Possibly the default image now contains the RFNoC content?
Please advise.  Thanks.

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

Re: [Discuss-gnuradio] No module named _runtime_swig in version 3.7.11

[Cinaed Simson]

Type

  gnuradio-config-info --prefix

and post it.

Whether or not you need to add anything to your PYTHONPATH or
LD_LIBRARY_PATH depends on where you installed it.

-- Cinaed

On 04/05/2018 02:52 AM, Vladimir Komendantskiy wrote:
> Thanks for your questions. I will be happy to clarify the issue. It
> should be clear though that I don't have two different installations of
> gnuradio on any single machine at any point in time.
> 
> This is what I'm doing. My goals are to install and run gnuradio. My
> distribution, as I wrote earlier, is Debian testing, codenamed Buster.
> My previous installation I had since last Summer was compiled from
> source and was working without any Python environment errors.
> Unfortunately I removed that installation in order to install the latest
> gnuradio. And that one didn't work.
> 
> Ways I tried, each one after removing any other gnuradio installations:
> 
> 1. Install from package: sudo apt install gnuradio. Installation
> successful. gnuradio-companion displays the error dialog and exits.
> 
> 
> 2. build-gnuradio. Compilation of gnuradio fails because of this issue:
> 
>  
> https://github.com/gnuradio/gnuradio/commit/00c6f258259c61f25dc220402a9d07544942b414
> 
> 
> I fixed the issue by applying the above patch. Compilation succeeds. The
> error dialog is the same and gnuradio-companion still doesn't work.
> 
> 
> 3. Compile gnuradio from github. Managed to compile but same error dialog.
> 
> Furthermore, in each of the 3 cases above I first tried running
> gnuradio-companion with the default environment: LD_LIBRARY_PATH
> and PYTHONPATH _empty_. When that didn't work, I set the environment
> according to the README and to my Python version:
> 
> $ export PYTHONPATH=/usr/local/lib/python2.7/dist-packages
> $ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/local/lib
> 
> which didn't change the outcome a bit.
> 
> 
> For the sake of completeness, the dialog text is the following:
> 
> ==
> Cannot import gnuradio.
> 
> Is the model path environment variable set correctly?
>     All OS: PYTHONPATH
> 
> Is the library path environment variable set correctly?
>     Linux: LD_LIBRARY_PATH
>     Windows: PATH
>     MacOSX: DYLD_LIBRARY_PATH
> 
> 
> (No module named _runtime_swig)
> ==
> 
> 
> Any ideas apart from changing the Linux distribution? The distro has to
> stay. I can always go back to the version of gnuradio that worked but I
> have a feeling that the issue here is very minor and can be fixed if you
> know the details.
> 
> --Vladimir
> 
> 
> On 5 April 2018 at 00:02, Cinaed Simson  > wrote:
> 
> On 04/04/2018 08:58 AM, Vladimir Komendantskiy wrote:
> > Hi,
> >
> > I tried the latest Debian testing package of gnuradio and compiled from
> > git master (applying one version 3.7.12 patch to fix a compile-time 
> error).
> >
> > In both cases gnuradio-companion only displays the following error 
> dialog:
> 
> It's not clear what it is you're doing.
> 
> Bottom line, you can't have 2 installations of gnuradio on the same
> machine - if that's what you're doing.
> 
> Stick to one machine with only 1 installation of gnuradio - ideally a
> normal Debian install.
> 
> >
> > ==
> > Cannot import gnuradio.
> >
> > Is the model path environment variable set correctly?
> >     All OS: PYTHONPATH
> >
> > Is the library path environment variable set correctly?
> >     Linux: LD_LIBRARY_PATH
> >     Windows: PATH
> >     MacOSX: DYLD_LIBRARY_PATH
> >
> >
> > (No module named _runtime_swig)
> 
> Show us the answers to the above questions for PYTHONPATH,
> LD_LIBRARY_PATH.
> 
> Most likely they're not set correctly.
> 
> And why can't you use the default version 3.7.10 for Debian Jessie?
> Which version of Debian are you using?
> 
> -- Cinaed
> 
> > ==
> >
> > Is there a solution for that? I also tried setting the above mentioned
> > paths according to the git README to no avail.
> >
> > To be sure I tried on two different machines. One of those has a very
> > recent installation of Debian and no custom environment, only the
> > environment set by the distro.
> >
> > --Vladimir
> >
> >
> > ___
> > 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] Ways to improve latency of a low bandwidth stream

[Mario Rossi]

Hello list!

I'm using named pipes to stream data that I want modulated to gnuradio and I'm 
receiving modulated samples back using the same named pipes method. I then 
forward the modulated samples to a SDR via some low latency C implementation I 
wrote and perform the same operations in reverse at the receiving end.

I'm for now experimenting with a simple FSK modulator/demodulator running at 50 
kbaud/s, with 20 samples per symbol and 16 bytes (128 symbols) packet sizes. By 
embedding a timestamp in the packets before sending them I'm measuring an end 
to end latency ranging from 50 to 250 milliseconds (with a lot of jitter). 

This should mean that I have at least 300-1500 KB worth of buffers in my 
application (this was calculated using the data rate of the input/output data, 
it would be a much bigger number if I considered the modulated signal).

My understanding is that most of the latency is coming from my input/output 
pipes/sinks, as once the signal is modulated each byte of my data in/out 
becomes 8 (bits per byte) * 20 (samples per symbol), so that each gnuradio 
block working with the modulated signal, in a worst case scenario where 4096 
samples are processed at the time, only corresponds to 25 bytes worth of 
buffered, unmodulated data at any given time (4096/(8*20)). Since that my 
buffer is at least 100 times that and I don't have 100 blocks, that shouldn't 
be the issue.

Now on to my ideas on how to decrease latency for the input/output pipes/blocks:

1) Add padding bytes after the packet before sending it to the pipe/input file 
source block. Add a block after the file source dropping those padding bytes, 
that would probably require writing a custom block but should effectively 
eliminate any latency due to pipes and the file source block. A similar method 
can be used for the file sink block.

2) Use gr-eventstream to implement some version of the above. Not sure if this 
would be of any use though, I haven't spent much reading about it.

3) Hack the input/output sink blocks to (for example) allow a maximum output 
buffer lower than 4096 (I'm met with an error when I try to set the output 
buffer of my file source block to anything less than that).

4) Same as the first idea, but don't drop the padding bytes/data. Instead leave 
the blocks running with junk at the end, so that the output will be what you 
want and junk there after. This isn't a problem at the receiver because of how 
packet synchronisation works, but you would need to somehow know what's going 
on with your output IF pipe in your transmitter stream. This would also get rid 
of all the buffers/latency from all of gnuradio.

Any other ideas, or suggestions on what is the most feasible path?

I hope this email isn't too confusing, I know I don't have a gift for writing.

Thank you.

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

[Discuss-gnuradio] Read output of Packet Decoder, save it into a variable and print (inside generated python file)

[Marvin Biedermann]

Hello,
I am new to Gnuradio and I have a simple protocol of sending a textfile from 
one usrp to another. My receiver-flowgraph contains a USRP Source, GMSK Demod 
and Packet Decoder. Finally the output of the Packet Decoder is saved to a 
textfile with File Sink.
So far, the transmitter sends data of a textfile that only contains a 1 and the 
receiver stores it in a textfile. That works but this is quiet impractical.

I want to replace the step of saving the data by simply storing the output-data 
of the Packet Decoder in a variable and print it on the screen. I have extended 
the generated python-file of my flowgraph with a threadfunction. Inside this 
function, when the variable (containing the output-data of the Packet Decoder) 
has a speficif value (in this case a 1), then it triggers an event. If the 
variable has another value, maybe 2, it triggers another event.

But so far I have no idea how to get the byte-data from the output of the 
Packet-Decoder and save it to a variable or print in on the console and I did 
not find anything related to this problem. Could someone help me?
Greetings

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

[Discuss-gnuradio] Setting up OOT module to include/extend another OOT Module class

[Anshul Thakur]

I am trying to extend the gr-osmosdr source block with a PMT message sink
to send messages to it during runtime (to say, change the sample rate). I
intend to develop this as a part of a differnt OOT module.

How do I add such dependencies in the CMake list? (I am not very conversant
with Cmake)

Is there a good tutorial demonstrating one such example?

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

Re: [Discuss-gnuradio] GR-Inspector Issues

[Sebastian Müller]

Hi Shalom,
Am 5. April 2018 um 11:14:22, Shalom Dubinsky (smdubin...@gmail.com) schrieb:



Hello,

My name is Shalom Dubinsky, and I'm having some trouble with the
gr-inspector module.  I'm trying to use it to detect signals
in the 2.4ghz range, and I can't get reliable responses from
it.  Information on it seems scarce, so I'm asking
here.


First, I tried playing with the default example of 3 cosine waves
all summed with a noise source and run through the Signal Detector
block.  This works as expected - both the GUI Inspector sink
and the message debug output match. However, if I increase the
sample rate too much it loses any accuracy it had. 
Specifically, a sample rate of 4M only picks up two signals, and a
sample rate of 40M only picks up one signal. The error is much
higher in both of them, up to several hundred hz.  Decreasing
it to 20k gives me two reasonably accurate signals and one garbage
signal.


I also tried building my own graph.  I ran a single cosine
wave broadcasting at 200M through a noise generator, the signal
detector block, and the GUI Inspector block.  The sample rate
was consistent throughout the graph, and the FFT length was set to
4096 across the board. The center frequency of the inspector sink
was set at 200M.  The messages reported the signal to be at
800, while the graph displayed it as 208Mhz. Dropping the
cosine frequency to 800k allowed the signal detector to work more
or less correctly, but I had to change the center frequency of the
inspector sink to 0 for it to display the signal correctly. 
The problem at 800k was that the messages would alternate between
~80 and ~-10183594. This isn't the only time I saw negative
frequencies, either.


I next tried attaching it to a real radio.  When I broadcast a
signal(from a different radio) at 2.425ghz, it detected that a
signal was being broadcast, meaning it only reported something when
I broadcast a signal,  but did not accurately detect the
signal frequency. Instead, it would bounce around detecting
different frequencies.


Questions:
Generally I’d like to point to the official documentation [1].



* What is the relationship between sampling rate and signal
detection accuracy?
As described in the docs, the bandwidth of the signal is quantized with the 
block parameter ‚Rel. quantization‘.

This avoids high message load because of noise that slightly changes the 
detection boundries.

The quantization is relative to the used sample frequency. More info can be 
found in the docs and the code.



* What is the relationship between fft length and sampling
rate?  Is it related to signal detection accuracy?
Definitely. One FFT bin covers samp_rate/fft_length Hz. This is the maximum 
resolution

you can get for estimating the signal parameters and highly affects your 
accuracy.

In other words: there is a trade-off between bandwidth and resolution.


* Why does it sometimes report signals with negative
frequencies?
The frequencies are reported in *complex baseband*. Please research what that 
means,

but in a nutshell the frequencies are relative to the carrier frequency. This 
is intended behaviour.



* Why does it sometimes seem to report a frequency
delta?
I’m not sure what you mean by that. The message format is (center_freq, 
bandwidth).



* Is there anything else I'm missing about this module?
If you’re just planning to detect signals, you might be better extending the

gr-inspector detection block or write your own. The algorithm used is very basic

and only works well for steep signal flanks. Depending on the kind of signals 
you plan

to detect you probably want to use a different algorithm. I tried to 
communicate that in

my blog [2].




I've attached the gr-inspector example signal-detection .grc as
well as the modified .grcs mentioned earlier.
Also I’ve seen you mostly use the default parameters in the flowgraphs for your

application, which most likely won’t work. You need to understand the 
parameters and

sensibly choose them if you want the software to behave like you want.




Thank you,

Shalom Dubinsky

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




[1] http://gnuradio.github.io/gr-inspector/
[2] https://grinspector.wordpress.com/2016/06/26/week-5-midterms/

Regards,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE

signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] NEWSDR at WPI on Thr/Fri May 3/4

[Neel Pandeya]

*
  *** NEWSDR at WPI on Thr/Fri May 3/4 ***

*
* Symposium Registration Now Open *

 * Workshop Registration Now Open *

  * Poster Registration Now Open *

  * Registration Closes Saturday April 21 *

*
NEWSDR 2018

 New England Workshop on Software Defined Radio

   Eighth Annual

 Workshops
   Thursday May 3
   16:00 to 21:00

 Symposium
Friday May 4
   08:00 to 17:00

  Worcester Polytechnic Institute (WPI)
Worcester, Massachusetts, USA

  http://www.sdr-boston.org/

  Free Registration

*
 INVITATION TO PARTICIPATE

You are cordially invited to the 2018 New England Workshop on
Software Defined Radio (NEWSDR 2018), which is the eighth installment
of an annual series of symposium and workshop events organized by
the Boston SDR User Group (SDR-Boston).

This year, NEWSDR will be held at Worcester Polytechnic Institute (WPI),
and consists of a day-long symposium on Friday, as well as several
hands-on short courses the evening before on Thursday. You are welcome
to attend either or both events, which are entirely free.

Attendance is typically about 100 people, and attendees come from
both academia and industry.

*
 WORKSHOPS

   Thursday May 3
   16:00 to 21:00

 Worcester Polytechnic Institute (WPI)
  Atwater Kent Laboratories Building
   125 Salisbury Street
Worcester, MA 01609

  AGENDA

16:00 to 17:00   Pizza/Soda and Attendee Networking

17:00 to 18:00   Early Session for Setup

18:00 to 21:00   Workshop Events

Two workshops are being offered:

* "Real Time Over-the-Air Communications Links with MATLAB/Simulink"
   by MathWorks

* "FPGA Programming on the USRP with the RFNoC Framework"
   by Ettus Research

MathWorks and Ettus Research will each run a short course during the
evening before the main event. Short courses are technical, practical,
hands-on activities in a group setting. Specific topics and further
details about the short courses will be announced shortly. Attendance
is free, but advance registration is required. Free pizza and soda
will be provided.

 
Title:
FPGA Programming on the USRP using the RFNoC Framework

Abstract:
Ettus Research's RFNoC (RF Network-on-Chip) software framework is
designed to decrease the development time for experienced FPGA
engineers seeking to integrate IP into the USRP FPGA signal
processing chain. RFNoC is the framework for USRP devices that use
Xilinx 7-series FPGAs (E310, E312, X300, X310). RFNoC is built around
a packetized network infrastructure in the FPGA that handles the
transport of control and sample data between the host CPU and the
radio. Users target their custom algorithms to the FPGA in the form
of Computation Engines (CE), which are processing blocks that attach
to this network. CEs act as independent nodes on the network that can
receive and transmit data to any other node (e.g., another CE, the
radio block, or the host CPU).  Users can create modular,
FPGA-accelerated SDR applications by chaining CEs into a flow graph.
RFNoC is supported in UHD and GNU Radio. In this workshop, we will
present an interactive hands-on tutorial on RFNoC, including a
discussion on its design and capabilities, demonstrations of several
existing examples, and a walk-through on implementing a user-defined
CE and integrating the CE into GNU Radio.

Prerequisites:
Attendees do not need to bring any USRP radios or laptop computers.
All necessary hardware and software will be provided in the workshop.

Attendees should have some previous experience with Linux and using
the Linux command line, and basic familiarity with a programming
language such as C, C++, or Python, and have basic understanding of
fundamental concepts in DSP and RF. Attendees should also have some
basic familiarity with Verilog. Extensive or deep experience with
these topics is not necessary.

 
Title:
Real Time Over-the-Air Communications Links with MATLAB/Simulink

Abstract:
In this talk we show how you can transmit and receive over-the-air
signals with MATLAB and a variety of hardware, such as RTL-SDR,

[Discuss-gnuradio] Announcing GNU Radio and RFNoC Workshops in the Boston Area

[Neel Pandeya]

==
  ** Announcing GNU Radio and RFNoC Workshops in the Boston Area **

==
Ettus Research will be running two free, hands-on, technical workshops
in the Boston area, and you are welcome to attend!

==
*GNU Radio Workshop*

   Monday April 30
   09:00 to 17:00

National Instruments
  800 Cummings Park Drive
  Woburn, MA 01801
 (I-93, Exit 36, Washington Street)

Breakfast and Set-up start at 08:30
 Workshop runs from 09:00 to 17:00

Registration Link:
https://docs.google.com/forms/d/e/1FAIpQLSfGz45YGv1kN-LQIZFg9C2bW-7Vt8-81OXKtRQ-NTAM4BwcVg/viewform

Full Title:
Introduction to the USRP, UHD, and GNU Radio (Open-Source Toolchain)

Abstract:
This workshop will provide a thorough and practical introduction to
the USRP hardware and the open-source software toolchain (UHD and
GNU Radio). We will examine the hardware and architecture of the
entire USRP family of software-defined radios. We will discuss topics
such as how to get started using a new USRP device, how to install and
configure the open-source software toolchain, programming the USRP
using the UHD API from C++, using GNU Radio with the USRP and creating
and running flowgraphs, using GNU Radio from both GRC and Python, and
various debugging techniques. Several exercises will be performed,
such as implementing an FM transmitter and receiver. Various
demonstrations of wireless systems will be shown. A discussion of the
embedded E310 radio and using embedded SDR will be included. Several
other open-source tools will be discussed, such as GQRX, Fosphor,
Inspectrum, and several Out-of-Tree (OOT) modules. A discussion of
cellular applications, including OpenBTS and LTE stacks, as well as
GPS/GNSS applications will be presented. Several other miscellaneous
topics such as 10 Gigabit Ethernet networking, host system performance
tuning, X300/X310 device recovery, and some best practices will be
discussed. Attendees should come away with a solid foundation and
practical understanding of how to configure, program, and use the USRP
to implement a wide range range of wireless systems.

Prerequisites:
Attendees do not need to bring any USRP radios or laptop computers.
All necessary hardware and software will be provided in the workshop.

Attendees should have some previous experience with Linux and using
the Linux command line, and basic familiarity with a programming
language such as C, C++, or Python, and have basic understanding of
fundamental concepts in DSP and RF. Extensive or deep experience with
these topics is not necessary.

Attendees may optionally bring their own laptops for use in the
workshop. The laptop should have a minimum of 4 GB memory, 60 GB
of free disk space, one Ethernet port available, and one USB 3.0
port available, and should be able to have Linux installed onto them.

==
 *RFNoC Workshop*

  Thursday May 3
  16:00 to 21:00

Run as part of NEWSDR
  http://www.sdr-boston.org/
  http://ecewp.ece.wpi.edu/wordpress/sdr-boston/workshops/newsdr-18/

 Worcester Polytechnic Institute (WPI)
  Atwater Kent Laboratories Building
   125 Salisbury Street
Worcester, MA 01609

Pizza/Soda and Set-up start at 16:00
  Workshop runs from 17:00 to 21:00

Registration Link:
https://docs.google.com/forms/d/e/1FAIpQLSdNwqutzlxOhAgKQt17_XjIi-4pUUkTe5oO-u4TZaQt_iqnvg/viewform

Full Title:
FPGA Programming on the USRP with the RFNoC Framework

Abstract:
Ettus Research's RFNoC (RF Network-on-Chip) software framework is
designed to decrease the development time for experienced FPGA
engineers seeking to integrate IP into the USRP FPGA signal
processing chain. RFNoC is the framework for USRP devices that use
Xilinx 7-series FPGAs (E310, E312, X300, X310). RFNoC is built around
a packetized network infrastructure in the FPGA that handles the
transport of control and sample data between the host CPU and the
radio. Users target their custom algorithms to the FPGA in the form
of Computation Engines (CE), which are processing blocks that attach
to this network. CEs act as independent nodes on the network that can
receive and transmit data to any other node (e.g., another CE, the
radio block, or the host CPU).  Users can create modular,
FPGA-accelerated SDR applications by chaining CEs into a flow graph.
RFNoC is supported in UHD and GNU Radio. In this 

Re: [Discuss-gnuradio] GNURadio : GPL use cases

[Ben Hilburn]

Hi Fabian -

Sorry I didn't see your question a couple of days ago! Martin's response is
good. If you are not conveying GPL software outside of your company, then
you have no obligations and can do what you wish. If you are conveying a
product with GPL software to customers, then you are obligated to provide
your customer the source to the GPL software in that product.

If you have further general questions, I'm happy to answer them.
Realistically, though, as Martin said, copyright law is different in every
country, and I have no familiarity with the French system. If you are
building a product with GPL'd software and have questions, we recommend
that you consult an IP attorney familiar with the copyright law in your
country.

I hope that helps!

Cheers,
Ben

On Wed, Apr 4, 2018 at 5:32 PM, Martin Braun  wrote:

> On 04/03/2018 06:15 AM, MARCHAND Fabien wrote:
> > In a professionnal context, I want to use GNURadio in 2 cases :
> >
> > -  Work bench : for internally use in a internally developed
> > software, to test some hardware for example.
> >
> > -  Embedded : I think about having GNURadio embedded in hardware
> > which will be sold to customers, and be called by the same software
> > developed internally
> >
> >
> >
> > In those 2 cases, I have a doubt concerning the license. Does it force
> > us to distribute our software code in none/one/all of those cases ?
>
> Fabien,
>
> I'm not a lawyer, and you can't use the mailing list for binding legal
> advice, especially across jurisdictions (France might be different from
> the USA, for example). However, there's some comparisons that can be
> drawn to other commercial entities using GNU Radio:
>
> - If you're using GNU Radio internally on your work benches, you can do
> whatever you want (i.e., if no code or binaries leave your company).
>
> - As for your embedded devices, there are many embedded devices that
> have GPL'd software (like, most routers and many TV set top boxes), and
> the legalities over those have been pretty much hashed out. You can look
> up some of the rulings and see if they apply to you.
>   One thing to keep in mind is that if you write software that links
> against GNU Radio, your software is itself GPL. That doesn't mean your
> customer's software has to be GPL, e.g., if it calls into your
> application through some network interface. Of course, you will need to
> provide source codes for all GPL components (this is not a GNU Radio
> specific thing) upon request to anyone who is buying your embedded device.
>
> Like I said, GPL software usage is well understood, and all those rules
> apply to GNU Radio as well. I would encourage you to look around for
> other GPL-related license interpretations.
>
> -- Martin
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ERROR DURING GR-GFDM INSTALLATION BLOCKS IN GNURADIO.

[Andrej Rode]

Hi guys, 

thanks for the interest in gr-gfdm. 
I recently added the check for a volk version >= 1.3 due to otherwise
missing  `volk_32f_index_max_32u`. 
Thus you need volk 1.3 or higher to succesfully run gr-gfdm. 

As outlined the commpy python module is needed as well. Though it should
be easy to replace it with GNU Radio Python bindings if
necessary.

Feel free to file issues/contribute code at https://github.com/kit-cel/gr-gfdm/

Cheers
Andrej


On Wed, Apr 04, 2018 at 10:55:19PM -0400, Michael Dickens wrote:
> Hi Elkin - Reviewing the files "CMakeLists.txt" and
> "lib/CMakeLists.txt", it seems as though Volk is requested but not
> required, and then not used:{{{
> % find . -name CMakeLists.txt -exec grep -i volk {} +
> ./CMakeLists.txt:find_package(Volk "1.3")
> }}}
> Also, FFTW3f is used internally in the C++ code, but is not checked for
> or linked against. Those are pretty easy additions to those
> CMakeLists.txt files ... look at (for example, respectively of Volk and
> FFTW3f) gr-ieee802-15-4 and gr-iqbal. As already pointed out, you'll
> need to remove the "1.3" from the Volk check, since Volk API 1.3 isn't
> necessarily backward compatible with the 1.4 API; for the needs of gr-
> gfdm, either 1.3 or 1.4 seem to work. You also need the Python commpy
> package for testing. Hope this is useful. - MLD
> On Wed, Apr 4, 2018, at 5:24 PM, Elkin Ducuara wrote:
> > Hi everybody, I am trying to install "gr-gfdm" downloaded from GitHub,
> > I follow step by step installation process but when I execute the line
> > command "make test" got the next errors.> 
> > "user@USER:~/gr-gfdm/build$ make test
> > Running tests...
> > Test project /home/user/gr-gfdm/build
> >   Start  1: test_gfdm
> >  1/16 Test  #1: test_gfdm    Passed
> >0.05 sec>   Start  2: qa_modulator_cc
> >  2/16 Test  #2: qa_modulator_cc ..***Failed
> >0.33 sec>   Start  3: qa_sync_cc
> >  3/16 Test  #3: qa_sync_cc ...***Failed
> >0.21 sec>   Start  4: qa_cyclic_prefixer_cc
> >  4/16 Test  #4: qa_cyclic_prefixer_cc ***Failed
> >0.19 sec>   Start  5: qa_simple_modulator_cc
> >  5/16 Test  #5: qa_simple_modulator_cc ...***Failed
> >0.18 sec>   Start  6: qa_transmitter_chain_cc
> >  6/16 Test  #6: qa_transmitter_chain_cc ..***Failed
> >0.18 sec>   Start  7: qa_simple_receiver_cc
> >  7/16 Test  #7: qa_simple_receiver_cc ***Failed
> >0.18 sec>   Start  8: qa_advanced_receiver_sb_cc
> >  8/16 Test  #8: qa_advanced_receiver_sb_cc ...***Failed
> >0.32 sec>   Start  9: qa_resource_mapper_cc
> >  9/16 Test  #9: qa_resource_mapper_cc ***Failed
> >0.21 sec>   Start 10: qa_frame_energy_detector_cc
> > 10/16 Test #10: qa_frame_energy_detector_cc ..***Failed
> >0.18 sec>   Start 11: qa_simple_preamble_sync_cc
> > 11/16 Test #11: qa_simple_preamble_sync_cc ...***Failed
> >0.19 sec>   Start 12: qa_resource_demapper_cc
> > 12/16 Test #12: qa_resource_demapper_cc ..***Failed
> >0.18 sec>   Start 13: qa_remove_prefix_cc
> > 13/16 Test #13: qa_remove_prefix_cc ..***Failed
> >0.21 sec>   Start 14: qa_extract_burst_cc
> > 14/16 Test #14: qa_extract_burst_cc ..***Failed
> >0.20 sec>   Start 15: qa_py_channel_estimator_cc
> > 15/16 Test #15: qa_py_channel_estimator_cc ...   Passed
> >0.72 sec>   Start 16: qa_channel_estimator_cc
> > 16/16 Test #16: qa_channel_estimator_cc ..***Failed
> >0.18 sec> 
> > 13% tests passed, 14 tests failed out of 16
> > 
> > Total Test time (real) =   3.74 sec
> > 
> > The following tests FAILED:
> >   2 - qa_modulator_cc (Failed)
> >   3 - qa_sync_cc (Failed)
> >   4 - qa_cyclic_prefixer_cc (Failed)
> >   5 - qa_simple_modulator_cc (Failed)
> >   6 - qa_transmitter_chain_cc (Failed)
> >   7 - qa_simple_receiver_cc (Failed)
> >   8 - qa_advanced_receiver_sb_cc (Failed)
> >   9 - qa_resource_mapper_cc (Failed)
> >  10 - qa_frame_energy_detector_cc (Failed)
> >  11 - qa_simple_preamble_sync_cc (Failed)
> >  12 - qa_resource_demapper_cc (Failed)
> >  13 - qa_remove_prefix_cc (Failed)
> >  14 - qa_extract_burst_cc (Failed)
> >  16 - qa_channel_estimator_cc (Failed)
> > Errors while running CTest
> > Makefile:127: fallo en las instrucciones para el objetivo 'test'
> > make: *** [test] Error 8"
> > 
> > 
> > For show the cause of error of an specific item (for example "5 -
> > qa_simple_modulator_cc") I trying with the command line "ctest -V -R
> > qa_simple_modulator_cc" and the result is the next:> 
> > "user@USER:~/gr-gfdm/build$ ctest -V -R qa_simple_modulator_cc
> > UpdateCTestConfiguration  from :/home/user/gr-
> > gfdm/build/DartConfiguration.tcl> UpdateCTestConfiguration  from 
> > :/home/user/gr-
> > gfdm/build/DartConfiguration.tcl> Test project /home/user/gr-gfdm/build
> > Constructing 

Re: [Discuss-gnuradio] No module named _runtime_swig in version 3.7.11

[Vladimir Komendantskiy]

Thanks for your questions. I will be happy to clarify the issue. It should
be clear though that I don't have two different installations of gnuradio
on any single machine at any point in time.

This is what I'm doing. My goals are to install and run gnuradio. My
distribution, as I wrote earlier, is Debian testing, codenamed Buster. My
previous installation I had since last Summer was compiled from source and
was working without any Python environment errors. Unfortunately I removed
that installation in order to install the latest gnuradio. And that one
didn't work.

Ways I tried, each one after removing any other gnuradio installations:

1. Install from package: sudo apt install gnuradio. Installation
successful. gnuradio-companion displays the error dialog and exits.


2. build-gnuradio. Compilation of gnuradio fails because of this issue:

  https://github.com/gnuradio/gnuradio/commit/00c6f258259c61f25dc220402a9d07
544942b414

I fixed the issue by applying the above patch. Compilation succeeds. The
error dialog is the same and gnuradio-companion still doesn't work.


3. Compile gnuradio from github. Managed to compile but same error dialog.

Furthermore, in each of the 3 cases above I first tried running
gnuradio-companion with the default environment: LD_LIBRARY_PATH
and PYTHONPATH _empty_. When that didn't work, I set the environment
according to the README and to my Python version:

$ export PYTHONPATH=/usr/local/lib/python2.7/dist-packages
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/local/lib

which didn't change the outcome a bit.


For the sake of completeness, the dialog text is the following:

==
Cannot import gnuradio.

Is the model path environment variable set correctly?
All OS: PYTHONPATH

Is the library path environment variable set correctly?
Linux: LD_LIBRARY_PATH
Windows: PATH
MacOSX: DYLD_LIBRARY_PATH


(No module named _runtime_swig)
==


Any ideas apart from changing the Linux distribution? The distro has to
stay. I can always go back to the version of gnuradio that worked but I
have a feeling that the issue here is very minor and can be fixed if you
know the details.

--Vladimir


On 5 April 2018 at 00:02, Cinaed Simson  wrote:

> On 04/04/2018 08:58 AM, Vladimir Komendantskiy wrote:
> > Hi,
> >
> > I tried the latest Debian testing package of gnuradio and compiled from
> > git master (applying one version 3.7.12 patch to fix a compile-time
> error).
> >
> > In both cases gnuradio-companion only displays the following error
> dialog:
>
> It's not clear what it is you're doing.
>
> Bottom line, you can't have 2 installations of gnuradio on the same
> machine - if that's what you're doing.
>
> Stick to one machine with only 1 installation of gnuradio - ideally a
> normal Debian install.
>
> >
> > ==
> > Cannot import gnuradio.
> >
> > Is the model path environment variable set correctly?
> > All OS: PYTHONPATH
> >
> > Is the library path environment variable set correctly?
> > Linux: LD_LIBRARY_PATH
> > Windows: PATH
> > MacOSX: DYLD_LIBRARY_PATH
> >
> >
> > (No module named _runtime_swig)
>
> Show us the answers to the above questions for PYTHONPATH, LD_LIBRARY_PATH.
>
> Most likely they're not set correctly.
>
> And why can't you use the default version 3.7.10 for Debian Jessie?
> Which version of Debian are you using?
>
> -- Cinaed
>
> > ==
> >
> > Is there a solution for that? I also tried setting the above mentioned
> > paths according to the git README to no avail.
> >
> > To be sure I tried on two different machines. One of those has a very
> > recent installation of Debian and no custom environment, only the
> > environment set by the distro.
> >
> > --Vladimir
> >
> >
> > ___
> > 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] GR-Inspector Issues

[Shalom Dubinsky]

Hello,

My name is Shalom Dubinsky, and I'm having some trouble with the
gr-inspector module.  I'm trying to use it to detect signals in the 2.4ghz
range, and I can't get reliable responses from it.  Information on it seems
scarce, so I'm asking here.

First, I tried playing with the default example of 3 cosine waves all
summed with a noise source and run through the Signal Detector block.  This
works as expected - both the GUI Inspector sink and the message debug
output match. However, if I increase the sample rate too much it loses any
accuracy it had.  Specifically, a sample rate of 4M only picks up two
signals, and a sample rate of 40M only picks up one signal. The error is
much higher in both of them, up to several hundred hz.  Decreasing it to
20k gives me two reasonably accurate signals and one garbage signal.

I also tried building my own graph.  I ran a single cosine wave
broadcasting at 200M through a noise generator, the signal detector block,
and the GUI Inspector block.  The sample rate was consistent throughout the
graph, and the FFT length was set to 4096 across the board. The center
frequency of the inspector sink was set at 200M.  The messages reported the
signal to be at 800, while the graph displayed it as 208Mhz. Dropping
the cosine frequency to 800k allowed the signal detector to work more or
less correctly, but I had to change the center frequency of the inspector
sink to 0 for it to display the signal correctly.  The problem at 800k was
that the messages would alternate between ~80 and ~-10183594. This
isn't the only time I saw negative frequencies, either.

I next tried attaching it to a real radio.  When I broadcast a signal(from
a different radio) at 2.425ghz, it detected that a signal was being
broadcast, meaning it only reported something when I broadcast a signal,
 but did not accurately detect the signal frequency. Instead, it would
bounce around detecting different frequencies.

Questions:

* What is the relationship between sampling rate and signal detection
accuracy?

* What is the relationship between fft length and sampling rate?  Is it
related to signal detection accuracy?

* Why does it sometimes report signals with negative frequencies?

* Why does it sometimes seem to report a frequency delta?

* Is there anything else I'm missing about this module?

I've attached the gr-inspector example signal-detection .grc as well as the
modified .grcs mentioned earlier.

Thank you,

Shalom Dubinsky


signal_detection_ghz.grc
Description: application/gnuradio-grc


signal_detection.grc
Description: application/gnuradio-grc


live_signal_detection.grc
Description: application/gnuradio-grc


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

Re: [Discuss-gnuradio] FSK Burst emission

[samuel verdon]

Hello
I come back with my 2FSK burst emission. I will try to be as clear as I can .

As you recommended , I have checked the and install the eventstream block.
My modulation is the following :
- Frequency : 145 MHz
- Modulation : 2FSK
- Deviation : plus minus 1200kHz 
- Bitrate : 1200 bit/sec
- Hardware : LimeSDR

I have built my flowgraph like the eventstream example here:
https://oshearesearch.com/index.php/2015/05/31/building-a-burst-fsk-modem-in-gnu-radio-with-message-lambda-blocks-and-eventstream/

But adapted the parameter with mine. As there is no FSK nodulation block, these 
“message lambda block” creates the block I need.
I attached the grc file to this e-mail.

The result is not really clear for me. I connect my Lime to a spectrum 
analyser.  I was hoping for a signal like this one:
https://ibb.co/nzfFex 
The image was the result of a ADF sending random data with the parameter listed 
above.

But the output of my flowgraph(GRC) is the following:
https://ibb.co/iq3e6c 

And the result on the Spectum Analyser(SA) is the following:
https://ibb.co/kjEVCH 

I don’t understand why my signal looks so peaky and not with a good shape like 
the ADF.
- How can I have a signal similar to the ADF?
- How can I confirm that my data are sent at 1200bit/s?
- Do I have change something special in the lambda except my parameter?

Thank you in advance for your help.

Samuel

De : Müller, Marcus (CEL)
Envoyé le :Friday, March 30, 2018 18:27
À : discuss-gnuradio@gnu.org; willco...@gmail.com
Objet :Re: [Discuss-gnuradio] FSK Burst emission

So, to give a bit of insight where I think this will, medium-to-long
term end up:

We'll do message passing much more than before. We certainly need a way
of doing so with backpressure – tagged stream blocks does implement
that, but I frankly think that it's been an architectural experiment
that turned up a lot of problems, and we'll need to find a way to work
around these; I don't think TSB will be the go-to solution for this in
the long run.

Remote things will require two things:

· Ctrlport that actually works for most. And with that I mean we need
to replace Thrift.
· We'll need a common command format. I've had some code a while back
that basically made it easy for blocks to register a message handler
for every method; we need to standardize the way we're going to do
that. Essentially, the preferred way of mucking around with blocks'
states should be through messages, not direct method calls (that solves
a lot of threading issues for free, too)
· We'll need a sane format to transport these commands. ZeroMQ does
work well for a transport, but PMT is really holding us back at this
point. What use is a serialization library that's not fully machine-
independent, can't be used with static class members, makes it hard to
construct even the most basic structures, doesn't come with any
language bindings than those that  just as well could directly
interface directly with GR, and isn't installable without a full GR
runtime? (don't get me started about the object ownership/refcounting
issues that its Python wrapper introduces.) I'm partial to messagepack
at this point, but I've not done enough research to say it's 100% what
we should be using.

Best regards,
Marcus

On Thu, 2018-03-29 at 11:17 -0400, Jeff Long wrote:
> Two things I think would be a big win for GR are a clean interface
> with 
> message-oriented sources/sinks and easier distributed
> deployment/remote 
> control. Maybe that's three things.
> 
> On 03/29/2018 08:22 AM, Müller, Marcus (CEL) wrote:
> > That's actually an extensively great idea (though I admit it hadn't
> > crossed my mind so far)!
> > 
> > So, for this to make it upstream, first of all, it'd need an OK
> > from
> > Tim, as that probably kinda reassigns copyright to the FSF (Ben
> > would
> > be my go-to authority on that).
> > 
> > Then, I'd obviously have to play "grumpy mean old maintainer" a
> > bit:
> > I know there's qa_es.py, but I think it's been written before we
> > fixed
> > shutdown bugs, so, probably, there's a bit good functionality
> > that's
> > not covered by tests. Seeing how much "fun" we've had after
> > extending
> > runtime infrastructure (and that's what I'd consider eventstream),
> > to
> > avoid regressions in the future, I'd have to insist on a few
> > additional
> > tests. Don't know how they'd look like, which might be an
> > indication
> > I'd need to invite Tim for a beer and talk about what should be
> > tested.
> > Code coverage metrics alone do not make for good testing.
> > 
> > And: As cool as eventstream is, and as much as I like Tim's blog,
> > we'd
> > obviously need formal documentation; right now, I can't find a
> > docs/
> > folder in my gr-eventstream build directory, so at least the
> > building
> > of API docs needs to be fixed. And: if we do gr-eventstream, we'd
> > do it
> > properly, which means that someone needs to sit down and write a
> > guide
> > that integrates with the tutorials. I'm afraid a simple