[Discuss-gnuradio] synchronization problem

[김무연]

 As you mentioned I used costas loop block connected to usrp sources but it didn't work as i expected I want to the receiver to get cosine wave form that the transmitters senMy professor said to me that because it is not synchronized, the received signal looks like a barcodeI discribe my experimentLike you said, I don't send information
My goal is beamforing
transmitters ,2 usrps connected with mimo cable, send the same 
cosine signal and the receiver ,1 usrp, receives the signal and it sends
 1-bit feedback to transmitters
The receiver measures the power of the received signal and saves the biggest power
And it compares the biggest power with the power of recent received signal continually
If the power of recent received signal is bigger than the biggest power, it sends bit 1 as a feedback
if the power of recent received signal is not bigger than the biggest power, it sends bit 0 as feedback
If transmitters get bit 1, they change the phase of signal
If transmitters get bit 0, they maintain the phase of signal
I want to the usrps to find the best phase for beamforming automatically

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

[Discuss-gnuradio] What's VOLK (and why is it cool that we got it)? (was: VOLK v1.3.1 and v1.4)

[CEL]

It's worth noting that Nathan really did wonders here to make these
releases possible on short notice – so, this is a big "thank you" in
his direction.

I think once in a while it's worth introducing the fauna of our SDR
ecosystem:

VOLK is the "Vector Optimized Library of Kernels"[1].
GNU Radio has a lot of blocks that do math on a lot of data at once –
and it's generally a good idea to accelerate that by employing the
ability of modern CPUs to do SIMD – Single Instruction, Multiple Data. 

For example, you can add two streams of numbers simply by adding them
in a for loop, and compile that for loop into valid i386 assembler.
That would work on any PC that could possibly run a Windows or Linux
for x86, and it would get two numbers from RAM into registers, add
them, write the result from a register into RAM, get the next two
numbers, rinse, repeat.

SIMD instructions give processors the ability to be told things like
"here's four floating point numbers in memory, load them into a four-
float-register" and "here's two four-float-registers, add all four
pairs of floats". That often speeds up computation significantly. We
have these for MMX, S[S]SE{2,3,4,4.2}, AVX, NEON…

Of course, things like addition were the very first ones to be
accelerated by hand-coding them for the different SIMD instruction set
extensions. On the other hand, loops like 

for(unsigned i = 0; i < len; ++i) {
   a[i] += b[i]
}

are easy for compilers to optimize themselves. Thus, current VOLK
kernels can be dauntingly complex. One of these is the polarbutterfly
kernel – it's a core component for the Polar codes of rate-achieving
fame, implemented by Johannes Demel. Sadly, fixing a bug in that
required a release 1.4 in the end – which really put Nathan to work to
gather all goodness and bring it into releasable shape in fantastic
time.

So, if you're doing things with a lot of data, linear in RAM – take a
look at the VOLK project and its many existing kernels. We've got basic
arithmetics, trigonometrics, fast exp and logs, converters, byte
shufflers, detectors and bit-wise ops, and quite a bit more in stock
for the OP/s-hungry programmer[2].

Hope this inspires some appetite to make use of hand-optimized code, or
 to try one's own hand to use VOLK's infrastructure for selecting the
appropriate implementation on each machine.

Best regards,
Marcus


[1] http://libvolk.org
[2] http://libvolk.org/doxygen/kernels.html
On Mon, 2018-03-26 at 21:05 -0400, West, Nathan wrote:
> Hi all,
> 
> After a long time, new Volk releases are out. Release notes and downloads are 
> in the normal places on libvolk.org with md5sums and signatures signed by me 
> (nathan.w...@gnuradio.org).
> 
> v1.3.1 is a support release with bug fixes. I've switched to the "merge back" 
> model for this release where everything goes in to master and I cherry-pick 
> commits back to a support branch. I think this makes it easier to keep all of 
> the changes in one place-- but I'd like to know what kind of support users 
> would like. If you care about stable APIs for a long time I'd like to hear 
> about it so that I can develop a sense of how long or how many "stable" 
> branches I should keep around.
> 
> v1.4 has a ton of new stuff... It builds with python3, has new kernels, new 
> protokernels with lots of AVX support, and some added NEON support. I'm 
> pretty excited about this release since it adds a good bit of fast code!
> 
> Call for development:
> v1.5 is not out yet (or started), but I imagine that it will add support for 
> AVX512 and purge boost (that might make it in to a v1.4.1) as a dependency 
> and maybe replace some verbose support code with c++11. Right now there are 2 
> remaining lines that require boost. If you care about that kind of thing 
> check out the boost::filesystem use in volk_profile. I have heard of someone 
> adding AVX512 support, but I don't have a machine that supports it-- continue 
> down that path if you have a machine with support!
> 
> Cheers,
> Nathan
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Dropping samples "D" when CPU at 60%

[CEL]

Dear Bakshi,
again, we'd need to get a holistic view of what you're doing. All we
can do is speculate wildly based on your description.

> Is it just that the block I've written is not efficient enough? I
would expect higher CPU utilization in that case.

Possibly. Don't know. You tell us nothing about your block, especially
no code.

Please be more precise when asking, give your code, give actual
throughput benchmark, give us hardware information (which I've asked of
you before, but you never delivered). It's actually not easy to ask a
good question, but you really need to get better at it!

Fair warning: a sum rate of 18.75MS/s is really not that little. It's
absolutely possible you have shoddy network hardware or drivers that
just can't deal with that much data. Again, pure speculation, since you
tell us nothing about your hardware, or your OS, or anything about the
environment you're working in.

All that we can say is: something in your overall system, be it
hardware, your CPU, your RAM, your software or anything else, doesn't
work as you want it to.

Best regards,
Marcus

On Sat, 2018-03-24 at 19:30 +, Bakshi, Arjun wrote:
> Hi all,
> 
> I have written a block in python to detect and decode some packet 
> transmissions. I've noticed that when I have 3 rx streams running at 6.25Msps 
> (total network traffic is 75MB/s), the host starts dropping samples after a 
> while. The CPU utilization does not exceed 60%, and the Ethernet isn't being 
> saturated. I've increased buffer sizes (net.core.w/rmem_max) to the largest 
> values possible
> 
> A 'D' in the console means that the host isn't consuming samples fast enough.
> 
> Is it just that the block I've written is not efficient enough? I would 
> expect higher CPU utilization in that case.
> 
> I think the most expensive thing I'm doing is looking at each sample in a 
> stream of floats to find where the values goes above a threshold. This part 
> is in my block, and triggers the decoding logic, which is in the same block.
> 
> I don't know how to do this more efficiently. I'm thinking of re-writing it 
> in C++, but I don't know how much better it'll get.
> 
> Thank you,
> 
> AB
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM TX/RX

[CEL]

