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. E310 DRAM Question (Rigney, Kevin E)
2. Store and Replay N2x0 (Dave NotTelling)
3. Re: E310 DRAM Question (Leandro Echevarr?a)
4. Does send block the thread? (Jacob Knoles)
5. usrp x310 full duplex: receiving flowgraph can cause
underflow problem at transmitter side (Yang Liu)
6. Time it takes to call get_time_now() (Dave NotTelling)
7. Re: usrp x310 full duplex: receiving flowgraph can cause
underflow problem at transmitter side (Marcus D. Leech)
8. Re: Does send block the thread? (Dave NotTelling)
9. Re: usrp x310 full duplex: receiving flowgraph can cause
underflow problem at transmitter side (Yang Liu)
10. Re: usrp x310 full duplex: receiving flowgraph can cause
underflow problem at transmitter side (Marcus D. Leech)
11. Re: usrp x310 full duplex: receiving flowgraph can cause
underflow problem at transmitter side (Yang Liu)
12. Re: Does send block the thread? (Jacob Knoles)
13. Help required in Setting up USRP N200 (Rizwan Akram)
14. Any EMI Information For the E310? Thanks
(Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC])
15. Re: Two RFNoC FFT blocks on X310? (Raj Bhattacharjea)
16. Re: Two RFNoC FFT blocks on X310? (Jonathon Pendlum)
17. Re: Does send block the thread? (Martin Braun)
18. Re: Store and Replay N2x0 (Martin Braun)
19. Re: E310 gnuradio not showing RFNoC blocks (Martin Braun)
20. Re: Does send block the thread? (Jacob Knoles)
21. Re: Store and Replay N2x0 (Dave NotTelling)
22. Re: Any EMI Information For the E310? Thanks (Marcus M?ller)
23. Re: Any EMI Information For the E310? Thanks (Neel Pandeya)
----------------------------------------------------------------------
Message: 1
Date: Fri, 23 Jun 2017 16:15:59 +0000
From: "Rigney, Kevin E" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] E310 DRAM Question
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello,
I'm working on a design that uses the E310 DRAM connected to the PL. There
appears to be a discrepancy in the clocking scheme and power of the DRAM.
If I look up the power of the DRAM part on Micron's website
(https://www.micron.com/parts/dram/ddr3-sdram/mt41k256m16ha-125-it) it says it
runs at 1.35V. But the MIG is set to 1.5V.
Also the MIG says the two clocks are 400MHz and 100MHz. But following the
design it appears that the two clocks are 200MHz and 50MHz.
Can someone help me resolve these discrepancies?
Thanks,
-Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/c1707487/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 23 Jun 2017 12:22:56 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Store and Replay N2x0
Message-ID:
<CAK6GVuMQ=s-pgka-ys2mjfpvfasnn4b7zgvoafrqybtzo9_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Is there any way to send the N2x0 a complex waveform and have it transmit
the waveform at multiple different times without needing to send the
waveform again?
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/2a11ebfb/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 23 Jun 2017 16:28:17 +0000
From: Leandro Echevarr?a <[email protected]>
To: "Rigney, Kevin E" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 DRAM Question
Message-ID:
<caleoa2jpybnsr+md6qaqkmh4bhu3geg7ofmi8t7s45kbdc3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Rigney,
The L in DDR3L RAM stands for "Low Voltage". This means it CAN run on
1.35V, but it also supports the standard DDR3 voltage of 1.5V (I would risk
to say that by doing so it could achieve lower latencies, but I'm not
really sure).
As to the clock speeds, I'm not sure. Maybe it has to do with the fact that
DDR transmits data both on raising and falling edges of the clock signals?
Sometimes manufacturers use MHz incorrectly, when they actually mean MT/s
(Mega Transfers per second).
Hope it helps,
Leo.
On Fri, Jun 23, 2017 at 1:17 PM Rigney, Kevin E via USRP-users <
[email protected]> wrote:
> Hello,
>
>
>
> I?m working on a design that uses the E310 DRAM connected to the PL. There
> appears to be a discrepancy in the clocking scheme and power of the DRAM.
>
>
>
> If I look up the power of the DRAM part on Micron?s website (
> https://www.micron.com/parts/dram/ddr3-sdram/mt41k256m16ha-125-it) it
> says it runs at 1.35V. But the MIG is set to 1.5V.
>
>
>
> Also the MIG says the two clocks are 400MHz and 100MHz. But following the
> design it appears that the two clocks are 200MHz and 50MHz.
>
>
>
> Can someone help me resolve these discrepancies?
>
>
>
> Thanks,
>
>
>
> -Kevin
>
>
> _______________________________________________
> 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/20170623/22caa356/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 23 Jun 2017 10:17:44 -0700
From: Jacob Knoles <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Does send block the thread?
Message-ID:
<ca+z4yffhysni77nzhihfjxpn+reid-61zkdjvzbphs0otbu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The UHD API and several examples indicate that tx_stream->send(...) will
block the thread until the samples have been sent, and if the metadata
provided has a time_spec then it will block until that time has come. I am
not seeing this behavior at all, in fact if I do not manually block the
thread it will fly through all the send commands and bursts I need to send,
end the function, thus closing the stream, and I get no output at all...?
What is going on here?
How can I send multiple bursts that are time specific?
Please help.
-----------------------------
Jacob Knoles
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/7f52e00f/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 23 Jun 2017 13:36:53 -0400
From: Yang Liu <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] usrp x310 full duplex: receiving flowgraph can
cause underflow problem at transmitter side
Message-ID:
<cad4vfme3q7jkymq_yvgw5pdzxjw_mcvtiuvok-33ccttqkz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
we are using one usrp x310 with two UBX 160 in a full duplex mode (one ubx
for transmitting and the second one for receiving, with a 10G connection).
In the code, two separate TX and RX flowgraphs are established. However, in
the actual test, we found that once RX flowgraph is busy at processing
data, the transmitter will suffer from severe underflow problem while
sending packets. Sample rate is just 5Msps, using TX flowgraph alone will
not have underflow and RX flowgraph alone no overflow either under the same
sample rate.
Since these two flowgraphs are separate, and that gnuradio will assign one
thread to one block, it seems to me that processing data should not have
impact at transmitting (independent). I am wondering how could this happen.
I tried to use gr::hier_blocks::set_processor_affinity to separate core
resources also, but it didn't work.
Any explanations to this observation and any advice about how to tackle
this will be greatly appreciated!
Thanks,
Yang
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/ae8d8d0a/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 23 Jun 2017 13:56:00 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Time it takes to call get_time_now()
Message-ID:
<cak6gvumm7o_nyin97re9ggu5ybwq+fmpjsitqehbh0l0f5a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I noticed during some testing that the N210 takes almost exactly 3 times as
long to call get_time_now() as an X310. Why is that, and can it be tuned
on the N210? I get that the X310 is a more powerful board as a whole.
It's just strange that the difference is almost exactly 3x.
Took 49.00670971163s to ask the X310 for time 1000000 times. Averaged
0.00004900671s/iter
Took 147.02336484520s to ask the N210 for time 1000000 times. Averaged
0.00014702336s/iter
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/d8cbf5df/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 23 Jun 2017 14:02:41 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] usrp x310 full duplex: receiving flowgraph
can cause underflow problem at transmitter side
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 06/23/2017 01:36 PM, Yang Liu via USRP-users wrote:
> Dear all,
>
> we are using one usrp x310 with two UBX 160 in a full duplex mode (one
> ubx for transmitting and the second one for receiving, with a 10G
> connection). In the code, two separate TX and RX flowgraphs are
> established. However, in the actual test, we found that once RX
> flowgraph is busy at processing data, the transmitter will suffer from
> severe underflow problem while sending packets. Sample rate is just
> 5Msps, using TX flowgraph alone will not have underflow and RX
> flowgraph alone no overflow either under the same sample rate.
>
> Since these two flowgraphs are separate, and that gnuradio will assign
> one thread to one block, it seems to me that processing data should
> not have impact at transmitting (independent). I am wondering how
> could this happen. I tried to use
> gr::hier_blocks::set_processor_affinity to separate core resources
> also, but it didn't work.
>
> Any explanations to this observation and any advice about how to
> tackle this will be greatly appreciated!
>
> Thanks,
> Yang
When you say "two flow-graphs" do you mean two separate processes?
Only a single process can "own" the network USRP interface at a time.
------------------------------
Message: 8
Date: Fri, 23 Jun 2017 14:03:38 -0400
From: Dave NotTelling <[email protected]>
To: Jacob Knoles <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Does send block the thread?
Message-ID:
<CAK6GVuMSEO0r6M-bdQTTmAhKd=ahzkkrc9t04xdfthhnuya...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I think that the send() command will block until the data is transmitted
*or* until all of the data can be copied over to RAM on the radio. Check
out
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-November/022482.html
.
On Fri, Jun 23, 2017 at 1:17 PM, Jacob Knoles via USRP-users <
[email protected]> wrote:
> The UHD API and several examples indicate that tx_stream->send(...) will
> block the thread until the samples have been sent, and if the metadata
> provided has a time_spec then it will block until that time has come. I am
> not seeing this behavior at all, in fact if I do not manually block the
> thread it will fly through all the send commands and bursts I need to send,
> end the function, thus closing the stream, and I get no output at all...?
>
> What is going on here?
>
> How can I send multiple bursts that are time specific?
>
> Please help.
>
> -----------------------------
> Jacob Knoles
>
>
> _______________________________________________
> 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/20170623/ff1e8da7/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 23 Jun 2017 14:15:48 -0400
From: Yang Liu <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] usrp x310 full duplex: receiving flowgraph
can cause underflow problem at transmitter side
Message-ID:
<cad4vfmeo9vafhxn5gxkcvsfrmuv1gmlq5o3ojo7nsuepeeq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus,
Thanks for the quick reply.
In my code transmitting flowgraph and receiving flowgraph are under a
single process, but under two separate connections. Let me put my code in
the below:
top_block:
self.txpath = tx_hier(...) self.rxpath = rx_hier(...)
self.source = uhd_receiver(...) # set up usrp, subdev: A:0
self.sink = uhd_transmitter(...) # set up usrp, subdev B:0
self.connect(self.source, self.rxpath)
self.connect(self.txpath, self.sink)
Hope this helps.
Thanks,
Yang
On Fri, Jun 23, 2017 at 2:02 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 06/23/2017 01:36 PM, Yang Liu via USRP-users wrote:
>
>> Dear all,
>>
>> we are using one usrp x310 with two UBX 160 in a full duplex mode (one
>> ubx for transmitting and the second one for receiving, with a 10G
>> connection). In the code, two separate TX and RX flowgraphs are
>> established. However, in the actual test, we found that once RX flowgraph
>> is busy at processing data, the transmitter will suffer from severe
>> underflow problem while sending packets. Sample rate is just 5Msps, using
>> TX flowgraph alone will not have underflow and RX flowgraph alone no
>> overflow either under the same sample rate.
>>
>> Since these two flowgraphs are separate, and that gnuradio will assign
>> one thread to one block, it seems to me that processing data should not
>> have impact at transmitting (independent). I am wondering how could this
>> happen. I tried to use gr::hier_blocks::set_processor_affinity to
>> separate core resources also, but it didn't work.
>>
>> Any explanations to this observation and any advice about how to tackle
>> this will be greatly appreciated!
>>
>> Thanks,
>> Yang
>>
> When you say "two flow-graphs" do you mean two separate processes?
>
> Only a single process can "own" the network USRP interface at a time.
>
>
>
>
>
>
>
> _______________________________________________
> 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/20170623/93aaa349/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 23 Jun 2017 14:19:18 -0400
From: "Marcus D. Leech" <[email protected]>
To: Yang Liu <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] usrp x310 full duplex: receiving flowgraph
can cause underflow problem at transmitter side
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 06/23/2017 02:15 PM, Yang Liu wrote:
> Hi Marcus,
>
> Thanks for the quick reply.
>
> In my code transmitting flowgraph and receiving flowgraph are under a
> single process, but under two separate connections. Let me put my
> code in the below:
>
> top_block:
>
> self.txpath = tx_hier(...)
> self.rxpath = rx_hier(...)
> self.source = uhd_receiver(...) # set up usrp, subdev: A:0
> self.sink = uhd_transmitter(...) # set up usrp, subdev B:0
> self.connect(self.source, self.rxpath)
> self.connect(self.txpath, self.sink)
>
> Hope this helps.
>
> Thanks,
> Yang
>
> On Fri, Jun 23, 2017 at 2:02 PM, Marcus D. Leech via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 06/23/2017 01:36 PM, Yang Liu via USRP-users wrote:
>
> Dear all,
>
> we are using one usrp x310 with two UBX 160 in a full duplex
> mode (one ubx for transmitting and the second one for
> receiving, with a 10G connection). In the code, two separate
> TX and RX flowgraphs are established. However, in the actual
> test, we found that once RX flowgraph is busy at processing
> data, the transmitter will suffer from severe underflow
> problem while sending packets. Sample rate is just 5Msps,
> using TX flowgraph alone will not have underflow and RX
> flowgraph alone no overflow either under the same sample rate.
>
> Since these two flowgraphs are separate, and that gnuradio
> will assign one thread to one block, it seems to me that
> processing data should not have impact at transmitting
> (independent). I am wondering how could this happen. I tried
> to use gr::hier_blocks::set_processor_affinity to separate
> core resources also, but it didn't work.
>
> Any explanations to this observation and any advice about how
> to tackle this will be greatly appreciated!
>
> Thanks,
> Yang
>
> When you say "two flow-graphs" do you mean two separate processes?
>
> Only a single process can "own" the network USRP interface at a time.
>
OK, so you're going to have to find the "hot spots" in your code to see
about optimizing them. Gnu Radio puts each block in a separate thread,
but that's no guarantee that they can all get the CPU they need, when
they need it.
That discussion (optimizing GR flow-graphs) should probably be held on
the discuss-gnuradio mailing list, rather than here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/8db11946/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 23 Jun 2017 14:33:57 -0400
From: Yang Liu <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] usrp x310 full duplex: receiving flowgraph
can cause underflow problem at transmitter side
Message-ID:
<CAD4vFMEp0r6YfXZyQF9=MR2OD-665rTBeego41o=is8bqrh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Marcus,
I just transferred my email to discuss-gnuradio mailing list.
Yang
On Fri, Jun 23, 2017 at 2:19 PM, Marcus D. Leech <[email protected]> wrote:
> On 06/23/2017 02:15 PM, Yang Liu wrote:
>
> Hi Marcus,
>
> Thanks for the quick reply.
>
> In my code transmitting flowgraph and receiving flowgraph are under a
> single process, but under two separate connections. Let me put my code in
> the below:
>
> top_block:
>
> self.txpath = tx_hier(...) self.rxpath = rx_hier(...)
>
> self.source = uhd_receiver(...) # set up usrp, subdev: A:0
> self.sink = uhd_transmitter(...) # set up usrp, subdev B:0
>
> self.connect(self.source, self.rxpath)
> self.connect(self.txpath, self.sink)
>
> Hope this helps.
>
>
> Thanks,
> Yang
>
> On Fri, Jun 23, 2017 at 2:02 PM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 06/23/2017 01:36 PM, Yang Liu via USRP-users wrote:
>>
>>> Dear all,
>>>
>>> we are using one usrp x310 with two UBX 160 in a full duplex mode (one
>>> ubx for transmitting and the second one for receiving, with a 10G
>>> connection). In the code, two separate TX and RX flowgraphs are
>>> established. However, in the actual test, we found that once RX flowgraph
>>> is busy at processing data, the transmitter will suffer from severe
>>> underflow problem while sending packets. Sample rate is just 5Msps, using
>>> TX flowgraph alone will not have underflow and RX flowgraph alone no
>>> overflow either under the same sample rate.
>>>
>>> Since these two flowgraphs are separate, and that gnuradio will assign
>>> one thread to one block, it seems to me that processing data should not
>>> have impact at transmitting (independent). I am wondering how could this
>>> happen. I tried to use gr::hier_blocks::set_processor_affinity to
>>> separate core resources also, but it didn't work.
>>>
>>> Any explanations to this observation and any advice about how to tackle
>>> this will be greatly appreciated!
>>>
>>> Thanks,
>>> Yang
>>>
>> When you say "two flow-graphs" do you mean two separate processes?
>>
>> Only a single process can "own" the network USRP interface at a time.
>>
> OK, so you're going to have to find the "hot spots" in your code to see
> about optimizing them. Gnu Radio puts each block in a separate thread,
> but that's no guarantee that they can all get the CPU they need, when they
> need it.
>
> That discussion (optimizing GR flow-graphs) should probably be held on the
> discuss-gnuradio mailing list, rather than here.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/ed0dc4b6/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 23 Jun 2017 11:46:05 -0700
From: Jacob Knoles <[email protected]>
To: Dave NotTelling <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Does send block the thread?
Message-ID:
<CA+z4yFFB3mgSQ7JeFfbPjXZ5xRgsR1509qgsiYZ+gC=p7tu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thank you Dave that makes a lot of sense and seems to be the case here. I
am getting much better results by forcing my function thread to wait after
issuing all of the transmit commands for all of my bursts and in my output
I can clearly see where the usrp buffer is filling up and causing the
thread to block!
Thanks again!!
On Fri, Jun 23, 2017 at 11:03 AM, Dave NotTelling <[email protected]>
wrote:
> I think that the send() command will block until the data is transmitted
> *or* until all of the data can be copied over to RAM on the radio. Check
> out http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/2016-November/022482.html.
>
> On Fri, Jun 23, 2017 at 1:17 PM, Jacob Knoles via USRP-users <
> [email protected]> wrote:
>
>> The UHD API and several examples indicate that tx_stream->send(...) will
>> block the thread until the samples have been sent, and if the metadata
>> provided has a time_spec then it will block until that time has come. I am
>> not seeing this behavior at all, in fact if I do not manually block the
>> thread it will fly through all the send commands and bursts I need to send,
>> end the function, thus closing the stream, and I get no output at all...?
>>
>> What is going on here?
>>
>> How can I send multiple bursts that are time specific?
>>
>> Please help.
>>
>> -----------------------------
>> Jacob Knoles
>>
>>
>> _______________________________________________
>> 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/20170623/8d020fea/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 23 Jun 2017 02:32:13 -0700
From: Rizwan Akram <[email protected]>
To: [email protected]
Subject: [USRP-users] Help required in Setting up USRP N200
Message-ID:
<cahg9atjxdokehqfxzmccsemmudm-pb+rmd-cp5y+emtwavt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Everyone,
I am using N200 USRP for radio direction finder project as a replacement of
NI USRP 2920. I am unable to connect with N200. tried to ping as well.
still can't detect. Also, it does not appear in NI USRP Configuration
utility. only orange light is on of the LAN cable from the inside. i will
appreciate a lot if someone can guide me on this as i am quite new to this
area. thanks in advance
Best Regard,
Rizwan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/c1d97d2e/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 23 Jun 2017 19:00:38 +0000
From: "Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC]"
<[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Any EMI Information For the E310? Thanks
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/53ad33af/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 23 Jun 2017 16:19:24 -0400
From: Raj Bhattacharjea <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Two RFNoC FFT blocks on X310?
Message-ID:
<cap3eqjdft-w_bufv8x82dt31uwea930s2dc+nhpzctx7kru...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
To wrap up this thread, it worked! Here's what I did:
uhd_image_builder.py fft fft duc duc ddc ddc -d x310 -t X310_RFNOC_XG -m 7
--fill-with-fifos
And so I got an image with dual 10 GigE and:
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * Radio_1
| | | * FFT_0
| | | * FFT_1
| | | * DDC_0
| | | * DDC_1
| | | * DUC_0
| | | * DUC_1
| | | * FIFO_0
Haven't had time to test, but this setup should get two full receive chains
with FFTs without sacrificing any TX capability, right?
On Tue, Jun 20, 2017 at 3:13 PM, Raj Bhattacharjea <[email protected]
> wrote:
> Thanks!
>
> On Tue, Jun 20, 2017 at 3:10 PM, Jonathon Pendlum <
> [email protected]> wrote:
>
>> Hi,
>>
>> The stock image does not have two FFTs. You can make an image with two of
>> them in it and it will fit.
>>
>> Jonathon
>>
>> On Tue, Jun 20, 2017 at 11:39 AM, Raj Bhattacharjea via USRP-users <
>> [email protected]> wrote:
>>
>>> We have an application with an X310 where we'd like to have two
>>> daughterboards (both UBX-160) receiving on one X310, and we'd like to
>>> do length 1024 FFTs on these two parallel streams on the FPGA using RFNoC.
>>> I'm not somewhere where I can check what's in the stock image, but is
>>> having two RFNoC FFT blocks (one for each RX chain) supported and will it
>>> fit on the FPGA on the X310 in this configuration? Note I'm willing to take
>>> out TX capabilities from the image.
>>>
>>> --
>>> Raj Bhattacharjea
>>> http://www.prism.gatech.edu/~rb288/
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
>
> --
> Raj Bhattacharjea
> http://www.prism.gatech.edu/~rb288/
>
--
Raj Bhattacharjea
http://www.prism.gatech.edu/~rb288/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/8a48fb33/attachment-0001.html>
------------------------------
Message: 16
Date: Fri, 23 Jun 2017 14:09:33 -0700
From: Jonathon Pendlum <[email protected]>
To: Raj Bhattacharjea <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Two RFNoC FFT blocks on X310?
Message-ID:
<CAGdo0uQ8kHPDswpyU0gT1cGBBO2W8CAAT=rykmsv1u_gabb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
>
> Haven't had time to test, but this setup should get two full receive
> chains with FFTs without sacrificing any TX capability, right?
Correct
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/7f676683/attachment-0001.html>
------------------------------
Message: 17
Date: Fri, 23 Jun 2017 15:00:15 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Does send block the thread?
Message-ID: <20170623220015.GA26490@glad0s>
Content-Type: text/plain; charset="utf-8"
On Fri, Jun 23, 2017 at 11:46:05AM -0700, Jacob Knoles via USRP-users wrote:
> Thank you Dave that makes a lot of sense and seems to be the case here. I
> am getting much better results by forcing my function thread to wait after
> issuing all of the transmit commands for all of my bursts and in my output
> I can clearly see where the usrp buffer is filling up and causing the
> thread to block!
> Thanks again!!
For the record, send() will block until all the samples are released
from the buffer, and on the way to the antenna. That doesn't mean
they're sent. You could have a send time set that's way in the future,
and as long as the device can buffer, it'll accept samples.
However, it'll block until samples were read from the user buffer. That
means when send() returns, you can overwrite the parts of the input
buffer that were read (and you use the return value of send() to figure
out how many samples were read exactly).
-- M
>
> On Fri, Jun 23, 2017 at 11:03 AM, Dave NotTelling <[email protected]>
> wrote:
>
> I think that the send() command will block until the data is transmitted
> *or* until all of the data can be copied over to RAM on the radio.??
> Check
>
> out??http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-November/022482.html.
> On Fri, Jun 23, 2017 at 1:17 PM, Jacob Knoles via USRP-users
> <[email protected]> wrote:
>
> The UHD API and several examples indicate that tx_stream->send(...)
> will block the thread until the samples have been sent, and if the
> metadata provided has a time_spec then it will block until that time
> has come. I am not seeing this behavior at all, in fact if I do not
> manually block the thread it will fly through all the send commands
> and bursts I need to send, end the function, thus closing the stream,
> and I get no output at all...?
> What is going on here???
> How can I send multiple bursts that are time specific?
> Please help.
> -----------------------------
> Jacob Knoles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/936ce360/attachment-0001.asc>
------------------------------
Message: 18
Date: Fri, 23 Jun 2017 15:00:51 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Store and Replay N2x0
Message-ID: <20170623220051.GB26490@glad0s>
Content-Type: text/plain; charset="us-ascii"
On Fri, Jun 23, 2017 at 12:22:56PM -0400, Dave NotTelling via USRP-users wrote:
> Is there any way to send the N2x0 a complex waveform and have it transmit
> the waveform at multiple different times without needing to send the
> waveform again?
Unfortunately, no. That would require FPGA modifications.
-- M
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/1b70a2ac/attachment-0001.asc>
------------------------------
Message: 19
Date: Fri, 23 Jun 2017 15:02:52 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E310 gnuradio not showing RFNoC blocks
Message-ID: <20170623220252.GC26490@glad0s>
Content-Type: text/plain; charset="us-ascii"
On Fri, Jun 23, 2017 at 11:13:27AM -0400, Jason Matusiak via USRP-users wrote:
> My fresh E310 seems to be running fine and a uhd_usrp_probe shows me the
> default RFNoC blocks, so I know the bitfile and UHD is good.
>
> When I run GRC on there are no RFNoC blocks or the device3 block, is there a
> step I missed (I don't usually have all these issues with my host machine
> and my X310)?
The blocks in GRC are not related to the device you're running -- is
gr-ettus properly installed?
-- M
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170623/373350e2/attachment-0001.asc>
------------------------------
Message: 20
Date: Fri, 23 Jun 2017 15:25:40 -0700
From: Jacob Knoles <[email protected]>
To: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Does send block the thread?
Message-ID:
<ca+z4yfgjtg3lwv78p4lrnggevuj6spwcizcnpgyk7fyadp3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Martin,
I am not sure I fully understand. I get that when the samples leave the
buffer there will be a delay before they hit the antenna. But it seems to
me that you are suggesting that send() will not return until the samples
leave the buffer? This does not appear to be the case for me, as I am doing
what you have described, the burst trigger time is well in the future but
according to my diagnostic output send() returns almost instantly. By time
stamping the diagnostic output I can clearly see when the buffer fills and
send blocks the thread but it is not until many many many samples are sent.
-----------------------------
Jacob Knoles
Compliance Engineer / Software Developer
MiCOM Labs Inc.
Pleasanton, CA
On Fri, Jun 23, 2017 at 3:00 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> On Fri, Jun 23, 2017 at 11:46:05AM -0700, Jacob Knoles via USRP-users
> wrote:
> > Thank you Dave that makes a lot of sense and seems to be the case
> here. I
> > am getting much better results by forcing my function thread to wait
> after
> > issuing all of the transmit commands for all of my bursts and in my
> output
> > I can clearly see where the usrp buffer is filling up and causing the
> > thread to block!
> > Thanks again!!
>
> For the record, send() will block until all the samples are released
> from the buffer, and on the way to the antenna. That doesn't mean
> they're sent. You could have a send time set that's way in the future,
> and as long as the device can buffer, it'll accept samples.
>
> However, it'll block until samples were read from the user buffer. That
> means when send() returns, you can overwrite the parts of the input
> buffer that were read (and you use the return value of send() to figure
> out how many samples were read exactly).
>
> -- M
>
>
>
> >
> > On Fri, Jun 23, 2017 at 11:03 AM, Dave NotTelling <
> [email protected]>
> > wrote:
> >
> > I think that the send() command will block until the data is
> transmitted
> > *or* until all of the data can be copied over to RAM on the radio.?
> > Check
> > out? http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/2016-November/022482.html.
> > On Fri, Jun 23, 2017 at 1:17 PM, Jacob Knoles via USRP-users
> > <[email protected]> wrote:
> >
> > The UHD API and several examples indicate that
> tx_stream->send(...)
> > will block the thread until the samples have been sent, and if the
> > metadata provided has a time_spec then it will block until that
> time
> > has come. I am not seeing this behavior at all, in fact if I do
> not
> > manually block the thread it will fly through all the send
> commands
> > and bursts I need to send, end the function, thus closing the
> stream,
> > and I get no output at all...?
> > What is going on here??
> > How can I send multiple bursts that are time specific?
> > Please help.
> > -----------------------------
> > Jacob Knoles
>
>
> _______________________________________________
> 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/20170623/739ce7eb/attachment-0001.html>
------------------------------
Message: 21
Date: Sat, 24 Jun 2017 00:17:20 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>, Martin
Braun <[email protected]>
Subject: Re: [USRP-users] Store and Replay N2x0
Message-ID:
<cak6gvumrdkgi8gxmdrhomax5tzphedn2akqan2cw-8xjbsn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Okay, thanks!
On Jun 23, 2017 18:01, "Martin Braun via USRP-users" <
[email protected]> wrote:
> On Fri, Jun 23, 2017 at 12:22:56PM -0400, Dave NotTelling via USRP-users
> wrote:
> > Is there any way to send the N2x0 a complex waveform and have it
> transmit
> > the waveform at multiple different times without needing to send the
> > waveform again?
>
> Unfortunately, no. That would require FPGA modifications.
>
> -- M
>
> _______________________________________________
> 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/20170624/76f0f49a/attachment-0001.html>
------------------------------
Message: 22
Date: Sat, 24 Jun 2017 14:19:52 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Any EMI Information For the E310? Thanks
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Matheou,
hm, what specifically are you looking for? Considering the E310 is and
SDR, and can by principle emit any spectrum in any 56 MHz bandwidth
between 70 and 6000 MHz, plus spurs caused by unwanted effects depending
on the oscillators' frequencies involved and the signal you're
transmitting, I'm not quite sure anyone can give you the data you'd
need, but maybe I'm approaching this the wrong way around?
Best regards,
Marcus
On 06/23/2017 09:00 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN
TECHNOLOGIES INC] via USRP-users wrote:
>
>
>
>
>
> _______________________________________________
> 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/20170624/e9aac720/attachment-0001.html>
------------------------------
Message: 23
Date: Sat, 24 Jun 2017 07:56:04 -0700
From: Neel Pandeya <[email protected]>
To: [email protected]
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Any EMI Information For the E310? Thanks
Message-ID:
<CACaXmv-1nKb=OMP_Z7u0a1T_YhHd_MykcsvGvNwU=rmdy1a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Konstantin Matheou:
We do not have any EMI data published for the E310 at the moment, but we
are in the process of testing now, and we will have some data shortly.
Please contact me directly off-list, and I'll share with you whatever
information we have currently.
--?Neel Pandeya
On 24 June 2017 at 05:19, Marcus M?ller via USRP-users <
[email protected]> wrote:
> Hi Matheou,
>
> hm, what specifically are you looking for? Considering the E310 is and
> SDR, and can by principle emit any spectrum in any 56 MHz bandwidth between
> 70 and 6000 MHz, plus spurs caused by unwanted effects depending on the
> oscillators' frequencies involved and the signal you're transmitting, I'm
> not quite sure anyone can give you the data you'd need, but maybe I'm
> approaching this the wrong way around?
>
> Best regards,
>
> Marcus
>
> On 06/23/2017 09:00 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES
> INC] via USRP-users wrote:
>
>
>
>
> _______________________________________________
> 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/20170624/65f257fe/attachment-0001.html>
------------------------------
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 82, Issue 23
******************************************
