Re: [Discuss-gnuradio] Automating Transmit Gain

[Nicolas Cuervo]

Hello Tellrell,

the description that you are making as a possible solution to your problem
sounds very reasonable in many ways. As an informative example for the
command messages. you can check the "uhd_msg_tune.grc" example in
gnuradio/gr-uhd [1] where the uhd control over message is shown.

A second block that will only issue the messages based on a tagged input
might be superfluous, as you can also add a message port in the original
block that passes messages asynchronously containing the command to the uhd
sink. However, without knowing deeply what the overall purpose of your
application is, all solutions seem reasonable. Maybe you find the second
block that you have in mind (the one that generates the command for uhd
based on a tagged stream) useful in other applications, so its development
might not hurt.

Regards,
- Nicolas





[1] https://github.com/gnuradio/gnuradio/tree/maint/gr-uhd/examples/grc

On Mon, Jun 26, 2017 at 7:48 PM, Tellrell White  wrote:

> Hello Guys
> I want to have the uhd sink block in my flow graph automatically cycle
> through a number of transmit gain values. I'm thinking of developing two
> blocks, one which will take in  a certain number of items and once it
> reaches a certain value a message will be sent to another block which will
> send a command to the uhd sink block to adjust the gain by a certain
> amount. I'm wondering if I could accomplish this task by just creating a
> single block similar to the "tagged stream to pdu" which takes in a stream
> of data and outputs a message. Any feedback would be greatly appreciated.
>
> Thanks
> Tellrell
>
>
> ___
> 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] usrp x310 full duplex: receiving flowgraph can cause underflow problem at transmitter side

[Nicolas Cuervo]

Hello Yang,

it is true that each block will have its own thread in GNURadio, but, in
any case, your resources are limited when it comes to CPU processing. What
seems to be happening is that one of your paths is demanding resources and,
when it gets them, leaves the other path without enough resources to
perform its tasks. You will have to identify the critical paths of your
signal processing and optimize them in order to have enough resources for
both TX and RX to run simultaneously.

An easy first step to identify where most of the load is being done is by
using tools such as "htop", where each thread (created for each block) can
be listed, along with the percentage of CPU that they are using; high CPU
percentage might be a call for optimization.

Assuming that you are writing your own blocks in this application. there
are multiple ways to further analyze/optimize the performance of your
processes. Maybe some of the functions that you are using can be optimized,
or replaced with VOLK [1]. You could also turn on the performance counters
[2] and use the information to profile your blocks sample-wise. In
addition, using performance profiling tools such as "perf" or "valgrind"
might also give you a good insight to where the most processing is being
done in your application.

In addition, you can tweak your system a little in order to get more
performance from your host machine. Please have a look at the system
configuration page [3] of our manual and specify priority scheduling as
well as setting your CPU governors to "performance" (in case you haven't
done that yet). This might also boost the performance and reduce the
problems that you are encountering. The rest of that configuration page [3]
might come handy for further tweaking.

Regards,
-Nicolas

[1] https://gnuradio.org/doc/doxygen/volk_guide.html
[2] https://wiki.gnuradio.org/index.php/PerformanceCounters
[3] https://files.ettus.com/manual/page_usrp_x3x0_config.html

On Fri, Jun 23, 2017 at 8:32 PM, Yang Liu  wrote:

> Dear all,
>
> we are using one usrp x310 with two UBX 160 in a full duplex mode (one ubx
> for transmitting and the second one for receiving, with a 10G connection).
> In the code, two separate TX and RX flowgraphs are established (under a
> single process).
>
> top_block:
>
> self.txpath = tx_hier(...)self.rxpath = rx_hier(...)
>
> self.source = uhd_receiver(...)  # set up usrp, subdev: A:0
> self.sink = uhd_transmitter(...)  # set up usrp, subdev B:0
>
> self.connect(self.source, self.rxpath)
> self.connect(self.txpath, self.sink)
>
>
>  However, in the actual test, we found that once RX flowgraph is busy at
> processing data, the transmitter will suffer from severe underflow problem
> while sending packets. Sample rate is just 5Msps, using TX flowgraph alone
> will not have underflow and RX flowgraph alone no overflow either under the
> same sample rate.
>
> Since these two flowgraphs are separate, and that gnuradio will assign one
> thread to one block, it seems to me that processing data should not have
> impact at transmitting (independent). I am wondering how could this happen.
> I tried to use gr::hier_blocks::set_processor_affinity to separate core
> resources also, but it didn't work. Maybe blocks at transmitter can't get
> the resource it needs while RX flowgraph is busy at processing?
>
> Any explanations to this observation and any advice about how to tackle
> this will be greatly appreciated!
>
> Thanks,
> Yang
>
> ___
> 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] USRP phase to sample index relation in the DDC/DUC chain

