Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Timed Commands for GPIO (X3x0 and N2x0) (Dave NotTelling)
2. Re: underflow during transmission in usrp x310/2953R
(Marcus M?ller)
3. Re: Timed Commands for GPIO (X3x0 and N2x0) (Michael West)
4. Re: DAC front-end sync failed (Marcus M?ller)
5. Re: DAC front-end sync failed (Rob Kossler)
6. Re: RFNoC synchronous streaming (Marcus M?ller)
7. Re: Timed Commands for GPIO (X3x0 and N2x0) (Dave NotTelling)
8. Re: DAC front-end sync failed (Marcus M?ller)
9. Re: DAC front-end sync failed (Rob Kossler)
10. Re: RX chain slow down due to TX chain U/L warnings
(Dario Fertonani)
11. Re: Cannot remove X310 image (David Miller)
12. Error Using X310 ( NI USRP 2940 R) (Francesco Giannone)
13. Re: Implementing design on FPGA in X310 (Nives Novkovi?)
14. Re: Implementing design on FPGA in X310 (Jonathon Pendlum)
15. Re: RFNOC x310 image 2 bytes too large (Jonathon Pendlum)
16. Re: Implementing design on FPGA in X310 (Nives Novkovi?)
----------------------------------------------------------------------
Message: 1
Date: Thu, 29 Sep 2016 12:39:35 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Timed Commands for GPIO (X3x0 and N2x0)
Message-ID:
<cak6gvun46io-su7gk2fejdj9cp0lh8og4wr6m2wmnwyqkkf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Is it possible to set the GPIO pins on the N or X series radios at specific
times the same way that front end params (freq, gain, etc) can be set?
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/77786c3a/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 29 Sep 2016 09:40:42 -0700
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] underflow during transmission in usrp
x310/2953R
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
That's pretty strange; could you share which version of UHD you're using?
If that doesn't help: We might need to figure where your underflows
originate. I think your benchmark_rate based approach is probably pretty
good; it eliminates the added complexity of GNU Radio.
Let's first do a cross-check: if you instead connect your USRP with a
simple Gigabit Ethernet cable, does it work without underflows?
Furthermore, you might want to dive into where your cycles go. I held a
quick, very ad-hoc presentation about that [1]. You could follow the
setup on these slides to get a perf recording ("perf record
benchmark_rate --tx_rate 10000000") of your benchmark_rate, and analyze
that with "perf report".
Best regards,
Marcus
[1]https://github.com/marcusmueller/perfpres/blob/master/pres.pdf
On 09/29/2016 01:15 AM, Nikita Airee via USRP-users wrote:
> Hello all,
>
> this is what I'm using :
>
> USRP: NI USRP 2953R with CBX-40MHz daughterboards.
> Connected using PCI express to my laptop
> Laptop: Ubuntu 14.04, 16 GB memory, and processor Intel Core i5-3320M
> CPU @ 2.60GHz ? 4
>
> The issue I'm facing is that whenever I transmit anything using my
> usrp, I get a lot of underflow so much so that 'U's fill up the
> console and gnuradio freezes. Sometimes, I have to force it shut and
> start gnuradio again and sometimes, the screen unfreezes on its own
> after a while. I've attached a screenshot as well.
> The signal to be transmitted can be as simple as a sine wave of
> 100kHz or one of the transmitting flowgraphs of gr-uhd.
>
> I understand this has something to do with the sampling rate and have
> read through this
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-January/017766.html>
> thread.
>
> Following the steps mentioned there:
>
> output of free -m :
>
> total used free shared buffers cached
> Mem: 15621 2387 13234 319 76 1064
> -/+ buffers/cache: 1246 14375
> Swap: 15949 0 15949
>
> output to sudo lspci -vv is attached
>
> benchmark_rate gives serious underflows as well (tx_rate=10M)
>
> $/usr/local/lib/uhd/examples/benchmark_rate --tx_rate=10000000
> --tx_subdev=A:0
>
> Benchmark rate summary:
> Num received samples: 0
> Num dropped samples: 0
> Num overflows detected: 0
> Num transmitted samples: 108381056
> Num sequence errors: 0
> Num underflows detected: 1451
> Num late commands: 0
> Num timeouts: 0
>
> I even tried device calibration using:
> uhd_cal_rx_iq_balance --verbose --args="resource=RIO0"
> uhd_cal_tx_iq_balance --verbose --args="resource=RIO0"
> uhd_cal_tx_dc_offset --verbose --args="resource=RIO0"
>
> This starts out fine but ends with the following error: Receiver
> error: ERROR_CODE_TIMEOUT terminate called after throwing an instance
> of
> 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error>
> >' what(): boost: mutex lock failed in pthread_mutex_lock: Invalid
> argument Aborted (core dumped)
> I really can't get my head around the problem. Any and all ideas are
> welcome.
> Nikita
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/89fc817d/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 29 Sep 2016 09:43:18 -0700
From: Michael West <[email protected]>
To: Dave NotTelling <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Timed Commands for GPIO (X3x0 and N2x0)
Message-ID:
<CAM4xKrqBZG2vFNdW1V=UieiOB_Vm52=ao119iuaqtr_a9g2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Dave,
Yes. Just use the same set/clear_command_time() calls around your calls to
set the GPIO values.
Regards,
Michael
On Thu, Sep 29, 2016 at 9:39 AM, Dave NotTelling via USRP-users <
[email protected]> wrote:
> Is it possible to set the GPIO pins on the N or X series radios at
> specific times the same way that front end params (freq, gain, etc) can be
> set?
>
> Thanks!
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/b07fc8b5/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 29 Sep 2016 11:13:51 -0700
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] DAC front-end sync failed
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Follow up: What hardware ref is your mboard? You can tell from the upper
of the two little blue stickers on the motherboard PCB. What's the
letter in front of the dash?
Best regards,
Marcus
On 09/28/2016 03:13 PM, Rob Kossler via USRP-users wrote:
> On Wed, Sep 28, 2016 at 5:32 PM, Marcus D. Leech via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 09/28/2016 05:27 PM, Rob Kossler via USRP-users wrote:
>
> Hi,
> I occasionally still see the following failure (although it
> indicates warning, it crashes my application). This one seems
> to have been around for a while so I'm wondering if maybe it
> is thought to have been fixed already. I typically just
> re-execute my application and everything is fine.
>
> Rob
>
>
> UHD Warning:
> x300_dac_ctrl: front-end sync failed. unexpected FIFO
> depth [0x3]
> Error: RuntimeError: x300_dac_ctrl: front-end sync failed.
> unexpected FIFO depth [0x3]
>
>
> My specific config...
> UHD: UHD_003.010.000.000-0-a0ceeddc
> OS: Ubuntu 14.04 LTS
> X310 w/ two UBX-160 daughterboards
>
> What master clock rate--the standard 200MHz?
>
>
> Yes.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/d4fdffaf/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 29 Sep 2016 14:26:44 -0400
From: Rob Kossler <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] DAC front-end sync failed
Message-ID:
<cab__htt20wpzc6exkry2nrrqytwdrkhtakovflkozib+t8g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Unfortunately, not that easy to get to. Does this snippet from
uhd_usrp_probe answer the question?
| | Mboard: X310
| | revision: 6
| | revision_compat: 4
| | product: 30508
On Thu, Sep 29, 2016 at 2:13 PM, Marcus M?ller via USRP-users <
[email protected]> wrote:
> Follow up: What hardware ref is your mboard? You can tell from the upper
> of the two little blue stickers on the motherboard PCB. What's the letter
> in front of the dash?
>
> Best regards,
>
> Marcus
>
> On 09/28/2016 03:13 PM, Rob Kossler via USRP-users wrote:
>
> On Wed, Sep 28, 2016 at 5:32 PM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 09/28/2016 05:27 PM, Rob Kossler via USRP-users wrote:
>>
>>> Hi,
>>> I occasionally still see the following failure (although it indicates
>>> warning, it crashes my application). This one seems to have been around
>>> for a while so I'm wondering if maybe it is thought to have been fixed
>>> already. I typically just re-execute my application and everything is fine.
>>>
>>> Rob
>>>
>>>
>>> UHD Warning:
>>> x300_dac_ctrl: front-end sync failed. unexpected FIFO depth [0x3]
>>> Error: RuntimeError: x300_dac_ctrl: front-end sync failed. unexpected
>>> FIFO depth [0x3]
>>>
>>>
>>> My specific config...
>>> UHD: UHD_003.010.000.000-0-a0ceeddc
>>> OS: Ubuntu 14.04 LTS
>>> X310 w/ two UBX-160 daughterboards
>>>
>>> What master clock rate--the standard 200MHz?
>>
>>
> Yes.
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/91fa208a/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 29 Sep 2016 11:29:17 -0700
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] RFNoC synchronous streaming
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Frank,
yes, you can do time-aligned streaming with multiple channels.
Also: UHD itself doesn't have a Python API. However, GNU Radio has, and
with gr-ettus, there's a neat wrapper around UHD/RFNoC. You've probably
heard of the GNU Radio Companion, which you can use to generate GNU
Radio/gr-ettus/UHD/RFNoC flow graphs, and which generates python code
that sets everything up. You can work purely graphically, you can modify
the generated python, and you can of course modify and add your own GNU
Radio and RFNoC blocks.
Best regards,
Marcus
On 09/28/2016 10:07 PM, Frank Liu via USRP-users wrote:
>
> Following up on this: when using RFNoC, is it possible to stream
> samples directly to the host PC purely using Python? We'd like to
> contain all of our application's steps (building the RFNoC graph,
> streaming data to the host, and processing the results using our
> scripts) in a contained package.
>
> On Wed, Sep 28, 2016 at 4:43 PM, Frank Liu <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> Please forgive me if this is a newbie question, but is there a way
> to do synchronous streaming using RFNoC? All of the examples that
> I've seen allow for streaming through only one channel.
>
> --Frank
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/22f0a735/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 29 Sep 2016 14:37:24 -0400
From: Dave NotTelling <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Timed Commands for GPIO (X3x0 and N2x0)
Message-ID:
<cak6gvuoii2zape4chzysyvqpaw2lwbbabquxu0r6ku1vwoz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Michael,
Thank you!!
-Dave
On Thu, Sep 29, 2016 at 12:43 PM, Michael West <[email protected]>
wrote:
> Hi Dave,
>
> Yes. Just use the same set/clear_command_time() calls around your calls
> to set the GPIO values.
>
> Regards,
> Michael
>
> On Thu, Sep 29, 2016 at 9:39 AM, Dave NotTelling via USRP-users <
> [email protected]> wrote:
>
>> Is it possible to set the GPIO pins on the N or X series radios at
>> specific times the same way that front end params (freq, gain, etc) can be
>> set?
>>
>> Thanks!
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/f280758c/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 29 Sep 2016 11:50:11 -0700
From: Marcus M?ller <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] DAC front-end sync failed
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
The point is that the DAC sync would fail (AFAIK) if you had a rev7
board but somehow ended up with a rev6 mb eeprom. When did you buy this
X310?
Best regards,
Marcus
On 09/29/2016 11:26 AM, Rob Kossler wrote:
> Unfortunately, not that easy to get to. Does this snippet from
> uhd_usrp_probe answer the question?
>
> | | Mboard: X310
> | | revision: 6
> | | revision_compat: 4
> | | product: 30508
>
>
> On Thu, Sep 29, 2016 at 2:13 PM, Marcus M?ller via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Follow up: What hardware ref is your mboard? You can tell from the
> upper of the two little blue stickers on the motherboard PCB.
> What's the letter in front of the dash?
>
> Best regards,
>
> Marcus
>
>
> On 09/28/2016 03:13 PM, Rob Kossler via USRP-users wrote:
>> On Wed, Sep 28, 2016 at 5:32 PM, Marcus D. Leech via USRP-users
>> <[email protected] <mailto:[email protected]>>
>> wrote:
>>
>> On 09/28/2016 05:27 PM, Rob Kossler via USRP-users wrote:
>>
>> Hi,
>> I occasionally still see the following failure (although
>> it indicates warning, it crashes my application). This
>> one seems to have been around for a while so I'm
>> wondering if maybe it is thought to have been fixed
>> already. I typically just re-execute my application and
>> everything is fine.
>>
>> Rob
>>
>>
>> UHD Warning:
>> x300_dac_ctrl: front-end sync failed. unexpected FIFO
>> depth [0x3]
>> Error: RuntimeError: x300_dac_ctrl: front-end sync
>> failed. unexpected FIFO depth [0x3]
>>
>>
>> My specific config...
>> UHD: UHD_003.010.000.000-0-a0ceeddc
>> OS: Ubuntu 14.04 LTS
>> X310 w/ two UBX-160 daughterboards
>>
>> What master clock rate--the standard 200MHz?
>>
>>
>> Yes.
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
> _______________________________________________ USRP-users mailing
> list [email protected]
> <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/ff556e8b/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 29 Sep 2016 15:23:55 -0400
From: Rob Kossler <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] DAC front-end sync failed
Message-ID:
<cab__htsau0vt4tgcmxwas3hfuulssrxupmqwhbtuwcaym7y...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
This X310 is relatively old. Maybe it is possible to verify that from the
SN (F5FDDE). And, it generally does not fail - just occasionally.
Rob
On Thu, Sep 29, 2016 at 2:50 PM, Marcus M?ller <[email protected]>
wrote:
> The point is that the DAC sync would fail (AFAIK) if you had a rev7 board
> but somehow ended up with a rev6 mb eeprom. When did you buy this X310?
>
> Best regards,
>
> Marcus
> On 09/29/2016 11:26 AM, Rob Kossler wrote:
>
> Unfortunately, not that easy to get to. Does this snippet from
> uhd_usrp_probe answer the question?
>
> | | Mboard: X310
> | | revision: 6
> | | revision_compat: 4
> | | product: 30508
>
>
> On Thu, Sep 29, 2016 at 2:13 PM, Marcus M?ller via USRP-users <
> [email protected]> wrote:
>
>> Follow up: What hardware ref is your mboard? You can tell from the upper
>> of the two little blue stickers on the motherboard PCB. What's the letter
>> in front of the dash?
>>
>> Best regards,
>>
>> Marcus
>>
>> On 09/28/2016 03:13 PM, Rob Kossler via USRP-users wrote:
>>
>> On Wed, Sep 28, 2016 at 5:32 PM, Marcus D. Leech via USRP-users <
>> [email protected]> wrote:
>>
>>> On 09/28/2016 05:27 PM, Rob Kossler via USRP-users wrote:
>>>
>>>> Hi,
>>>> I occasionally still see the following failure (although it indicates
>>>> warning, it crashes my application). This one seems to have been around
>>>> for a while so I'm wondering if maybe it is thought to have been fixed
>>>> already. I typically just re-execute my application and everything is
>>>> fine.
>>>>
>>>> Rob
>>>>
>>>>
>>>> UHD Warning:
>>>> x300_dac_ctrl: front-end sync failed. unexpected FIFO depth [0x3]
>>>> Error: RuntimeError: x300_dac_ctrl: front-end sync failed. unexpected
>>>> FIFO depth [0x3]
>>>>
>>>>
>>>> My specific config...
>>>> UHD: UHD_003.010.000.000-0-a0ceeddc
>>>> OS: Ubuntu 14.04 LTS
>>>> X310 w/ two UBX-160 daughterboards
>>>>
>>>> What master clock rate--the standard 200MHz?
>>>
>>>
>> Yes.
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> _______________________________________________ USRP-users mailing list
>> [email protected] http://lists.ettus.com/mailman
>> /listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/8f5d8a1d/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 29 Sep 2016 16:12:46 -0700
From: Dario Fertonani <[email protected]>
To: Tom Tsou <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RX chain slow down due to TX chain U/L
warnings
Message-ID:
<CAJGEdAiiRJpmypQZtmJP2T-httuNV6mrWX=_fd5dpzdyuay...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I learned a bit more about the problem. The recv call returns with
fewer-than-expected samples, which I assumed was due to a timeout (all of
this is in the middle of a STREAM_MODE_START_CONTINUOUS recv stream) and
hence called a "RX slowdown". However, I verified with other timers that no
timeout actually happened. What else can be going on? More formally:
*Why would the recv call return with fewer-than-expected samples if not for
a timeout?*
In case it matters, I'm referring to recv calls with four parameters
(hence, with the fifth parameter one_packet left to its default value).
This is the metadata dump for the call the returns unexpectedly:
Has timespec: Yes Time of first sample: 145.803
Fragmented: No Fragmentation offset: 0
Start of burst: No End of burst: No
Error Code: ERROR_CODE_NONE Out of sequence: No
And this is the metadata dump for the following call (debug only, as the
previous return kills everything in regular operations).
Has timespec: Yes Time of first sample: 145.804
Fragmented: No Fragmentation offset: 0
Start of burst: No End of burst: No
Error Code: ERROR_CODE_OVERFLOW (Overflow) Out of
sequence: No
On Thu, Sep 29, 2016 at 12:19 AM, Tom Tsou <[email protected]> wrote:
> On Sat, Sep 24, 2016 at 11:32 AM, Dario Fertonani via USRP-users
> <[email protected]> wrote:
> > The following is seen on all B210 models we have, and is more pronounced
> at
> > high sampling rates (20+ MHz) in full-duplex MIMO operations.
> >
> > A stream of U/L warnings, caused by about 10-15 ms worth of IQ samples
> > getting too late to the TX chain, causes the rx chain to slow down too.
> > Specifically, the recv( ) call blocks for longer. If the U/L warnings
> are a
> > few ms worth of IQ samples, nothing that critical happens.
>
> Consider setting uhd::set_thread_priority() on the main thread (where
> you call the usrp constructor). Then run the application as root or
> setup priority user permissions. That should reduce I/O call blocking
> by boosting the thread priority of the USB event handler internal to
> UHD.
>
> Also, if you are using 16-bit samples over-the-wire, try setting the
> streamers to 12-bits. If 12-bit samples perform worse, then there are
> CPU limitations - 12-bit (un)packing trades lower I/O for higher
> sample processing load.
>
> > Is there any way to configure UHD so that a better decoupling of TX and
> RX
> > chains is achieved? I'm assuming some buffer fills up, either in the host
> > machine or in the B210 FPGA, creating this unwanted coupling. Maybe
> tuning
> > some of the optional parameters in stream_args_t?
>
> USB is asynchronously driven by the host so Tx/Rx inherently have some
> overlap. Pure buffer blocking can be addressed by increasing libusb
> transport parameters. Buffer tuning gains are possible but I suspect
> preemption where the I/O itself stalls (due to the OS or application
> itself taking over) is the bigger issue.
>
> http://files.ettus.com/manual/page_transport.html#transport_usb_params
>
> > Another possibility I thought about... Maybe the RX slow down is due to
> the
> > async messages in charge of catching/dumping the TX warnings.
>
> Doesn't hurt, but probably won't help much either.
>
> -TT
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/7d169edb/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 30 Sep 2016 11:42:15 +0100
From: David Miller <[email protected]>
To: Paul David <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Cannot remove X310 image
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi Paul and usrp-users,
So, I used Vivado hardware manager to program the FPGA with 3.9.4
bitfile (I'm stuck with 3.9.4 for the moment) and confirmed with
uhd_usrp_probe that all appears OK.
I did not power cycle the X310.
But then trying to use uhd_image_loader with the 3.9.4 bitfile fails
with the same "Error: RunTimeError: Device reported an error during
initialization".
Maybe I should re-program the 3.8.2 image back first?
Any ideas?
Thanks,
Dave
On 20/09/2016 19:07, Paul David wrote:
> Hi David,
>
> To answer your question: you do need Vivado in order to configure the
> FPGA over JTAG using the command: viv_jtag_program <bitfile path> .
>
> Or you can use the hardware manager in Vivado. After you do that,
> you'll need to use uhd_image_loader to burn the same FPGA image so
> that it persists after a power cycle.
>
> I would recommend upgrading UHD to a more recent tagged release as well.
>
> -- Paul
>
> On Tue, Sep 20, 2016 at 9:08 AM, David Miller via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi,
>
> I have acquired an X310 with an image based on the original uhd
> 3.8.2 image, not sure what it does but doing a uhd_usrp_probe with
> uhd 3.8.2 it works as expected, however no samples are emitted
> with the utilities, it's hosed!
>
> Anyways, I have tried the 3.8.2 burn program
> (usrp_x3xx_fpga_burner) which fails, and currently tried the 3.9.4
> uhd_image_loader.
>
> uhd_image_loader fails (and similarly usrp_x3xx_fpga_burner) with:
>
> Error: RunTimeError: Device reported an error during initialization.
>
> I hacked the code in the x310_send_and_receive() function,
> somewhere in the code, to see if there is any kind of status
> message generated that might help, the recv function returns a len
> of 4 (0 being a timeout), which fails a subsequent check function
> that masks this len value (with 0x04, or whatever the def is) to
> determine that this is a failure. Sorry to be a bit vague, I don't
> have the setup in front of me at the moment.
>
> So, the real question is: How do I recover the unit and burn back
> a working image, is it now only possible using Vivado/ISE/JTAG?
>
> Hope you can help?
>
> Thanks,
> Dave
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/3fa50933/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 30 Sep 2016 16:24:23 +0200
From: Francesco Giannone <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] Error Using X310 ( NI USRP 2940 R)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi All,
I?m quite new of this field. I started to use USRP because I?m working with a
5G network simulator/emulator.
I have a NI USRP 2940 R in which I installed the Ettus X310 firmware. When I
run the code I get this error:
UHD Warning:
Unable to set the thread priority. Performance may be negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
Checking for USRPs : UHD 003.010.000.000-release (3.10.0)
Found USRP X300
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:184.32
terminate called after throwing an instance of 'uhd::assertion_error'
what(): AssertionError: block_def
in void uhd::usrp::device3_impl::enumerate_rfnoc_blocks(size_t, size_t,
size_t, const uhd::sid_t&, uhd::device_addr_t, uhd::endianness_t)
at /build/uhd-SfT4TV/uhd-3.10.0.0/host/lib/usrp/device3/device3_impl.cpp:148
Aborted (core dumped)
Any ideas?
Thanks a lot in advance!!
Best Regards.
Francesco.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/138a5bbc/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 30 Sep 2016 16:57:36 +0200
From: Nives Novkovi? <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Implementing design on FPGA in X310
Message-ID:
<calutkdd8xegwhkxwmfegxaoyz3zah+q0mzdsjdsklfrr_+t...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Martin,
thank you for the information. I am quite new at this and I'm still trying
to figure some stuff out so I am sorry if I repeat some questions. I just
want to be sure to get it right. Which .xdc files are relevant to me if I
want to implement a new FPGA design on an X310? As much as I figured the
constraints for E310 and X310 different, so I cannot use an .xdc file in
X310 which is meant for E310? Thank you for your patience and consideration.
Kind regards,
Nives
> Date: Wed, 28 Sep 2016 09:13:30 -0700
> From: Martin Braun <[email protected]>
> To: [email protected]
> Subject: Re: [USRP-users] Implementing design on FPGA in X310
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=UTF-8
> On 09/28/2016 05:56 AM, Nives Novkovi? via USRP-users wrote:
> Hi Sugandha,
>
> thank you for your reply. Now for the implementation I need the pin
> layout information written in .xdc file, as far as I've seen. But I
> cannot seem to find it for X310. I've searched on
> https://github.com/EttusResearch/fpga/tree/master/usrp3/top/ , but could
> find only information for the E300. Am I looking in the wrong place?
> For RFNoC, go to usrp3_rfnoc. For E310 RFNoC development, go to the
> rfnoc-devel branch.
> Cheers,
> Martin
>
> Kind regards,
> Nives
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/9589e72e/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 30 Sep 2016 10:32:05 -0500
From: Jonathon Pendlum <[email protected]>
To: Nives Novkovi? <[email protected]>
Cc: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Implementing design on FPGA in X310
Message-ID:
<cagdo0uthyc1feocznf8qmf7o_gfxjkuj7sc9kacedqvkvgf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Nives,
The xdc files in the directory usrp3/top/x300 are the constraint files you
will want to use in a X3x0 design (x300.xdc, x300_dram.xdc, etc...). You
absolutely cannot use a E310 constraints file (such as e300.xdc) in a X310
design or vice versa.
Jonathon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/3a3fa62f/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 30 Sep 2016 10:37:25 -0500
From: Jonathon Pendlum <[email protected]>
To: "Long, Jeffrey P." <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
Message-ID:
<cagdo0usavjqhh5ssbxmh3sm1uurak80cv0kgw_0p4htoqrx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jeff,
Another customer has reported this issue. I thought it might be an issue
with his setup, but now that you've ran into it as well I'll file a bug and
try to reproduce. Can you send me your rfnoc_ce_auto_inst_x310.v file?
Jonathon
On Wed, Sep 28, 2016 at 4:14 PM, Long, Jeffrey P. via USRP-users <
[email protected]> wrote:
> I just did a new build in the latest rfnoc-devel branch using the make.py
> and adding in a couple stock ce?s (null sink and siggen). The build
> completed but I just tried to burn it to my x310 and it told me the image
> was too large 15878034 vs 15878032
>
>
>
> I saw reference to this issue last March but I thought it would have been
> fixed by now.
>
>
>
> Did I do something wrong here?
>
>
>
> Thanks
>
> Jeff
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/3bf48a01/attachment-0001.html>
------------------------------
Message: 16
Date: Fri, 30 Sep 2016 17:40:26 +0200
From: Nives Novkovi? <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Implementing design on FPGA in X310
Message-ID:
<calutkddezpubh4sqykdmvxmmoroq7vmxudntqypsdti+7pv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jonathon,
Thank you for the quick reply. I thought so too, but I cannot find the
directory usrp3/top/x300. This is all I see
2016-09-30 17:32 GMT+02:00 Jonathon Pendlum <[email protected]>:
> Hi Nives,
>
> The xdc files in the directory usrp3/top/x300 are the constraint files you
> will want to use in a X3x0 design (x300.xdc, x300_dram.xdc, etc...). You
> absolutely cannot use a E310 constraints file (such as e300.xdc) in a X310
> design or vice versa.
>
>
>
> Jonathon
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/17f89de8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_17.png
Type: image/png
Size: 52898 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/17f89de8/attachment-0001.png>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 73, Issue 28
******************************************
