Re: [USRP-users] max input power B200

2017-10-02 Thread Marcus Müller via USRP-users 
Marcus is right, but: Also, what is to be clarified? 20 dBm (or 10 dBm)
is way more than 0dBm, true, but when would you ever expect a receive
antenna to generate 1V, if you're not standing right next to a massive
broadcast transmitter, or radar transmitter, or put your WiFi antenna in
a microwave oven?

Aside from that, 1 kHz is way below the lowest frequency the B2xx can
receive (not that frequency matters at all for the power aspects in
general, but that 1kHz wouldn't even pass through the coupling
capacitors without significant attenuation. 1kHz is, for all practical
issues of RF communications, DC). Also note that 0dBm is not the maximum
sensibly receivable signal; your receiver will be clipping at this point
very much! Sensible receive powers are more in the range of -20dBm or less.

Best regards,

Marcus


On 02.10.2017 08:16, Marcus D. Leech via USRP-users wrote:
> On 10/02/2017 12:10 AM, Nirmala Soundararajan via USRP-users wrote:
>> Hi,
>>
>> B200 mini data sheet mentions maximum input power as 0 dBm. A 1V, 1
>> kHz signal will give 0.5W power which is above 20 dBm and way above 0
>> dBm!  Can this please be clarified?
>>
>> regards
>>
>> Nirmala
>>
>>
> You should perhaps study this table:
>
> http://wera.cen.uni-hamburg.de/DBM.shtml
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Signal Processing Block with Control Port

2017-10-02 Thread Marcus Müller via USRP-users 
Hi Hafiz,

this is a GNU Radio question, and not directly related to USRPs. I'd
recommend you address this to the discuss-gnuradio list, to which you
can sign up on [1], instead.

Best regards,
Marcus

[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


On 02.10.2017 08:39, Hafiz Hashim Imtiaz via USRP-users wrote:
> Hi,
>
> Is it possible to make a signal processing block which contains two
> input ports, one is byte type and the other is complex type. The only
> output port is also complex type. The byte type input port would just
> act like a controller port that when it receives "1", it allows data
> to flow form input complex port to output complex port.
> If it is not possible, is there any alternative way to do this job in
> gnuradio companion?
>
>
>
>
> regards,
> Hafiz Hashim Imtiaz
> Research Assistant
> Information Technology University, Punjab
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] How update CMake version in the software development kit (SDR)?

2017-10-02 Thread Torbjörn Olsson via USRP-users 
Hello,

I am trying to put GR-Inspector on my Ettus Research E312 (an embedded system). 
But when running cmake in the installation process I get:
olt@aes:~/e300/src/gr-inspector/build$ cmake ..
CMake Error at CMakeLists.txt:23 (cmake_minimum_required):
 CMake 3.1 or higher is required.  You are running version 2.8.12.2


-- Configuring incomplete, errors occurred!
olt@aes:~/e300/src/gr-inspector/build$
It seems like the SDK used to cross compile for the E312 uses an older version 
of CMake than required by GR-Inspector. Has anyone experienced the same issue 
(and found a solution?). 

Grateful for any help!

Regards

Torbjörn 
(embedded software and SDR newbie)___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] How update CMake version in the software development kit (SDR)?

2017-10-02 Thread Philip Balister via USRP-users 
On 10/02/2017 02:57 AM, Torbjörn Olsson via USRP-users wrote:
> Hello,
> 
> I am trying to put GR-Inspector on my Ettus Research E312 (an embedded 
> system). But when running cmake in the installation process I get:
> olt@aes:~/e300/src/gr-inspector/build$ cmake ..
> CMake Error at CMakeLists.txt:23 (cmake_minimum_required):
>  CMake 3.1 or higher is required.  You are running version 2.8.12.2

Try this image and sdk:

http://files.ettus.com/e3xx_images/beta/jethro-test/

The manifest shows: nativesdk-cmake x86_64-nativesdk 3.3.1-r0

Philip

> 
> 
> -- Configuring incomplete, errors occurred!
> olt@aes:~/e300/src/gr-inspector/build$
> It seems like the SDK used to cross compile for the E312 uses an older 
> version of CMake than required by GR-Inspector. Has anyone experienced the 
> same issue (and found a solution?). 
> 
> Grateful for any help!
> 
> Regards
> 
> Torbjörn 
> (embedded software and SDR newbie)
> 
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X300 STREAM_MODE_NUM_SAMPS_AND_DONE length limitation

