date:20180504

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

2018-05-04 Thread Michael West via USRP-users

Hi Andrew,

The fix is on the master branch (commit 8922095
).
It is being included in the next set of commits on the maint branch that
should be available in the next few days.

Regards,
Michael

On Wed, May 2, 2018 at 1:13 PM, switchlanez  wrote:

> Hi Michael,
>
> I see new commits have been entered in the uhd maint branch in the last
> couple days. Were any related to this issue?
>
> Andrew
>
> On Mon, Apr 23, 2018 at 11:12 AM, Michael West 
> wrote:
>
>> Hi Louis/Andrew,
>>
>> The root cause of the issue has been identified and a fix is in
>> progress.  We should have the fix available on the head of the maint branch
>> very soon.  Thank you for bringing it to our attention!
>>
>> Regards,
>> Michael
>>
>> On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> I have an issue that may be related. Using LFTX and LFRX boards in an
>>> X310, anytime I use the RFNoC Radio block in Rx mode the run terminates
>>> with:
>>>
>>> terminate called after throwing an instance of 'std::out_of_range'
>>>   what():  map::at
>>>
>>> Following for updates.
>>>
>>> Andrew
>>>
>>>
>>> On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hello Louis:

 Thanks for the detailed feedback. We have reproduced this issue, and
 are debugging it now. We will get back to you and post an update shortly.

 --Neel Pandeya




 On 12 April 2018 at 18:46, Louis Brown via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Could it be something to do with this commit for address offsets?
>
> https://github.com/EttusResearch/uhd/commit/8ee22529f33a63c2
> 064b0dc6fbcc04c2ded94b4a
>
> Lou
>
>
> On Apr 12, 2018, at 16:38, Louis Brown  wrote:
>
>
> Did something change with respect to daughter board addressing in UHD
> 3.11?
> I have an X310 with LFTX and LFRX  in motherboard slot A.
> When I run benchmark_rate it core dumps as follows:
>
> /*
> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
> "addr=192.168.40.2" --tx_rate=10E6
>
> [INFO] [UHD] linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5);
> Boost_106400; UHD_3.11.0.1-0-unknown
> [00:00:00.06] Creating the usrp device with: addr=192.168.40.2...
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Determining maximum frame size...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Setup basic communication...
> [INFO] [X300] Loading values from EEPROM...
> [INFO] [X300] Setup RF frontend clocking...
> [INFO] [X300] Radio 1x clock:200
> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0...
> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1299 MB/s)
> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1...
> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1302 MB/s)
> [WARNING] [RFNOC] [0/Radio_0] defines 2 input buffer sizes, but 1
> input ports
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [WARNING] [RFNOC] [0/Radio_1] defines 2 input buffer sizes, but 1
> input ports
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> Using Device: Single USRP:
> Device: X-Series Device
> Mboard 0: X310
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: LFRX (AB)
> RX Channel: 1
> RX DSP: 0
> RX Dboard: B
> RX Subdev: Unknown (0x) - 0
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: LFTX (AB)
> TX Channel: 1
> TX DSP: 0
> TX Dboard: B
> TX Subdev: Unknown (0x) - 0
>
> [00:00:02.623786] Setting device timestamp to 0...
> terminate called after throwing an instance of 'std::out_of_range'
> what(): map::at
> Aborted (core dumped)
> */
>
>
> If I specify tx_channels "1" it runs, lighting up the slot B TX/RX
> LED, or course I have no boards installed there.
>
> /*
> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
> "addr=192.168.40.2" --tx_rate=100E6 --tx_channels "1"
> */
>
> If I specify tx_channels "0" it core dumps with the same
> std::out_of_range
>
> Flow graphs that ran in UHD 3.10 with sub-device "A:AB" no longer run:
>
> /*
> [INFO] [CORES] Timer loopback test passed
> terminate called after throwing an instance of 'std::out_of_range'
> what(): map::at
> */
>

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

2018-05-04 Thread switchlanez via USRP-users

Thanks Michael. Do you know if I were to install rfnoc under a different
prefix would the UHD version be able to be switched between the prefixes?
I'm using an older rfnoc build compatible with Vivado 2015.4 and hesitant
to install the latest build and checkout that new fix if it it will
overwrite the older UHD version.

On Fri, May 4, 2018 at 11:25 AM, Michael West 
wrote:

> Hi Andrew,
>
> The fix is on the master branch (commit 8922095
> ).
> It is being included in the next set of commits on the maint branch that
> should be available in the next few days.
>
> Regards,
> Michael
>
> On Wed, May 2, 2018 at 1:13 PM, switchlanez  wrote:
>
>> Hi Michael,
>>
>> I see new commits have been entered in the uhd maint branch in the last
>> couple days. Were any related to this issue?
>>
>> Andrew
>>
>> On Mon, Apr 23, 2018 at 11:12 AM, Michael West 
>> wrote:
>>
>>> Hi Louis/Andrew,
>>>
>>> The root cause of the issue has been identified and a fix is in
>>> progress.  We should have the fix available on the head of the maint branch
>>> very soon.  Thank you for bringing it to our attention!
>>>
>>> Regards,
>>> Michael
>>>
>>> On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 I have an issue that may be related. Using LFTX and LFRX boards in an
 X310, anytime I use the RFNoC Radio block in Rx mode the run terminates
 with:

 terminate called after throwing an instance of 'std::out_of_range'
   what():  map::at

 Following for updates.

 Andrew


 On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Hello Louis:
>
> Thanks for the detailed feedback. We have reproduced this issue, and
> are debugging it now. We will get back to you and post an update shortly.
>
> --Neel Pandeya
>
>
>
>
> On 12 April 2018 at 18:46, Louis Brown via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Could it be something to do with this commit for address offsets?
>>
>> https://github.com/EttusResearch/uhd/commit/8ee22529f33a63c2
>> 064b0dc6fbcc04c2ded94b4a
>>
>> Lou
>>
>>
>> On Apr 12, 2018, at 16:38, Louis Brown  wrote:
>>
>>
>> Did something change with respect to daughter board addressing in UHD
>> 3.11?
>> I have an X310 with LFTX and LFRX  in motherboard slot A.
>> When I run benchmark_rate it core dumps as follows:
>>
>> /*
>> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
>> "addr=192.168.40.2" --tx_rate=10E6
>>
>> [INFO] [UHD] linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5);
>> Boost_106400; UHD_3.11.0.1-0-unknown
>> [00:00:00.06] Creating the usrp device with: addr=192.168.40.2...
>> [INFO] [X300] X300 initialization sequence...
>> [INFO] [X300] Determining maximum frame size...
>> [INFO] [X300] Maximum frame size: 8000 bytes.
>> [INFO] [X300] Setup basic communication...
>> [INFO] [X300] Loading values from EEPROM...
>> [INFO] [X300] Setup RF frontend clocking...
>> [INFO] [X300] Radio 1x clock:200
>> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0...
>> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1299 MB/s)
>> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1...
>> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1302 MB/s)
>> [WARNING] [RFNOC] [0/Radio_0] defines 2 input buffer sizes, but 1
>> input ports
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [WARNING] [RFNOC] [0/Radio_1] defines 2 input buffer sizes, but 1
>> input ports
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [INFO] [CORES] Performing timer loopback test...
>> [INFO] [CORES] Timer loopback test passed
>> [INFO] [CORES] Performing timer loopback test...
>> [INFO] [CORES] Timer loopback test passed
>> Using Device: Single USRP:
>> Device: X-Series Device
>> Mboard 0: X310
>> RX Channel: 0
>> RX DSP: 0
>> RX Dboard: A
>> RX Subdev: LFRX (AB)
>> RX Channel: 1
>> RX DSP: 0
>> RX Dboard: B
>> RX Subdev: Unknown (0x) - 0
>> TX Channel: 0
>> TX DSP: 0
>> TX Dboard: A
>> TX Subdev: LFTX (AB)
>> TX Channel: 1
>> TX DSP: 0
>> TX Dboard: B
>> TX Subdev: Unknown (0x) - 0
>>
>> [00:00:02.623786] Setting device timestamp to 0...
>> terminate called after throwing an instance of 'std::out_of_range'
>> what(): map::at
>> Aborted (core dumped)
>> */
>>
>>
>> If I specify tx_channels "1" it runs, lighting up the slot B TX/RX
>>

[USRP-users] how to know the number of losted samples when overflow occurs ?

2018-05-04 Thread Matis Alun via USRP-users

Hi,

I remark that the "time_spec" passed to the "recv" method of an rx_streamer is 
not in
exact relation
with the length of the received vectors. For example, when receiving buffers of 
length
16384 at Fs=362319 Hz,
the buffer length should be equal to (16384+1)/362319=0.0452225 seconds, while 
the time
spec difference
between two successive calls to recv is 0.0483315 and sometimes 0.033402 (with 
a mean
value equals to 0.0452225).

My first idea was that the time_spec returned by the recv method was the time 
stamp of the
first sample of the
buffer, but I realize that it is false. Is it exact ?

As a consequence, how can I know the number of losted samples when an overflow 
occurs ?

thanks.

matis



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

Re: [USRP-users] USRP Underruns "UUUUU"

2018-05-04 Thread Kyeong Su Shin via USRP-users

Hello Yeo Jin,


First, find the maximum effective sampling rate that you can achieve with your 
computer. Connect a constant source to a USRP sink (for USRP sink underruns), 
or connect a USRP source to a null sink (for USRP source overruns) and run the 
flow graph. Try different sampling rates to find the maximum achievable 
sampling rate for your hardware (max samp rate that gives no underruns or 
overruns).



If the maximum stable sampling rate that you can achieve is still 4MS/s, then 
you are pretty much out of luck. You can try installing different versions of 
GNU Radio and UHD (older version/newer version, version with AVX support, etc) 
and then try again. If that does not help (very likely), then you WILL have to 
upgrade your computer. In some cases, using a different network card (for 
network-based USRPs) or USB card (for USB-based USRPs) may improve the 
achivable rate (when the bottleneck is the link between the USRP and the PC). 
If that doesn't work either, then you will have to get a faster machine.


If you can achieve a higher sampling rate with the simple flow graphs stated 
above, then the problem is the maximum throughput of your code. You can try 
optimizing your GNU Radio flow graphs and blocks. Try using simpler filters, 
and parallelize the bottlenecks within your flow graphs if possible (so as the 
CPU usage would go up to approx. 100% during the execution). You can run top 
and press H to see which block is taking the most CPU time (assuming a typical 
GNU/Linux distro).


If you do not need to generate your I-Q data in real time, then generate your 
data before the execution of the flow graph and simply play back the 
pre-generated data (with a File Source block). You can also push down some of 
your DSP logics to the FPGA of the USRPs, if you have licences for the needed 
software (and if you are okay with HDL).


Regards,

Kyeong Su Shin



보낸 사람: Yeo Jin Kuang Alvin (IA) via USRP-users  대신 
USRP-users 
보낸 날짜: 2018년 5월 4일 금요일 오후 6:29:09
받는 사람: usrp-users@lists.ettus.com
제목: [USRP-users] USRP Underruns "U"


Hi all,



I am getting underruns and overruns when trying to run the UHD programs, both 
GNU radio and C++. The maximum my computer can handle is 4MHz sampling rate 
before seeing “U”.

I’ve searched online and most people say, change a new computer into quad core 
etc.



Are there any other ways to solve this problem? I want to hit around 20 MHz, 
but 30 MHz – 40MHz if possible.



Thank you in advance!
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] B200mini sc12 wire format broken?

2018-05-04 Thread Emanuel via USRP-users

Hi,

I switched from UHD release 3.10.2.0 to the latest release 3.11.0.0 and 
recognized in my Gnuradio application, that UHD gives errors when using the 
sc12 wire format. However, only when I use the USRP in receive mode. In 
transmit mode, the sc12 format works. The sc8 and sc16 wire format work well 
for the receive mode. The same issue comes with 3.11.0.1.
Release 3.10.2.0 does not show this error.

Did anyone else experience that?

Best regards,
Emanuel

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

Re: [USRP-users] B200mini sc12 wire format broken?

2018-05-04 Thread Marcus D. Leech via USRP-users


On 05/04/2018 01:45 AM, Emanuel via USRP-users wrote:


Hi,

I switched from UHD release 3.10.2.0 to the latest release 3.11.0.0 
and recognized in my Gnuradio application, that UHD gives errors when 
using the sc12 wire format. However, only when I use the USRP in 
receive mode. In transmit mode, the sc12 format works. The sc8 and 
sc16 wire format work well for the receive mode. The same issue comes 
with 3.11.0.1.


Release 3.10.2.0 does not show this error.

Did anyone else experience that?

Best regards,

Emanuel__



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Could you perhaps share the error log?  That would help developers and 
others...




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

[USRP-users] USRP Underruns "UUUUU"

2018-05-04 Thread Yeo Jin Kuang Alvin (IA) via USRP-users

Hi all,

I am getting underruns and overruns when trying to run the UHD programs, both 
GNU radio and C++. The maximum my computer can handle is 4MHz sampling rate 
before seeing "U".
I've searched online and most people say, change a new computer into quad core 
etc.

Are there any other ways to solve this problem? I want to hit around 20 MHz, 
but 30 MHz - 40MHz if possible.

Thank you in advance!
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP Underruns "UUUUU"

2018-05-04 Thread Alfredo GARDEL - UAH via USRP-users


Hi Yeo,

Just in case, confirm that you have connected the board to a USB3 port.
Afterwards, confirm that the program logs says that "it is operating 
with USB3 speeds".


Hope it helps.
Alfredo Gardel

El 04/05/2018 a las 11:29, Yeo Jin Kuang Alvin (IA) via USRP-users escribió:


Hi all,

I am getting underruns and overruns when trying to run the UHD 
programs, both GNU radio and C++. The maximum my computer can handle 
is 4MHz sampling rate before seeing “U”.


I’ve searched online and most people say, change a new computer into 
quad core etc.


Are there any other ways to solve this problem? I want to hit around 
20 MHz, but 30 MHz – 40MHz if possible.


Thank you in advance!



Esta parte del cuerpo del mensaje se descargarÃ¡ bajo demanda.


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

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[USRP-users] how to know the number of losted samples when overflow occurs ?

Re: [USRP-users] USRP Underruns "UUUUU"

[USRP-users] B200mini sc12 wire format broken?

Re: [USRP-users] B200mini sc12 wire format broken?

[USRP-users] USRP Underruns "UUUUU"

Re: [USRP-users] USRP Underruns "UUUUU"

8 matches

Site Navigation

Mail list logo

Footer information