[Marcus Müller]

Hello Nicolas,

sorry for the delayed reaction!

So, the signal chain looks roughly like this:

RX:

ADC (@Master Clock Rate (MCR) --> Rotator (@MCR) --> decimator --> Host
(@user-requested sampling rate)

TX:

Host (@user sampling rate) --> interpolator --> Rotator (@MCR) --> DAC
(@MCR)

The two rotators here are the CORDICs you're referring to.

UHD just calculates by how much of the master clock rate you need to
rotate per sample – e.g. if you tune digitally by 1 MHz, and your MCR is
200 MHz, then each sample needs to be phase-shifted by
$\frac{2\pi}{\frac{\text{MCR}}{f_\text{offset}}}$; ie. you need a
multiplicator that takes the input sample, and multiplies it with a
complex factor $e^{j\varphi}$; and after each sample, that $\varphi$
needs to be incremented by $\frac{2\pi}{200}$.

Thus, what UHD calculates is exactly that factor of 2π/200 and sends it
to the CORDIC unit on the FPGA, which then uses that value as phase
increase.

Best regards,

Marcus


On 06/09/2017 11:04 AM, Nicolas GALLAND wrote:
> Hello everyone,
>
> I am using a USRP X310 with basic RX and basic TX daughterboards and I
> would like to know the exact relation between the number I enter as a
> parameter for the central frequency in the UHD USRP sink/source block
> (which is a real number) and the actual phase per each sample.
>
> As a matter of facts, if the DDC/DUC chains were using a DDS, the
> relation would be pretty straightforward (knowing the control word of
> the DDS and the number of bits of the phase accumulator...). However,
> as I understand, the FPGA design uses a CORDIC for the DDC/DUC chain,
> for which the exact correspondence between sample index and phase is
> not as straight forward to derive. I am sorry if this is textbook
> material for CORDIC specialists (which I am not...), but I am
> wondering if someone could point me to the exact formula of phase vs
> sample index that I could use to very accurately know what is going on
> in the DDC/DUC chain. The bottom line is that I need to be sure of
> what is happening at the nrad level for MHz-ish input/output and
> mod/demod frequency, and the intricacies of the CORDIC behavior is -
> to my best understanding - playing a major role at this level.
>
> Any help would be greatly appreciated.
>
> Best regards,
>
> Nicolas
>
>
> ___
> 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] (no subject)

[Rafik ZITOUNI]

Dear all,

I translate the /gr-digital/examples/narrowband/digital_bert_tx.py and the
/gr-digital/examples/narrowband/digital_bert_rx.py python source codes to
GRC flow graphs. The objective is to get more graphical possibilities with
a GRC.  My flow graph gives a fine result of BER and SNR for DBPSK
modulation.
The problem is with the rotating points of my constellation. I think that
the rotation of my view comes from a lack of frequency synchronization, but
why I obtained a correct BER and SNR?
[image: Images intégrées 1]
You find attached to this message a constellation view obtained by my flow
graph.

Please could you explain me this  result or give an advice to improve the
obtained result?

Regards,


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

[Discuss-gnuradio] Lunar imaging experiment

[Juha Vierinen]

Hi,

Just to let you guys know, I'll be radiating the moon with 1 MW and 36 dBi
49.92 MHz on 2017/07/04 at 01:21:00 UTC. The experiment will repeat also at
 2017/07/05 02:04:00 UTC. Both experiments last about 15 minutes, when the