2017-10-02 Thread Derek Kozel via USRP-users 
That assertion is protecting a register in the Radio Block on the FPGA. You
could try modifying that area of the logic which is counting the outputted
samples as they are packetized. I do not believe that other areas of the
code would be impacted (other than that assertion in the host code of
course).

While the continuous mode is less convenient when you need a very specific
number of samples it does not require very much helper code to receive any
arbitrary number of samples and flush any excess ones away. The overhead of
doing so is minimal when only done once every few seconds.

A related note to be aware of is that the num_samps value is actually at
the radio clock sample rate not the final sample rate, so if the DDC is
used to lower the sample rate then the maximum number of samples which can
be received with STREAM_MODE_NUM_SAMPS_AND_DONE is reduced by the
decimation factor.

Regards,
Derek

On Fri, Sep 29, 2017 at 7:53 AM, Vladimir via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> Trying to save more than 2 sec trace with X300 at Fsamp = 100MHz, I
> encounter some block length limit of 0x0fff = 268.4 MSamps, which means
> only 2.6 sec of time. A bit surprised to see this in 64-bit environment...
> The assertion is in module rx_vita_core_3000.cpp:
>
> UHD_ASSERT_THROW(stream_cmd.num_samps <= 0x0fff);
>
> Is this some physical limit, or it can be patched to a larger value? It's
> kind of inconvenient to solve this through continuous streaming when you
> need a trace of a certain length...
>
> Vladimir
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] the rfnoc fifos

2017-10-02 Thread Derek Kozel via USRP-users 
Hi Jason,

Adding FIFOs adds buffering which helps with any transient changes in
throughput, such as over the 10 GigE connection. It gives the flow control
more room to work with before an overflow occurs (on receive). On the
transmit side the DMA FIFO usually fills that role.

On Fri, Sep 29, 2017 at 4:12 AM, Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> OK, thanks Martin.  I guess I am still confused though (no surprise
> there).  You say that they're "generally useful."  In what way?  If I have
> a flow graph that has 3 RFNoC blocks, what is the benefit of adding a FIFO
> or two to it?
>
> Thanks!
>
>
>
> On 09/28/2017 03:10 PM, Martin Braun via USRP-users wrote:
>
> On Wed, Sep 27, 2017 at 01:42:22PM -0400, Jason Matusiak via USRP-users wrote:
>
> OK, dumb question, but I just can't come up with a good answer.  I
> understand that the RFNoC FIFOs are a must if you only have one NoC block
> that you want to use and are using the GNURadio host [1].  So why do pretty
> much most of the examples ALWAYS have at least one, and why would I want to
> fill my bitfile with FIFOs, why not just use one?
>
> Note that this is a gr-ettus limitation, not RFNoC. And also, you only
> need FIFOs if you have only a single block (PC -> Block -> PC).
>
> And you don't need to fill up with FIFOs, they're just generally useful
> and thus we have that option.
>
> -- M
>
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] ADC Self-Test FAILED

2017-10-02 Thread Mark Koenig via USRP-users 
All,


I am getting the following output when trying to recover the mb EEprom.  Can 
anyone be of assistance?

Thank you

Mark


[root@localhost utils]# ./usrp_burn_mb_eeprom 
--args="recover_mb_eeprom,addr=192.168.20.2" --values="revision=4"
linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-16); Boost_105300; 
UHD_003.009.000-0-gcd88f80f

Creating USRP device from address: recover_mb_eeprom,addr=192.168.20.2
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...

UHD Warning:
UHD is operating in EEPROM Recovery Mode which disables hardware version 
checks.
Operating in this mode may cause hardware damage and unstable radio 
performance!
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO Found an internal GPSDO
-- Initialize Radio0 control...
-- Performing register loopback test... pass
-- Initialize Radio1 control...
-- Performing register loopback test... pass
Error: RuntimeError: ADC self-test failed! Ramp checker status: {ADC0_I=Bit 
Errors!, ADC0_Q=Good, ADC1_I=Good, ADC1_Q=Good}

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] max input power

2017-10-02 Thread Nirmala Soundararajan via USRP-users 
Hi Marcus,

I think I did'nt frame the question properly!. I know the calculations but
I just wanted to know in what voltage range must the input be given to
B200? (in mV-micro volts range?)

regards

Nirmala
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] max input power

2017-10-02 Thread Marcus D. Leech via USRP-users 

On 10/02/2017 10:33 AM, Nirmala Soundararajan via USRP-users wrote:

Hi Marcus,

I think I did'nt frame the question properly!. I know the calculations 
but I just wanted to know in what voltage range must the input be 
given to B200? (in mV-micro volts range?)