On Fri, 2018-03-23 at 14:21 -0700, Martin Braun wrote:
> If you've
> increased the number of carriers, PAPR also goes up (a bit).

Yep, by the same factor as you increase the number of carriers (proof
idea: time-symbol with worst PAPR is the discrete dirac over the vector
of FFT length N. That has a PAPR of N/1 = N if freq domain samples were
amplitude-limited to 1.)

The probability to hit a PAPR that bad is, however, limited.
Considering an M-PSK modulation on the N subcarriers. Then there's a
total of M^N possible time-domain OFDM symbols, but only M·N of these
are worst-PAPR, so
P(worst PAPR for N carriers) = M·N/M^N = N / M^(N-1)
assuming equally likely symbols. Since M^N pretty certainly grows
faster than N, your likelihood of ending up in the "worst PAPR"
scenario actually drops with N.

The story looks a bit different if you're not interested in the worst-
PAPR-symbol, but in all symbols that have a PAPR worse than some
threshold, e.g. 20dB. Especially for LTE, there's a lot of
simulative/monte carlo PAPR>threshold curves, as things like trading
clipping for amplifier efficiency plays a very commercially relevant
role there.

Best regards,

Marcus

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] synchronization problem

[CEL]

Hi!
On Tue, 2018-03-27 at 16:28 +0900, 김무연 wrote:
>  As you mentioned I used costas loop block connected to usrp sources but it 
> didn't work as i expected

What does that mean? What did you expect, what did it do instead, how
did you parameterize your costas loop? Plots/Graphs!

>  I want to the receiver to get cosine wave form that the transmitters sen

I understood that.

> My professor said to me that because it is not synchronized, the received 
> signal looks like a barcode

What does "look like a barcode" mean? In which visualization?

> I discribe my experiment
> Like you said, I don't send information 
> My goal is beamforing 

Aha!

> transmitters ,2 usrps connected with mimo cable,

So, USRP N210?

>  send the same cosine signal and the receiver ,1 usrp, receives the signal 
> and it sends 1-bit feedback to transmitters 

> The receiver measures the power of the received signal and saves the biggest 
> power 

So, a kind of a max hold envelope detector? For that, frequency
synchronization wouldn't matter at all. A cosine with 1kHz has exactly
the same envelope as one with 3 kHz. The only thing I could imagine if
that if your control (see below) has a bandwidth large relative to the
frequency of your oscillation, you get into trouble, because you're
"following" the power variations of the carrier. But I think we can
savely rule that one out.

> And it compares the biggest power with the power of recent received signal 
> continually 
> If the power of recent received signal is bigger than the biggest power, it 
> sends bit 1 as a feedback 
> if the power of recent received signal is not bigger than the biggest power, 
> it sends bit 0 as feedback 
> If transmitters get bit 1, they change the phase of signal 
> If transmitters get bit 0, they maintain the phase of signal 
> I want to the usrps to find the best phase for beamforming automatically 

That constitutes kind of a binary control loop.
I think you should probably be keeping track of what your phase
adjustment does – you probably just constantly jump around in far too
large steps to ever sensibly converge. Don't forget the beam pattern of
a phased 2-array is symmetric and not unambigous in itself – I don't
think a 1-bit quantized purely differentiating control loop fits your
problem at all, but I'm, to be completely honest, not enough of an
expert for discrete state systems to be able to make qualified
statements on control loop design myself.

Have you, before employing your automated adjustment algorithm,
actually verified your beamforming works as expected, for example by
manually adjusting phase, and looking for the direction of receive
power maxima? Have you designed your beamforming control loop with a
reasonable bandwidth? Why the 1-bit quantization? Seems like an
additional hurdle one would avoid for a start?

Best regards,
Marcus

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM TX/RX

[CEL]

Oooh, that's a nice plot!
This is way better than I would have anticipated. Can I attribute that
to awesome whitening properties of the code itself and following
scramblers/interleavers?

Marcus
On Tue, 2018-03-27 at 02:31 -0700, Ron Economos wrote:
> CCDF (Complementary Cumulative Distribution Function) is often used to show 
> PAPR probability. Here's what the GNU Radio DVB-T2 transmitter looks like at 
> 32K (27841 active) carriers with an without tone reservation PAPR reduction.
> 
> Ron
> On 03/27/2018 02:09 AM, Müller, Marcus (CEL) wrote:
> > On Fri, 2018-03-23 at 14:21 -0700, Martin Braun wrote:
> > > If you've
> > > increased the number of carriers, PAPR also goes up (a bit).
> > 
> > Yep, by the same factor as you increase the number of carriers (proof
> > idea: time-symbol with worst PAPR is the discrete dirac over the vector
> > of FFT length N. That has a PAPR of N/1 = N if freq domain samples were
> > amplitude-limited to 1.)
> > 
> > The probability to hit a PAPR that bad is, however, limited.
> > Considering an M-PSK modulation on the N subcarriers. Then there's a
> > total of M^N possible time-domain OFDM symbols, but only M·N of these
> > are worst-PAPR, so
> > P(worst PAPR for N carriers) = M·N/M^N = N / M^(N-1)
> > assuming equally likely symbols. Since M^N pretty certainly grows
> > faster than N, your likelihood of ending up in the "worst PAPR"
> > scenario actually drops with N.
> > 
> > The story looks a bit different if you're not interested in the worst-
> > PAPR-symbol, but in all symbols that have a PAPR worse than some
> > threshold, e.g. 20dB. Especially for LTE, there's a lot of
> > simulative/monte carlo PAPR>threshold curves, as things like trading
> > clipping for amplifier efficiency plays a very commercially relevant
> > role there.
> > 
> > Best regards,
> > 
> > Marcus
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM TX/RX

[Ron Economos]

Yes, I think the whitener does the trick. If you plot the PAPR of band 
limited white noise, it's pretty much the same curve.


Ron

On 03/27/2018 02:36 AM, Müller, Marcus (CEL) wrote:

Oooh, that's a nice plot!
This is way better than I would have anticipated. Can I attribute that
to awesome whitening properties of the code itself and following
scramblers/interleavers?

Marcus
On Tue, 2018-03-27 at 02:31 -0700, Ron Economos wrote:

CCDF (Complementary Cumulative Distribution Function) is often used to show 
PAPR probability. Here's what the GNU Radio DVB-T2 transmitter looks like at 
32K (27841 active) carriers with an without tone reservation PAPR reduction.

Ron
On 03/27/2018 02:09 AM, Müller, Marcus (CEL) wrote:

On Fri, 2018-03-23 at 14:21 -0700, Martin Braun wrote:

If you've
increased the number of carriers, PAPR also goes up (a bit).

Yep, by the same factor as you increase the number of carriers (proof
idea: time-symbol with worst PAPR is the discrete dirac over the vector
of FFT length N. That has a PAPR of N/1 = N if freq domain samples were
amplitude-limited to 1.)