Moon transits the radar beam.

In case somebody wants to tune in with their gear, here are some details.

I'm using the Jicamarca radio observatory radar, which is located in Peru.
The system is locked to GPS. The transmissions are binary phase coded
pulses with 10 microsecond baud length, so a recording with >100 kHz
bandwidth is needed.

If you've got a GPS locked system, you should be able to produce a lunar
synthetic aperture radar map, such as this one:

 http://www.haystack.mit.edu/~j/ns-depolarized.png

The phase code is a 13*13 bit Kroenecker product Barker code. The phases
are listed here:
http://www.haystack.mit.edu/~j/b169.h5

In text form, the code is:
[ 1.  1.  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1.  1.  1.  1.  1.  1.
 -1. -1.  1.  1. -1.  1. -1.  1.  1.  1.  1.  1.  1. -1. -1.  1.  1. -1.
  1. -1.  1.  1.  1.  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1.  1.  1.
  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1. -1. -1. -1. -1. -1.  1.  1.
 -1. -1.  1. -1.  1. -1. -1. -1. -1. -1. -1.  1.  1. -1. -1.  1. -1.  1.
 -1.  1.  1.  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1.  1.  1.  1.  1.
  1. -1. -1.  1.  1. -1.  1. -1.  1. -1. -1. -1. -1. -1.  1.  1. -1. -1.
  1. -1.  1. -1.  1.  1.  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1. -1.
 -1. -1. -1. -1.  1.  1. -1. -1.  1. -1.  1. -1.  1.  1.  1.  1.  1. -1.
 -1.  1.  1. -1.  1. -1.  1.]

Any reports of hearing the transmissions are appreciated.

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

Re: [Discuss-gnuradio] Lunar imaging experiment

[Juha Vierinen]

Hi,

I forgot to mention that the interpulse period is 38 ms on  2017/07/04 at
01:21:00 UTC and 40 ms on 2017/07/05 02:04:00 UTC.

juha


On Mon, Jul 3, 2017 at 9:58 PM, Juha Vierinen  wrote:

> Hi,
>
> Just to let you guys know, I'll be radiating the moon with 1 MW and 36 dBi
> 49.92 MHz on 2017/07/04 at 01:21:00 UTC. The experiment will repeat also at
>  2017/07/05 02:04:00 UTC. Both experiments last about 15 minutes, when the
> Moon transits the radar beam.
>
> In case somebody wants to tune in with their gear, here are some details.
>
> I'm using the Jicamarca radio observatory radar, which is located in Peru.
> The system is locked to GPS. The transmissions are binary phase coded
> pulses with 10 microsecond baud length, so a recording with >100 kHz
> bandwidth is needed.
>
> If you've got a GPS locked system, you should be able to produce a lunar
> synthetic aperture radar map, such as this one:
>
>  http://www.haystack.mit.edu/~j/ns-depolarized.png
>
> The phase code is a 13*13 bit Kroenecker product Barker code. The phases
> are listed here:
> http://www.haystack.mit.edu/~j/b169.h5
>
> In text form, the code is:
> [ 1.  1.  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1.  1.  1.  1.  1.  1.
>  -1. -1.  1.  1. -1.  1. -1.  1.  1.  1.  1.  1.  1. -1. -1.  1.  1. -1.
>   1. -1.  1.  1.  1.  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1.  1.  1.
>   1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1. -1. -1. -1. -1. -1.  1.  1.
>  -1. -1.  1. -1.  1. -1. -1. -1. -1. -1. -1.  1.  1. -1. -1.  1. -1.  1.
>  -1.  1.  1.  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1.  1.  1.  1.  1.
>   1. -1. -1.  1.  1. -1.  1. -1.  1. -1. -1. -1. -1. -1.  1.  1. -1. -1.
>   1. -1.  1. -1.  1.  1.  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1. -1.
>  -1. -1. -1. -1.  1.  1. -1. -1.  1. -1.  1. -1.  1.  1.  1.  1.  1. -1.
>  -1.  1.  1. -1.  1. -1.  1.]
>
> Any reports of hearing the transmissions are appreciated.
>
> juha
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP Packet Decoder and Encoder