regards

Nirmala

0 dBm would be the highest I would recommend for the B210 or about 630mV 
P-P in a 50-ohm system.  But keep in mind, at that power level,
  the input will be overloading and produce clipped results, depending 
on gain settings.







___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X300 STREAM_MODE_NUM_SAMPS_AND_DONE length limitation

2017-10-02 Thread Vladimir via USRP-users 
Derek,

Thanks for the reply!

When you say "try modifying that area of the logic", you refer to FPGA code 
(which I assume is related with rebuilding the firmware image)? Or to host side 
code where I can simply increase that assertion limit to some more bits (say to 
0x7fff ) and see if it produces problems receiving samples?

> so if the DDC is used to lower the sample rate then the maximum number of 
> samples which can be received with STREAM_MODE_NUM_SAMPS_AND_DONE is reduced 
> by the decimation factor.

When (under what condition) should I notice the effect of this factor? Because 
now I use 200 MHz master clock and sample at 100 MSps rate, and I'm able to 
receive all 0x0fff samples which is the assertion limit.

> While the continuous mode is less convenient when you need a very specific 
> number of samples it does not require very much helper code to receive any 
> arbitrary number of samples and flush any excess ones away.

I understand that, still additional efforts are needed here. Eg, are there any 
example code on how to do this flushing correctly? Because rx_samples_to_file 
stops streaming just by Ctrl-C handler, without any additional actions. After I 
issued stop streaming cmd, how should I do such a flush operation? I mean I 
want to avoid waiting for any timeouts which will prolongate the overall input 
duration. If it's not possible without waiting for time out, then of which 
order this time out should be, to make it minimal?

Vladimir

>Понедельник,  2 октября 2017, 16:59 +03:00 от Derek Kozel 
>:
>
>That assertion is protecting a register in the Radio Block on the FPGA. You 
>could try modifying that area of the logic which is counting the outputted 
>samples as they are packetized. I do not believe that other areas of the code 
>would be impacted (other than that assertion in the host code of course).
>
>While the continuous mode is less convenient when you need a very specific 
>number of samples it does not require very much helper code to receive any 
>arbitrary number of samples and flush any excess ones away. The overhead of 
>doing so is minimal when only done once every few seconds.
>
>A related note to be aware of is that the num_samps value is actually at the 
>radio clock sample rate not the final sample rate, so if the DDC is used to 
>lower the sample rate then the maximum number of samples which can be received 
>with STREAM_MODE_NUM_SAMPS_AND_DONE is reduced by the decimation factor.
>
>Regards,
>Derek
>
>On Fri, Sep 29, 2017 at 7:53 AM, Vladimir via USRP-users  < 
>usrp-users@lists.ettus.com > wrote:
>>Hello,
>>
>>Trying to save more than 2 sec trace with X300 at Fsamp = 100MHz, I encounter 
>>some block length limit of 0x0fff = 268.4 MSamps, which means only 2.6 
>>sec of time. A bit surprised to see this in 64-bit environment... The 
>>assertion is in module rx_vita_core_3000.cpp:
>>
>>UHD_ASSERT_THROW(stream_cmd.num_samps <= 0x0fff);
>>
>>Is this some physical limit, or it can be patched to a larger value? It's 
>>kind of inconvenient to solve this through continuous streaming when you need 
>>a trace of a certain length...
>>
>>Vladimir
>>
>>
>>
>>___
>>USRP-users mailing list
>>USRP-users@lists.ettus.com
>>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Frequency synching USRP B210

2017-10-02 Thread Cho, Daniel J (332C) via USRP-users 
Hello -

I am using a USRP B210 with a GPSDO.  All the parts are assembled.  When I 
power up my USRP, I get a green light at the GPS ANT LED for a couple seconds 
before it shuts off.  When I run a program, it recognizes that a GPSDO module 
is installed.  I ran query_gpsdo_sensors to make sure that GPS is locked and it 
is.  When I run gnuradio, I make sure to set both USRP sink and source clock 
sources to O/B GPSDO and unknown PPS.

The setup is just one USRP B210 transmitting a BPSK signal from file and 
another USRP B210 receiving the BPSK signal and plotting it on the QT GUI sink. 
 When looking at the constellation plot of the QT GUI sink, the constellation 
is rotating thus the USRPs are not being synched.  How can I get the two USRPs 
synched using the GPSDO?  What am I doing wrong?

UHD version is 3.9.6.

Thanks,
Daniel Cho

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Error building OOT RFNOC Module with dependencies