The probability to hit a PAPR that bad is, however, limited.
Considering an M-PSK modulation on the N subcarriers. Then there's a
total of M^N possible time-domain OFDM symbols, but only M·N of these
are worst-PAPR, so
P(worst PAPR for N carriers) = M·N/M^N = N / M^(N-1)
assuming equally likely symbols. Since M^N pretty certainly grows
faster than N, your likelihood of ending up in the "worst PAPR"
scenario actually drops with N.

The story looks a bit different if you're not interested in the worst-
PAPR-symbol, but in all symbols that have a PAPR worse than some
threshold, e.g. 20dB. Especially for LTE, there's a lot of
simulative/monte carlo PAPR>threshold curves, as things like trading
clipping for amplifier efficiency plays a very commercially relevant
role there.

Best regards,

Marcus


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

[Discuss-gnuradio] How to stop GRC flowgraph after a defined time

[Priyanka]

Hello,

I am very new to GNURadio and I have made a FM radio receiver in which I 
am recording the data in a file sink.


But, I want to record the data for one millisecond(means i want to stop 
the flow graph after 1 millisecond). How can I run the execution of the 
flow graph for this specified time?


Any help would be appreciated. Thank you.

Priyanka


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

[Discuss-gnuradio] How to stop GRC flowgraph after a defined time

[Priyanka Priyadarshini]

Hello,

I am very new to GNURadio and I have made a FM radio receiver in which I am
recording the data in a file sink.

But, I want to record the data for one millisecond(means i want to stop the
flow graph after 1 millisecond). How can I run the execution of the flow
graph for this specified time?

Any help would be appreciated. Thank you.

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

Re: [Discuss-gnuradio] How to stop GRC flowgraph after a defined time

[Gilad Beeri (ApolloShield)]

Check out the Head block, which takes N as input, and stops (the whole
flowgraph as a result of how GNU Radio works) after N samples.
N = sample_rate * desired_duration


On Tue, Mar 27, 2018 at 2:08 PM Priyanka Priyadarshini <
ppriyadarshin...@gmail.com> wrote:

> Hello,
>
> I am very new to GNURadio and I have made a FM radio receiver in which I
> am recording the data in a file sink.
>
> But, I want to record the data for one millisecond(means i want to stop
> the flow graph after 1 millisecond). How can I run the execution of the
> flow graph for this specified time?
>
> Any help would be appreciated. Thank you.
>
> Priyanka
> ___
> 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] How to stop GRC flowgraph after a defined time

[Priyanka Priyadarshini]

Thanks for your reply. But where should I connect the input and output port
of this head block?

Thanks

On Tue, Mar 27, 2018 at 1:26 PM, Gilad Beeri (ApolloShield) <
gi...@apolloshield.com> wrote:

> Check out the Head block, which takes N as input, and stops (the whole
> flowgraph as a result of how GNU Radio works) after N samples.
> N = sample_rate * desired_duration
>
>
> On Tue, Mar 27, 2018 at 2:08 PM Priyanka Priyadarshini <
> ppriyadarshin...@gmail.com> wrote:
>
>> Hello,
>>
>> I am very new to GNURadio and I have made a FM radio receiver in which I
>> am recording the data in a file sink.
>>
>> But, I want to record the data for one millisecond(means i want to stop
>> the flow graph after 1 millisecond). How can I run the execution of the
>> flow graph for this specified time?
>>
>> Any help would be appreciated. Thank you.
>>
>> Priyanka
>> ___
>> 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] How to stop GRC flowgraph after a defined time

[CEL]

Wherever you like, as you know (or can easily infer) the sampling rate
at every step in your signal chain.

I'd recommend you start by reading the chapter 0 and 1 of https://tutor
ials.gnuradio.org ; afterwards, a lot of things will be clearer to you
and you might be able to answer such question much quicker yourself.
On Tue, 2018-03-27 at 13:41 +0200, Priyanka Priyadarshini wrote:
> Thanks for your reply. But where should I connect the input and output port 
> of this head block?
> 
> Thanks
> 
> On Tue, Mar 27, 2018 at 1:26 PM, Gilad Beeri (ApolloShield) 
>  wrote:
> > Check out the Head block, which takes N as input, and stops (the whole 
> > flowgraph as a result of how GNU Radio works) after N samples.
> > N = sample_rate * desired_duration
> > 
> > 
> > On Tue, Mar 27, 2018 at 2:08 PM Priyanka Priyadarshini 
> >  wrote:
> > > Hello,
> > > 
> > > I am very new to GNURadio and I have made a FM radio receiver in which I 
> > > am recording the data in a file sink.
> > > 
> > > But, I want to record the data for one millisecond(means i want to stop 
> > > the flow graph after 1 millisecond). How can I run the execution of the 
> > > flow graph for this specified time?
> > > 
> > > Any help would be appreciated. Thank you.
> > > 
> > > Priyanka
> > > ___
> > > 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

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to stop GRC flowgraph after a defined time

[Ed Criscuolo]

Priyanka,

Based on what you've described so far, it sounds like the most
likely place for it is right after the signal source (UHD, Osmocom,
FCD, etc).

For example, if your source is sampling at a rate of 1e6 (one million)
samples per second, put the head block after it and set the count to
1000. This will shut down after 1 millisecond.

@(^.^)@ Ed


On 3/27/18 7:41 AM, Priyanka Priyadarshini wrote:

Thanks for your reply. But where should I connect the input and output
port of this head block?

Thanks

On Tue, Mar 27, 2018 at 1:26 PM, Gilad Beeri (ApolloShield)
mailto:gi...@apolloshield.com>> wrote:

Check out the Head block, which takes N as input, and stops (the
whole flowgraph as a result of how GNU Radio works) after N samples.
N = sample_rate * desired_duration


On Tue, Mar 27, 2018 at 2:08 PM Priyanka Priyadarshini
mailto:ppriyadarshin...@gmail.com>> wrote:

Hello,

I am very new to GNURadio and I have made a FM radio receiver in
which I am recording the data in a file sink.

But, I want to record the data for one millisecond(means i want
to stop the flow graph after 1 millisecond). How can I run the
execution of the flow graph for this specified time?

Any help would be appreciated. Thank you.

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





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




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

Re: [Discuss-gnuradio] How to stop GRC flowgraph after a defined time

[Priyanka Priyadarshini]

thank you.

One more question: Where can i find the python code files of GNUradio
blocks?

Thank you

On Tue, Mar 27, 2018 at 2:01 PM, Müller, Marcus (CEL) 
wrote:

> Wherever you like, as you know (or can easily infer) the sampling rate
> at every step in your signal chain.
>
> I'd recommend you start by reading the chapter 0 and 1 of https://tutor
> ials.gnuradio.org ; afterwards, a lot of things will be clearer to you
> and you might be able to answer such question much quicker yourself.
> On Tue, 2018-03-27 at 13:41 +0200, Priyanka Priyadarshini wrote:
> > Thanks for your reply. But where should I connect the input and output
> port of this head block?
> >
> > Thanks
> >
> > On Tue, Mar 27, 2018 at 1:26 PM, Gilad Beeri (ApolloShield) <
> gi...@apolloshield.com> wrote:
> > > Check out the Head block, which takes N as input, and stops (the whole
> flowgraph as a result of how GNU Radio works) after N samples.
> > > N = sample_rate * desired_duration
> > >
> > >
> > > On Tue, Mar 27, 2018 at 2:08 PM Priyanka Priyadarshini <
> ppriyadarshin...@gmail.com> wrote:
> > > > Hello,
> > > >
> > > > I am very new to GNURadio and I have made a FM radio receiver in
> which I am recording the data in a file sink.
> > > >
> > > > But, I want to record the data for one millisecond(means i want to
> stop the flow graph after 1 millisecond). How can I run the execution of
> the flow graph for this specified time?
> > > >
> > > > Any help would be appreciated. Thank you.
> > > >
> > > > Priyanka
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to stop GRC flowgraph after a defined time

[CEL]

Within the gnuradio source tree, https://github.com/gnuradio/gnuradio .
 Where they've been installed depends on your system, but you'd
typically look in places like
/usr/[local/]lib[64]/python2.7/{site,dist}-packages/gnuradio

Note that most of the blocks that come with GNU Radio aren't written in
Python, but C++.

Best regards,
Marcus

On Tue, 2018-03-27 at 14:25 +0200, Priyanka Priyadarshini wrote:
> thank you.
> 
> One more question: Where can i find the python code files of GNUradio blocks? 
> 
> Thank you
> 
> On Tue, Mar 27, 2018 at 2:01 PM, Müller, Marcus (CEL)  wrote:
> > Wherever you like, as you know (or can easily infer) the sampling rate
> > at every step in your signal chain.
> > 
> > I'd recommend you start by reading the chapter 0 and 1 of https://tutor
> > ials.gnuradio.org ; afterwards, a lot of things will be clearer to you
> > and you might be able to answer such question much quicker yourself.
> > On Tue, 2018-03-27 at 13:41 +0200, Priyanka Priyadarshini wrote:
> > > Thanks for your reply. But where should I connect the input and output 
> > > port of this head block?
> > >
> > > Thanks
> > >
> > > On Tue, Mar 27, 2018 at 1:26 PM, Gilad Beeri (ApolloShield) 
> > >  wrote:
> > > > Check out the Head block, which takes N as input, and stops (the whole 
> > > > flowgraph as a result of how GNU Radio works) after N samples.
> > > > N = sample_rate * desired_duration
> > > >
> > > >
> > > > On Tue, Mar 27, 2018 at 2:08 PM Priyanka Priyadarshini 
> > > >  wrote:
> > > > > Hello,
> > > > >
> > > > > I am very new to GNURadio and I have made a FM radio receiver in 
> > > > > which I am recording the data in a file sink.
> > > > >
> > > > > But, I want to record the data for one millisecond(means i want to 
> > > > > stop the flow graph after 1 millisecond). How can I run the execution 
> > > > > of the flow graph for this specified time?
> > > > >
> > > > > Any help would be appreciated. Thank you.
> > > > >
> > > > > Priyanka
> > > > > ___
> > > > > 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
> 
> 

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Problems with dvbt 8k 64QAM

[Juan Antonio]

Hello, someone would be so kind to tell me how to download the examples of
dtv-utils?

http://www.w6rz.net/adv8dvbt12.ts

http://www.w6rz.net/adv8dvbt23.ts

etc...
No matter how hard I try it alone: 404 error or a page with many symbols
that I do not know how to transform into a ts file

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

[Discuss-gnuradio] more questions

[김무연]

I used costas loop for each synchronization and it workedMy thinking was wrong I thought the signals from different usrps are synchronized together without controlling the offset of usrpsI use usrp N210Now i need to know frequency offset of each usrpAnd my professor and our team read a thesis about beamforingIn the page there were 3 types of similar oneFirst one, send continuous signal and send continuous signal as a feedbackSecond one, send continuous signal and send 1bit feedbackLast one, send bits and send bits as a feedbackAnyway thanks for your helpingAs you mentioned I will try to do it manually and I will check the outcomeI think i need more help in the futureThanks for now___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Increasing the noutput_items limit

[Jason Hein]

I'm having issues increasing the global noutput_items value on my
flowgraph.  I'm setting the value in the python flowgraph to be global
for all blocks.  The code is below.  However, when I print the value
of noutput_items in my general_work() function within one of my
blocks, it's still the default value of 16384.  Any suggestions?

tb = top_block_cls(fft_size=options.fft_size, freq=options.freq,
port=options.port, samp_rate=options.samp_rate,
update_rate=options.update_rate)
tb.set_max_noutput_items(72000)
tb.set_max_output_buffer(72000)
tb.start()
tb.show()

Jason

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

Re: [Discuss-gnuradio] Increasing the noutput_items limit

[CEL]

You set a maximum, and what you got is a value below. Did you plan to
set a minimum instead? What is it that you want to achieve?

Also, noutput_items is not _necessarily_ the full buffer. Typically, on
the first call, you'd get offered half the buffer "to keep the spice
flowing", if I remember correctly.

Best regards
Marcus
On Tue, 2018-03-27 at 11:05 -0400, Jason Hein wrote:
> I'm having issues increasing the global noutput_items value on my
> flowgraph.  I'm setting the value in the python flowgraph to be global
> for all blocks.  The code is below.  However, when I print the value
> of noutput_items in my general_work() function within one of my
> blocks, it's still the default value of 16384.  Any suggestions?
> 
> tb = top_block_cls(fft_size=options.fft_size, freq=options.freq,
> port=options.port, samp_rate=options.samp_rate,
> update_rate=options.update_rate)
> tb.set_max_noutput_items(72000)
> tb.set_max_output_buffer(72000)
> tb.start()
> tb.show()
> 
> Jason
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to stop GRC flowgraph after a defined time

[Benny Alexandar]

Hi Priyanka,

GRC will generate python code for free when you create the flow graph. After 
that its like any python coding adding delay. timer etc.
Modify the python code for your need.

-ben

From: Discuss-gnuradio  
on behalf of Priyanka 
Sent: Tuesday, March 27, 2018 4:32 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] How to stop GRC flowgraph after a defined time

Hello,

I am very new to GNURadio and I have made a FM radio receiver in which I
am recording the data in a file sink.

But, I want to record the data for one millisecond(means i want to stop
the flow graph after 1 millisecond). How can I run the execution of the
flow graph for this specified time?

