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. Re: GRC flowgraph taking longer than I think it should
(Marcus M?ller)
2. Re: Using on-board DRAM on x310 (Michael West)
3. Re: XML file for multiple output ports (Marcus M?ller)
4. Re: Multi Thread on E310 (Marcus M?ller)
5. Re: unable to set remote file system path (Marcus M?ller)
6. Re: Using the gpio in an OOT (Marcus M?ller)
7. Re: Building FPGA image for an Schmidl-Cox Synchronization
block (OFDM Receiver) (Marcus M?ller)
8. Re: SDRAM bandwidth (Michael West)
9. Re: Multiple timed bursts on X300 (Michael West)
10. Re: Different streaming modes at the same time with same USRP
hardware (Michael West)
11. Re: Using on-board DRAM on x310 (Leandro Echevarr?a)
12. Re: Different streaming modes at the same time with same USRP
hardware (Felipe Augusto Pereira de Figueiredo)
13. Re: SDRAM bandwidth (Leandro Echevarr?a)
14. Re: RFNoC Log Power Block (Muhammad, Siraj)
15. Re: RFNoC Log Power Block (Sylvain Munaut)
16. Re: RFNoC Log Power Block (Muhammad, Siraj)
17. Resend: PPS output jumping around (Sean Nowlan)
18. Re: Using on-board DRAM on x310 (Michael West)
19. Re: Resend: PPS output jumping around (Marcus D. Leech)
20. Re: SDRAM bandwidth (Michael West)
21. Re: Different streaming modes at the same time with same USRP
hardware (Michael West)
22. Re: Different streaming modes at the same time with same USRP
hardware (Felipe Augusto Pereira de Figueiredo)
----------------------------------------------------------------------
Message: 1
Date: Fri, 30 Jun 2017 19:44:09 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GRC flowgraph taking longer than I think it
should
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Thomas,
sorry for the late reply; as we're going through the mailing list, we
found your question unanswered.
So, basically, this is a bit of a GNU Radio question and might be better
answered on the GNU Radio mailing list, but I'll try my best to analyze
the situation here:
GNU Radio is a buffer-driven architecture, ie. each block is asked to
fill as much of its output buffer as fast as possible with the input
it's given. That might absolutely mean that the USRP Source firs
accumulates e.g. 400 samples before it hands them off to the filter, and
then immediately goes back to producing more samples, while the filter
process the first ones; when the filter is done with that and "looks"
for new input, maybe 4000 samples might have already accumulated in its
input buffer.
I've actually tried to line out that working really shortly in a text a
wrote a few months ago:
https://gnuradio.org/blog/buffers
Best regards,
Marcus
On 03/03/2017 01:19 AM, Thomas Wright via USRP-users wrote:
> Hi all,
>
> I have a simple flowgraph:
>
> usrp n210 -> low pass filter -> stream to vector decimator -> msg
> queue sink
>
> with important parameters:
> sample rate = .195312 MSps
> vector length = 128
> decimation rate = 16
> msg queue length = 1
>
> and my application is trying to capture samples of a given signal as
> fast as possible. I'm using a GRC generated python script that I'm
> editing, and looking at time stamps I'm creating with datetime.now().
> My general code is:
>
> TIMESTAMP1
> flowgraph.usrp.set_center_freq(center freq)
> TIMESTAMP2
>
> flowgraph.set_sample_rate(samplerate) #does usrp, filter, etc.
> TIMESTAMP3
>
> flowgraph.start()
> TIMESTAMP4
>
> flowgraph.msg_queue.delete_head() #waits for there to be data in the
> queue
> TIMESTAMP5
>
> flowgraph.stop()
>
> average difference between timestamps:
> 1 -> 2 = .5ms
> 2 -> 3 = 1ms
> 3 -> 4 = 4ms
> 4 -> 5 = 80ms
>
> My issue is that I think the time between timestamps 4 and 5 should
> take about 10ms:
>
> 128 samp/vector * 16 vector * (1second / 195312 samp) =~ 10ms.
>
> My questions that arise from this:
> How much overhead SWIG/python introduce, could that be significantly
> hampering performance? Would a c++ version perform significantly better?
> Would a higher end usrp perform significantly better?
> How close I can expect to get to the theoretical minimum?
>
> I appreciate any information anyone could provide. Thanks very much.
>
> -Scott
>
>
> _______________________________________________
> 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/20170630/bdb10925/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 30 Jun 2017 10:46:17 -0700
From: Michael West <[email protected]>
To: Leandro Echevarr?a <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using on-board DRAM on x310
Message-ID:
<CAM4xKrpA0=hdaekgubnxfuopqzmgdsdy2ddek00kr-wmqea...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Leo,
For the TX side, you can already do that by just specifying a future
timestamp in the TX metadata. For the RX side, you can just use system
memory on the host and control the amount of buffering by adjusting the
recv_buff_size. The timespec in the stream command will control timing and
multiple stream commands can be queued.
If you are trying to do a more elaborate FGPA design, you can use RFNoC and
connect the DMA FIFO block however your design requires and get the
buffering you need where you need it. There can be only one DRAM
controller, so only one DMA FIFO block can be used. The current block only
has 2 input and output ports, but you can modify the block to support more
if necessary.
Regards,
Michael
On Wed, May 24, 2017 at 11:14 AM, Leandro Echevarr?a via USRP-users <
[email protected]> wrote:
> Hey everyone,
>
> As far as I'm concerned, the DMA FIFO included in the latest releases
> makes use of the external DRAM module to act as a rather large I/O buffer.
> Is there a way to also access the DRAM as temporary storage to write and
> read signals at specified times? I'm using an x310, by the way.
>
> Thanks in advance,
>
> Leo.
>
> _______________________________________________
> 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/20170630/f417a6aa/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 30 Jun 2017 19:58:55 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] XML file for multiple output ports
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Doug,
I know this is coming very late, but: Do you still need help with that?
I'm not absolutely sure what you're askingf about, how is your output
port associated with a settings register?
Best regards,
Marcus
On 04/14/2017 07:25 PM, Barker, Douglas W. via USRP-users wrote:
>
> Hello,
>
>
>
> How does one make the block descriptor XML file when the RFNoC block
> has multiple outputs. Specifically, each output port has an
> associated set of settings registers. How do you associated a group
> of settings registers with a particular output port. There are no
> examples like this.
>
>
>
> Thanks
>
> Doug
>
>
>
> _______________________________________________
> 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/20170630/a49c0cd3/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 30 Jun 2017 20:02:13 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Multi Thread on E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi!
Hm, this might be a little late, so I guess you've already helped
yourself, but:
It's pretty likely that the IO operation to SD card doesn't come "free",
neither in terms of CPU / interrupts, nor in bus bandwidth :(
Best regards,
Marcus
On 05/05/2017 05:41 PM, Disco Daniele via USRP-users wrote:
>
> Hi!
>
> I?m using a code similar to rx_multi_samples.cpp to receive LTE data
> from the two inputs in sc16 format.
>
> The maximum vector that the USRP allow to store in memory is 84MS (2
> complex sc16 streams) corresponding ad ~43 seconds of acquisition.
>
>
>
> If I want to extend this rx time, a possibility is to use a
> multi-threads approach:
>
> The main is the ?producer? that write data in the vector
>
> A parallel thread is the ?consumer? that write data on SD card.
>
> A simple circular buffer is used addressing the element of the vector
> with (item-i)%(length_Vector).
>
> The code read burst of data of length = 1016 samples so the consumer
> write on SD always 2 x 1016 samples in two separate files
>
>
>
> To tune the multi threads approach I developed a ?fake? program where
> there is a function that write in the vector the sequence of data from
> 0 to 1015 in the real part and in the imaginary part the number of the
> burst considered; a delay of 500 micro seconds is necessary, similar
> of the time necessary to acquire 1016 samples at 1.92MSPS (529 micro
> seconds); there is a thread that write data on files in parallel to a
> loop that write data in the vector.
>
>
>
> Using a vector size of 83677 * 1016 < 84M I?m verified that on E310
> I?m able to store data of length ~2 * 84M on two file one per the port
> A and the second for port B in format sc16.
>
>
>
> Moving this approach on the real program, I?m not able to obtain same
> results.
>
> AN ?O? appears on the screen and the acquisition stops.
>
>
>
> It seems that two threads where the first one manage the usrp and the
> second write on sd is not possible to E310.
>
> Can you comment on that and advise me if I can test or try if a
> possible solution there is?
>
> Thank you in advice
>
> Daniele
>
>
>
>
>
>
>
>
>
>
>
> _____________________________________________**
>
> logo1*
> **Daniele Disco*
> Engeenering & Tilab ? Wireless Access
> Wireless Innovation
> Via Reiss Romoli, 274 ? 10148 Torino
> tel . +39 011 228 7271
> cell. +39 331 600 1113
>
> Fax. +39 06 4186 5196
> Tim Official: *Facebook* <https://www.facebook.com/TimOfficialPage>-
> *Twitter* <https://twitter.com/tim_official>
> *www.tim.it* <http://www.tim.it/>
>
>
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente
> alle persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente
> vietate. Qualora abbiate ricevuto questo documento per errore siete
> cortesemente pregati di darne immediata comunicazione al mittente e di
> provvedere alla sua distruzione, Grazie.
>
> /This e-mail and any attachments is confidential and may contain
> privileged information intended for the addressee(s) only.
> Dissemination, copying, printing or use by anybody else is
> unauthorised. If you are not the intended recipient, please delete
> this message and any attachments and advise the sender by return
> e-mail, Thanks. /
>
> *Rispetta l'ambiente. Non stampare questa mail se non ? necessario.*
>
>
>
> _______________________________________________
> 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/20170630/b7951896/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2519 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170630/b7951896/attachment-0001.jpe>
------------------------------
Message: 5
Date: Fri, 30 Jun 2017 20:05:09 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] unable to set remote file system path
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Olivani,
if that's really happening, it would be misbehaviour of the shell you're
using ? after an "export", the variable should definitely be set as
environment for anything /spawned from the same shell/. Do you run the
"echo $PATH" in the same shell as you "source"?
Best regards,
Marcus
On 05/02/2017 04:53 PM, deepa kumar via USRP-users wrote:
> Hi
>
> I created set_env as follows
>
> LOCALPREFIX=~/usr
> export PATH=$LOCALPREFIX/bin:$PATH
> export LD_LOAD_LIBRARY=$LOCALPREFIX/lib:$LD_LOAD_LIBRARY
> export LD_LIBRARY_PATH=$LOCALPREFIX/lib:$LD_LIBRARY_PATH
> export PYTHONPATH=$LOCALPREFIX/lib/python2.7/site-packages:$PYTHONPATH
> export PKG_CONFIG_PATH=$LOCALPREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
> export
> GRC_BLOCKS_PATH=$LOCALPREFIX/share/gnuradio/grc/blocks:$GRC_BLOCKS_PATH
> export UHD_RFNOC_DIR=$LOCALPREFIX/share/uhd/rfnoc/
> export UHD_IMAGES_DIR=$LOCALPREFIX/share/uhd/images
>
>
> after running source ./set_env , when I echo $LD_LIBRARY_PATH it shows
>
> /lib:/root/usr
>
> echo $LOCALPREFIX
> /home/root/usr
>
> but when echo $PATH
> *bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin*
>
> *
> *
>
> *so when I do a which uhd_find_devices it keeps pointing to *
>
> /usr/bin/uhd_find_devices
> and not to
>
> /home/root/usr
>
>
> can somebody help me with this.
>
> Thanks and Regards,
> Olivani
>
>
>
>
> _______________________________________________
> 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/20170630/d902bd92/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 30 Jun 2017 20:06:57 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Using the gpio in an OOT
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Santos,
has that been solved already?
My gut feeling is that you'd want a pointer to the non-abstract
gr::uhd::usrp_sink or ::usrp_source blocks, not their common
::usrp_block superclass?
Can you elaborate on "it crashes the flow graph"?
Best regards,
Marcus
On 06/06/2017 05:57 PM, Santos Campos via USRP-users wrote:
> Hello, all!
>
> I took a crack at this a while ago and decided to try again.
>
> So, I'm having trouble getting the uhd gpio functions in my OOT module
> to play nice with my flow graph. Am I making this shared pointer
> correctly?
> #include <gnuradio/uhd/usrp_block.h>`
> .
> .
> .
> boost::shared_ptr<gr::uhd::usrp_block> usrp;
>
> It compiles fine, but when I try to access the set_gpio_attr function
> it crashes the flow graph.
> Any push in the right direction would be much appreciated!
>
> Also, I'm trying to use a usrp sink in the same graph. Could I be
> having some conflict with that?
> I'm trying to use the same device
>
> --
> /*
> Santos Campos
> University of Michigan '17 | B.S.E. Computer Engineering
> santosecampos.com <http://santosecampos.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/20170630/fb0c73fc/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 30 Jun 2017 20:09:55 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Building FPGA image for an Schmidl-Cox
Synchronization block (OFDM Receiver)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear Luis,
it's thoroughly possible that we broke the schmidl-cox.v on the
rfnoc-devel branch; there's a reason we split off the ofdm branch :(
Best regards,
Marcus
On 06/16/2017 07:02 PM, Torres Figueroa, Luis Angel via USRP-users wrote:
>
> Hi all,
>
>
>
> I am trying to synthesize a Schmidl-Cox block using the UHD image
> builder, so I can use it in a NI USRP-2953R device (Xilinx part:
> xc7k410tffg900-2) along with GNU Radio Companion. For this purpose, I
> am using the latest commit of the rfnoc-devel branch (commit
> 74d1448e375d4b9e30d762976d20d2378112576f, April 11th 2017), and I have
> added some of the missing verilog files listed in the schmidl_cox.v
> module that are available from the rfnoc-ofdm branch (commit
> 6467d4b48a8ac76bff7bf5380c00b039182e5ef7, April 11th 2016). I have
> made a comparison of the latest commits on both branches and added the
> latest versions to my RTL design, and I have additionally made a
> couple of modifications in the arguments of some modules (so updated
> version of the modules in the rfnoc-ofdm branch are compatible with
> older ones in the rfnoc-devel branch). The list of changes that I have
> done can be found below:
>
>
>
> 1. Schmidl_cox.v (rfnoc-ofdm branch)
> 1. Replaced by ofdm version (devel v2014, ofdm v2015)
> 2. Lines 42, 51, 114 modified: parameter FIFOSIZE is now called
> FIFO_SIZE
> 3. Lines 79, 86, 138, 162: parameter MAX_LEN_LOG2 and argument 8
> changed to MAX_LEN and 255, respectively, so they are
> compatible with devel version.
> 4. Lines 188, 189: divide_int32.v is the same in all branches.
> The bus m_axis_dout_tuser listed in schmidl_cox.v is disabled
> since it was not implemented in the module.
> 2. split_stream_fifo.v (rfnoc-devel branch)
> 1. The verilog file in the rfnoc-devel branch is the most recent,
> the only difference is the size of the FIFO (5 in devel, 6 in
> ofdm) [However this is an input parameter, which is set upon
> calling the module].
> 3. ofdm_plateau_detector.v (rfnoc-ofdm branch)
> 1. Non-existent in devel, rfnoc-ofdm version copied.
> 2. line 94, modified: divide_int16 changed to divide_int16_int32
> 3. line 68, 107,211 modified: MAX_LENGTH instead of
> MAX_LENGTH_LOG2 and argument modified be consistent
> (substracted by one to obtain the correct log2).
> 4. Line 185: FIFOSIZE changed by FIFO_SIZE as defined in updated
> module.
> 4. multiply.v (ofdm)
> 1. Non-existent, rfnoc-ofdm version copied
> 5. moving_sum.v (rfnoc-devel branch)
> 1. rfnoc-devel version used, since it is the most recent one
> 6. complex_to_mag_approx.v (rfnoc-ofdm branch)
> 1. lines 78, 98, 118: rfnoc-ofdm version has more relevant
> changes, though an update of the axi_fifo_flop to
> axi_fifo_flop2 is needed, since the rfnoc-devel version
> included that one later.
> 7. periodic_framer.v (rfnoc-ofdm branch)
> 1. copied from rfnoc-ofdm branch, this was the latest version.
>
>
>
> I have also taken into consideration the recommendations given in the
> previous post:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-March/019341.html
>
>
>
> However, I cannot build the FPGA image. When using the UHD image
> builder command, I am getting the following errors. I am using
> UHD_4.0.0.rfnoc-devel-348-g2c2e1a99.
>
>
>
> $ python2 uhd_image_builder.py schmidl_cox -I ../../lib/rfnoc -d x310
> -t X310_RFNOC_HG -m3 --fill-with-fifos
>
> *ERROR*: [Synth 8-448] named port connection 's_axis_phase_tlast' does
> not exist for instance 'cordic_freq_offset_correction' of module
> 'cordic_rotator'
> [/home/ltorresf/uhd/fpga-src/usrp3/lib/rfnoc/schmidl_cox.v:235]
>
> *ERROR*: [Synth 8-285] failed synthesizing module
> 'setting_reg__parameterized26'
> [/home/ltorresf/uhd/fpga-src/usrp3/lib/control/setting_reg.v:12]
>
> *ERROR*: [Synth 8-285] failed synthesizing module 'periodic_framer'
> [/home/ltorresf/uhd/fpga-src/usrp3/lib/rfnoc/periodic_framer.v:5]
>
> *ERROR*: [Synth 8-285] failed synthesizing module 'schmidl_cox'
> [/home/ltorresf/uhd/fpga-src/usrp3/lib/rfnoc/schmidl_cox.v:5]
>
> *ERROR*: [Synth 8-285] failed synthesizing module
> 'noc_block_schmidl_cox'
> [/home/ltorresf/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_schmidl_cox.v:5]
>
> *ERROR*: [Synth 8-285] failed synthesizing module 'x300_core'
> [/home/ltorresf/uhd/fpga-src/usrp3/top/x300/x300_core.v:2]
>
> *ERROR*: [Synth 8-285] failed synthesizing module 'x300'
> [/home/ltorresf/uhd/fpga-src/usrp3/top/x300/x300.v:15]
>
> *ERROR*: [Common 17-69] Command failed: Synthesis failed - please see
> the console or run log file for details
>
>
>
> The list of previous changes were done using Vivado v2015.4, where I
> was actually able to synthesize the schmidl_cox.v module and obtain
> the schematics, but when running the implementation I run into the
> following errors:
>
>
>
> [DRC 23-20] Rule violation (INBB-3) Black Box Instances - Cell
> 'cmult1/cmult1' of type 'cmult1/cmult1/complex_multiplier' has
> undefined contents and is considered a black box. The contents of
> this cell must be defined for opt_design to complete successfully.
>
> [DRC 23-20] Rule violation (INBB-3) Black Box Instances - Cell
> 'complex_to_magphase_int32' of type
> 'complex_to_magphase_int32/complex_to_magphase' has undefined contents
> and is considered a black box. The contents of this cell must be
> defined for opt_design to complete successfully.
>
> [DRC 23-20] Rule violation (INBB-3) Black Box Instances - Cell
> 'cordic_freq_offset_correction' of type
> 'cordic_freq_offset_correction/cordic_rotator' has undefined contents
> and is considered a black box. The contents of this cell must be
> defined for opt_design to complete successfully.
>
> [DRC 23-20] Rule violation (INBB-3) Black Box Instances - Cell
> 'corr_sqr_div_energy_sqr' of type
> 'corr_sqr_div_energy_sqr/divide_int32' has undefined contents and is
> considered a black box. The contents of this cell must be defined for
> opt_design to complete successfully.
>
> [DRC 23-20] Rule violation (INBB-3) Black Box Instances - Cell
> 'ofdm_plateau_detector/divide_gain' of type
> 'ofdm_plateau_detector/divide_gain/divide_int16_int32' has undefined
> contents and is considered a black box. The contents of this cell
> must be defined for opt_design to complete successfully.
>
> [Vivado_Tcl 4-78] Error(s) found during DRC. Opt_design not run.
>
>
>
> I am now looking into the details of the specific blocks (UHD image
> building errors, highlighted), however since this block worked in the
> past, could you provide me with some information why they are not
> working anymore? Or let me know whether the approach I am taking is
> the correct one?
>
>
>
> Here you can find some printscreens: https://goo.gl/HZqAS8. Any
> insight on how to make it work will be appreciated.
>
>
>
> Best,
>
> Luis A. Torres
>
>
>
>
>
> _______________________________________________
> 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/20170630/e91e9593/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 30 Jun 2017 11:17:55 -0700
From: Michael West <[email protected]>
To: Leandro Echevarr?a <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] SDRAM bandwidth
Message-ID:
<cam4xkrofjd1_h6ugfmm-qehabkfbzyugve79zbsbtgx9qfm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Leandro,
The comments are out-dated. The actual clock is 150 MHz and the width is
256 bits, so that works out to 38.4 Gbps theoretical maximum bandwidth.
But that does not take into account the controller latency. Actual
bandwidth through the controller has been measured at ~10.4 Gbps. The
clock rate had to be lowered from 250 MHz to 150 MHz to meet timing for the
FPGA build.
Regards,
Michael
On Tue, Jun 13, 2017 at 4:31 AM, Leandro Echevarr?a via USRP-users <
[email protected]> wrote:
> Hey everybody,
>
> I'm using a USRP X310. In the file x300_core.v, just before the I/O
> declaration to the external SDRAM chip, there's a comment that says:
>
> // AXI4 (128b@250MHz) interface to DDR3 controller
>
> *Does this mean the maximum throughput to the DDR3 RAM is 32 Gbps?* I'm a
> little bit confused because the immediate data port that's declared after
> this comment is 256 bits wide (which makes me suspect it's 128 bits DDR, so
> 64 Gbps).
>
> 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/20170630/63c1a849/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 30 Jun 2017 11:30:54 -0700
From: Michael West <[email protected]>
To: Jacob Knoles <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Multiple timed bursts on X300
Message-ID:
<cam4xkrr0j3cfdzup6fgsrjduqqe60oabhg1wokjnwpkdgvu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
HI Jacob,
Do not wait to transmit the end of burst packet. Waiting to send the end
of burst will result in an underrun and an empty packet with the end of
burst flag may not illicit an ACK. Also, examine the sequence of the
time_spec and has_time_spec values for every packet you send (including the
one with the end of burst). There may be something off with one of the
timestamps that would result in blocking everything after it.
Regards,
Michael
On Thu, Jun 22, 2017 at 5:09 PM, Jacob Knoles via USRP-users <
[email protected]> wrote:
> Hello,
>
> I am trying to transmit a sequence of bursts using a X300 being programmed
> with the UHD C++ api.
>
> At this time I am successfully transmitting the first burst but all
> subsequent bursts result in a failure.
> After each burst transmission I check the tx stream for async messages,
> looking for the ack, after the first burst returns successfully I get no
> messages back from any other burst, resulting in a tx failure.
>
> I have followed the tx_bursts example provided with UHD but it seems to me
> like send is not blocking the thread, as it is described to do. I have a
> loop that checks the device time, waiting until the known end of the burst
> period before advancing to the next burst and without this loop the code
> executes everything immediately and I see no transmissions at all.
>
> I have a queue of burst information objects that I iterate through with
> the following processing:
> Set the metadata with a known timespec to transmit.
> transmit the signal
> Wait until the signal should have finished
> transmit an end of burst packet.
> pop the queue and repeat.
>
> I am not sure what is going wrong here?
>
> Thanks for any help.
> -- Jacob
>
> _______________________________________________
> 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/20170630/1bfbb51a/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 30 Jun 2017 11:32:45 -0700
From: Michael West <[email protected]>
To: Felipe Augusto Pereira de Figueiredo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Different streaming modes at the same time
with same USRP hardware
Message-ID:
<cam4xkrrucudubvvv0nwwsahzd2xs8yrjvknn0so2zirlxqx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Felipe,
Yes. If you create different streamers, each with a different set of
channels, each streamer can be configured independently.
Regards,
Michael
On Tue, Jun 27, 2017 at 7:28 AM, Felipe Augusto Pereira de Figueiredo via
USRP-users <[email protected]> wrote:
> Dear folks,
>
> I've got a x310 and I'd like to know if it is possible to open two streams
> with different streaming modes at the same time in the same USRP hardware.
>
> For example, the first RF chain would be configures as
>
> *UHD_STREAM_MODE_START_CONTINUOUS*
>
> and the second one would be set to
>
> *UHD_STREAM_MODE_NUM_SAMPS_AND_DONE*
>
> Is is possible?
>
> Thanks and Kind regards,
>
> Felipe Augusto
>
> _______________________________________________
> 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/20170630/74bc4e54/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 30 Jun 2017 18:49:25 +0000
From: Leandro Echevarr?a <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using on-board DRAM on x310
Message-ID:
<CALEOA2gWTHzftgJkrf=5+D0Kk9cMWVku2crZrXeNghe=w-u...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Michael,
Thank you very much for your answer. Since this question was asked, I have
been working on the issue, and the proposed design now involves creating a
custom RFNoC block by reusing the shell of the noc_block_axi_dma_fifo.v
(this is, keeping mainly the NoC Shell and the AXI DMA MASTER inside each
of the axi_dma_fifo.v blocks), and replacing the input/output pipes FIFO
logic by something with more complex addressing capabilities.
I understand each DMA MASTER inside each FIFO ultimately acts as a slave to
the 2x64_axi_interconnect, which then connects to the DRAM controller as
the master device. We'd like to keep one of the two dma fifos that are
included by default, thus releasing one slave in the axi interconnect
block, and connecting our custom block there. As far as I'm concerned, I
think this is possible wire-wise, but I'm not sure how the DRAM controller
is going to react to being hooked up to a DMA fifo and to a custom block at
the same time. We wouldn't be using more than one DRAM controller, anyway.
What do you think about this approach? Should we drop the DMA FIFOs
entirely and just use our blocks connected to the DRAM?
Thanks again,
Leo.
On Fri, Jun 30, 2017 at 2:46 PM Michael West <[email protected]> wrote:
> Hi Leo,
>
> For the TX side, you can already do that by just specifying a future
> timestamp in the TX metadata. For the RX side, you can just use system
> memory on the host and control the amount of buffering by adjusting the
> recv_buff_size. The timespec in the stream command will control timing and
> multiple stream commands can be queued.
>
> If you are trying to do a more elaborate FGPA design, you can use RFNoC
> and connect the DMA FIFO block however your design requires and get the
> buffering you need where you need it. There can be only one DRAM
> controller, so only one DMA FIFO block can be used. The current block only
> has 2 input and output ports, but you can modify the block to support more
> if necessary.
>
> Regards,
> Michael
>
> On Wed, May 24, 2017 at 11:14 AM, Leandro Echevarr?a via USRP-users <
> [email protected]> wrote:
>
>> Hey everyone,
>>
>> As far as I'm concerned, the DMA FIFO included in the latest releases
>> makes use of the external DRAM module to act as a rather large I/O buffer.
>> Is there a way to also access the DRAM as temporary storage to write and
>> read signals at specified times? I'm using an x310, by the way.
>>
>> Thanks in advance,
>>
>> Leo.
>>
>> _______________________________________________
>> 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/20170630/b61e182e/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 30 Jun 2017 21:00:10 +0200
From: Felipe Augusto Pereira de Figueiredo <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Different streaming modes at the same time
with same USRP hardware
Message-ID:
<CA+abmwKfkH+wt+UpD0fpoF+-ZK9oyCdTk=6ay3jxxoeb4pg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Michael,
Thanks for the reply.
Given your answer, I've got two additional questions:
1) Does it mean I can create a RX stream to read RXed samples from the RF
chain 0 (I think you call DSP0) and another RX stream to read samples from
RF chain 1 (DSP1)? I'd like to have a SISO physical layer running (TX/RX)
on the RF chain 0 at frequency X and sample rate Y and a spectrum sensing
module with different sampling rate Z at frequency W on the RF chain 1.
2) Is there any example on how to create different streamers to
receive/transmit using different RF Chains?
Many Thanks and Kind Regards,
Felipe Augusto
On Fri, Jun 30, 2017 at 8:32 PM, Michael West <[email protected]>
wrote:
> Hi Felipe,
>
> Yes. If you create different streamers, each with a different set of
> channels, each streamer can be configured independently.
>
> Regards,
> Michael
>
> On Tue, Jun 27, 2017 at 7:28 AM, Felipe Augusto Pereira de Figueiredo via
> USRP-users <[email protected]> wrote:
>
>> Dear folks,
>>
>> I've got a x310 and I'd like to know if it is possible to open two
>> streams with different streaming modes at the same time in the same USRP
>> hardware.
>>
>> For example, the first RF chain would be configures as
>>
>> *UHD_STREAM_MODE_START_CONTINUOUS*
>>
>> and the second one would be set to
>>
>> *UHD_STREAM_MODE_NUM_SAMPS_AND_DONE*
>>
>> Is is possible?
>>
>> Thanks and Kind regards,
>>
>> Felipe Augusto
>>
>> _______________________________________________
>> 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/20170630/8aaf2042/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 30 Jun 2017 19:04:10 +0000
From: Leandro Echevarr?a <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] SDRAM bandwidth
Message-ID:
<CALEOA2hDhOePJeGsuXWg9cYgaVX3kWE1H=mjppycd2ammqn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
Thanks again, you're making my day. Is this ~10.4 Gbps throughput you're
talking about true for totally sequential reading/writing? Or should I
expect better performance in this case?
Best regards,
Leo.
On Fri, Jun 30, 2017 at 3:17 PM Michael West <[email protected]> wrote:
> Hi Leandro,
>
> The comments are out-dated. The actual clock is 150 MHz and the width is
> 256 bits, so that works out to 38.4 Gbps theoretical maximum bandwidth.
> But that does not take into account the controller latency. Actual
> bandwidth through the controller has been measured at ~10.4 Gbps. The
> clock rate had to be lowered from 250 MHz to 150 MHz to meet timing for the
> FPGA build.
>
> Regards,
> Michael
>
> On Tue, Jun 13, 2017 at 4:31 AM, Leandro Echevarr?a via USRP-users <
> [email protected]> wrote:
>
>> Hey everybody,
>>
>> I'm using a USRP X310. In the file x300_core.v, just before the I/O
>> declaration to the external SDRAM chip, there's a comment that says:
>>
>> // AXI4 (128b@250MHz) interface to DDR3 controller
>>
>> *Does this mean the maximum throughput to the DDR3 RAM is 32 Gbps?* I'm
>> a little bit confused because the immediate data port that's declared after
>> this comment is 256 bits wide (which makes me suspect it's 128 bits DDR, so
>> 64 Gbps).
>>
>> 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/20170630/1a2e43ee/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 30 Jun 2017 20:05:13 +0000
From: "Muhammad, Siraj" <[email protected]>
To: Sylvain Munaut <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC Log Power Block
Message-ID:
<dm2pr03mb3355742fcdd52d9af844778cd...@dm2pr03mb335.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi Sylvain,
Thanks for the reply. Never thought about fixed-point... it makes things a
little bit messy. I have a few questions:
1- What is the representation of this fixed-point implementation? (i.e., how
many bits for the binary point?)
2- I assume all of your implementations on the FPGA are fixed-point? FFT,
LogPower,...
3- Do I have to implement my custom computation engines in fixed-point all the
time?
I hope you bear with me as I am trying to tackle this issue... it's been a
while since I've last dealt with FP and FPGA in general.
Thank you very much again.
Regards,
Siraj
-----Original Message-----
From: Sylvain Munaut [mailto:[email protected]]
Sent: Friday, June 30, 2017 10:32 AM
To: Muhammad, Siraj <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] RFNoC Log Power Block
Hi,
> I am examining the RFNoC Loq Power block which is based on
> f15_logpwr.v. In that Verilog source code, the header says it computes
>
> 2048 * log2(i^2+q^2) given a complex input.
That statement is only valid for the 16 bits fixed points values fed to the
verilog code.
> So I tested this by feeding the block a constant complex number: 1+1j.
Well there's your first issue, you can't actually represent '1' really.
Because the FPGA uses 16 bits fixed point, it will take floating point number
and multiply by 32768 then map that to 16 bits. Problem is that
16 bits signed number go from -32768 to 32767 ... to you can't really represent
'1' but only ~0.9997 as the max value.
Then the return value when fed back to GR is converted back from 16 bits fixed
point to float by dividing by 32768.
So in your case the block computes 2048 * log2( 32767 * 32767 + 32767
* 32767 ) ~= 63488 (because the output is 16 bits unsigned).
Then if you look when this is mapped back to rfnoc, the LSB is dropped :
assign s_axis_data_tdata = { 1'b0, s_axis_data_tdata16[15:1], 16'b0 };
So 31744 is what's sent back to the host. And when mapped to float
31744 / 32768 = 0.96875
Cheers,
Sylvain
------------------------------
Message: 15
Date: Fri, 30 Jun 2017 22:57:43 +0200
From: Sylvain Munaut <[email protected]>
To: "Muhammad, Siraj" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC Log Power Block
Message-ID:
<CAHL+j08MYuvbGrT+HitCGWyR6Aa4C7ud3+Xs=4ceepfzm16...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi,
> Thanks for the reply. Never thought about fixed-point... it makes things a
> little bit messy. I have a few questions:
> 1- What is the representation of this fixed-point implementation? (i.e., how
> many bits for the binary point?)
You can see it as having all the bits are after the binary point. 16
bits values where 1 bit is the sign bit, and 15 bits are fractional
bits.
Other option is to see all the numbers as being in the range -32768 to
32767 and this being the entire dynamic range you have to fit into.
Really that's just a point of view thing and doesn't affect either the
actual math or the implementation.
> 2- I assume all of your implementations on the FPGA are fixed-point? FFT,
> LogPower,...
Yes
> 3- Do I have to implement my custom computation engines in fixed-point all
> the time?
Yes
Cheers,
Sylvain
------------------------------
Message: 16
Date: Fri, 30 Jun 2017 21:41:23 +0000
From: "Muhammad, Siraj" <[email protected]>
To: Sylvain Munaut <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC Log Power Block
Message-ID:
<dm2pr03mb335a66a299b31045e67f644cd...@dm2pr03mb335.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi Sylvain,
I am thinking again about your previous email.
1- I understand that the range of numbers I can represent is -1 ~ 0.99997
correct?
2- When numbers out of this range are passed, overflow happens?
3- I understand that conversion between float and fixed-point happens
automatically?
4- Data from host to FPGA are always considered float and mapped to 16-bit
fixed-point? Conversely, data from FPGA to host are always mapped back to
float? Can I interpret them differently without conversion?
5- What about user registers? I assume they are passed as is and I have to take
care of converting them to fixed-point in my CE if ever used with data buses.
Correct?
Thanks a lot,
Siraj
-----Original Message-----
From: Sylvain Munaut [mailto:[email protected]]
Sent: Friday, June 30, 2017 3:58 PM
To: Muhammad, Siraj <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] RFNoC Log Power Block
Hi,
> Thanks for the reply. Never thought about fixed-point... it makes things a
> little bit messy. I have a few questions:
> 1- What is the representation of this fixed-point implementation?
> (i.e., how many bits for the binary point?)
You can see it as having all the bits are after the binary point. 16 bits
values where 1 bit is the sign bit, and 15 bits are fractional bits.
Other option is to see all the numbers as being in the range -32768 to
32767 and this being the entire dynamic range you have to fit into.
Really that's just a point of view thing and doesn't affect either the actual
math or the implementation.
> 2- I assume all of your implementations on the FPGA are fixed-point? FFT,
> LogPower,...
Yes
> 3- Do I have to implement my custom computation engines in fixed-point all
> the time?
Yes
Cheers,
Sylvain
------------------------------
Message: 17
Date: Fri, 30 Jun 2017 17:44:19 -0400
From: Sean Nowlan <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Resend: PPS output jumping around
Message-ID:
<CAGmpSnq4mGaNijGv5eRByMsK6YD8emDyGW7+P=axjcddn-u...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Sent about 10 days ago, resending again hoping for a response:
To Whom It May Concern:
I'm using a B200mini (we also have some B205minis which I believe behave
exactly the same). I'm working on a narrowband application that requires a
precise clock due to susceptibility to carrier frequency offset. So far
we've been using a 1PPS as a reference, which gives good accuracy, better
than 100ppb. However, I've noticed that the frequency reference jumps in
discrete steps at 1 second intervals, leading me to believe that the
control voltage to the VCTCXO is updated at the 1PPS edge, and the loop
filter bandwidth in the digital PLL implementation [1] may be too wide. Do
you have any recommendations for greatly reducing the discrete jumps, e.g.,
by greatly narrowing the bandwidth of the loop filter? In our application
it won't be a problem to let the PLL converge over a long period
(hours/days).
Also for clarification, past emails on the list about the TCXO stability
refer to its accuracy (over temperature, I'm assuming) as +/- 0.5ppm.
However the code [1] states that the TCXO is 5ppm. What are these numbers
referring to, and which one is correct?
Thanks,
Sean Nowlan
[1] https://github.com/EttusResearch/fpga/blob/master/usrp3/top/b2xxmini/
b205_ref_pll.v
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170630/d6e15ed7/attachment-0001.html>
------------------------------
Message: 18
Date: Fri, 30 Jun 2017 15:41:39 -0700
From: Michael West <[email protected]>
To: Leandro Echevarr?a <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using on-board DRAM on x310
Message-ID:
<CAM4xKrorU682FzxMZtPQLgW=hqd+zyfkqsbfgzch16b_omp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Leo,
I think your approach should be fine. I'm just not sure how much you may
be over-complicating things. I would check to see if there is a way you
could use the DMA FIFO block as is and just create your own custom blocks
and connect everything up the way you need it. The DMA FIFO is just a
buffer after all. You can put it anywhere in the stream.
Regards,
Michael
On Fri, Jun 30, 2017 at 11:49 AM, Leandro Echevarr?a <
[email protected]> wrote:
> Hey Michael,
>
> Thank you very much for your answer. Since this question was asked, I have
> been working on the issue, and the proposed design now involves creating a
> custom RFNoC block by reusing the shell of the noc_block_axi_dma_fifo.v
> (this is, keeping mainly the NoC Shell and the AXI DMA MASTER inside each
> of the axi_dma_fifo.v blocks), and replacing the input/output pipes FIFO
> logic by something with more complex addressing capabilities.
>
> I understand each DMA MASTER inside each FIFO ultimately acts as a slave
> to the 2x64_axi_interconnect, which then connects to the DRAM controller as
> the master device. We'd like to keep one of the two dma fifos that are
> included by default, thus releasing one slave in the axi interconnect
> block, and connecting our custom block there. As far as I'm concerned, I
> think this is possible wire-wise, but I'm not sure how the DRAM controller
> is going to react to being hooked up to a DMA fifo and to a custom block at
> the same time. We wouldn't be using more than one DRAM controller, anyway.
> What do you think about this approach? Should we drop the DMA FIFOs
> entirely and just use our blocks connected to the DRAM?
>
> Thanks again,
>
> Leo.
>
> On Fri, Jun 30, 2017 at 2:46 PM Michael West <[email protected]>
> wrote:
>
>> Hi Leo,
>>
>> For the TX side, you can already do that by just specifying a future
>> timestamp in the TX metadata. For the RX side, you can just use system
>> memory on the host and control the amount of buffering by adjusting the
>> recv_buff_size. The timespec in the stream command will control timing and
>> multiple stream commands can be queued.
>>
>> If you are trying to do a more elaborate FGPA design, you can use RFNoC
>> and connect the DMA FIFO block however your design requires and get the
>> buffering you need where you need it. There can be only one DRAM
>> controller, so only one DMA FIFO block can be used. The current block only
>> has 2 input and output ports, but you can modify the block to support more
>> if necessary.
>>
>> Regards,
>> Michael
>>
>> On Wed, May 24, 2017 at 11:14 AM, Leandro Echevarr?a via USRP-users <
>> [email protected]> wrote:
>>
>>> Hey everyone,
>>>
>>> As far as I'm concerned, the DMA FIFO included in the latest releases
>>> makes use of the external DRAM module to act as a rather large I/O buffer.
>>> Is there a way to also access the DRAM as temporary storage to write and
>>> read signals at specified times? I'm using an x310, by the way.
>>>
>>> Thanks in advance,
>>>
>>> Leo.
>>>
>>> _______________________________________________
>>> 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/20170630/eb785186/attachment-0001.html>
------------------------------
Message: 19
Date: Fri, 30 Jun 2017 19:02:47 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Resend: PPS output jumping around
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 06/30/2017 05:44 PM, Sean Nowlan via USRP-users wrote:
> Sent about 10 days ago, resending again hoping for a response:
>
> To Whom It May Concern:
>
> I'm using a B200mini (we also have some B205minis which I believe
> behave exactly the same). I'm working on a narrowband application that
> requires a precise clock due to susceptibility to carrier frequency
> offset. So far we've been using a 1PPS as a reference, which gives
> good accuracy, better than 100ppb. However, I've noticed that the
> frequency reference jumps in discrete steps at 1 second intervals,
> leading me to believe that the control voltage to the VCTCXO is
> updated at the 1PPS edge, and the loop filter bandwidth in the digital
> PLL implementation [1] may be too wide. Do you have any
> recommendations for greatly reducing the discrete jumps, e.g., by
> greatly narrowing the bandwidth of the loop filter? In our application
> it won't be a problem to let the PLL converge over a long period
> (hours/days).
>
> Also for clarification, past emails on the list about the TCXO
> stability refer to its accuracy (over temperature, I'm assuming) as
> +/- 0.5ppm. However the code [1] states that the TCXO is 5ppm. What
> are these numbers referring to, and which one is correct?
>
> Thanks,
> Sean Nowlan
>
> [1]
> https://github.com/EttusResearch/fpga/blob/master/usrp3/top/b2xxmini/b205_ref_pll.v
>
> <https://github.com/EttusResearch/fpga/blob/master/usrp3/top/b2xxmini/b205_ref_pll.v>
>
The data-sheet for the B205mini says +/- 2PPM for frequency accuracy.
The DPLL implementation in the "mini" series could likely be improved,
but I'll leave it to someone from R&D to comment on exactly *now* that might
come about. I do know that several approaches were tried, and the
DPLL in the released FPGA code version had the best behavior, but not
perfect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170630/74cbbeb8/attachment-0001.html>
------------------------------
Message: 20
Date: Fri, 30 Jun 2017 17:05:55 -0700
From: Michael West <[email protected]>
To: Leandro Echevarr?a <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] SDRAM bandwidth
Message-ID:
<CAM4xKrpfgAhG6xmaAOYZbsa6d+r=inpajva5mjezv3zlov9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Leo,
The ~10.4 Gbps was a rough number I got from a colleague of mine that had
done some testing on it. It was most likely using the DRAM as a FIFO with
random 8k reads and writes. I would expect sequential reads/writes to be a
bit better, but I could not say how much.
Regards,
Michael
On Fri, Jun 30, 2017 at 12:04 PM, Leandro Echevarr?a <
[email protected]> wrote:
> Hi Michael,
>
> Thanks again, you're making my day. Is this ~10.4 Gbps throughput you're
> talking about true for totally sequential reading/writing? Or should I
> expect better performance in this case?
>
> Best regards,
>
> Leo.
>
> On Fri, Jun 30, 2017 at 3:17 PM Michael West <[email protected]>
> wrote:
>
>> Hi Leandro,
>>
>> The comments are out-dated. The actual clock is 150 MHz and the width is
>> 256 bits, so that works out to 38.4 Gbps theoretical maximum bandwidth.
>> But that does not take into account the controller latency. Actual
>> bandwidth through the controller has been measured at ~10.4 Gbps. The
>> clock rate had to be lowered from 250 MHz to 150 MHz to meet timing for the
>> FPGA build.
>>
>> Regards,
>> Michael
>>
>> On Tue, Jun 13, 2017 at 4:31 AM, Leandro Echevarr?a via USRP-users <
>> [email protected]> wrote:
>>
>>> Hey everybody,
>>>
>>> I'm using a USRP X310. In the file x300_core.v, just before the I/O
>>> declaration to the external SDRAM chip, there's a comment that says:
>>>
>>> // AXI4 (128b@250MHz) interface to DDR3 controller
>>>
>>> *Does this mean the maximum throughput to the DDR3 RAM is 32 Gbps?* I'm
>>> a little bit confused because the immediate data port that's declared after
>>> this comment is 256 bits wide (which makes me suspect it's 128 bits DDR, so
>>> 64 Gbps).
>>>
>>> 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/20170630/d452a752/attachment-0001.html>
------------------------------
Message: 21
Date: Fri, 30 Jun 2017 17:16:48 -0700
From: Michael West <[email protected]>
To: Felipe Augusto Pereira de Figueiredo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Different streaming modes at the same time
with same USRP hardware
Message-ID:
<CAM4xKroizW-3qs+idRXeqi5eSe7Na-=y=nf9n9uodo6vjo0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Felipe,
1) Yes, that is supported.
2) There is no example, but it is pretty easy. Just set the
uhd::stream_args_t::channels value correctly for each streamer object.
Regards,
Michael
On Fri, Jun 30, 2017 at 12:00 PM, Felipe Augusto Pereira de Figueiredo <
[email protected]> wrote:
> Dear Michael,
>
> Thanks for the reply.
>
> Given your answer, I've got two additional questions:
>
> 1) Does it mean I can create a RX stream to read RXed samples from the RF
> chain 0 (I think you call DSP0) and another RX stream to read samples from
> RF chain 1 (DSP1)? I'd like to have a SISO physical layer running (TX/RX)
> on the RF chain 0 at frequency X and sample rate Y and a spectrum sensing
> module with different sampling rate Z at frequency W on the RF chain 1.
>
> 2) Is there any example on how to create different streamers to
> receive/transmit using different RF Chains?
>
> Many Thanks and Kind Regards,
>
> Felipe Augusto
>
> On Fri, Jun 30, 2017 at 8:32 PM, Michael West <[email protected]>
> wrote:
>
>> Hi Felipe,
>>
>> Yes. If you create different streamers, each with a different set of
>> channels, each streamer can be configured independently.
>>
>> Regards,
>> Michael
>>
>> On Tue, Jun 27, 2017 at 7:28 AM, Felipe Augusto Pereira de Figueiredo via
>> USRP-users <[email protected]> wrote:
>>
>>> Dear folks,
>>>
>>> I've got a x310 and I'd like to know if it is possible to open two
>>> streams with different streaming modes at the same time in the same USRP
>>> hardware.
>>>
>>> For example, the first RF chain would be configures as
>>>
>>> *UHD_STREAM_MODE_START_CONTINUOUS*
>>>
>>> and the second one would be set to
>>>
>>> *UHD_STREAM_MODE_NUM_SAMPS_AND_DONE*
>>>
>>> Is is possible?
>>>
>>> Thanks and Kind regards,
>>>
>>> Felipe Augusto
>>>
>>> _______________________________________________
>>> 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/20170630/747f5db9/attachment-0001.html>
------------------------------
Message: 22
Date: Sat, 1 Jul 2017 11:45:05 +0200
From: Felipe Augusto Pereira de Figueiredo <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Different streaming modes at the same time
with same USRP hardware
Message-ID:
<CA+abmwJP4UQdvgtbrrV6rxOb70riKMHx_pbey=lw60j1jzu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Michael,
Some more questions follows inline.
Thanks and Kind Regards,
Felipe Augusto
On Sat, Jul 1, 2017 at 2:16 AM, Michael West <[email protected]> wrote:
> Hi Felipe,
>
> 1) Yes, that is supported.
>
When you say that is supported, do you mean with legacy UHD API or with
RFNoC one? Even though I have a x310 I'm still using the legacy API.
>
> 2) There is no example, but it is pretty easy. Just set the
> uhd::stream_args_t::channels value correctly for each streamer object.
>
Do I need to create two different stream objects?
>
> Regards,
> Michael
>
> On Fri, Jun 30, 2017 at 12:00 PM, Felipe Augusto Pereira de Figueiredo <
> [email protected]> wrote:
>
>> Dear Michael,
>>
>> Thanks for the reply.
>>
>> Given your answer, I've got two additional questions:
>>
>> 1) Does it mean I can create a RX stream to read RXed samples from the RF
>> chain 0 (I think you call DSP0) and another RX stream to read samples from
>> RF chain 1 (DSP1)? I'd like to have a SISO physical layer running (TX/RX)
>> on the RF chain 0 at frequency X and sample rate Y and a spectrum sensing
>> module with different sampling rate Z at frequency W on the RF chain 1.
>>
>> 2) Is there any example on how to create different streamers to
>> receive/transmit using different RF Chains?
>>
>> Many Thanks and Kind Regards,
>>
>> Felipe Augusto
>>
>> On Fri, Jun 30, 2017 at 8:32 PM, Michael West <[email protected]>
>> wrote:
>>
>>> Hi Felipe,
>>>
>>> Yes. If you create different streamers, each with a different set of
>>> channels, each streamer can be configured independently.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Tue, Jun 27, 2017 at 7:28 AM, Felipe Augusto Pereira de Figueiredo
>>> via USRP-users <[email protected]> wrote:
>>>
>>>> Dear folks,
>>>>
>>>> I've got a x310 and I'd like to know if it is possible to open two
>>>> streams with different streaming modes at the same time in the same USRP
>>>> hardware.
>>>>
>>>> For example, the first RF chain would be configures as
>>>>
>>>> *UHD_STREAM_MODE_START_CONTINUOUS*
>>>>
>>>> and the second one would be set to
>>>>
>>>> *UHD_STREAM_MODE_NUM_SAMPS_AND_DONE*
>>>>
>>>> Is is possible?
>>>>
>>>> Thanks and Kind regards,
>>>>
>>>> Felipe Augusto
>>>>
>>>> _______________________________________________
>>>> 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/20170701/d7182d21/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 83, Issue 1
*****************************************