2017-10-02 Thread John Medrano via USRP-users 
Thank you. Added lines from Makefile and it worked.

On Thu, Sep 28, 2017 at 4:58 PM, Nicolas Cuervo 
wrote:

> Hello John,
>
> the testbench for the siggen is located at 
> uhd-fpga/usrp3/lib/sim/rfnoc/noc_block_siggen/.
> It might be worth to try to add the cordic as it is being done there
> https://github.com/EttusResearch/fpga/blob/rfnoc-
> devel/usrp3/lib/sim/rfnoc/noc_block_siggen/Makefile#L23
>
> -N
>
> On Fri, Sep 29, 2017 at 12:12 AM, John Medrano 
> wrote:
>
>> Hello,
>>
>> We could not find a test bench for the SIGGEN.
>>
>> We did modify Makefile in testbench directory to add LIB_IP_DIR = $(
>> BASE_DIR)/../lib/ip
>>
>> When try to build testbench we got the same error.
>>
>> Thank you
>>
>> On Thu, Sep 28, 2017 at 8:06 AM, Nicolas Cuervo > > wrote:
>>
>>> Hello John,
>>>
>>> did you base the Makefile in your OOT siggen on the Makefile of the
>>> noc_block_siggen as well?
>>>
>>> Regards,
>>> - Nicolas
>>>
>>> On Thu, Sep 28, 2017 at 12:32 AM, Tom Bereknyei via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 John, will this be open source? We are also looking at modifying the
 SIGGEN to add functionality. From the name it seems you are transmitting on
 two channels. We would need more, but the concept seems similar.
 On Wed, Sep 27, 2017 at 18:10 John Medrano via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Hello,
>
> We have modified sig_gen module to create an OOT module and we are
> attempting to build image. But we receive an error while trying to build
> the test bench.
>
> sig_gen relies on modules cadd, cordic_rotater, and axi_clip_complex.
> As seen below, it is unable to find these modules while building test
> bench.
>
> These files all exist with FPGA_SOURCE and are part of the original
> sig_gen module.
>
> Please advise.
>
> INFO: [VRFC 10-311] analyzing module glbl
> INFO: [USF-XSim-3] XSim::Elaborate design
> INFO: [USF-XSim-61] Executing 'ELABORATE' step in
> '/home/joseavila/Documents/gnuradio_source/rfnoc-siggen2ch/r
> fnoc/testbenches/noc_block_twochannelsiggen_tb/xsim_proj/xsi
> m_proj.sim/sim_1/behav'
> Vivado Simulator 2015.4
> Copyright 1986-1999, 2001-2015 Xilinx, Inc. All Rights Reserved.
> Running: /opt/Xilinx/Vivado/2015.4/bin/unwrapped/lnx64.o/xelab -wto
> b9f75645c2494d95a76a86ec25333ddc --debug all --relax --mt 8 -d
> WORKING_DIR=/home/joseavila/Documents/gnuradio_source/rfnoc-
> siggen2ch/rfnoc/testbenches/noc_block_twochannelsiggen_tb -L work -L
> unisims_ver -L unimacro_ver -L secureip --snapshot
> noc_block_twochannelsiggen_tb_behav work.noc_block_twochannelsiggen_tb
> work.glbl -log elaborate.log -timescale 1ns/1ns
> Using 8 slave threads.
> Starting static elaboration
> ERROR: [VRFC 10-2063] Module  not found while
> processing module instance  [/usr/src/gnuradio_source/fpga
> /usrp3/lib/rfnoc/sine_tone.v:63]
> ERROR: [VRFC 10-2063] Module  not found while processing module
> instance  [/home/joseavila/Documents/gnu
> radio_source/rfnoc-siggen2ch/rfnoc/fpga-src/noc_block_twocha
> nnelsiggen.v:255]
> ERROR: [VRFC 10-2063] Module  not found while
> processing module instance  [/home/joseavila/Documents/gnu
> radio_source/rfnoc-siggen2ch/rfnoc/fpga-src/noc_block_twocha
> nnelsiggen.v:265]
> ERROR: [XSIM 43-3322] Static elaboration of top level Verilog design
> unit(s) in library work failed.
> INFO: [USF-XSim-99] Step results log file:'/home/joseavila/Document
> s/gnuradio_source/rfnoc-siggen2ch/rfnoc/testbenches/noc_bloc
> k_twochannelsiggen_tb/xsim_proj/xsim_proj.sim/sim_1/behav
> /elaborate.log'
> ERROR: [USF-XSim-62] 'elaborate' step failed with error(s). Please
> check the Tcl console output or '/home/joseavila/Documents/gnu
> radio_source/rfnoc-siggen2ch/rfnoc/testbenches/noc_block_two
> channelsiggen_tb/xsim_proj/xsim_proj.sim/sim_1/behav/elaborate.log'
> file for more information.
> # if [string equal $vivado_mode "batch"] {
> # puts "BUILDER: Closing project"
> # close_project
> # } else {
> # puts "BUILDER: In GUI mode. Leaving project open."
> # }
> BUILDER: Closing project
> ** Webtalk v2015.4 (64-bit)
>    SW Build 1412921 on Wed Nov 18 09:44:32 MST 2015
>    IP Build 1412160 on Tue Nov 17 13:47:24 MST 2015
> ** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
>
> source /home/joseavila/Documents/gnuradio_source/rfnoc-siggen2ch/rf
> noc/testbenches/noc_block_twochannelsiggen_tb/xsim_proj/xsim
> _proj.hw/webtalk/labtool_webtalk.tcl -notrace
> INFO: [Common 17-206] Exiting Webtalk at Wed Sep 27 15:09:04 2017...
> INFO: [Common 17-206] Exiting Vivado at Wed Sep 27 15:09:04 2017...
> Built target noc_block_twochannelsiggen_tb
>
> ___
> USRP-use

