By convention, FFT sizes seem to be powers of 2. And Gnu Radio
Companion throws an error if you try to set a size of 16384 -- but will
accept 16383.
In some cases, I'd like to match FFT size to sample rate. For example,
with a 100 sample/second rate, I'd like to use a 100 bin FFT to
(hopefully) get 1.0 frames per second.
Is using a non-power-of-2 FFT simply less efficient, or are there other
concerns?
And is there a reason why GRC sets the limit at one less than 16384? If
8192 is the max because of power-of-two requirements, it would be more
helpful to state the limitation as ">8192" rather than "<16384".
Thanks,
John
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Thursday, November 30, 2017
Re: [Discuss-gnuradio] Rounding errors in PFB channelizer?
On 11/30/2017 02:08 PM, Müller, Marcus (CEL) wrote:
[ snip ]
[ snip ]
> You can do that (obviously, it works!), but I'd recommend you just use
> a channelizer with N=125 instead of 117! Your channel map can be used
> to ignore the channels you don't need (which seem to be the 4 upper and
> lower "edge" ones), and by only increasing the workload of the PFB ever
> so slightly (probably even actually decreasing it, because an 125=5³-
> FFT is likely to be much more efficient than an 117=3²·13-FFT), you get
> rid of the rational resampler, which not only brings more CPU load, but
> also a resampling filter response that might have ripple and aliases.
Thanks for that suggestion, Marcus! I have the resampler version
running right now but will change to use the channel count idea instead.
John
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Audio-file transmit with CODEC2 (based on Loopback-Example)
Hi everyone.
I'm trying to implement Audio-file transmit with CODEC2 Encoding/Decoding scheme.
For this purpose I redesigned the loopback-example from Martin Brown. Rx/Tx files in the attachment.
The audio is transmitting, but very abruptly, choppy.
What could cause this problem? Where should I look for a solution?
I tried to add synchronization tools ( FLL Fullband Edge, Costas Loop, MM Clock Recovery) but it had no effect.
I edited gr-audio-alsa.conf in order to tune audio-output. It did not help me either.
Any help would be greatly appreciated, thanks in advance.
TimurRe: [Discuss-gnuradio] Stop flow graph after fixed time
Hi all,
I have a quick question. Let us say I have a simple GRC with source and File sink. I would like to generate a sine wave for a fixed period (for example for 2 seconds) and stop the flow graph. Which means, I would like to save only 2 seconds of data in duration. I just wanted to know how I would be able to run my program, or save only a fixed period of signal not the entire generated sine wave.
Thank you
Re: [Discuss-gnuradio] Announcing USRP/GNU Radio and RFNoC Workshops in the Los Angeles Area
Hello Sumit:
Thank you for your interest. We are not yet sure of our plans for 2018, but we will very likely run something at NEWSDR and GNU Radio Conference in 2018. We will announce upcoming workshops here on the mailing list. Please feel free to check back with me directly in February for an update.
--Neel Pandeya
Thank you for your interest. We are not yet sure of our plans for 2018, but we will very likely run something at NEWSDR and GNU Radio Conference in 2018. We will announce upcoming workshops here on the mailing list. Please feel free to check back with me directly in February for an update.
--Neel Pandeya
On 29 November 2017 at 22:43, Sumit Kumar <sumit.kumar@alumni.iiit.ac.in> wrote:
Hello Neel,Sounds great!Do you have such workshop plans in Europe, probably in France/Germany. Recently I attended the NI workshop on the same during ICC 2017 Paris, but due to some reasons the agenda was not covered during the workshop. And it was very short also.I am very much interested in attending such detailed workshop. I request you to plan :)RegardsSumitOn Wed, Nov 29, 2017 at 6:58 PM, Neel Pandeya <neel.pandeya@ettus.com> wrote:______________________________============================================================ ==========
Ettus Research will be running a series of free, hands-on,
technical workshops in the Los Angeles area.
USRP, UHD, GNU Radio Workshop
Tuesday December 12, from 09:00 to 17:00
El Segundo, California, USA
RFNoC Workshop
Wednesday December 13, from 09:00 to 16:00
El Segundo, California, USA
USRP, UHD, GNU Radio Workshop
Thursday December 14, from 09:00 to 17:00
Santa Ana, California, USA
RFNoC Workshop
Friday December 15, from 09:00 to 16:00
Santa Ana, California, USA
============================================================ ==========
Descriptions of the Workshops:
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.
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 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.
============================================================ ==========
Addresses of the two workshop locations:
AWR Corporation / National Instruments
1960 E Grand Avenue, Suite 430
El Segundo, California, 90245
http://www.awrcorp.com/company/contact-us/locations
WinSoft
1932 E Deere Avenue, Suite 110
Santa Ana, California, 92705
http://www.winsoft.com/
http://www.ni.com/training/locations/
============================================================ ==========
Details and Logistics:
* The workshops are free, technical, and hands-on.
* The content of the two sessions of the USRP, UHD, GNU Radio Workshop
and the RFNoC Workshop will be the same between El Segundo
and Santa Ana.
* Each day, coffee and donuts/bagels will be provided at 08:30,
as well as lunch around 12:00, and an afternoon snack.
* In both workshops, laptop computers and USRP radios will be
provided for use. Attendees do not need to bring or prepare anything.
* Space is limited and will be allocated on a first-come,
first-serve basis.
* Registration is required in advance.
To register, please email "support@ettus.com".
* Be sure to specify your (1) full name, (2) email address,
(3) telephone number, (4) company/organization, and (5) which
workshop(s) you will attend.
* Your registration information will not be shared with any external
third-parties whatsoever.
* You are not considered to be registered until you have received
a confirmation email.
* For the USRP/GNU Radio 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 basic fundamental concepts in DSP and RF. For the RFNoC Workshop,
attendees should also have some basic familiarity with Verilog.
Extensive or deep experience with these topics is not necessary.
* Please email "support@ettus.com" if you have any questions.
* We look forward to seeing you there!
============================================================ ========== _________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Wednesday, November 29, 2017
Re: [Discuss-gnuradio] Announcing USRP/GNU Radio and RFNoC Workshops in the Los Angeles Area
Hello Neel,
Sounds great!
Do you have such workshop plans in Europe, probably in France/Germany. Recently I attended the NI workshop on the same during ICC 2017 Paris, but due to some reasons the agenda was not covered during the workshop. And it was very short also.
I am very much interested in attending such detailed workshop. I request you to plan :)
Regards
Sumit
On Wed, Nov 29, 2017 at 6:58 PM, Neel Pandeya <neel.pandeya@ettus.com> wrote:
============================================================ ==========
Ettus Research will be running a series of free, hands-on,
technical workshops in the Los Angeles area.
USRP, UHD, GNU Radio Workshop
Tuesday December 12, from 09:00 to 17:00
El Segundo, California, USA
RFNoC Workshop
Wednesday December 13, from 09:00 to 16:00
El Segundo, California, USA
USRP, UHD, GNU Radio Workshop
Thursday December 14, from 09:00 to 17:00
Santa Ana, California, USA
RFNoC Workshop
Friday December 15, from 09:00 to 16:00
Santa Ana, California, USA
============================================================ ==========
Descriptions of the Workshops:
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.
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 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.
============================================================ ==========
Addresses of the two workshop locations:
AWR Corporation / National Instruments
1960 E Grand Avenue, Suite 430
El Segundo, California, 90245
http://www.awrcorp.com/company/contact-us/locations
WinSoft
1932 E Deere Avenue, Suite 110
Santa Ana, California, 92705
http://www.winsoft.com/
http://www.ni.com/training/locations/
============================================================ ==========
Details and Logistics:
* The workshops are free, technical, and hands-on.
* The content of the two sessions of the USRP, UHD, GNU Radio Workshop
and the RFNoC Workshop will be the same between El Segundo
and Santa Ana.
* Each day, coffee and donuts/bagels will be provided at 08:30,
as well as lunch around 12:00, and an afternoon snack.
* In both workshops, laptop computers and USRP radios will be
provided for use. Attendees do not need to bring or prepare anything.
* Space is limited and will be allocated on a first-come,
first-serve basis.
* Registration is required in advance.
To register, please email "support@ettus.com".
* Be sure to specify your (1) full name, (2) email address,
(3) telephone number, (4) company/organization, and (5) which
workshop(s) you will attend.
* Your registration information will not be shared with any external
third-parties whatsoever.
* You are not considered to be registered until you have received
a confirmation email.
* For the USRP/GNU Radio 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 basic fundamental concepts in DSP and RF. For the RFNoC Workshop,
attendees should also have some basic familiarity with Verilog.
Extensive or deep experience with these topics is not necessary.
* Please email "support@ettus.com" if you have any questions.
* We look forward to seeing you there!
============================================================ ==========
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rounding errors in PFB channelizer?
And the resampler did the trick. Carriers are now nicely aligned. Thanks again!
On Nov 29, 2017, at 4:48 PM, John Ackermann N8UR <jra@febo.com> wrote:
Hi Marcus --
First, thanks for catching the typo in the channel map. There was no
plan to skip any channels; the goal is to get each channel in frequency
order (out0 = 540 kHz; out116 = 1700 kHz).
I did an experiment using a signal generator feeding the Red Pitaya
receiver and testing various channels. I started at the center channel,
1120 kHz, and found there was zero offset from nominal. I then went 1,
2, and 3 channels both lower and higher and came up with this map:
1090 +2.05 kHz
1100 +1.37 kHz
1110 +0.68 kHz
1120 0.00 kHz
1130 -0.68 kHz
1140 -1.37 kHz
1150 -2.05 kHz
Now, the sample rate coming out of the channelizer (hardware sample rate
of 1.25 msps divided by 117) is ~10.683 ksps. Gee, that 683 is pretty
close to the per-channel offset.
I didn't test further, but I strongly suspect this offset of ~680
Hz/channel continues in both directions, so that the signal has moved
far from the expected point as you get further away.
So, I think this tells me that the sample rate going into the PFB,
divided by the number of channels, needs to match the channel spacing.
That means a rational resampler going into the PFB to change 1.25 msps
to 1.17 msps.
I don't think I've ever read anything before that the sample_in rate has
to equal (channel_num x channel_spacing). It makes perfect sense when
you think about it, though. Your reference to the "channel raster" was
enough to make the light bulb turn on for me, and thanks very much for that!
Now to test with the resampler... Thanks much for helping me work
through this!
John
----
On 11/29/2017 01:20 PM, Müller, Marcus (CEL) wrote:Hi John,
given the fact that the frequency shifting of the individual sub-
filters is actually done via a DFT implemented by an FFT, and that
should have negligible phase accumulation error for benign FFT length
(i.e. channel numbers, let's say <1e6), hm.
First gut feeling, and easiest to check:
The output channels seem to have an offset in the range > of 400 to700 Hz versus the unchannelized input.
Make double sure that (sampling rate going into the channelizer) / 117
is actually exactly the raster you want.
If I interpret your file correctly, there's 1.25 MHz going into the
channelizer, so channel raster is 1250 / 117 kHz = 10.684 kHz. Hope
that's right!
What I could imagine are artifacts due to the non-perfect filter phase
linearity; but that would actually be a pretty intense speculation;
unless we're leaving the areas where our floating point numbers are
accurate enough, there shouldn't be non-linear (i.e. frequency-
shifting) behaviour.
I just threw together this:
from gnuradio.filter import firdes
file_sample_rate = 2.5e6
decimation = 2
pfb_taps = firdes.low_pass(2.0, file_sample_rate/decimation,10000,5000,
firdes.WIN_HAMMING, 6.76)
(pretty much lifted straight from your GRC)
Inspecting pfb_taps yielded a length of 603 taps, which we'll "evenly
as possible" have to distribute across the channels (117 of which
exist, as your channelizer map has length 116, but is missing the 56).
You could build a simple "unit test": Use a Vector source that pushes
[1 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 4 … 0 0 0 0 0 0 0 117
0 0 0 0 0 0 0 ]
through a length=117*8 IFFT, and push the result (after a vector-to-
stream) through your channelizer. You should see single tones in all
your channels. (The different amplitudes might help telling them
apart). Do they end up in the center of your bins?
Best regards,
Marcus
On Wed, 2017-11-29 at 10:34 -0500, John Ackermann N8UR wrote:I'm building a ridiculous flowgraph that breaks the AM broadcast band
(540 - 1700 kHz in the U.S.) into 117 10 kHz wide channels and measures
the energy in each. The thing is working but I see a frequency offset
in the output channels that is not present in the data before
channelizing. The output channels seem to have an offset in the range
of 400 to 700 Hz versus the unchannelized input.
The signal chain is:
2.5 msps recording centered at 1.4e6 Hz -> xlating filter, decimation 2,
output centered at 1.12e6 -> PFB channelizer with 117 channels, yielding
a channel rate of 10,683.760683...... samples per second.
Looking at the spectrum at the output of the xlating filter, the carrier
frequencies are correct. Looking at the output of a channel, the
carriers are offset by several hundred Hertz, always high. (Given the
absolute frequency is in the 1 MHz range, these offsets are parts in
1e3, a pretty large amount.)
I wonder if the large number of PFB channels is causing a rounding error
that results in these frequency offsets. Or is there something else
going on?
I can probably fudge the xlating filter frequency a bit to move the
carriers closer to nominal, but would like to understand what's happening.
I'm attaching the (absurdly huge) .grc file. The canvas is 4192 pixels
tall, so the flowgraph is smaller than the screenshot. :-)
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] Rounding errors in PFB channelizer?
Hi Marcus --
First, thanks for catching the typo in the channel map. There was no
plan to skip any channels; the goal is to get each channel in frequency
order (out0 = 540 kHz; out116 = 1700 kHz).
I did an experiment using a signal generator feeding the Red Pitaya
receiver and testing various channels. I started at the center channel,
1120 kHz, and found there was zero offset from nominal. I then went 1,
2, and 3 channels both lower and higher and came up with this map:
1090 +2.05 kHz
1100 +1.37 kHz
1110 +0.68 kHz
1120 0.00 kHz
1130 -0.68 kHz
1140 -1.37 kHz
1150 -2.05 kHz
Now, the sample rate coming out of the channelizer (hardware sample rate
of 1.25 msps divided by 117) is ~10.683 ksps. Gee, that 683 is pretty
close to the per-channel offset.
I didn't test further, but I strongly suspect this offset of ~680
Hz/channel continues in both directions, so that the signal has moved
far from the expected point as you get further away.
So, I think this tells me that the sample rate going into the PFB,
divided by the number of channels, needs to match the channel spacing.
That means a rational resampler going into the PFB to change 1.25 msps
to 1.17 msps.
I don't think I've ever read anything before that the sample_in rate has
to equal (channel_num x channel_spacing). It makes perfect sense when
you think about it, though. Your reference to the "channel raster" was
enough to make the light bulb turn on for me, and thanks very much for that!
Now to test with the resampler... Thanks much for helping me work
through this!
John
----
On 11/29/2017 01:20 PM, Müller, Marcus (CEL) wrote:
> Hi John,
>
> given the fact that the frequency shifting of the individual sub-
> filters is actually done via a DFT implemented by an FFT, and that
> should have negligible phase accumulation error for benign FFT length
> (i.e. channel numbers, let's say <1e6), hm.
>
> First gut feeling, and easiest to check:
>
>> The output channels seem to have an offset in the range > of 400 to
> 700 Hz versus the unchannelized input.
>
> Make double sure that (sampling rate going into the channelizer) / 117
> is actually exactly the raster you want.
>
> If I interpret your file correctly, there's 1.25 MHz going into the
> channelizer, so channel raster is 1250 / 117 kHz = 10.684 kHz. Hope
> that's right!
>
> What I could imagine are artifacts due to the non-perfect filter phase
> linearity; but that would actually be a pretty intense speculation;
> unless we're leaving the areas where our floating point numbers are
> accurate enough, there shouldn't be non-linear (i.e. frequency-
> shifting) behaviour.
>
> I just threw together this:
>
> from gnuradio.filter import firdes
>
> file_sample_rate = 2.5e6
> decimation = 2
>
> pfb_taps = firdes.low_pass(2.0, file_sample_rate/decimation,10000,5000,
> firdes.WIN_HAMMING, 6.76)
>
> (pretty much lifted straight from your GRC)
>
> Inspecting pfb_taps yielded a length of 603 taps, which we'll "evenly
> as possible" have to distribute across the channels (117 of which
> exist, as your channelizer map has length 116, but is missing the 56).
>
> You could build a simple "unit test": Use a Vector source that pushes
>
> [1 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 4 … 0 0 0 0 0 0 0 117
> 0 0 0 0 0 0 0 ]
>
> through a length=117*8 IFFT, and push the result (after a vector-to-
> stream) through your channelizer. You should see single tones in all
> your channels. (The different amplitudes might help telling them
> apart). Do they end up in the center of your bins?
>
> Best regards,
> Marcus
>
> On Wed, 2017-11-29 at 10:34 -0500, John Ackermann N8UR wrote:
>> I'm building a ridiculous flowgraph that breaks the AM broadcast band
>> (540 - 1700 kHz in the U.S.) into 117 10 kHz wide channels and measures
>> the energy in each. The thing is working but I see a frequency offset
>> in the output channels that is not present in the data before
>> channelizing. The output channels seem to have an offset in the range
>> of 400 to 700 Hz versus the unchannelized input.
>>
>> The signal chain is:
>>
>> 2.5 msps recording centered at 1.4e6 Hz -> xlating filter, decimation 2,
>> output centered at 1.12e6 -> PFB channelizer with 117 channels, yielding
>> a channel rate of 10,683.760683...... samples per second.
>>
>> Looking at the spectrum at the output of the xlating filter, the carrier
>> frequencies are correct. Looking at the output of a channel, the
>> carriers are offset by several hundred Hertz, always high. (Given the
>> absolute frequency is in the 1 MHz range, these offsets are parts in
>> 1e3, a pretty large amount.)
>>
>> I wonder if the large number of PFB channels is causing a rounding error
>> that results in these frequency offsets. Or is there something else
>> going on?
>>
>> I can probably fudge the xlating filter frequency a bit to move the
>> carriers closer to nominal, but would like to understand what's happening.
>>
>> I'm attaching the (absurdly huge) .grc file. The canvas is 4192 pixels
>> tall, so the flowgraph is smaller than the screenshot. :-)
>> _______________________________________________
>> 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] QPSK decoding help
Hi,
I am new to gnu radio and trying to do transmit and receive a file in QPSK. Here's my flow graph:
I get clean constellation at the output of costas loop. The part that is not working is the decoding. I am not quite sure where to go from here. I have tried using PSK modulator and demodulator as well. Any help would be greatly appreciated.
Thank you very much,
Damo
Re: [Discuss-gnuradio] Output block: vector of a vector
Everything is now clear!
Thank you for the patience and sorry for my little knowledge.
Thanks to rear1019, Marcus and MLD
Alice
Thank you for the patience and sorry for my little knowledge.
Thanks to rear1019, Marcus and MLD
Alice
Il 29/11/17 20:32, Michael Dickens ha scritto:
On Wed, Nov 29, 2017, at 11:30 AM, Alice Lo Valvo wrote:
I'm wondering if it is possible to make an output of a block that is a vector of a vector.
I tried with:
int
vector_source_tagged_impl::work(int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
std::vector<int> *optr = (std::vector<int> *) output_items[0];
and there are not compiling errors, but when I run GRC, it stops with this:
Executing: /usr/bin/python -u /home/alice/project_GNURADIO/tx_ofdm.py
Using Volk machine: avx2_64_mmx_orc
>>> Done
Any suggestions?
Thanks in advance.
Re: [Discuss-gnuradio] Output block: vector of a vector
Hi Alice - Inside "work" or "general_work", all you have is access to is pointers to buffers. The "shape" of them is inferred by the block implementation specifics, for example a pointer to unsigned char array, or pointer to float array. Recasting pointers as you describe will cause a crash, because the std::vector structure isn't valid. You can, on the other hand, instantiate a std::vector in the ::work code & provide it with the memory location of the data & length & that could work. Does this make sense? If not, maybe read up on the inner working of GR via some of TomR's presentations from GRCon & elsewhere; poke through the code in gnuradio-runtime to get an idea of the GR workings behind the scenes; read up on how C++ classes & memory allocations work. Doing those sorts of things will increase your knowledge base & improve how you use GR and interact with this list. Hope this helps! - MLD
On Wed, Nov 29, 2017, at 11:30 AM, Alice Lo Valvo wrote:
I'm wondering if it is possible to make an output of a block that is a vector of a vector.I tried with:intvector_source_tagged_impl::work(int noutput_items,gr_vector_const_void_star &input_items,gr_vector_void_star &output_items){std::vector<int> *optr = (std::vector<int> *) output_items[0];and there are not compiling errors, but when I run GRC, it stops with this:Executing: /usr/bin/python -u /home/alice/project_GNURADIO/tx_ofdm.pyUsing Volk machine: avx2_64_mmx_orc>>> DoneAny suggestions?Thanks in advance.
[Discuss-gnuradio] Announcing USRP/GNU Radio and RFNoC Workshops in the Los Angeles Area
======================================================================
Ettus Research will be running a series of free, hands-on,
technical workshops in the Los Angeles area.
USRP, UHD, GNU Radio Workshop
Tuesday December 12, from 09:00 to 17:00
El Segundo, California, USA
RFNoC Workshop
Wednesday December 13, from 09:00 to 16:00
El Segundo, California, USA
USRP, UHD, GNU Radio Workshop
Thursday December 14, from 09:00 to 17:00
Santa Ana, California, USA
RFNoC Workshop
Friday December 15, from 09:00 to 16:00
Santa Ana, California, USA
======================================================================
Descriptions of the Workshops:
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.
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 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.
======================================================================
Addresses of the two workshop locations:
AWR Corporation / National Instruments
1960 E Grand Avenue, Suite 430
El Segundo, California, 90245
http://www.awrcorp.com/company/contact-us/locations
WinSoft
1932 E Deere Avenue, Suite 110
Santa Ana, California, 92705
http://www.winsoft.com/
http://www.ni.com/training/locations/
======================================================================
Details and Logistics:
* The workshops are free, technical, and hands-on.
* The content of the two sessions of the USRP, UHD, GNU Radio Workshop
and the RFNoC Workshop will be the same between El Segundo
and Santa Ana.
* Each day, coffee and donuts/bagels will be provided at 08:30,
as well as lunch around 12:00, and an afternoon snack.
* In both workshops, laptop computers and USRP radios will be
provided for use. Attendees do not need to bring or prepare anything.
* Space is limited and will be allocated on a first-come,
first-serve basis.
* Registration is required in advance.
To register, please email "support@ettus.com".
* Be sure to specify your (1) full name, (2) email address,
(3) telephone number, (4) company/organization, and (5) which
workshop(s) you will attend.
* Your registration information will not be shared with any external
third-parties whatsoever.
* You are not considered to be registered until you have received
a confirmation email.
* For the USRP/GNU Radio 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 basic fundamental concepts in DSP and RF. For the RFNoC Workshop,
attendees should also have some basic familiarity with Verilog.
Extensive or deep experience with these topics is not necessary.
* Please email "support@ettus.com" if you have any questions.
* We look forward to seeing you there!
======================================================================
Ettus Research will be running a series of free, hands-on,
technical workshops in the Los Angeles area.
USRP, UHD, GNU Radio Workshop
Tuesday December 12, from 09:00 to 17:00
El Segundo, California, USA
RFNoC Workshop
Wednesday December 13, from 09:00 to 16:00
El Segundo, California, USA
USRP, UHD, GNU Radio Workshop
Thursday December 14, from 09:00 to 17:00
Santa Ana, California, USA
RFNoC Workshop
Friday December 15, from 09:00 to 16:00
Santa Ana, California, USA
======================================================================
Descriptions of the Workshops:
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.
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 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.
======================================================================
Addresses of the two workshop locations:
AWR Corporation / National Instruments
1960 E Grand Avenue, Suite 430
El Segundo, California, 90245
http://www.awrcorp.com/company/contact-us/locations
WinSoft
1932 E Deere Avenue, Suite 110
Santa Ana, California, 92705
http://www.winsoft.com/
http://www.ni.com/training/locations/
======================================================================
Details and Logistics:
* The workshops are free, technical, and hands-on.
* The content of the two sessions of the USRP, UHD, GNU Radio Workshop
and the RFNoC Workshop will be the same between El Segundo
and Santa Ana.
* Each day, coffee and donuts/bagels will be provided at 08:30,
as well as lunch around 12:00, and an afternoon snack.
* In both workshops, laptop computers and USRP radios will be
provided for use. Attendees do not need to bring or prepare anything.
* Space is limited and will be allocated on a first-come,
first-serve basis.
* Registration is required in advance.
To register, please email "support@ettus.com".
* Be sure to specify your (1) full name, (2) email address,
(3) telephone number, (4) company/organization, and (5) which
workshop(s) you will attend.
* Your registration information will not be shared with any external
third-parties whatsoever.
* You are not considered to be registered until you have received
a confirmation email.
* For the USRP/GNU Radio 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 basic fundamental concepts in DSP and RF. For the RFNoC Workshop,
attendees should also have some basic familiarity with Verilog.
Extensive or deep experience with these topics is not necessary.
* Please email "support@ettus.com" if you have any questions.
* We look forward to seeing you there!
======================================================================
[Discuss-gnuradio] problem with Tagged File Sink
I have a custom block that is adding the "burst" "True" and "False" tags
via:
add_item_tag(0, d_total_passed_samples, pmt::mp("burst"), pmt::mp("True"));
and
add_item_tag(0, d_total_passed_samples-1, pmt::mp("burst"),
pmt::mp("False"));
via:
add_item_tag(0, d_total_passed_samples, pmt::mp("burst"), pmt::mp("True"));
and
add_item_tag(0, d_total_passed_samples-1, pmt::mp("burst"),
pmt::mp("False"));
When I run it and look at the output via Tag Debug, I see:
----------------------------------------------------------------------
Tag Debug: burst
Input Stream: 00
Offset: 0 Source: n/a Key: burst Value: True
----------------------------------------------------------------------
----------------------------------------------------------------------
Tag Debug: burst
Input Stream: 00
Offset: 4999999 Source: n/a Key: burst Value: False
----------------------------------------------------------------------
Which seems correct to me. I have a sample rate of 5Msps, and was
attempting to save 1 seconds worth of data, so 5000000 seems like the
right number of samples to pass through.
Yet if I look at what gets generated by Tagged File Sink, I see this file:
file4_0_0.00000000.dat of size 39997440
Then when I close the flowgraph, it appears that it finishes writing the
file and it looks like this:
file4_0_0.00000000.dat of size 40000000
If I don't close the flowgraph and send another burst through, I get the
Tag Debug of:
----------------------------------------------------------------------
Tag Debug: burst
Input Stream: 00
Offset: 5000000 Source: n/a Key: burst Value: True
----------------------------------------------------------------------
----------------------------------------------------------------------
Tag Debug: burst
Input Stream: 00
Offset: 9999999 Source: n/a Key: burst Value: False
----------------------------------------------------------------------
and the file is the same name and now has a size of 39997440 until I
close it, then it has a size of 40000000.
So this leads me to believe that my Flase tag is not making it through
the stream, but I think I am pringing it right.
Is there a bug in Tagged File Sink (not likely)? Or am I doing
something wrong (where my money is)?
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rounding errors in PFB channelizer?
Does the number of channels have to be a power of 2?
On Wed, Nov 29, 2017 at 10:39 AM John Ackermann N8UR <jra@febo.com> wrote:
I'm building a ridiculous flowgraph that breaks the AM broadcast band
(540 - 1700 kHz in the U.S.) into 117 10 kHz wide channels and measures
the energy in each. The thing is working but I see a frequency offset
in the output channels that is not present in the data before
channelizing. The output channels seem to have an offset in the range
of 400 to 700 Hz versus the unchannelized input.
The signal chain is:
2.5 msps recording centered at 1.4e6 Hz -> xlating filter, decimation 2,
output centered at 1.12e6 -> PFB channelizer with 117 channels, yielding
a channel rate of 10,683.760683...... samples per second.
Looking at the spectrum at the output of the xlating filter, the carrier
frequencies are correct. Looking at the output of a channel, the
carriers are offset by several hundred Hertz, always high. (Given the
absolute frequency is in the 1 MHz range, these offsets are parts in
1e3, a pretty large amount.)
I wonder if the large number of PFB channels is causing a rounding error
that results in these frequency offsets. Or is there something else
going on?
I can probably fudge the xlating filter frequency a bit to move the
carriers closer to nominal, but would like to understand what's happening.
I'm attaching the (absurdly huge) .grc file. The canvas is 4192 pixels
tall, so the flowgraph is smaller than the screenshot. :-)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Very Respectfully,
Dan CaJacob
[Discuss-gnuradio] Output block: vector of a vector
Hi,
I'm wondering if it is possible to make an output of a block that is a vector of a vector.
I tried with:
int
vector_source_tagged_impl::work(int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
std::vector<int> *optr = (std::vector<int> *) output_items[0];
and there are not compiling errors, but when I run GRC, it stops with this:
Thanks in advance.
I'm wondering if it is possible to make an output of a block that is a vector of a vector.
I tried with:
int
vector_source_tagged_impl::work(int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
std::vector<int> *optr = (std::vector<int> *) output_items[0];
and there are not compiling errors, but when I run GRC, it stops with this:
Executing: /usr/bin/python -u /home/alice/project_GNURADIO/tx_ofdm.pyAny suggestions?
Using Volk machine: avx2_64_mmx_orc
>>> Done
Thanks in advance.
Alice
[Discuss-gnuradio] Rounding errors in PFB channelizer?
I'm building a ridiculous flowgraph that breaks the AM broadcast band
(540 - 1700 kHz in the U.S.) into 117 10 kHz wide channels and measures
the energy in each. The thing is working but I see a frequency offset
in the output channels that is not present in the data before
channelizing. The output channels seem to have an offset in the range
of 400 to 700 Hz versus the unchannelized input.
The signal chain is:
2.5 msps recording centered at 1.4e6 Hz -> xlating filter, decimation 2,
output centered at 1.12e6 -> PFB channelizer with 117 channels, yielding
a channel rate of 10,683.760683...... samples per second.
Looking at the spectrum at the output of the xlating filter, the carrier
frequencies are correct. Looking at the output of a channel, the
carriers are offset by several hundred Hertz, always high. (Given the
absolute frequency is in the 1 MHz range, these offsets are parts in
1e3, a pretty large amount.)
I wonder if the large number of PFB channels is causing a rounding error
that results in these frequency offsets. Or is there something else
going on?
I can probably fudge the xlating filter frequency a bit to move the
carriers closer to nominal, but would like to understand what's happening.
I'm attaching the (absurdly huge) .grc file. The canvas is 4192 pixels
tall, so the flowgraph is smaller than the screenshot. :-)
(540 - 1700 kHz in the U.S.) into 117 10 kHz wide channels and measures
the energy in each. The thing is working but I see a frequency offset
in the output channels that is not present in the data before
channelizing. The output channels seem to have an offset in the range
of 400 to 700 Hz versus the unchannelized input.
The signal chain is:
2.5 msps recording centered at 1.4e6 Hz -> xlating filter, decimation 2,
output centered at 1.12e6 -> PFB channelizer with 117 channels, yielding
a channel rate of 10,683.760683...... samples per second.
Looking at the spectrum at the output of the xlating filter, the carrier
frequencies are correct. Looking at the output of a channel, the
carriers are offset by several hundred Hertz, always high. (Given the
absolute frequency is in the 1 MHz range, these offsets are parts in
1e3, a pretty large amount.)
I wonder if the large number of PFB channels is causing a rounding error
that results in these frequency offsets. Or is there something else
going on?
I can probably fudge the xlating filter frequency a bit to move the
carriers closer to nominal, but would like to understand what's happening.
I'm attaching the (absurdly huge) .grc file. The canvas is 4192 pixels
tall, so the flowgraph is smaller than the screenshot. :-)
Tuesday, November 28, 2017
[Discuss-gnuradio] QPSK decoding help
Hi,
I am new to gnu radio and trying to do transmit and receive a file in QPSK. Here's my flow graph:
I get clean constellation at the output of costas loop. The part that is not working is the decoding. I am not quite sure where to go from here. I have tried using PSK modulator and demodulator as well. Any help would be greatly appreciated.
Thank you very much,
Damo
[Discuss-gnuradio] QPSK decoding help
Hi,
I am new to gnu radio and trying to do transmit and receive a file in QPSK. Here's my flow graph:
I get clean constellation at the output of costas loop. The part that is not working is the decoding. I am not quite sure where to go from here. I have tried using PSK modulator and demodulator as well. Any help would be greatly appreciated.
Thank you very much,
Damo
Re: [Discuss-gnuradio] Value of noutput_items
On Tue, 28 Nov 2017 at 19:09:19 +0100, Alice Lo Valvo wrote:
> d_i: 1
> /* noutput_items */512
> d_i: 2
> /* noutput_items */511
> d_i: 3
> /* noutput_items */48
> d_i: 4
> /* noutput_items */48
> ....
>
> Why? Any ideas?
> d_i: 1
> /* noutput_items */512
> d_i: 2
> /* noutput_items */511
> d_i: 3
> /* noutput_items */48
> d_i: 4
> /* noutput_items */48
> ....
>
> Why? Any ideas?
This behaviour is not a bug. The value of "noutput_items" depends on
several factors and is determined by GNU Radio's scheduler. If you want
"noutput_items" to be always a multiple of 48, call the function
"set_output_multiple(48)" in your block's constructor.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Value of noutput_items
Hi,
I don't understand the reason why the noutput_items is different in first two lines from the other lines (see below).
This is my code when I defines the io_signature:
I also tried to set Max Output Buffer to 48 (I noticed that warning messages disappeared), but it gives the following warning:
Thanks in advance,
Alice
I don't understand the reason why the noutput_items is different in first two lines from the other lines (see below).
Generating: '/home/alice/project_GNURADIO/tx_ofdm.py'
Executing: /usr/bin/python -u /home/alice/project_GNURADIO/tx_ofdm.py
Using Volk machine: avx2_64_mmx_orc
d_i: 1
/* noutput_items */8192
d_i: 2
(tx_ofdm.py:4455): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17
(tx_ofdm.py:4455): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17
(tx_ofdm.py:4455): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17
(tx_ofdm.py:4455): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 17
/* noutput_items */8191
d_i: 3
/* noutput_items */48
d_i: 4
/* noutput_items */48
d_i: 5
/* noutput_items */48
This is my code when I defines the io_signature:
gr::io_signature::make(0, 0, 0),
gr::io_signature::make(1, 1, sizeof(int)),
I also tried to set Max Output Buffer to 48 (I noticed that warning messages disappeared), but it gives the following warning:
gr::log :WARN: flat_flowgraph - Block (vector_source_tagged0) max output buffer set to 1024 instead of requested 48and then
d_i: 1Why? Any ideas?
/* noutput_items */512
d_i: 2
/* noutput_items */511
d_i: 3
/* noutput_items */48
d_i: 4
/* noutput_items */48
....
Thanks in advance,
Alice
Re: [Discuss-gnuradio] FFTW and python magic
Hi Dmitriy - From the error message, it's does not look like FFTW is the
issue. It looks like your OOT block "fbank_24_96_raw" was not found in
your OOT GR component "tolbi". Maybe it wasn't installed into the noted
PYTHONPATH? Do you have a public repo (e.g., on GitHub) that you can
point us to? Hope this helps! - MLD
On Tue, Nov 28, 2017, at 08:56 AM, Dmitriy Tochansky wrote:
> In my module I have to call fftw functions(gr::fft is not an option) but
> I found an issue.
> I linked module with fftw3f lib and install it. But when I run:
>
> ~$ PYTHONPATH=/usr/local/lib/python2.7/site-packages/ ./top_block.py
>
> I got an error:
>
> Traceback (most recent call last):
> File "./top_block.py", line 167, in <module>
> main()
> File "./top_block.py", line 155, in main
> tb = top_block_cls()
> File "./top_block.py", line 68, in __init__
> self.tolbi_fbank_24_96_raw_0 = tolbi.fbank_24_96_raw()
> AttributeError: 'module' object has no attribute 'fbank_24_96_raw'
>
> It's just a test module, so I commented out call to fftw_execute(there
> is only one for now)
> and everything goes on. Any ideas?
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
issue. It looks like your OOT block "fbank_24_96_raw" was not found in
your OOT GR component "tolbi". Maybe it wasn't installed into the noted
PYTHONPATH? Do you have a public repo (e.g., on GitHub) that you can
point us to? Hope this helps! - MLD
On Tue, Nov 28, 2017, at 08:56 AM, Dmitriy Tochansky wrote:
> In my module I have to call fftw functions(gr::fft is not an option) but
> I found an issue.
> I linked module with fftw3f lib and install it. But when I run:
>
> ~$ PYTHONPATH=/usr/local/lib/python2.7/site-packages/ ./top_block.py
>
> I got an error:
>
> Traceback (most recent call last):
> File "./top_block.py", line 167, in <module>
> main()
> File "./top_block.py", line 155, in main
> tb = top_block_cls()
> File "./top_block.py", line 68, in __init__
> self.tolbi_fbank_24_96_raw_0 = tolbi.fbank_24_96_raw()
> AttributeError: 'module' object has no attribute 'fbank_24_96_raw'
>
> It's just a test module, so I commented out call to fftw_execute(there
> is only one for now)
> and everything goes on. Any ideas?
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FFTW and python magic
Hi there!
In my module I have to call fftw functions(gr::fft is not an option) but
I found an issue.
I linked module with fftw3f lib and install it. But when I run:
~$ PYTHONPATH=/usr/local/lib/python2.7/site-packages/ ./top_block.py
I got an error:
Traceback (most recent call last):
File "./top_block.py", line 167, in <module>
main()
File "./top_block.py", line 155, in main
tb = top_block_cls()
File "./top_block.py", line 68, in __init__
self.tolbi_fbank_24_96_raw_0 = tolbi.fbank_24_96_raw()
AttributeError: 'module' object has no attribute 'fbank_24_96_raw'
It's just a test module, so I commented out call to fftw_execute(there
is only one for now)
and everything goes on. Any ideas?
--
D
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
In my module I have to call fftw functions(gr::fft is not an option) but
I found an issue.
I linked module with fftw3f lib and install it. But when I run:
~$ PYTHONPATH=/usr/local/lib/python2.7/site-packages/ ./top_block.py
I got an error:
Traceback (most recent call last):
File "./top_block.py", line 167, in <module>
main()
File "./top_block.py", line 155, in main
tb = top_block_cls()
File "./top_block.py", line 68, in __init__
self.tolbi_fbank_24_96_raw_0 = tolbi.fbank_24_96_raw()
AttributeError: 'module' object has no attribute 'fbank_24_96_raw'
It's just a test module, so I commented out call to fftw_execute(there
is only one for now)
and everything goes on. Any ideas?
--
D
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Monday, November 27, 2017
[Discuss-gnuradio] Python enabler block not working
"""
Embedded Python Blocks:
I am trying to make a python block that would act as an enabler between audio source and audio sink such that whenever I hit space from my keyboard the transmission begins and should stop after re hitting again. For starters I tried to start the transmission using just only one space hit but even this seems to be failing.I am using python block module from gnuradio. I get the following errors on my report panel. The source code of the block and the GRC screenshot is also attached.
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/gnuradio/gr/gateway.py", line 55, in eval
try: self._callback()
File "/usr/lib/python2.7/dist-packages/gnuradio/gr/gateway.py", line 160, in __gr_block_handle
) for i in self.__out_indexes],
TypeError: in method 'block_gw_message_type_work_args_return_value_set', argument 2 of type 'int'
thread[thread-per-block[1]: <block Embedded Python Block (1)>]: SWIG director method error. Error detected when calling 'feval_ll.eval'
If anybody figure out the problem or its probable solution please let me know
Regards
Abdul Samad
Embedded Python Blocks:
Each this file is saved, GRC will instantiate the first class it finds to get
ports and parameters of your block. The arguments to __init__ will be the
parameters. All of them are required to have default values!
"""
import numpy as np
import sys
from gnuradio import gr
class blk(gr.sync_block):
def __init__(self, enabler=False): # only default arguments here
gr.sync_block.__init__(
self,
name='Embedded Python Block',
in_sig=[np.float32],
out_sig=[np.float32]
)
self.enabler = enabler
def work(self, input_items, output_items):
key = sys.stdin.read(1)
if key==' ':
self.enabler=True
if self.enabler == True:
output_items[0][:] = input_items[0]
return len(output_items[0])
"""Created by Abdul Samad Usman"""
I am trying to make a python block that would act as an enabler between audio source and audio sink such that whenever I hit space from my keyboard the transmission begins and should stop after re hitting again. For starters I tried to start the transmission using just only one space hit but even this seems to be failing.I am using python block module from gnuradio. I get the following errors on my report panel. The source code of the block and the GRC screenshot is also attached.
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/gnuradio/gr/gateway.py", line 55, in eval
try: self._callback()
File "/usr/lib/python2.7/dist-packages/gnuradio/gr/gateway.py", line 160, in __gr_block_handle
) for i in self.__out_indexes],
TypeError: in method 'block_gw_message_type_work_args_return_value_set', argument 2 of type 'int'
thread[thread-per-block[1]: <block Embedded Python Block (1)>]: SWIG director method error. Error detected when calling 'feval_ll.eval'
If anybody figure out the problem or its probable solution please let me know
Regards
Abdul Samad
Re: [Discuss-gnuradio] 2 inputs and 1 output
Hi Alice - If you make both inputs tagged streams and your carrier
allocator inherits from the gr::tagged_stream_block, then you should be
able to do what you're asking for. Hope this helps! - MLD
On Mon, Nov 27, 2017, at 12:40 PM, Alice Lo Valvo wrote:
> I'm trying to make a custom OFDM Carrier Allocator in which there are 2
> inputs and 1 output.
> One input is the the normal flow and the second input is a vector, as
> shown in the figure.
> There are three main errors:
> - the lack of the tag in the second stream (I tryed to add a stream to
> tagged stream but the length of the second flow is different from the
> first and I don't know how fix this);
> - the different length of two streams;
> - the definition of the length of the output of the vector block (I
> prefer that it is dynamic) and of the second input of the custom block.
> Can someone help me to understand?
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
allocator inherits from the gr::tagged_stream_block, then you should be
able to do what you're asking for. Hope this helps! - MLD
On Mon, Nov 27, 2017, at 12:40 PM, Alice Lo Valvo wrote:
> I'm trying to make a custom OFDM Carrier Allocator in which there are 2
> inputs and 1 output.
> One input is the the normal flow and the second input is a vector, as
> shown in the figure.
> There are three main errors:
> - the lack of the tag in the second stream (I tryed to add a stream to
> tagged stream but the length of the second flow is different from the
> first and I don't know how fix this);
> - the different length of two streams;
> - the definition of the length of the output of the vector block (I
> prefer that it is dynamic) and of the second input of the custom block.
> Can someone help me to understand?
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] Phase sync with different frequencies
I've redone my experiments using the octo-clock as the time/clock/PPS source, but still can't get a reliable phase across multiple runs.
If I could get confirmation that the following is possible or impossible through timed commands, I'd have something to go on:
I have 2 USRP N210s each with an SBX. I form 2 "links":
link1 = tx of USRP-A connected to rx of USRP-B by a wire. tx/rx @ freq1
link2 = tx of USRP-B connected to rx of USRP-A by a wire. tx/rx @ freq2
All wire lengths are the same. I believe the wires are also from the same manufacturing batch.
Note that the frequencies being used on each link are different, so I don't expect the phase value to be the same across the links. Just the same for each link after restarting the USRPs.
I would like to see the same phase X on link1 no matter how many times I restart the 2 USRPs, and the same phase Y on link2.
Thank you,
AB
From: Bakshi, Arjun
Sent: Saturday, November 25, 2017 10:40:54 PM
To: John Shields; discuss-gnuradio@gnu.org; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Phase sync with different frequencies
Sent: Saturday, November 25, 2017 10:40:54 PM
To: John Shields; discuss-gnuradio@gnu.org; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Phase sync with different frequencies
Hi John,
Thanks for the reply. In my setup I make one of the USRPs use the time source and clock source as the MIMO cable, while both get an external PPS signal. Thinking about it now, it may have been better to just have everything from the external octo clock.
My goal is to get the same channel 'X' on link1, and the same channel 'Y' on link2, no matter how many times I restart the USRPs. Or every time I restart I should get a*X and a*Y as my channels on the two links where 'a' can change each time. Right now I observe different/random channels on each link every time I restart.
To clarify link1 = tx of USRP-A connected to rx of USRP-B by a wire. tx/rx @ freq1
link2 = tx of USRP-B connected to rx of USRP-A by a wire. tx/rx @ freq2
My concern is that maybe trying to set the tx and rx chains to different frequencies on the same daughterboard is not a "normal" operation. I was able to observe the same channel over multiple restarts when I use only 1 of the two links. But not when I use both.
I'll re-do my setup with time/clock source as octo-clock and update on Monday.
Thank you,
Arjun
From: John Shields <john.shields@xtra.co.nz>
Sent: Saturday, November 25, 2017 10:07:14 PM
To: Bakshi, Arjun; discuss-gnuradio@gnu.org; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Phase sync with different frequencies
Sent: Saturday, November 25, 2017 10:07:14 PM
To: Bakshi, Arjun; discuss-gnuradio@gnu.org; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Phase sync with different frequencies
Hi Arjun,
You mention that you have both units connected to 'external PPS source, and have a MIMO cable between them'. Not sure where the Vref is coming from but I presume over the MIMO cable?
I wonder how you are setting the clock and time source but I had an issue with my understanding of the behaviour of the MIMO cable in a configuration of 2xN200 each with an SBX.
Firstly, while the documentation on MIMO doesn't explicitly mention/highlight it, the PPS is not distributed over the MIMO cable – the RTC register of the master is copied to the slave which means that the slave doesn't actually 'see' a PPS over the MIMO cable. This was not a big issue for me but it meant that operations such as get_last_pps and setting the 'sync' on the slave to 'unknown PPS' both fail though, get_time_now works, so your timed commands should be good.
Secondly, while it is obvious when you think about it, if the slave is receiving Vref over the MIMO cable there will always be a fixed phase offset based, at a minimum, on the physical length of the MIMO so the Vref offset is a function of the frequency.
Once I understood especially the second behaviour, my system performed as I would expect.
I know that your setup is different than mine (I was just supplying the same signal through a splitter to each USRP and measuring the phase offset), but wonder if this might explain your observations?
Kind Regards,
John
Sent: Sunday, November 26, 2017 10:28 AM
Subject: [USRP-users] Phase sync with different frequencies
Hi all,
I'd like to use the phase resync freature on the SBX to get reliable phase alignment in the following setup:
link_freq1 = USRP-A TX @ Freq1 ---> USRP-B RX @ Freq1
link_freq2 = USRP-B TX @ Freq2 ---> USRP-A RX @ Freq2
Where link_freq1 should always have phase X, and link_freq2 should always have phase Y. I measure the phase by first calculating the channel over a wire for that link. I then look at the phase of the channel.
The USRPs are connected to an external PPS source, and have a MIMO cable between them.
I've been able to use timed commands to get the same channel/phase every time (after multiple restarts) in a single link setup like:
USRP-A TX @ Freq1 ---> USRP-B RX @ Freq1
But my code for phase sync in the 2-link setup doesn't seem to work(copied below). I understand that the phase of each link's channel may not be the same as the frequencies are different. However is it possible to set it up so that the phase/channel over wire in link_freq1 is always X and that in link_freq2 is always Y? Or is that impossible because of some hardware constraints?
Thank you,
AB
code snippet:
## 2-channel usrp source and sink have been initialized, everything except
## center feqs have been set
## uhd_usrp_source_0 is a multi usrp source block
## uhd_usrp_sink_0 is a multi usrp sink block
## both blocks have device args set to : "addr0=192.168.10.3, addr1=192.168.10.2"
## the following code is added in the init() function:
time.sleep(1)
future_cmd_time = self.uhd_usrp_source_0.get_time_last_pps() + uhd.time_spec_t(1.0)
self.uhd_usrp_source_0.set_command_time(future_cmd_time)
self.uhd_usrp_sink_0.set_command_time(future_cmd_time)
self.uhd_usrp_source_0.set_center_freq(uhd.tune_request(cf), 0)
self.uhd_usrp_source_0.set_center_freq(uhd.tune_request(cf2), 1)
self.uhd_usrp_sink_0.set_center_freq(uhd.tune_request(cf2), 0)
self.uhd_usrp_sink_0.set_center_freq(uhd.tune_request(cf), 1)
self.uhd_usrp_source_0.clear_command_time()
self.uhd_usrp_sink_0.clear_command_time()
##My guess is that both physical USRPs should see this time since MIMO+same external PPS
self.uhd_usrp_source_0.set_command_time(future_cmd_time)
self.uhd_usrp_sink_0.set_command_time(future_cmd_time)
self.uhd_usrp_source_0.set_center_freq(uhd.tune_request(cf), 0)
self.uhd_usrp_source_0.set_center_freq(uhd.tune_request(cf2), 1)
self.uhd_usrp_sink_0.set_center_freq(uhd.tune_request(cf2), 0)
self.uhd_usrp_sink_0.set_center_freq(uhd.tune_request(cf), 1)
self.uhd_usrp_source_0.clear_command_time()
self.uhd_usrp_sink_0.clear_command_time()
This is in the init() function. I don't re-tune the frequencies again after this.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[Discuss-gnuradio] 2 inputs and 1 output
I'm trying to make a custom OFDM Carrier Allocator in which there are 2
inputs and 1 output.
One input is the the normal flow and the second input is a vector, as
shown in the figure.
There are three main errors:
- the lack of the tag in the second stream (I tryed to add a stream to
tagged stream but the length of the second flow is different from the
first and I don't know how fix this);
- the different length of two streams;
- the definition of the length of the output of the vector block (I
prefer that it is dynamic) and of the second input of the custom block.
Can someone help me to understand?
Thank you,
Alice
Saturday, November 25, 2017
Re: [Discuss-gnuradio] [USRP-users] Phase sync with different frequencies
On 11/25/2017 10:40 PM, Bakshi, Arjun wrote:
If you have an Octoclock, I'd suggest using it for both USRPs, with equal-length cabling, from the same batch of cables.Hi John,
Thanks for the reply. In my setup I make one of the USRPs use the time source and clock source as the MIMO cable, while both get an external PPS signal. Thinking about it now, it may have been better to just have everything from the external octo clock.
My goal is to get the same channel 'X' on link1, and the same channel 'Y' on link2, no matter how many times I restart the USRPs. Or every time I restart I should get a*X and a*Y as my channels on the two links where 'a' can change each time. Right now I observe different/random channels on each link every time I restart.
To clarify link1 = tx of USRP-A connected to rx of USRP-B by a wire. tx/rx @ freq1
link2 = tx of USRP-B connected to rx of USRP-A by a wire. tx/rx @ freq2
My concern is that maybe trying to set the tx and rx chains to different frequencies on the same daughterboard is not a "normal" operation. I was able to observe the same channel over multiple restarts when I use only 1 of the two links. But not when I use both.
I'll re-do my setup with time/clock source as octo-clock and update on Monday.
Thank you,
Arjun
From: John Shields <john.shields@xtra.co.nz>
Sent: Saturday, November 25, 2017 10:07:14 PM
To: Bakshi, Arjun; discuss-gnuradio@gnu.org; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Phase sync with different frequenciesHi Arjun,You mention that you have both units connected to 'external PPS source, and have a MIMO cable between them'. Not sure where the Vref is coming from but I presume over the MIMO cable?I wonder how you are setting the clock and time source but I had an issue with my understanding of the behaviour of the MIMO cable in a configuration of 2xN200 each with an SBX.Firstly, while the documentation on MIMO doesn't explicitly mention/highlight it, the PPS is not distributed over the MIMO cable – the RTC register of the master is copied to the slave which means that the slave doesn't actually 'see' a PPS over the MIMO cable. This was not a big issue for me but it meant that operations such as get_last_pps and setting the 'sync' on the slave to 'unknown PPS' both fail though, get_time_now works, so your timed commands should be good.Secondly, while it is obvious when you think about it, if the slave is receiving Vref over the MIMO cable there will always be a fixed phase offset based, at a minimum, on the physical length of the MIMO so the Vref offset is a function of the frequency.Once I understood especially the second behaviour, my system performed as I would expect.I know that your setup is different than mine (I was just supplying the same signal through a splitter to each USRP and measuring the phase offset), but wonder if this might explain your observations?Kind Regards,JohnSent: Sunday, November 26, 2017 10:28 AMSubject: [USRP-users] Phase sync with different frequenciesHi all,
I'd like to use the phase resync freature on the SBX to get reliable phase alignment in the following setup:
link_freq1 = USRP-A TX @ Freq1 ---> USRP-B RX @ Freq1
link_freq2 = USRP-B TX @ Freq2 ---> USRP-A RX @ Freq2Where link_freq1 should always have phase X, and link_freq2 should always have phase Y. I measure the phase by first calculating the channel over a wire for that link. I then look at the phase of the channel.
The USRPs are connected to an external PPS source, and have a MIMO cable between them.
I've been able to use timed commands to get the same channel/phase every time (after multiple restarts) in a single link setup like:
USRP-A TX @ Freq1 ---> USRP-B RX @ Freq1
But my code for phase sync in the 2-link setup doesn't seem to work(copied below). I understand that the phase of each link's channel may not be the same as the frequencies are different. However is it possible to set it up so that the phase/channel over wire in link_freq1 is always X and that in link_freq2 is always Y? Or is that impossible because of some hardware constraints?
Thank you,
AB
code snippet:
## 2-channel usrp source and sink have been initialized, everything except
## center feqs have been set
## uhd_usrp_source_0 is a multi usrp source block
## uhd_usrp_sink_0 is a multi usrp sink block## both blocks have device args set to : "addr0=192.168.10.3, addr1=192.168.10.2"
## the following code is added in the init() function:
time.sleep(1)
future_cmd_time = self.uhd_usrp_source_0.get_time_last_pps() + uhd.time_spec_t(1.0)
##My guess is that both physical USRPs should see this time since MIMO+same external PPS
self.uhd_usrp_source_0.set_command_time(future_cmd_time)
self.uhd_usrp_sink_0.set_command_time(future_cmd_time)
self.uhd_usrp_source_0.set_center_freq(uhd.tune_request(cf), 0)
self.uhd_usrp_source_0.set_center_freq(uhd.tune_request(cf2), 1)
self.uhd_usrp_sink_0.set_center_freq(uhd.tune_request(cf2), 0)
self.uhd_usrp_sink_0.set_center_freq(uhd.tune_request(cf), 1)
self.uhd_usrp_source_0.clear_command_time()
self.uhd_usrp_sink_0.clear_command_time()
This is in the init() function. I don't re-tune the frequencies again after this.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Virus-free. www.avast.com
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Subscribe to:
Posts (Atom)