Any help would be appreciated. Thank you.

Priyanka


___
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] Increasing the noutput_items limit

[Jason Hein]

Marcus,

You're correct, I probably want to set the minimum.  I'm writing a
GRPC source block to accept a data stream over the network.  Each read
over GRPC is about 64k bytes or 32k shorts (noutput_items), so I'd
like to increase this number so I don't have to worry about queueing.
I see a set_min_output_buffer() function, but no
set_min_noutput_items.  I imagine I'll have memory issues if I return
a vector larger than noutput_items?

Jason

On Tue, Mar 27, 2018 at 11:14 AM, Müller, Marcus (CEL)  wrote:
> You set a maximum, and what you got is a value below. Did you plan to
> set a minimum instead? What is it that you want to achieve?
>
> Also, noutput_items is not _necessarily_ the full buffer. Typically, on
> the first call, you'd get offered half the buffer "to keep the spice
> flowing", if I remember correctly.
>
> Best regards
> Marcus
> On Tue, 2018-03-27 at 11:05 -0400, Jason Hein wrote:
>> I'm having issues increasing the global noutput_items value on my
>> flowgraph.  I'm setting the value in the python flowgraph to be global
>> for all blocks.  The code is below.  However, when I print the value
>> of noutput_items in my general_work() function within one of my
>> blocks, it's still the default value of 16384.  Any suggestions?
>>
>> tb = top_block_cls(fft_size=options.fft_size, freq=options.freq,
>> port=options.port, samp_rate=options.samp_rate,
>> update_rate=options.update_rate)
>> tb.set_max_noutput_items(72000)
>> tb.set_max_output_buffer(72000)
>> tb.start()
>> tb.show()
>>
>> Jason
>>
>> ___
>> 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] Increasing the noutput_items limit

[CEL]

Jep, you'd just wrap around and overwrite unconsumed data (maybe even
your own current data).

set_min_output_buffer() should do the trick – after all, items and
buffer size is invariably linked through the itemsize :)

Best regards,
Marcus

On Tue, 2018-03-27 at 11:32 -0400, Jason Hein wrote:
> Marcus,
> 
> You're correct, I probably want to set the minimum.  I'm writing a
> GRPC source block to accept a data stream over the network.  Each read
> over GRPC is about 64k bytes or 32k shorts (noutput_items), so I'd
> like to increase this number so I don't have to worry about queueing.
> I see a set_min_output_buffer() function, but no
> set_min_noutput_items.  I imagine I'll have memory issues if I return
> a vector larger than noutput_items?
> 
> Jason
> 
> On Tue, Mar 27, 2018 at 11:14 AM, Müller, Marcus (CEL)  
> wrote:
> > You set a maximum, and what you got is a value below. Did you plan to
> > set a minimum instead? What is it that you want to achieve?
> > 
> > Also, noutput_items is not _necessarily_ the full buffer. Typically, on
> > the first call, you'd get offered half the buffer "to keep the spice
> > flowing", if I remember correctly.
> > 
> > Best regards
> > Marcus
> > On Tue, 2018-03-27 at 11:05 -0400, Jason Hein wrote:
> > > I'm having issues increasing the global noutput_items value on my
> > > flowgraph.  I'm setting the value in the python flowgraph to be global
> > > for all blocks.  The code is below.  However, when I print the value
> > > of noutput_items in my general_work() function within one of my
> > > blocks, it's still the default value of 16384.  Any suggestions?
> > > 
> > > tb = top_block_cls(fft_size=options.fft_size, freq=options.freq,
> > > port=options.port, samp_rate=options.samp_rate,
> > > update_rate=options.update_rate)
> > > tb.set_max_noutput_items(72000)
> > > tb.set_max_output_buffer(72000)
> > > tb.start()
> > > tb.show()
> > > 
> > > Jason
> > > 
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] RHEL/Centos 7 gnuradio packages missing gr-fec

[Adrian Musceac]

Hi guys,

I don't know if the RHEL packager is reading this list, but I want to
report that I tried to use GNU radio Centos 7 packages at work and
they are missing libgnuradio-fec and the corresponding headers. I'd
imagine RHEL and Fedora have the same problem.

Best regards,
Adrian

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

Re: [Discuss-gnuradio] Problems with dvbt 8k 64QAM

[Ron Economos]

Right click on the link and select "Save Link As..."

Ron

On 03/27/2018 06:14 AM, Juan Antonio wrote:

Hello, someone would be so kind to tell me how to download the examples of
dtv-utils?

http://www.w6rz.net/adv8dvbt12.ts

http://www.w6rz.net/adv8dvbt23.ts

etc...
No matter how hard I try it alone: 404 error or a page with many 
symbols that I do not know how to transform into a ts file


Best regards




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

Re: [Discuss-gnuradio] Problems with dvbt 8k 64QAM

[Juan Antonio]

Thanks  Ron ,you are  the best
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] build error at uhd::time_spec_t::get_system_time()

[Piotr Swiatkiewicz]

Hello Michael,

yes, this is true:

# pacman -Ss libuhd
community/libuhd 3.10.2.0-3 [installed]
Universal Software Radio Peripheral (USRP) userspace driver

So, apparently I had it installed. So, I did what you suggested (I think!):

git diff host/CMakeLists.txt
diff --git a/host/CMakeLists.txt b/host/CMakeLists.txt
index ab7f41fb5..5e88d38c9 100644
--- a/host/CMakeLists.txt
+++ b/host/CMakeLists.txt
@@ -324,8 +324,8 @@ SET(Boost_ADDITIONAL_VERSIONS
 )
 FIND_PACKAGE(Boost ${BOOST_MIN_VERSION} COMPONENTS
${BOOST_REQUIRED_COMPONENTS})

-INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
-LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
+#INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
+#LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})

 MESSAGE(STATUS "Boost include directories: ${Boost_INCLUDE_DIRS}")
 MESSAGE(STATUS "Boost library directories: ${Boost_LIBRARY_DIRS}")

Hope these are the correct lines to comment out.
But now - since the documentation for PyBOMBS is not that clear (and it
seems scattered among several places):
should I issue

pybombs rebuild uhd

If so - that did not work - I got exactly the same error. I may try to
remove the uhd package with pacman and retry,
however I just learned from PyBOMBS guys that only Python 2 is supported,
so I may now have a mess on my system.
Must check and clean it up before I continue.

Thanks for your help,
Peter
--
Piotr Swiatkiewicz


On 25 March 2018 at 18:51, Michael Dickens 
wrote:

> Hi Piotr - The error you encountered generally means that UHD was already
> installed in the same prefix as the build would be going into, and that the
> UHD API changed between the versions. Normally UHD can be build over a
> pre-existing install, but sometime not too long ago this feature was broken
> via these 2 lines in the top level CMakeLists.txt file: <
> https://github.com/EttusResearch/uhd/blob/maint/host/CMakeLists.txt#L327 >.
> Specifically for the build part, the 
> "INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})"
> comes before some (but not all) of the local-to-build INCLUDE_DIRECTORIES,
> which means that if the UHD API has changed, then the old API will be
> picked up -- as its headers come before the new (internal to build)
> headers. The easy fix for most OSs is to comment out those 2 lines & give
> the build a go again. I'm working on fixing this issue in a more robust
> way, since almost all of my builds / testing are on systems with UHD
> already installed into the build's prefix. Hope this helps! - MLD
>
> On Sun, Mar 25, 2018, at 7:43 AM, Piotr Swiatkiewicz wrote:
>
> I am trying to build GR with PyBOMBS and apart from problems with the
> build system itself (it would not start properly when python3 is used) I
> get the following error not far away (85% complete) from the end of the
> build:
>
> [ 85%] Building CXX object gr-uhd/swig/CMakeFiles/_uhd_sw
> ig.dir/uhd_swigPYTHON_wrap.cxx.o
> /home/pswiatki/devel/gr/default/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:
> In function 'PyObject* _wrap_time_spec_t_get_system_time(PyObject*,
> PyObject*)':
> /home/pswiatki/devel/gr/default/src/gnuradio/build/gr-uhd/sw
> ig/uhd_swigPYTHON_wrap.cxx:19850:34: error: 'get_system_time' is not a
> member of 'uhd::time_spec_t'
>result = uhd::time_spec_t::get_system_time();
>   ^~~
> make[2]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/build.make:71:
> gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o] Error 1
> make[1]: *** [CMakeFiles/Makefile2:13301: 
> gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all]
> Error 2
> make: *** [Makefile:163: all] Error 2
> PyBOMBS.Packager.source - ERROR - Build failed. See output above for error
> messages.
> PyBOMBS.Packager.source - ERROR - Problem occurred while building package
> gnuradio:
> Build failed.
> PyBOMBS.install_manager - ERROR - Error installing package gnuradio.
> Aborting.
>
> I tried building with python3 (3.6) and also with python2 (2.7). It fails
> at exactly the same point.
>
> Interestingly, I read this at http://files.ettus.com/
> manual/classuhd_1_1time__spec__t.html:
>
> static time_spec_t
>  uhd::time_
> spec_t::get_system_time
> (
> void
>
> )
>
> static
>
> DEPRECATED – Will get removed from UHD in future versions.
>
> Get the system time in time_spec_t
>  format.
> Uses the highest precision clock available.
> So, can it be it actually got removed and there is some incompatibility
> between UHD and GR?
>
> By the way, ByBOMBS pulled these commits from the respective repositories:
>
> UHD:
> commit 4844f66dccaa71da102b02bba7b8caf8f84a932c (HEAD -> master,
> origin/master)
> Author: Trung N Tran 
> Date:   Wed Mar 14 08:31:33 2018 -0700
>
> GNU Radio:
> commit 273392bda86688194df03cd1c3eef0819236b3b3 (HEAD -> master,
> origin/master, origin/HEAD)
> Author: japm48 
> Date:   Thu Mar 15 14:37:40 2018 +0100
>
> What am I doing wrong?
>
> *__

Re: [Discuss-gnuradio] Accessing the ADI registers on B200mini

[Firdavs Pulat]

Hi Marcus,

I tried to use the set_agc_mode the same way, but I get an error during the
build process that says: 'class uhd::usrp::multi_usrp' has no member named
'set_agc_mode.' This API is in the ad9361_ctrl, but it seems to be looking
for it in multi_usrp. How would I include the ad9361_ctrl?

Also, is there a way to read what all the AD registers are set to so I know
the default values? When I use the getter functions (e.g.,
self.uhd_usrp_source_0.get_gain()) in the python code, it doesn't seem to
do anything.

Thank you


On Wed, Mar 21, 2018 at 1:26 PM, Marcus D. Leech  wrote:

> On 03/21/2018 02:24 PM, Firdavs Pulat wrote:
>
> Hi Marcus,
>
> Thank you for your help and patience!
>
> Following your suggestion, I think I was able to turn the AGC on. Now, I'm
> wondering what mode it's running at (e.g., slow, fast, etc). Looking at the
> multi_usrp class, I don't see any API's to set the mode. But in the
> ad9361_ctrl class, I see an API called set_agc_mode. Can I use that API the
> same way I'm using set_rx_agc? I tried the following
> command: uhd_usrp_probe --string /mboards/0/dboards/A/rx_
> frontends/A/gain/agc/mode/value, and it returned 'slow', so I assume the
> default mode of AGC is slow?
>
> I know you said AGC isn't used by most applications, but the reason why
> I'm asking all of this is because our application was using the AD9361 chip
> and we were enabling AGC then, so I'm trying to do the same here with Ettus
> B200 since the RFIC is the same.
>
> Thanks!
>
> You should be able to use set_agc_mode() in the same way.
>
>
>
>
> On Tue, Mar 20, 2018 at 3:11 PM, Marcus D. Leech 
> wrote:
>
>> On 03/20/2018 03:27 PM, Firdavs Pulat wrote:
>>
>> Hi Marcus,
>>
>> Could you please elaborate on the "extend the Gnu Radio multi_usrp" part?
>> Maybe you could point me to some examples one how to set these (I assume
>> others must have played around with them since it's so essential), or
>> documentation on how that's done? I'm just not sure where/how in the
>> usrp_source impl source code I would set them. I have been looking online,
>> but haven't found anything of use yet.
>>
>> Thank you!
>>
>> In the Gnu Radio source code, in gr_uhd/usrp_source_impl.cc
>>
>> If you look at any of the setter functions for various device parameters,
>> you'd pattern your call to set_rx_agc() after one of those.  The
>> lowest-impact
>>   way to do it would be to "hijack" the existing gain-setting function,
>> and have it look for "magic" gain value that then turns on hardware AGC
>>   via the set_rx_agc() function.
>>
>> In reality, very few applications use the hardware AGC in the chip, which
>> is one of the reasons that it hasn't yet been "mapped" into the GR
>>   API wrapper.
>>
>>
>>
>>
>> On Thu, Mar 8, 2018 at 10:58 AM, Marcus D. Leech 
>> wrote:
>>
>>> On 03/08/2018 10:43 AM, Firdavs Pulat wrote:
>>>
 Hi all,

 Are there APIs as part of gnuradio that give access to the low level
 ADI registers (to both probe, and set)? For instance, I'm trying to see if
 the AGC is currently turned on on B200mini, and if it's, what kind of mode
 it is on (e.g., slow or fast). Looking at it the USRP manual online, I see
 functions like set_agc, set_agc_mode, etc. I just don't have any idea
 how/where to actually use/set these. Could anyone please help me out?

 Thanks!


 No need to tinker with ADI registers.
>>>
>>> The multi_usrp API provides access to a set_rx_agc function:
>>>
>>> https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__us
>>> rp.html#abdab1f6c3775a9071b15c9805f866486
>>>
>>> However, you'd have to extend the Gnu Radio multi_usrp "wrapper" (in
>>> gr-uhd in the main Gnu Radio codebase) to provide access to set_rx_agc().
>>>
>>> Note that in many cases, hardware AGC doesn't really work the way you'd
>>> like it to, since its "world view" may be very very different than the view
>>>   of your particular application.
>>>
>>>
>>>
>>>
>>> ___
>>> 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] Accessing the ADI registers on B200mini