Re: [USRP-users] R: X300 STREAM_MODE_NUM_SAMPS_AND_DONE length limitation

2017-10-02 Thread Vladimir via USRP-users 
Daniele,

Thank you for your advice! The problem here (not so big though) is that upon 
receiving of needed number of samps you need to stop streaming and that implies 
waiting for some timeout while excess samps being flushed (as I understood, 
after issuing STREAM_MODE_STOP_CONTINUOUS you have to clear input buffers using 
something like streamer->flush_all(0.01);). I'm trying to estimate how long 
that timeout should be, and in some cases it obviously would be more or less 
worse than a possible scenario without timeouting.

Vladimir


>Понедельник,  2 октября 2017, 16:05 +03:00 от Disco Daniele 
>:
>
>I have the same problem.
>In the generation of the streamer
>uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
>erase the instruction stream_cmd.num_amps = total_num_samps; (or similar)
> 
>and instead to use a counter over the samples use a counter over the blocks of 
>data that the streamer acquires.
> 
>In b210 each acquisition is of 2044 samples
>In E310 is of 1016 (samps_per_buff)
> 
> 
>You can divide the number of samples (>0xfff) for samps_per_buff and make 
>a for loop to acquire all the data that you need
>rx_stream->revc(buff_ptrs, samps_per_buff, md, timeout)
> 
>I hope this help you
> 
>Da: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] Per conto di  
>Vladimir via USRP-users
>Inviato: venerdì 29 settembre 2017 16:53
>A: usrp-users
>Oggetto: [USRP-users] X300 STREAM_MODE_NUM_SAMPS_AND_DONE length limitation
> 
>Hello,
>
>Trying to save more than 2 sec trace with X300 at Fsamp = 100MHz, I encounter 
>some block length limit of 0x0fff = 268.4 MSamps, which means only 2.6 sec 
>of time. A bit surprised to see this in 64-bit environment... The assertion is 
>in module rx_vita_core_3000.cpp:
>
>UHD_ASSERT_THROW(stream_cmd.num_samps <= 0x0fff);
>
>Is this some physical limit, or it can be patched to a larger value? It's kind 
>of inconvenient to solve this through continuous streaming when you need a 
>trace of a certain length...
>
>Vladimir
>
>Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle 
>persone indicate. La diffusione, copia o qualsiasi altra azione derivante 
>dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora 
>abbiate ricevuto questo documento per errore siete cortesemente pregati di 
>darne immediata comunicazione al mittente e di provvedere alla sua 
>distruzione, Grazie.
>   
>
>This e-mail and any attachments is confidential and may  contain privileged 
>information intended for the addressee(s) only. Dissemination, copying, 
>printing or use by anybody else is unauthorised. If you are not the intended 
>recipient, please delete this message and any attachments and advise the 
>sender by return  e-mail, Thanks.
>   
>
>Rispetta l'ambiente. Non stampare questa mail se non è necessario.


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Frequency synching USRP B210

2017-10-02 Thread Marcus Müller via USRP-users 
Hi Daniel,

I'm a bit confused by your wording:

you say you set the clock source to O/B GPSDO and unknown PPS; but PPS
has nothing to do with the clock source, but with the timing source. Can
you confirm that both the time source and the clock source are set to
the GPSDO?

