[USRP-users] Bug about for E312

[liu Jong via USRP-users]

HI all,
For multiple E312 synchronizing,we did synchronous reception tests, and
specific things as email descriptions:
https://mail.google.com/mail/u/0/?pc=topnav-about-en#all/15f24798ac0bac0b
I also noted that said it was a bug:
http://permalink.gmane.org/gmane.comp.hardware.usrp.e100/16889

Has this bug been repaired?  can E312 be used for TDOA measurement and, if
possible, how to implement it in the program?

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

[USRP-users] interpretation of received signal

[Nirmala Soundararajan via USRP-users]

Hi Konstantin and Mike,

In fact I started with 0 gains for both transmitter and receiver with
different amplitudes of input signal. The received power is always in the
range of -80 dbm to -100 dbm.

I am not sure how to say that a certain received power (in dbm) 'is
acceptable' when given an input signal  (that evaluates approx to 0 dbm in
fft) indoors when the transmitting and receiving antenna are very close say
just 0.5 meters apart for a carrier frequency of around 800 MHz.

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] UHD 3.10.2 | X300 - High CPU load even for low samples rate

[Marcus D. Leech via USRP-users]

On 10/19/2017 10:25 AM, Kai-Uwe Storek via USRP-users wrote:

Hey,

after experiencing some problems (time outs, etc) with the current UHD
develop version (master branch) I changed the UHD version to 3.10.2
(maint branch, #122bfae).

To do so, I just used the prefix recipe gnuradio-stable via pybombs.

Now I'm not able to transmit even low bandwidth signals. My setup is

- X300 via 1G ethernet
- gnuradio (maint branch)
- Debian with kernel 4.9.

I used a simple flow graph with just a sine source directly connected
to the USRP sink block. Even for sample rates below 2MSamples/s one of
the cpu core of my Xeon E5-2630 v2 is 100% busy.

Observing the cpu load with htop, I recognized that most of the cpu
load is red which indicates kernel space activities...

After several seconds I finally got many "U"s in the console window.

Some ideas how to isolate the problem?
Thanks in advance!

Kai

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
I just constructed the attached flow-graph, and ran it on my ancient 
Dell Latitude laptop:


[mleech@lab ~]$ ./x300_test.py
linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); Boost_105400; 
UHD_003.010.002.000-3-g122bfae1


-- X300 initialization sequence...
-- Determining maximum frame size... 4320 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO Found an internal GPSDO: LC_XO, Firmware 
Rev 0.929a

-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1290.6MB/s)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1309.7MB/s)
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass


No underruns at all, and CPU was quite modest.


Are you running within a VM?





x300_test.grc
Description: application/gnuradio-grc
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UHD 3.10.2 | X300 - High CPU load even for low samples rate

[Brent Stapleton via USRP-users]

Hi Kai,

Fully consuming one core isn't unusual. Why do you think you're not
transmitting?

If you want to isolate the USRP performance, you could use UHD example
code, like benchmark_rate (in /path/to/prefix/lib/uhd/examples/). This will
provide a summary after running, and may give an indication of what
problems you're seeing.

Regards,
Brent

On Thu, Oct 19, 2017 at 7:25 AM, Kai-Uwe Storek via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey,
>
> after experiencing some problems (time outs, etc) with the current UHD
> develop version (master branch) I changed the UHD version to 3.10.2
> (maint branch, #122bfae).
>
> To do so, I just used the prefix recipe gnuradio-stable via pybombs.
>
> Now I'm not able to transmit even low bandwidth signals. My setup is
>
> - X300 via 1G ethernet
> - gnuradio (maint branch)
> - Debian with kernel 4.9.
>
> I used a simple flow graph with just a sine source directly connected
> to the USRP sink block. Even for sample rates below 2MSamples/s one of
> the cpu core of my Xeon E5-2630 v2 is 100% busy.
>
> Observing the cpu load with htop, I recognized that most of the cpu
> load is red which indicates kernel space activities...
>
> After several seconds I finally got many "U"s in the console window.
>
> Some ideas how to isolate the problem?
> Thanks in advance!
>
> Kai
>
> ___
> 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] UBX-160 with X310 communication issue

[Mark Koenig via USRP-users]

Nate,

There seems to be a number of differences between the UBX-40 v1, UBX-40 v2 and 
UBX-160 v1, UBX-160 v2.  Is there any documentation describing the difference 
between the v1 and v2 daughtercards?  I am also noticing some communication 
anomalies when using the v2 daugtercard.

Thank you

Mark

From: Nate Temple 
Date: Tuesday, October 17, 2017 at 5:19 PM
To: Mark Koenig 
Cc: "usrp-users@lists.ettus.com" 
Subject: Re: [USRP-users] UBX-160 with X310 communication issue