[Marcus D. Leech]

On 03/27/2018 05:47 PM, Firdavs Pulat wrote:

Hi Marcus,

I tried to use the set_agc_mode the same way, but I get an error 
during the build process that says: 'class uhd::usrp::multi_usrp' has 
no member named 'set_agc_mode.' This API is in the ad9361_ctrl, but it 
seems to be looking for it in multi_usrp. How would I include the 
ad9361_ctrl?
The AGC_MODE actually is controllable via the property-tree which is an 
internal thing.  There's no direct mapping of this functionality through the

  multi_usrp API.

You want to peruse this part of the UHD manual:

https://files.ettus.com/manual/classuhd_1_1property__tree.html

And note that ad936x_manager.cpp adds subscriptions from the property 
tree to actual driver functions.






Also, is there a way to read what all the AD registers are set to so I 
know the default values? When I use the getter functions (e.g., 
self.uhd_usrp_source_0.get_gain()) in the python code, it doesn't seem 
to do anything.


Thank you


On Wed, Mar 21, 2018 at 1:26 PM, Marcus D. Leech > wrote:


On 03/21/2018 02:24 PM, Firdavs Pulat wrote:

Hi Marcus,

Thank you for your help and patience!

Following your suggestion, I think I was able to turn the AGC on.
Now, I'm wondering what mode it's running at (e.g., slow, fast,
etc). Looking at the multi_usrp class, I don't see any API's to
set the mode. But in the ad9361_ctrl class, I see an API called
set_agc_mode. Can I use that API the same way I'm using
set_rx_agc? I tried the following command: uhd_usrp_probe
--string /mboards/0/dboards/A/rx_frontends/A/gain/agc/mode/value,
and it returned 'slow', so I assume the default mode of AGC is slow?

I know you said AGC isn't used by most applications, but the
reason why I'm asking all of this is because our application was
using the AD9361 chip and we were enabling AGC then, so I'm
trying to do the same here with Ettus B200 since the RFIC is the
same.

Thanks!

You should be able to use set_agc_mode() in the same way.





On Tue, Mar 20, 2018 at 3:11 PM, Marcus D. Leech
mailto:mle...@ripnet.com>> wrote:

On 03/20/2018 03:27 PM, Firdavs Pulat wrote:

Hi Marcus,