Also, you say you see a rotating constellation – that could be perfectly
fine, depending on how fast that rotates. Could you give us some info
about what your carrier frequency is, what your symbol rate is, and how
fast the constellation is rotating?

Best regards,

Marcus the lesser experienced


On 10/02/2017 08:52 AM, Cho, Daniel J (332C) via USRP-users wrote:
>
> Hello –
>
>  
>
> I am using a USRP B210 with a GPSDO.  All the parts are assembled. 
> When I power up my USRP, I get a green light at the GPS ANT LED for a
> couple seconds before it shuts off.  When I run a program, it
> recognizes that a GPSDO module is installed.  I ran
> query_gpsdo_sensors to make sure that GPS is locked and it is.  When I
> run gnuradio, I make sure to set both USRP sink and source clock
> sources to O/B GPSDO and unknown PPS. 
>
>  
>
> The setup is just one USRP B210 transmitting a BPSK signal from file
> and another USRP B210 receiving the BPSK signal and plotting it on the
> QT GUI sink.  When looking at the constellation plot of the QT GUI
> sink, the constellation is rotating thus the USRPs are not being
> synched.  How can I get the two USRPs synched using the GPSDO?  What
> am I doing wrong?
>
>  
>
> UHD version is 3.9.6.
>
>  
>
> Thanks,
>
> Daniel Cho
>
>  
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] uhd python transmition

2017-10-02 Thread Ivan Zahartchuk via USRP-users 
Hi, Marcus

I'm working on the data transmission using USRP B200 and UHD Python driver.
When transmitting the data, the error U appears. I think that the problem
is in the USRP B200 initialisation. I want to start the transmission as
another process.
Here is my code:

from PyQt4 import QtCore,QtGui,uic
import sys
import libpyuhd as lib
import numpy as np
from multiprocessing import Process
from time import sleep

class MainWindows(QtGui.QWidget):
def __init__(self):
QtGui.QWidget.__init__(self)
uic.loadUi("wind.ui",self)
self.connect(self.pushButton,QtCore.SIGNAL("clicked()"),self.start_on)
def transmitter(self):
freq = 450e6
print (freq)
band = 30e6
usrp = lib.usrp.multi_usrp(" ")
st_args = lib.usrp.stream_args("fc32", "sc8")
streamer = usrp.get_tx_stream(st_args)
usrp.set_tx_rate(band, 0)
usrp.set_tx_freq(lib.types.tune_request(freq), 0)
usrp.set_tx_gain(40, 0)
st_args.channels = [0]
metadata = lib.types.tx_metadata()
metadata.start_of_burst = True
metadata.end_of_burst=False
metadata.time_spec = lib.types.time_spec(1)
data = np.array(np.random.uniform(0, 1, 4096), dtype=np.complex64)
# QtCore.QObject.connect(window.gener)
while True:
streamer.send(data, metadata)
metadata.time_spec = lib.types.time_spec(0)
#metadata.has_time_spec=False
#if window.gener.isChecked() == True:
def start_on(self):
p = Process(target=self.transmitter)
p.start()
p.join( )
if  __name__=="__main__":
app=QtGui.QApplication(sys.argv)
window=MainWindows()
window.show()
sys.exit(app.exec_())
if (sys.flags.interactive != 1) or not hasattr(QtCore, 'PYQT_VERSION'):
QtGui.QApplication.instance().exec_()


Tell me please, what seems to be a problem?

Thank you in advance.

PS sorry for my English
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] OFDM Broken

2017-10-02 Thread Francisco Alberto Kindelan-Espinosa via USRP-users 
Hello,

I'm trying to get something from RFNoC OFDM working but have had no luck.

In the rfnoc-devel branch, the schmidl_cox block cannot be built without
errors and the .v doesn't appear to be complete.

Using the ofdm-branches (gr-ettus, uhd, uhd-fpga), the schmidl_cox can be
built but runs with errors.

Is there a plan to get OFDM working?  I want to help the effort but don't
know where to begin.  Did OFDM ever work correctly (or close to correctly)
at some point?  If so, can someone point me to the right revisions of
gr-ettus, uhd, and uhd-fpga?

Thanks,
Frank
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] uhd python transmition

2017-10-02 Thread Marcus Müller via USRP-users 
Hi Ivan,

since you send the first samples with a timestamp of one, this is not a
good idea:


On 02.10.2017 21:46, Ivan Zahartchuk via USRP-users wrote:
>   metadata.time_spec = lib.types.time_spec(0)
That basically forces the next packet to have 0 timestamp, i.e. to be
more than 1s too late ("L" error).

Your "U" might be caused by the fact that 30 MS/s is actually a lot of data.

I'm not convinced by the idea to use multiple processes in a GUI / UHD
application. That's what threads are for. Processes don't share the same
memory. I'm not an expert on QT, but I can't help myself but think you
should stick to QT methodology here, and that implies starting your
transmitter thread as QThread.

Best regards,
Marcus
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] uhd python transmition

2017-10-02 Thread Andrej Rode via USRP-users 
Hi Ivan, 

> freq = 450e6
> print (freq)
> band = 30e6
> usrp = lib.usrp.multi_usrp(" ")
> st_args = lib.usrp.stream_args("fc32", "sc8")
> streamer = usrp.get_tx_stream(st_args)
> usrp.set_tx_rate(band, 0)
> usrp.set_tx_freq(lib.types.tune_request(freq), 0)
> usrp.set_tx_gain(40, 0)
> st_args.channels = [0]
> metadata = lib.types.tx_metadata()
> metadata.start_of_burst = True
> metadata.end_of_burst=False
> metadata.time_spec = lib.types.time_spec(1)
> data = np.array(np.random.uniform(0, 1, 4096), dtype=np.complex64)
> # QtCore.QObject.connect(window.gener)
> while True:
> streamer.send(data, metadata)
> metadata.time_spec = lib.types.time_spec(0)
> #metadata.has_time_spec=False
> #if window.gener.isChecked() == True:

From the this pieco of Code I see you are trying to transmit with a rate
of 30MS with a buffer size of 4096 items each. Your code is also pretty
stripped down. You could try to move the metadata creation in front of
the loop, memory allocation in a tight send loop could result in a
performance loss.

Other than that the code looks good. Sending data in bigger chunks would
certainly improve the performance.

Cheers,
Andrej
-- 
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA


signature.asc
Description: Digital signature
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] max input power

2017-10-02 Thread Marcus D. Leech via USRP-users 

On 10/02/2017 08:17 PM, Nirmala Soundararajan wrote:
I am trying to use live SDR environment for programming USRP B200 
mini. I have never tried it before. When I boot live SDR through flash 
drive, it says 'try ubuntu without installing' and 'install ubuntu'.


I tried with both options, but I found that Internet is very slow in 
'try ubuntu' mode vis-a-vis 'install ubuntu'. Is this normal??


regards

Nirmala


No idea.

You should always keep the mailing-list in the loop, and when your 
subject-matter changes, PLEASE update the subject line to match.


There should be no difference in performance between the two modes.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] OFDM Broken

2017-10-02 Thread Tom Bereknyei via USRP-users 
I ran into a similar issue. We ended up rebuilding portions of OFDM. We are
working to release, but trying to figure out some critical bugs first.

I'm sure there are many in a similar position. If we pool together, would
the groups you represent be willing to fund RFNoC developers to solidify
the OFDM block-set?
On Mon, Oct 2, 2017 at 15:51 Francisco Alberto Kindelan-Espinosa via
USRP-users  wrote:

> Hello,
>
> I'm trying to get something from RFNoC OFDM working but have had no luck.
>
> In the rfnoc-devel branch, the schmidl_cox block cannot be built without
> errors and the .v doesn't appear to be complete.
>
> Using the ofdm-branches (gr-ettus, uhd, uhd-fpga), the schmidl_cox can be
> built but runs with errors.
>
> Is there a plan to get OFDM working?  I want to help the effort but don't
> know where to begin.  Did OFDM ever work correctly (or close to correctly)
> at some point?  If so, can someone point me to the right revisions of
> gr-ettus, uhd, and uhd-fpga?
>
> Thanks,
> Frank
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-- 
Maj Tom Bereknyei
Defense Digital Service
t...@dds.mil
(571) 225-1630‬
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] cannot ping

2017-10-02 Thread seah chong via USRP-users 
sorry about that, the coverage networking is weak. IP Address PC A is
192.168.10.1 netmask 255.255.255.0. what i means with Omnidirectional is
actually the communication between the USRP  is propagate within the circle.

On Fri, Sep 29, 2017 at 11:31 AM, seah chong  wrote:

> hi
> the computer connected to the device of USRP N210 using Communication
> System Toolbox Support Packages. the device  connected using the ethernet
> Cable. The first and second  USRP will communicate within omnidirectional.
>
>
>
>
>
>
>
>
>
> *>> findsdruChecking radio connections...ans =  Platform:
> 'N200/N210/USRP2'IPAddress: '192.168.10.2'SerialNum: 'F5E4FF'*
> *   Status: 'Success'*
>
> Both USRP N210 are successfully connected to the PC but unable
> to communicate to each other.
> I also try ip route get
>
>
>
>
> *root@seah-Precision-T1700:~# ip route get 192.168.20.2192.168.20.2 via
> 20.20.20.20 dev wlan1  src 20.20.20.103 cache
> root@seah-Precision-T1700:~# ip route add 192.168.20.2 via 20.20.20.20*
>
>
>
>
>
>
>
>
> *root@seah-Precision-T1700:~# route -nKernel IP routing
> tableDestination Gateway Genmask Flags Metric Ref
> Use Iface0.0.0.0 20.20.20.20 0.0.0.0 UG0
> 00 wlan120.20.20.0  0.0.0.0 255.255.255.0   U
> 9  00 wlan1192.168.10.00.0.0.0 255.255.255.0
> U 0  00 eth0192.168.20.220.20.20.20 255.255.255.255
> UGH   0  00 wlan1*
>
>
>
>
>
>
>
>
>
> *root@seah-Precision-T1700:~# ping 192.168.20.2PING 192.168.20.2
> (192.168.20.2) 56(84) bytes of data.^C--- 192.168.20.2 ping statistics
> ---17 packets transmitted, 0 received, 100% packet loss, time
> 16128msroot@seah-Precision-T1700:~# ping 20.20.20.20PING 20.20.20.20
> (20.20.20.20) 56(84) bytes of data.64 bytes from **20.20.20.20*
> 
> *: icmp_seq=1 ttl=64 time=149 ms64 bytes from **20.20.20.20*
> 
> *: icmp_seq=3 ttl=64 time=160 ms64 bytes from **20.20.20.20*
> 
>
>
>
> *: icmp_seq=4 ttl=64 time=0.899 ms^C--- 20.20.20.20 ping statistics ---4
> packets transmitted, 3 received, 25% packet loss, time 3002msrtt
> min/avg/max/mdev = 0.899/103.625/160.323/72.769 ms*
>
>
> * I attach figure  how the computer connected. I hope someone can
> enlighten me and can give me the solutions.*
>
> Regards,
>
> ChongSeah
>
>
>
> 
>
> On Wed, Sep 27, 2017 at 1:30 PM, seah chong  wrote:
>
>> hi
>> the computer connected to the device of USRP N210 using Communication
>> System Toolbox Support Packages. the device  connected using the ethernet
>> Cable. The first and second  USRP will communicate within omnidirectional.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *>> findsdruChecking radio connections...ans =  Platform:
>> 'N200/N210/USRP2'IPAddress: '192.168.10.2'SerialNum: 'F5E4FF'*
>> *   Status: 'Success'*
>>
>> Both USRP N210 are successfully connected to the PC but unable
>> to communicate to each other.
>>
>>
>>
>> *I hope someone can enlighten me and can give me the solutions.*
>>
>> Regards,
>>
>> ChongSeah
>>
>>
>> On Tue, Sep 26, 2017 at 9:14 PM, Leandro Echevarría <
>> leoechevar...@gmail.com> wrote:
>>
>>> Hello ChongSeah,
>>>
>>> Can you explain a little more about what your network configuration
>>> looks like? Maybe a drawing of all the network interfaces with their
>>> respective IPs and subnet masks may help us understand the problem better.
>>>
>>> How are the computers connected? And how are the N210s connected to them?
>>>
>>> Regards,
>>>
>>> Leo.
>>>
>>> On Tue, Sep 26, 2017 at 6:00 AM seah chong via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 hi all,

 i have two Pc with device USRP N210. At PC A the IP address
 "192.168.10.1 netmask 255.255.255.0 and at PC B  the IP address
 "192.168.20.1 netmask 255.255.255.0.
 i also route add at the PC A using ip route add 192.168.20.0/24 via
 192.168.10.2 and at the PC B using ip route add 192.168.10.0/24 via
 192.168.20.2.But i cannot ping to PC B and same too goes to PC A.


 the error comes out like below





 *root@seah-Precision-T1700:~# ping 192.168.20.2PING 192.168.20.2
 (192.168.20.2) 56(84) bytes of data.^C--- 192.168.20.2 ping statistics ---3
 packets transmitted, 0 received, 100% packet loss, time 2016ms*

 I hope someone can enlighten me and can give me the solutions.

 Regards,

 ChongSeah

 ___
 USRP-users mailing list
 USRP-users@lists.ettus.com
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

>>>
>>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com