Hi Mark,

The UBX v2 is not supported using UHD 3.9.3. Support for the UBX v2 was added 
with UHD 3.9.5 and UHD 3.10.2.0. Can you please try updating to the newest UHD, 
such as 3.9.7 or 3.10.2.0 and try probing USRP/DBs again?

Regards,
Nate Temple

On Tue, Oct 17, 2017 at 1:01 PM, Mark Koenig via USRP-users 
> wrote:
Hello,

I am looking for some help with respect to the UBX-160.  I have two version 2 
daughtercards which were purchased a couple of months ago.

I am running on CentOS 7.2 and CentOS 6.5 with GNU radio version 3.7.4 and UHD 
version 003.009.003.

I can ping the USRP and also return information on the uhd_find_devices 
command, however, when I run the uhd_usrp_probe command I do not get a return 
for the daughtercards.  The example output is below.

Any help would be EXTREMELY appreciated.

Thank you
Mark

linux; GNU C++ version 4.4.7 20120313 (Red Hat 4.4.7-16); Boost_105300; 
UHD_003.009.004-0-g2b5a88bb

-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- 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
  _
/
|   Device: X-Series Device
| _
|/
|   |   Mboard: X310
|   |   revision: 11
|   |   revision_compat: 7
|   |   product: 30818
|   |   mac-addr0: 00:80:2f:17:43:3f
|   |   mac-addr1: 00:80:2f:17:43:40
|   |   gateway: 192.168.10.1
|   |   ip-addr0: 192.168.10.2
|   |   subnet0: 255.255.255.0
|   |   ip-addr1: 192.168.20.2
|   |   subnet1: 255.255.255.0
|   |   ip-addr2: 192.168.30.2
|   |   subnet2: 255.255.255.0
|   |   ip-addr3: 192.168.40.2
|   |   subnet3: 255.255.255.0
|   |   serial: 311FF4E
|   |   FW Version: 4.0
|   |   FPGA Version: 19.0
|   |
|   |   Time sources: internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: gps_gpgga, gps_gprmc, gps_time, gps_locked, gps_servo, 
ref_locked
|   | _
|   |/
|   |   |   RX DSP: 0
|   |   |   Freq range: -100.000 to 100.000 MHz
|   | _
|   |/
|   |   |   RX DSP: 1
|   |   |   Freq range: -100.000 to 100.000 MHz
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   |   ID: Unknown (0x007e)
|   |   |   Serial: 3120D56
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: Unknown (0x007e) - 0
|   |   |   |   Antennas:
|   |   |   |   Sensors:
|   |   |   |   Freq range: 0.000 to 0.000 MHz
|   |   |   |   Gain Elements: None
|   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: ads62p48
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   | _
|   |/
|   |   |   RX Dboard: B
|   |   |   ID: Unknown (0x007e)
|   |   |   Serial: 3120D4A
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: Unknown (0x007e) - 0
|   |   |   |   Antennas:
|   |   |   |   Sensors:
|   |   |   |   Freq range: 0.000 to 0.000 MHz
|   |   |   |   Gain Elements: None
|   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: B
|   |   |   |   Name: ads62p48
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   | _
|   |/
|   |   |   TX DSP: 0
|   |   |   Freq range: -100.000 to 100.000 MHz
|   | _
|   |/
|   |   |   TX DSP: 1
|   |   |   Freq 

[USRP-users] UHD 3.10.2 | X300 - High CPU load even for low samples rate

[Kai-Uwe Storek via USRP-users]

Hey,

after experiencing some problems (time outs, etc) with the current UHD
develop version (master branch) I changed the UHD version to 3.10.2
(maint branch, #122bfae).

To do so, I just used the prefix recipe gnuradio-stable via pybombs.

Now I'm not able to transmit even low bandwidth signals. My setup is

- X300 via 1G ethernet
- gnuradio (maint branch)
- Debian with kernel 4.9.

I used a simple flow graph with just a sine source directly connected
to the USRP sink block. Even for sample rates below 2MSamples/s one of
the cpu core of my Xeon E5-2630 v2 is 100% busy.

Observing the cpu load with htop, I recognized that most of the cpu
load is red which indicates kernel space activities...

After several seconds I finally got many "U"s in the console window.

Some ideas how to isolate the problem?
Thanks in advance!

Kai

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

Re: [USRP-users] Still having problems receiving multiple channels

[Janos Buttgereit via USRP-users]

Hi Robin,

Thank you so much, you pointed me to the right direction!

While nearly all calls I used to configure the device have the default argument 
ALL_CHANS or ALL_MBOARDS, set_rx_freq has the default argument chan=0. A quick 
look into the multi_usrp class reference should be enough to find that out, 
however I overlooked it for some reasons. Now I’m receiving multiple channels 
as expected.


> Am 17.10.2017 um 15:22 schrieb ROBIN TORTORA :
> 
> I have a very similar app, but I do take a bit of a different approach.
> 
> 
> 
> I dont know that any of these issues are related to your implementation, but 
> I will give you some insights into how I implemented my approach.
> 
> 
> 
> Simple thing first, set_time_unknown_pps can take up to 2 seconds to execute, 
> so I would increase your sleep time to something like this:
> 
> 
> 
> // Next, we want to set ALL MOTHERBAORD clocks to the same time based on the 
> 1PPS signal.
> g_usrp->set_time_unknown_pps( uhd::time_spec_t( 0.0 ) );
> 
> // Syncing to unknown pps can take up to 2 seconds, wait a bit longer to be 
> sure...
> std::this_thread::sleep_for( std::chrono::milliseconds( 2100 ) );
> 
> 
> 
> Some things happen on a motherboard level, some things happen on a 
> daughtercard level...
> 
> 
> 
> You may want to check the ref_locked flag on each motherboard before 
> proceeding to insure clock source sync...
> 
> 
> 
> I think you are only setting the frequency on channel 0...
> 
> 
> 
> Check the API, but I think set_rx_freq takes a channel number...  I think 
> this is your main problem...
> 
> 
> 
> You also may want to coherently tune the rx freq across daughtercards using 
> timed commands...
> 
> 
> 
> 
>> On October 17, 2017 at 8:00 AM Janos Buttgereit via USRP-users 
>>  wrote:
>> 
>> Hi Derek,
>> 
>> thank you for the quick response. I’m working with SBX 120 daughter cards. I 
>> copied the console output of my program to a comment under the gist I linked 
>> in my first post. Except for one warning about duplicate IP addresses for 
>> the 1GBit Link that never seemed to generate any problems when successfully 
>> running the devices with gnu radio and 10GBit Ethernet all seems fine to me. 
>> I hope this won’t be the problem, as I’m not the only one using the X300s 
>> round here and reconfiguring the IP addresses could lead to confusion with 
>> the other users. But I strongly doubt this to be an IP address error (I 
>> think in this case there would be no communication at all?), I expect the 
>> error to originate from some wrong settings for the signal path before the 
>> ADC.
>> 
>> Thanks,
>> Janos
>> 
>>> Am 17.10.2017 um 13:43 schrieb Derek Kozel >> >:
>>> 
>>> Hi Janos,
>>> 
>>> What daughtercards are you using? Can you include the console output of 
>>> your program when it runs? It looks like you have useful log messages.
>>> 
>>> Thanks,
>>> Derek
>>> 
>>> On Tue, Oct 17, 2017 at 11:32 AM, Janos Buttgereit via USRP-users 
>>> > wrote:
>>> Hello everybody,
>>> 
>>> I wrote to the mailing list some month ago as I had problems setting up a 
>>> multi_usrp from four USRP N210 with the help of the C++ API. As there are 
>>> other projects with higher priority, I’m just working on the USRP-based 
>>> stuff from time to time, that explains why there is a problem unsolved for 
>>> months now. In the end some specifications changed, so I dropped the N210 
>>> and I’m now working with a pair of X300 devices. 
>>> 
>>> The problem I still have after having solved a lot of other things with 
>>> your help, is that there’s always only valid data from the first channel. 
>>> To make sure that there is no bug in my fairly big code, I created a simple 
>>> command line application, that just records four channels to four .bin 
>>> files. These files are then loaded in gnu octave In this scenario, both 
>>> X300 devices are clocked and time synced by an external OctoClock and fed 
>>> with the same sine-wave, generated by a Signal Generator and split by a 
>>> power splitter.
>>> 
>>> I pasted my code and a plot of what the received data looks like here:
>>> https://gist.github.com/JanosGit/af51ae66c3a5c8a90119ec5f98e01162 
>>> 
>>> 
>>> By the way, a modified version of the rx_multi_samples example which I 
>>> modified to output the samples to a file instead of dropping them showed 
>>> the exactly same result.
>>> 
>>> For your Information: I’m working on a fresh Ubuntu installation with the 
>>> X300 devices connected over SFP Cables to a dual 10GBit Ethernet PCIe Card. 
>>> Receiving valid data on all four channels works with the same hardware but 
>>> a slightly older Ubuntu installation on a second computer when using gnu 
>>> radio (never change a running system), so I don’t think there is any 
>>> hardware