Could you please elaborate on the "extend the Gnu Radio
multi_usrp" part? Maybe you could point me to some examples
one how to set these (I assume others must have played
around with them since it's so essential), or documentation
on how that's done? I'm just not sure where/how in the
usrp_source impl source code I would set them. I have been
looking online, but haven't found anything of use yet.

Thank you!

In the Gnu Radio source code, in gr_uhd/usrp_source_impl.cc

If you look at any of the setter functions for various device
parameters, you'd pattern your call to set_rx_agc() after one
of those.  The lowest-impact
  way to do it would be to "hijack" the existing gain-setting
function, and have it look for "magic" gain value that then
turns on hardware AGC
  via the set_rx_agc() function.

In reality, very few applications use the hardware AGC in the
chip, which is one of the reasons that it hasn't yet been
"mapped" into the GR
  API wrapper.





On Thu, Mar 8, 2018 at 10:58 AM, Marcus D. Leech
mailto:mle...@ripnet.com>> wrote:

On 03/08/2018 10:43 AM, Firdavs Pulat wrote:

Hi all,

Are there APIs as part of gnuradio that give access
to the low level ADI registers (to both probe, and
set)? For instance, I'm trying to see if the AGC is
currently turned on on B200mini, and if it's, what
kind of mode it is on (e.g., slow or fast). Looking
at it the USRP manual online, I see functions like
set_agc, set_agc_mode, etc. I just don't have any
idea how/where to actually use/set these. Could
anyone please help me out?

Thanks!


No need to tinker with ADI registers.

The multi_usrp API provides access to a set_rx_agc function:


https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#abdab1f6c3775a9071b15c9805f866486



However, you'd have to extend the Gnu Radio multi_usrp
"wrapper" (in gr-uhd in the main Gnu Radio codebase) to
provide access to set_rx_agc().

Note that in many cases, hardware AGC doesn't really
work the way you'd like it to, since its "world view"
may be very very different than the view
  of your particular application.




___
Di

Re: [Discuss-gnuradio] build error at uhd::time_spec_t::get_system_time()

[Michael Dickens]

Hi Piotr - Yes, those are the correct lines to comment out. Remember
that you'll need to "rm -rf" the build directory and start from scratch
with the cmake command to get these changes to take ... cmake handles a
lot of changes very robustly, but tweaks like this not so much so. I
can't help with the pybombs command; still haven't worked through using
it yet. Good luck! - MLD
On Tue, Mar 27, 2018, at 5:17 PM, Piotr Swiatkiewicz wrote:
> yes, this is true:
> 
> # pacman -Ss libuhd
> community/libuhd 3.10.2.0-3 [installed]
> Universal Software Radio Peripheral (USRP) userspace driver
> 
> So, apparently I had it installed. So, I did what you suggested (I
> think!):> 
> git diff host/CMakeLists.txt 
> diff --git a/host/CMakeLists.txt b/host/CMakeLists.txt
> index ab7f41fb5..5e88d38c9 100644
> --- a/host/CMakeLists.txt
> +++ b/host/CMakeLists.txt
> @@ -324,8 +324,8 @@ SET(Boost_ADDITIONAL_VERSIONS
>  )
>  FIND_PACKAGE(Boost ${BOOST_MIN_VERSION} COMPONENTS
>  ${BOOST_REQUIRED_COMPONENTS})>  
> -INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
> -LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
> +#INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
> +#LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
>  
>  MESSAGE(STATUS "Boost include directories: ${Boost_INCLUDE_DIRS}")
>  MESSAGE(STATUS "Boost library directories: ${Boost_LIBRARY_DIRS}")
> 
> Hope these are the correct lines to comment out. 
> But now - since the documentation for PyBOMBS is not that clear (and
> it seems scattered among several places):> should I issue
> 
> pybombs rebuild uhd
> 
> If so - that did not work - I got exactly the same error. I may try to
> remove the uhd package with pacman and retry,> however I just learned from 
> PyBOMBS guys that only Python 2 is
> supported, so I may now have a mess on my system.> Must check and clean it up 
> before I continue.
> 
> Thanks for your help,
> 

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

[Discuss-gnuradio] Meaning of header_payload_demux0 - Parser returned #f

[Roberts, Alex S.]

I'm playing around with some of the packet and ofdm examples with the eventual 
goal of streaming udp packets generated by gsrteamer encoding a webcamera. 
Unfortunately, I've been having some difficulty with the examples that I can't 
understand. For example, running the packet_loopback_hier example, it will run 
fine for some period of time (seems to be different amount each run) then it 
stops printing message debugs and spams the console with


header_payload_demux0 - Parser returned #f

Occasionally, the flowchart will crash and stop running.

In the current run I have open, the correlation plot looks good, the transmit 
Time Freq and Constellation Plots are active, and the receive plots are no 
longer updated (probably because nothing is being decoded?)

I've tried looking a the archives to see what causes this problem, but have not 
found a good answer.



--

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

Re: [Discuss-gnuradio] Meaning of header_payload_demux0 - Parser returned #f

[Michael Dickens]

Hi Alex - The OFDM "#f" printouts means that the header didn't decode 
correctly, which in turn means its Rx-computed CRC8 didn't equal the embedded 
CRC8 from the header generation. This in turn generally means that OFDM sync 
has been lost, which in turn generally means that the Rx "SNR" isn't high 
enough ("SNR" here being the average power in the OFDM band divided by the 
average power outside the OFDM band but still within the sampling frequency 
range). I can't say specifically for the example you cite what's going on, but 
maybe the above helps? - MLD

On Tue, Mar 27, 2018, at 6:54 PM, Roberts, Alex S. wrote:
> I'm playing around with some of the packet and ofdm examples with the 
> eventual goal of streaming udp packets generated by gsrteamer encoding a 
> webcamera. Unfortunately, I've been having some difficulty with the examples 
> that I can't understand. For example, running the packet_loopback_hier 
> example, it will run fine for some period of time (seems to be different 
> amount each run) then it stops printing message debugs and spams the console 
> with
> 
>  header_payload_demux0 - Parser returned #f
>  
> Occasionally, the flowchart will crash and stop running.
>  
> In the current run I have open, the correlation plot looks good, the transmit 
> Time Freq and Constellation Plots are active, and the receive plots are no 
> longer updated (probably because nothing is being decoded?)
> 
> I've tried looking a the archives to see what causes this problem, but have 
> not found a good answer.

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

Re: [Discuss-gnuradio] Meaning of header_payload_demux0 - Parser returned #f

[Roberts, Alex S.]

Michael that provides insight into the error, unfortunately it does not explain 
the behavior of the example. The example uses the tx_packet and rx_packet 
hierarchical blocks. The output of the tx is routed to the input of the rx. I 
bypassed the example channel model and I’m not using hardware at the moment, so 
I would expect the example would have little issue with poor SNR and would 
maintain sync.

Thanks,
Alex.

Get Outlook for iOS



On Tue, Mar 27, 2018 at 6:37 PM -0500, "Michael Dickens" 
mailto:michael.dick...@ettus.com>> wrote:


Hi Alex - The OFDM "#f" printouts means that the header didn't decode 
correctly, which in turn means its Rx-computed CRC8 didn't equal the embedded 
CRC8 from the header generation. This in turn generally means that OFDM sync 
has been lost, which in turn generally means that the Rx "SNR" isn't high 
enough ("SNR" here being the average power in the OFDM band divided by the 
average power outside the OFDM band but still within the sampling frequency 
range). I can't say specifically for the example you cite what's going on, but 
maybe the above helps? - MLD

On Tue, Mar 27, 2018, at 6:54 PM, Roberts, Alex S. wrote:
> I'm playing around with some of the packet and ofdm examples with the 
> eventual goal of streaming udp packets generated by gsrteamer encoding a 
> webcamera. Unfortunately, I've been having some difficulty with the examples 
> that I can't understand. For example, running the packet_loopback_hier 
> example, it will run fine for some period of time (seems to be different 
> amount each run) then it stops printing message debugs and spams the console 
> with
>
>  header_payload_demux0 - Parser returned #f
>
> Occasionally, the flowchart will crash and stop running.
>
> In the current run I have open, the correlation plot looks good, the transmit 
> Time Freq and Constellation Plots are active, and the receive plots are no 
> longer updated (probably because nothing is being decoded?)
>
> I've tried looking a the archives to see what causes this problem, but have 
> not found a good answer.

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

[Discuss-gnuradio] spectrum monitoring / very wide band scanning

[Balthasar Indermuehle]

At my work we're using R&S EB500s for continuous spectrum monitoring at our
sites of interest. These machines step through the frequencies 70 - 3000
MHz in about 3 minutes in chunks of 50 MHz (from memory), and then assemble
the fragments into a contiguous waterfall display.

Is anyone aware of a wide band scanner software (that may or may not be
GNUradio based) that works with RTL-SDR dongles and with UHD drivers and
would allow to create a wide band spectrum sweep?

I've built a raw IQ recorder that does just that, but it needs to be
wrapped into a decent GUI, showing some nice waterfall displays and needs
to be made pretty. Before I'm investing the time to build this I thought
I'd check if that's not effort already done and shared by someone else.
Google thinks no... anyone know differently?

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

Re: [Discuss-gnuradio] spectrum monitoring / very wide band scanning

[Kevin Reid]

On Tue, Mar 27, 2018 at 6:19 PM, Balthasar Indermuehle 
wrote:
>
> Is anyone aware of a wide band scanner software (that may or may not be
> GNUradio based) that works with RTL-SDR dongles and with UHD drivers and
> would allow to create a wide band spectrum sweep?
>

I know that https://github.com/xmikos/qspectrumanalyzer exists but have not
used it. That program is a GUI — for further research, see also the list of
backend software it describes being able to use.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] spectrum monitoring / very wide band scanning

[Chris Kuethe]

Yet another probably 80% solution is rtl_power which emits a CSV of power
and rtl_heatmap which generates images.

On Tue, Mar 27, 2018 at 8:10 PM, Kevin Reid  wrote:

> On Tue, Mar 27, 2018 at 6:19 PM, Balthasar Indermuehle 
> wrote:
>>
>> Is anyone aware of a wide band scanner software (that may or may not be
>> GNUradio based) that works with RTL-SDR dongles and with UHD drivers and
>> would allow to create a wide band spectrum sweep?
>>
>
> I know that https://github.com/xmikos/qspectrumanalyzer exists but have
> not used it. That program is a GUI — for further research, see also the
> list of backend software it describes being able to use.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio