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. NI USRP 2940 R safe-mode button (francesco giannone)
2. Re: Implementing design on FPGA in X310 (Martin Braun)
3. Re: [Discuss-gnuradio] GNU flow graph containing a UHD block
- unable to detect USRP E310 (Derek Kozel)
4. schmidl-cox RFNoC examples (Jason Matusiak)
5. Re: schmidl-cox RFNoC examples (Jonathon Pendlum)
6. Re: schmidl-cox RFNoC examples (Jason Matusiak)
7. Re: schmidl-cox RFNoC examples (Marcus M?ller)
8. Re: RX chain slow down due to TX chain U/L warnings
(Dario Fertonani)
9. RFNOC x310 image 2 bytes too large (Long, Jeffrey P.)
10. DAC front-end sync failed (Rob Kossler)
11. Re: DAC front-end sync failed (Marcus D. Leech)
12. Re: DAC front-end sync failed (Rob Kossler)
13. RFNoC synchronous streaming (Frank Liu)
14. Re: DAC front-end sync failed (Michael West)
15. Re: RFNoC synchronous streaming (Frank Liu)
16. Re: NI USRP 2940 R safe-mode button (Marcus M?ller)
17. Re: About custom FPGA on X310 (Marcus M?ller)
18. Re: RX chain slow down due to TX chain U/L warnings (Tom Tsou)
19. underflow during transmission in usrp x310/2953R (Nikita Airee)
20. Re: schmidl-cox RFNoC examples (Jason Matusiak)
21. Long period, low-amplitude noise burst in receive during
active TDMA operation (B200mini) (Steven Knudsen)
----------------------------------------------------------------------
Message: 1
Date: Wed, 28 Sep 2016 13:36:28 +0200
From: francesco giannone <[email protected]>
To: [email protected]
Subject: [USRP-users] NI USRP 2940 R safe-mode button
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi All,
I have a NI USRP 2940 R which is unreachble via ethernet (1 Gb) after a
changing of a firmware.
For changing the firmware I used the following command:
uhd_image_loader --args="type=x300,addr=192.168.10.2"
--fpga-path="/usr/share/uhd/images/usrp_x310_fpga_XG.lvbitx"
The procedure seems like successfully completed:
-- Initializing FPGA loading...successful.
-- Loading HG FPGA image: 100% (121/121 sectors)
-- Finalizing image load...successful.
Power-cycle the USRP X310 to use the new image.
But after the power-cycle I cant able to ping the USRP and also the commands
uhd_find_devices and uhd_usrp_probe say "No UHD Devices Found". Therefore I was
thinking to put my NI USRP 2940 R in safe-mode.
In the "GETTING STARTED GUIDE NI USRP-2940R/2942R/2943R Universal Software
Radio Peripheral" (http://www.ni.com/pdf/manuals/375717f.pdf
<http://www.ni.com/pdf/manuals/375717f.pdf>) in the section "Why Doesn't the
Device IP Address Reset to the Default?", I found the procedure that says to
locate the push-button switch (S2).
The problem is that unlike NI USRP 2920 in which the S2 button is easily to
reach, I have not been able to find the safe-mode button inside the NI USRP
2940 R. I found only SW1 and SW3 buttons.
Has anyone idea on what are the buttons SW1 and SW3? Or better, how to reset
the NI USRP 2940 R?
Thanks a lot for your attention.
Best Regards.
Francesco.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160928/5cbb2f2b/attachment-0001.html>
------------------------------
Message: 2
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
>
> 2016-09-23 18:59 GMT+02:00 Sugandha Gupta <[email protected]
> <mailto:[email protected]>>:
>
> Hello Nives
>
> You can use RFNoC to add your own functionality to the existing
> code. Checkout the knowledge base article on it.
>
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
> <https://kb.ettus.com/Getting_Started_with_RFNoC_Development>
>
> Let me know if you have any questions. Will be happy to help you.
>
> Thanks
> Sugandha
>
>
>
> On Fri, Sep 23, 2016 at 1:57 AM, Nives Novkovi? via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hello again,
>
> I was wondering about implementing new functionalities on the
> FPGA in X310. If I would like the FPGA to maintain its current
> funcionality and I want to add something new but without erasing
> the pre-existing one, how do I do that? Thank you in advance.
>
> Kind regards,
> Nives
>
> _______________________________________________
> 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>
>
>
>
>
> --
> Sugandha Gupta
> Staff Software Engineer
> Ettus Research
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Wed, 28 Sep 2016 09:52:56 -0700
From: Derek Kozel <[email protected]>
To: John Smith <[email protected]>
Cc: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] GNU flow graph containing
a UHD block - unable to detect USRP E310
Message-ID:
<CAA+K=tsvwbtghfv+z0wgrzxsbdx14fjjstbwddcx7qifqnp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello John,
The E310 is designed to have GNU Radio run onboard the radio rather than on
an external computer. By default the USRP driver does not include support
for using the E310 remotely across a network. This is because network mode
was implemented primarily as a debugging aid. The sample rate which it is
possible to stream across the network is very low.
If you do want to stream samples across the network you will need to
compile UHD with custom settings. Also please note that the version of UHD
on the host computer must exactly match the version on the E310. You can
find out this version by connecting to the E310 using SSH or the USB serial
console and running a uhd command, which will print the UHD version.
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode
Regards,
Derek
On Wed, Sep 28, 2016 at 2:53 AM, John Smith <[email protected]> wrote:
> I have an E310 device connected over an Ethernet link to a laptop running
> GNU Radio.
>
> When I attempted to execute a GNU flow graph containing a UHD block, I got
> the following error:
>
> RuntimeError: LookupError: KeyError: No devices found for -----> Empty
> Device Address
>
> I have entered the device IP address in the UHD block.
>
> I can ping the E310.
>
> Any help much appreciated.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160928/bec8ba1c/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 28 Sep 2016 13:43:15 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] schmidl-cox RFNoC examples
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
I was digging around in a couple of the repos looking in a couple of
different branches and couldn't find an example that utilized the OFDM
Sync block (schmidl-cox). Are there any floating around?
------------------------------
Message: 5
Date: Wed, 28 Sep 2016 13:08:40 -0500
From: Jonathon Pendlum <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] schmidl-cox RFNoC examples
Message-ID:
<cagdo0urx3ebvhpgx+nhmxzfvzdagsh7e0nee-7hgr868fsu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Jason,
The rfnoc ofdm branch has some examples. It needs to be merged into
rfnoc-devel though and I plan on getting to that pretty soon.
Jonathon
On Wed, Sep 28, 2016 at 12:43 PM, Jason Matusiak via USRP-users <
[email protected]> wrote:
> I was digging around in a couple of the repos looking in a couple of
> different branches and couldn't find an example that utilized the OFDM Sync
> block (schmidl-cox). Are there any floating around?
>
>
> _______________________________________________
> 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/20160928/0b71b074/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 28 Sep 2016 15:30:08 -0400
From: Jason Matusiak <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] schmidl-cox RFNoC examples
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Jonathon, I looked through EttusResearch/fpga UHD repo in the rfnoc-ofdm
branch, but I don't see any GRC files in there.
On 09/28/2016 02:08 PM, Jonathon Pendlum wrote:
> Hey Jason,
>
> The rfnoc ofdm branch has some examples. It needs to be merged into
> rfnoc-devel though and I plan on getting to that pretty soon.
>
>
>
> Jonathon
>
> On Wed, Sep 28, 2016 at 12:43 PM, Jason Matusiak via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> I was digging around in a couple of the repos looking in a couple
> of different branches and couldn't find an example that utilized
> the OFDM Sync block (schmidl-cox). Are there any floating around?
>
>
> _______________________________________________
> 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/20160928/bdc10030/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 28 Sep 2016 12:35:02 -0700
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] schmidl-cox RFNoC examples
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
GRC files can't be part of the FPGA source code; the interface between
GNU Radio and RFNoC is, as you know, gr-ettus, and hence, you'll find
the GRC files in gr-ettus/grc.
Best regards,
Marcus
On 09/28/2016 12:30 PM, Jason Matusiak via USRP-users wrote:
>
> Jonathon, I looked through EttusResearch/fpga UHD repo in the
> rfnoc-ofdm branch, but I don't see any GRC files in there.
>
> On 09/28/2016 02:08 PM, Jonathon Pendlum wrote:
>> Hey Jason,
>>
>> The rfnoc ofdm branch has some examples. It needs to be merged into
>> rfnoc-devel though and I plan on getting to that pretty soon.
>>
>>
>>
>> Jonathon
>>
>> On Wed, Sep 28, 2016 at 12:43 PM, Jason Matusiak via USRP-users
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> I was digging around in a couple of the repos looking in a couple
>> of different branches and couldn't find an example that utilized
>> the OFDM Sync block (schmidl-cox). Are there any floating around?
>>
>>
>> _______________________________________________
>> 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]
> 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/20160928/72d0c958/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 28 Sep 2016 13:41:42 -0700
From: Dario Fertonani <[email protected]>
To: usrp-users <[email protected]>
Subject: Re: [USRP-users] RX chain slow down due to TX chain U/L
warnings
Message-ID:
<CAJGEdAi1oSvunFegZFB=ceccacrz-oqpbnkd2cbc018kepg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Any other ideas?
If not, how can I disable the message handler? I know how to redirect the
messages, but I don't know how to actually prevent message collection. I'd
find it surprising if that was the slow down cause (as opposed to some
buffer filling up), but I'd like to give it a try.
Thanks,
Dario
On Sun, Sep 25, 2016 at 6:43 AM, Tilla via USRP-users <
[email protected]> wrote:
> You could also try to disable the message handler if you don?t need it, it
> is synchronous and sloooowwwww?
>
>
>
> *From:* USRP-users [mailto:[email protected]] *On Behalf
> Of *Dario Fertonani via USRP-users
> *Sent:* Saturday, September 24, 2016 2:33 PM
> *To:* [email protected]
> *Subject:* [USRP-users] RX chain slow down due to TX chain U/L warnings
>
>
>
> 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.
>
>
>
> 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?
>
>
>
> Another possibility I thought about... Maybe the RX slow down is due to
> the async messages in charge of catching/dumping the TX warnings.
>
>
>
> Thanks,
>
> Dario
>
> _______________________________________________
> 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/20160928/d73a1a0d/attachment-0001.html>
------------------------------
Message: 9
Date: Wed, 28 Sep 2016 21:14:19 +0000
From: "Long, Jeffrey P." <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RFNOC x310 image 2 bytes too large
Message-ID:
<dm5pr09mb13724bcbe9e9c7a246214db0d9...@dm5pr09mb1372.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160928/d934bf0c/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 28 Sep 2016 17:27:57 -0400
From: Rob Kossler <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] DAC front-end sync failed
Message-ID:
<CAB__hTQq46DA3Zxvk3rd+K9MdCMz-s+0OftQ1TjpdT=qc6_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160928/d92e717e/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 28 Sep 2016 17:32:49 -0400
From: "Marcus D. Leech" <[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; format=flowed
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?
------------------------------
Message: 12
Date: Wed, 28 Sep 2016 18:13:27 -0400
From: Rob Kossler <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] DAC front-end sync failed
Message-ID:
<cab__hts7u7dfipropcqatsxfb0j3hz+fo6okxsnwed+zcuw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160928/cc044b9f/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 28 Sep 2016 16:43:15 -0700
From: Frank Liu <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RFNoC synchronous streaming
Message-ID:
<camzy46zpfsy96kne7jojkhc6ge3ak0m435jkkcqvcuu2d3k...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160928/1b943bfb/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 28 Sep 2016 19:46:27 -0700
From: Michael West <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] DAC front-end sync failed
Message-ID:
<CAM4xKrqWvNuW+VaCRAaY6D2QR0zEqBZukZ6zoJjzKzyGoH=5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Rob,
I have seen this in my testing as well. I have filed an issue against UHD
to have it investigated.
Regards,
Michael
On Wed, Sep 28, 2016 at 3:13 PM, Rob Kossler via USRP-users <
[email protected]> 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 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/20160928/305caaaa/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 28 Sep 2016 22:07:21 -0700
From: Frank Liu <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC synchronous streaming
Message-ID:
<CAMZy46aDivSzf0retFpCK0zBQT=le6vkampctdpb6w6wmpc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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]> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160928/07e42862/attachment-0001.html>
------------------------------
Message: 16
Date: Wed, 28 Sep 2016 22:31:08 -0700
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] NI USRP 2940 R safe-mode button
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Francesco,
you're right, the X3x0 (NI-USRP 294x and 295x) don't have a safe boot
mode. Hence, there's also no such buttons.
First of all, make sure that your IP address hasn't changed when you
power cycled; under some circumstances (amount of black cats, phase of
moon, mood of NetworkManager), the program in charge of managing the
network configuration just picks a new address when it senses a loss of
connectivity, and then you might not be able to ping your USRP any more,
even though it works correctly.
If, in fact, the flashing failed for some reason (or, and this might be
the case here, you wrote an incorrect image file), your only option is
to load a working image through the USB/JTAG connector. That sounds more
complex than it is: The FPGA tools that Ettus came up with contain
scripts to load images without much ado. The simplest way I've found:
1. make sure you've got the fpga source code. If you already have the
UHD host code, a simple "git submodule update --init" will get that.
Otherwise, clone https://github.com/EttusResearch/fpga;
2. get and install a free version of Xilinx Vivado 2015.4, find the
cable driver installer (typically,
/opt/Xilinx/Vivado/2015.4/data/xicom/cable_drivers/lin64/install_script/install_drivers/install_drivers),
run it with sudo (sudo ./install_drivers), then connect your USRP with USB.
3. let the scripts set up the paths etc, by "cd
fpga/usrp3_rfnoc/top/x300; source setupenv.sh". From the same shell, run
"viv_jtag_program //usr/share/uhd/images/usrp_x310_fpga_XG.bit" /(note
the file suffix)
Best regards,
Marcus
On 09/28/2016 04:36 AM, francesco giannone via USRP-users wrote:
> Hi All,
> I have a NI USRP 2940 R which is unreachble via ethernet (1 Gb) after
> a changing of a firmware.
>
>
>
> For changing the firmware I used the following command:
> /uhd_image_loader --args="type=x300,addr=192.168.10.2"
> --fpga-path="/usr/share/uhd/images/usrp_x310_fpga_XG.lvbitx"/
>
>
>
> The procedure seems like successfully completed:
> /-- Initializing FPGA loading...successful./
> /-- Loading HG FPGA image: 100% (121/121 sectors)/
> /-- Finalizing image load...successful./
> /Power-cycle the USRP X310 to use the new image./
>
>
>
> But after the power-cycle I cant able to ping the USRP and also the
> commands uhd_find_devices and uhd_usrp_probe say "No UHD Devices
> Found". Therefore I was thinking to put my NI USRP 2940 R in safe-mode.
>
>
>
> In the "GETTING STARTED GUIDE NI USRP-2940R/2942R/2943R Universal
> Software Radio Peripheral" (http://www.ni.com/pdf/manuals/375717f.pdf)
> in the section "Why Doesn't the Device IP Address Reset to the
> Default?", I found the procedure that says to locate the push-button
> switch (S2).
>
>
>
> The problem is that unlike NI USRP 2920 in which the S2 button is
> easily to reach, I have not been able to find the safe-mode button
> inside the NI USRP 2940 R. I found only SW1 and SW3 buttons.
>
>
>
> Has anyone idea on what are the buttons SW1 and SW3? Or better, how to
> reset the NI USRP 2940 R?
>
>
>
> Thanks a lot for your attention.
>
>
>
> Best Regards.
>
>
>
> Francesco.
>
>
> _______________________________________________
> 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/20160928/4d0cbf27/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 28 Sep 2016 22:43:43 -0700
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] About custom FPGA on X310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi,
see my answers in-text below:
On 09/27/2016 08:47 PM, liu Jong via USRP-users wrote:
> Dear all,
> We bought 2 X310,and we plan to develop rfnoc on x310.We saw the
>
> * RFNoC - Getting Started
> <https://github.com/EttusResearch/uhd/wiki/RFNoC%3A-Getting-Started>
> * RFNoC - Specification
> <https://github.com/EttusResearch/uhd/wiki/RFNoC%3A--Specification>
>
> but we still have some questions:
> 1. How to reflect online data format (OTW) in the implementation of
> the FPGA module?
The "default" sample format for NoC blocks is S(C)16. It's pretty safe
to assume you want to use that.
> Which module of FPGA or host is responsible for the data format
> conversion from otw to CPU?
That's transparently done by the host side's converters
> What are the effects of different OTW formats for the implementation
> of FPGA CE?
Well, different implementations? A 16 bit number needs different
handling than 8 bit numbers.
> We now want to implement our own FPGA CE, then how to specify the
> OTW format supported by the custom module?
You specify that in the block describing XML files, so that the host knows.
> 2.When you call the C++ library function to send or receive data, you
> need to use method of issue_stream_cmd () , then which FPGA module
> this method will eventually be applied to?
That's a very complex question, but in essence, you'll deal with the
host streamer and the crossbar, and with the command ports within
affected NoC blocks.
> Is that OK if we use default control class instead of developing a
> new control one?
Usually, yes!
> In what case can we use default class, and in what case must we
> implement our own control class?
If your block behaves in a way that it has an input and an output with a
fixed packet size, you're usually fine using the default class.
> For example, the CE we developed is similar to null_source module,
> it generates data cyclically, and these data will be received by the host.
> Is there any difference to other normal module(i.e. FIFO) when we
> write xml files?
no, not that I can see so far. But of course, I don't know how your
block works, or how the cyclical activation works ? that's basically a
bit of an unsolved problem, because as long as no one's talking to your
NoC block, there's nothing to "activate" that NoC block. You could
currently use workarounds such as "manually" routing the radio clock
into the block, and triggering on that.
> Does host need control class? Or we only need to use the basic
> class of block_ctrl_base?
You shouldn't worry about that too much. Get started using the
rfnoc_modtool, and you'll end up with a working host side C++
infrastructure.
> Is it necessary to specifically implement the method
> issue_stream_cmd()?
that is basically impossible, as far as I can tell. Or at least,
architecturally very complex.
> Are there any other aspects that we need to be noticed?
> 3.Questions about sampling rate of the module Radio.
> We use the latest rfnoc branch,logic and software code, and when we
> use the following code:
> pt_custom_usrp = uhd::usrp::multi_usrp::make(device_addrs[0]);
> pt_custom_usrp->set_tx_rate(rate);
Notice that you need a device3 somewhere here
> We encountered the following print when configuring tx_rate:
> Setting TX Rate: 10.000000 Msps...
> UHD Warning:
> The hardware does not support the requested TX sample rate:
> Target sample rate: 10.000000 MSps
> Actual sample rate: 200.000000 MSps
> UHD Warning:
> The hardware does not support the requested TX sample rate:
> Target sample rate: 10.000000 MSps
> Actual sample rate: 200.000000 MSps
>
> We want to know the reason. And how can we use API library
> function to achieve our goals?
Did you perhaps remove the DUC/DDC? The radio block itself has a fixed
rate...
>
> 4.Baseband IQ data interface and radio connection.
> We have implemented the CE module to generate the modulated IQ
> data, and we need to connect it to the radio, can it be directly
> connected?
well, yes, that is the idea of RFNoC.
> Does the baseband need to follow a certain data format when the
> IQdata is sent to the radio, for example, I0Q0I1Q1?
Yes, of course, the format is fixed. The radio takes the Ettus-typical
SC16 in IQIQIQIQ... format.
>
> 5.Rationality of module connection mode.
> As shown below, it is directly connected through internal FPGA
> pins from CE A to CE B.
That is a breach of RFNoC ideologies. CEs should only communicate
through the crossbar, otherwise you get interesting causality problems.
If that is impossible, your two CEs probably should be a single one.
> A has two outputs,one is hanging on the Xbar and the other is
> directly connected to the input of CE B.
> Similarly, CE B also has two ouputs, one is hanging on the Xbar and
> the other is directly connected to the output of CE A.
> The implementation of CE B function is similar to null source
> module.In the host side, we connect CE A to Radio through
> the method 'connect'. tx_streamer connects module CE A, while
> rx_streamer connects module CE B.
> Is this connection mode feasible in the framework of rfnoc?
No, because it implies that the backpressure-capable AXI crossbar
competes with your direct A->B connection, as far as I understand.
> If not, is there any problem the connection mode will lead to?
> Any more, what is your suggestion for the implementaion of this
> toplogy?
I don't know what your application's purpose is, so this is a tiny bit
hard to answer!
Best regards,
Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160928/b9efb675/attachment-0001.html>
------------------------------
Message: 18
Date: Thu, 29 Sep 2016 00:19:40 -0700
From: Tom Tsou <[email protected]>
To: Dario Fertonani <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RX chain slow down due to TX chain U/L
warnings
Message-ID:
<CAGNiu+cXJ4bZKsPd9rM8QOgfbipch=1p--quqt9zombwu4c...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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
------------------------------
Message: 19
Date: Thu, 29 Sep 2016 13:45:26 +0530
From: Nikita Airee <[email protected]>
To: [email protected]
Subject: [USRP-users] underflow during transmission in usrp x310/2953R
Message-ID:
<CAOT=STn1Lu2XTXggufcofk4_Rv+idN_5x+cLMHLF57_7Bc8B=q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/06dc018a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeze.png
Type: image/png
Size: 234058 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/06dc018a/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sudo lspci.png
Type: image/png
Size: 271716 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/06dc018a/attachment-0003.png>
------------------------------
Message: 20
Date: Thu, 29 Sep 2016 09:35:34 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>, Marcus
M?ller <[email protected]>
Subject: Re: [USRP-users] schmidl-cox RFNoC examples
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
> GRC files can't be part of the FPGA source code; the interface between
> GNU Radio and RFNoC is, as you know, gr-ettus, and hence, you'll find
> the GRC files in gr-ettus/grc.
I looked at the jarnold/schmidl-cox branch's examples/rfnoc folder and
there didn't appear to be any examples in there, so that is why I
started branching outward looking other places. I am not sure if they
maybe got dropped at some point.
------------------------------
Message: 21
Date: Thu, 29 Sep 2016 09:34:09 -0600
From: Steven Knudsen <[email protected]>
To: USRP-users <[email protected]>
Cc: Knud <[email protected]>
Subject: [USRP-users] Long period, low-amplitude noise burst in
receive during active TDMA operation (B200mini)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi All,
I have built a TDMA system that uses the B200mini. In doing a simple test to
look at processing load for transceiver operation (B200mini transmits when it
is told, otherwise is receiving), I noticed an interesting effect.
When the transmit and receive carrier frequencies are the same (below, 100
MHz), every 5 seconds or so (but periodic) a slow-amplitude burst signal
appears on the receive channel. The is no active transmission for that channel.
Indeed, when contigured with transmit on TRX and receive on RX2, there isn?t
even an antenna on the RX2.
I first noticed the ?noise? on a time sink, but the waterfall makes it easy to
see the periodicity.
Packets are transmitted at 100 packets/second and are ~1300 us in duration
(fixed).
I include some images below for consideration. The ?Packets? display is the
transmitted signal. The received noise burst amplitude is proportional to the
transmit gain, and it quite low, but not insignificant.
Anyone seen this?
To anticipate one question, no, I have not used a different B200mini to see if
it?s hardware, but the fact that I don?t see it at 900 MHz receive makes me
think it is not.
Figure 1 B200mini Tx and Rx using TRX port only, fTX = fRX = 100 MHz
Figure 2 B200mini Tx using TRX port, Rx using Rx2 port, fTX = fRX = 100 MHz
Figure 3 B200mini Tx using TRX port, Rx using Rx2 port, fTX = 100 MHz fRX = 900
MHz
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca <http://techconficio.ca/>
www.linkedin.com/in/knudstevenknudsen
<http://www.linkedin.com/in/knudstevenknudsen>
So fest wie die Hand den Stein h?lt. Sie h?lt ihn aber fest, nur um ihn desto
weiter zu verwerfen. Aber auch in jene Weite f?hrt der Weg. - Franz Kafka
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca <http://techconficio.ca/>
www.linkedin.com/in/knudstevenknudsen
<http://www.linkedin.com/in/knudstevenknudsen>
Du bist die Aufgabe. Kein Sch?ler weit und breit. - Franz Kafka
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/0a9e634e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TRX simultaneous.jpg
Type: image/jpeg
Size: 64515 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/0a9e634e/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TRX Tx100MHz RX2Rx100MHz.jpg
Type: image/jpeg
Size: 61553 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/0a9e634e/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TRX simultaneous Tx100MHzRx900MHz.jpg
Type: image/jpeg
Size: 62521 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160929/0a9e634e/attachment-0005.jpg>
------------------------------
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 27
******************************************