[Brian]

I have a flow graph that currently has a packet encoder at the transmitter and 
an encoder at the receiver.

I am attempting to send a file from one usrp to the other.

On investigating the output of the receiver it would not appear that it is 
processing anything possibly because of the access code but I have conformed 
they match and are suitably long and random.

The file I get out is 0bytes.  If I bypass the decoder a large file is created, 
although large and unusable (noise)

Any advice on how to proceed will be gratefully received and a pre-configured 
tx and rx flow graph will be most welcome.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Lunar imaging experiment

[Michael Ossmann]

Cool!  Is there an optimal receive antenna polarization?

Michael


On Mon, Jul 03, 2017 at 10:07:03PM +, Juha Vierinen wrote:
>
> Hi,
> 
> I forgot to mention that the interpulse period is 38 ms on  2017/07/04 at
> 01:21:00 UTC and 40 ms on 2017/07/05 02:04:00 UTC.
> 
> juha
> 
> 
> On Mon, Jul 3, 2017 at 9:58 PM, Juha Vierinen  wrote:
> 
> > Hi,
> >
> > Just to let you guys know, I'll be radiating the moon with 1 MW and 36 dBi
> > 49.92 MHz on 2017/07/04 at 01:21:00 UTC. The experiment will repeat also at
> >  2017/07/05 02:04:00 UTC. Both experiments last about 15 minutes, when the
> > Moon transits the radar beam.
> >
> > In case somebody wants to tune in with their gear, here are some details.
> >
> > I'm using the Jicamarca radio observatory radar, which is located in Peru.
> > The system is locked to GPS. The transmissions are binary phase coded
> > pulses with 10 microsecond baud length, so a recording with >100 kHz
> > bandwidth is needed.
> >
> > If you've got a GPS locked system, you should be able to produce a lunar
> > synthetic aperture radar map, such as this one:
> >
> >  http://www.haystack.mit.edu/~j/ns-depolarized.png
> >
> > The phase code is a 13*13 bit Kroenecker product Barker code. The phases
> > are listed here:
> > http://www.haystack.mit.edu/~j/b169.h5
> >
> > In text form, the code is:
> > [ 1.  1.  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1.  1.  1.  1.  1.  1.
> >  -1. -1.  1.  1. -1.  1. -1.  1.  1.  1.  1.  1.  1. -1. -1.  1.  1. -1.
> >   1. -1.  1.  1.  1.  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1.  1.  1.
> >   1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1. -1. -1. -1. -1. -1.  1.  1.
> >  -1. -1.  1. -1.  1. -1. -1. -1. -1. -1. -1.  1.  1. -1. -1.  1. -1.  1.
> >  -1.  1.  1.  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1.  1.  1.  1.  1.
> >   1. -1. -1.  1.  1. -1.  1. -1.  1. -1. -1. -1. -1. -1.  1.  1. -1. -1.
> >   1. -1.  1. -1.  1.  1.  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1. -1.
> >  -1. -1. -1. -1.  1.  1. -1. -1.  1. -1.  1. -1.  1.  1.  1.  1.  1. -1.
> >  -1.  1.  1. -1.  1. -1.  1.]
> >
> > Any reports of hearing the transmissions are appreciated.
> >
> > juha
> >

> ___
> 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] Lunar imaging experiment

[Juha Vierinen]

We're transmitting two linear polarizations interleaved. Any polarization
should work.

Two independent linear polarizations will give optimal results when
producing a map (one can form polarized and depolarized images).

Here's a link to the radar:
http://jro.igp.gob.pe/english/

juha

On Mon, Jul 3, 2017 at 10:26 PM, Michael Ossmann  wrote:

> Cool!  Is there an optimal receive antenna polarization?
>
> Michael
>
>
> On Mon, Jul 03, 2017 at 10:07:03PM +, Juha Vierinen wrote:
> >
> > Hi,
> >
> > I forgot to mention that the interpulse period is 38 ms on  2017/07/04 at
> > 01:21:00 UTC and 40 ms on 2017/07/05 02:04:00 UTC.
> >
> > juha
> >
> >
> > On Mon, Jul 3, 2017 at 9:58 PM, Juha Vierinen 
> wrote:
> >
> > > Hi,
> > >
> > > Just to let you guys know, I'll be radiating the moon with 1 MW and 36
> dBi
> > > 49.92 MHz on 2017/07/04 at 01:21:00 UTC. The experiment will repeat
> also at
> > >  2017/07/05 02:04:00 UTC. Both experiments last about 15 minutes, when
> the
> > > Moon transits the radar beam.
> > >
> > > In case somebody wants to tune in with their gear, here are some
> details.
> > >
> > > I'm using the Jicamarca radio observatory radar, which is located in
> Peru.
> > > The system is locked to GPS. The transmissions are binary phase coded
> > > pulses with 10 microsecond baud length, so a recording with >100 kHz
> > > bandwidth is needed.
> > >
> > > If you've got a GPS locked system, you should be able to produce a
> lunar
> > > synthetic aperture radar map, such as this one:
> > >
> > >  http://www.haystack.mit.edu/~j/ns-depolarized.png
> > >
> > > The phase code is a 13*13 bit Kroenecker product Barker code. The
> phases
> > > are listed here:
> > > http://www.haystack.mit.edu/~j/b169.h5
> > >
> > > In text form, the code is:
> > > [ 1.  1.  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1.  1.  1.  1.  1.
> 1.
> > >  -1. -1.  1.  1. -1.  1. -1.  1.  1.  1.  1.  1.  1. -1. -1.  1.  1.
> -1.
> > >   1. -1.  1.  1.  1.  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1.  1.
> 1.
> > >   1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1. -1. -1. -1. -1. -1.  1.
> 1.
> > >  -1. -1.  1. -1.  1. -1. -1. -1. -1. -1. -1.  1.  1. -1. -1.  1. -1.
> 1.
> > >  -1.  1.  1.  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1.  1.  1.  1.
> 1.
> > >   1. -1. -1.  1.  1. -1.  1. -1.  1. -1. -1. -1. -1. -1.  1.  1. -1.
> -1.
> > >   1. -1.  1. -1.  1.  1.  1.  1.  1. -1. -1.  1.  1. -1.  1. -1.  1.
> -1.
> > >  -1. -1. -1. -1.  1.  1. -1. -1.  1. -1.  1. -1.  1.  1.  1.  1.  1.
> -1.
> > >  -1.  1.  1. -1.  1. -1.  1.]
> > >
> > > Any reports of hearing the transmissions are appreciated.
> > >
> > > juha
> > >
>
> > ___
> > 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] Using two TwinRX in one x310

[Eugene Grayver]

Hello,

This may be an usrp-users question, but I can't seem to get approved for that 
list.  Is it possible to use two TwinRX boards (4 channels) in a X310?  As far 
as I can tell you need 4 DDCs, but only two are available by default.

A followup: why is it that TwinRX connection type is reported as 'Connection 
Type: II' for channel 0 QQ for channel 1.

Finally, I have a twinrx and a UBX board in one X310.  Trying to run all 3 RX 
at the same time I get:
UHD Warning:
[X300 Radio] Requesting invalid sampling rate from device: 100 MHz. Actual 
rate is: 200 MHz.
thread[thread-per-block[0]: ]: RuntimeError: 
Conflicting tick rates: One neighbouring block specifies 2e+08 MHz, another 
1e+08 MHz.


[cid:image001.png@01D2F424.CD93A110]

Thanks

___
Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274


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

[Discuss-gnuradio] Last call for abstracts for the IEEE Aerospace Conference!

[Eugene Grayver]

Hello fellow SDR developers.  I am still accepting abstracts for the SDR 
session at the Aerospace Conference to be held next March in Big Sky, MT.  Let 
me know if you are interested in submitting a paper (only abstracts are 
required right now), or just go to aeroconf.org.  Session 4.12.  Hope to see 
some of you there!

___
Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274


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