[USRP-users] FLEX900 + USRP1 Rev2 (Martin Braun)

Angilberto Muniz Sb angilberto at yahoo.com
Thu Oct 26 13:55:47 EDT 2017


Thankx for the info Martin.
By any chance, does anybody have a copy of old USRP1 Rev2 schematics?The one available for download is for USRP1 Rev3 or 4+... Angilberto. 

      From: "usrp-users-request at lists.ettus.com" <usrp-users-request at lists.ettus.com>
 To: usrp-users at lists.ettus.com 
 Sent: Thursday, October 26, 2017 1:40 PM
 Subject: USRP-users Digest, Vol 86, Issue 25
   
Send USRP-users mailing list submissions to
    usrp-users at lists.ettus.com

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
    usrp-users-request at lists.ettus.com

You can reach the person managing the list at
    usrp-users-owner at lists.ettus.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."


Today's Topics:

  1. 2 B210 synchronous problem (Hideyuki Matsunaga)
  2. B210 -- various questions on sampling/clock rates (Rob Heig)
  3. Re: FLEX900 + USRP1 Rev2 (Martin Braun)
  4. Re: systemverilog files in rfnoc block (Dario Pennisi)
  5. Re: systemverilog files in rfnoc block (Jade Anderson)
  6. Re: B210 -- various questions on sampling/clock rates
      (Anon Lister)
  7. Re: 2 N200 MIMO system phase offset varies with frequency,
      have used timed_command with tune and also integer-N Tuning per
      Marcus M post of Feb 17, 2016 (John Shields)
  8. USRP B210 time errors with high master clock rate
      (Perelman, Nathan)
  9. Re: B210 -- various questions on sampling/clock rates (Rob Heig)
  10. performance_data for TwinRx (liu Jong)
  11. B205mini: 0-value Samples When Switching Center Frequency
      (Gilad Beeri (ApolloShield))
  12. cross-compiling with external libraries on E310 (Francois Quitin)
  13. Re: cross-compiling with external libraries on E310
      (Philip Balister)
  14. Re: cross-compiling with external libraries on E310
      (Francois Quitin)
  15. Re: cross-compiling with external libraries on E310
      (Philip Balister)
  16. Re: B205mini: 0-value Samples When Switching Center Frequency
      (Marcus D. Leech)
  17. Re: [Discuss-gnuradio] Extra RF shielding? (Marcus M?ller)
  18. Re: Advise on how to modifying HDL design E310 to add custom
      blocks (Derek Kozel)


----------------------------------------------------------------------

Message: 1
Date: Wed, 25 Oct 2017 15:59:39 +0900
From: Hideyuki Matsunaga <hideyuki.matsunaga at gmail.com>
To: usrp-users at lists.ettus.com
Subject: [USRP-users] 2 B210 synchronous problem
Message-ID:
    <CA+HAK=qcXCr7ymvF8XWB5i2Kmmn2+o1TEtb60dt7OspGrD+jJA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi

I bought 2 B210s for testing direction of arrival estimation, like below.

=======================  Configuration =============================

Ch0 <--> | USRP0 Rx 0 |
        |            | <-- USB3.0 --> |      PC                        |
Ch1 <--> | USRP0 Rx 1 |                | Ubuntu 14.04                    |
                                      | GNU Radio Companion 3.7.11.1    |
Ch2 <--> | USRP1 Rx 0 |                | UHD_003.010.001.001-79-g7ac01c7f|
        |            | <-- USB3.0 --> |                                |
Ch3 <--> | USRP1 Rx 1 |

- External 10MHz reference CLK & 1PPS are provided by function
generator(Tektronix AFG1012) to each B210
- center freq  2.4GHz
- samping rate 4MHz

In GRC
- 2 separate USRP Source for each B210, settings are below
 - Sync option  unknown pps
 - Clock Source  External
 - Time Source  External
 - Num Channels  2

I generated python code by GRC and then I added custom timing adjustment
code.
```
 self.uhd_usrp_source_0.set_time_next_pps(uhd.time_spec(0))
 self.uhd_usrp_source_1.set_time_next_pps(uhd.time_spec(0))
 time.sleep(1.0)

 start_time = uhd.time_spec(5.0)
 self.uhd_usrp_source_0.set_start_time(start_time)
 self.uhd_usrp_source_1.set_start_time(start_time)
```
===========================================================================

I believe that I am following all the instructions what I found in web.
but, when I tried to check that sampling timing is exactly matched or not
by dumping all the samples(connect File Sink), I found sampling gaps
between 2 B210.

While testing, I confirmed that
- there are no overflow,
- start timing would be exactly the same(using Tag Debug to confirm)

I observed that
- gaps looks fixed size during running
- gaps are slightly different every time


Please let me know what I am missing.


Thanks,
Matsu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171025/0f49d3b3/attachment-0001.html>

------------------------------

Message: 2
Date: Wed, 25 Oct 2017 07:58:26 +0200
From: Rob Heig <robhhh6 at gmail.com>
To: usrp-users at lists.ettus.com
Subject: [USRP-users] B210 -- various questions on sampling/clock
    rates
Message-ID:
    <CAMpo1VJs+ghfEZGEH1MyaBq+jwL5FRxXM9AbBqh-DE0Vu8YDYA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi,

I am experimenting a bit with the B210 board and I have a couple of
questions concerning sampling/clock rates:

- is it normal that, on a decent modern PC with plenty of cores, memory,
and working on a SSD, a simple program that dumps I/Q data on file gives
more often than not overflows ("OOOO" messages from UHD) starting at around
40Msps (sometimes, with a very lightweight charge of the CPU, even at
10-20)? I have been monitoring USB traffic using vUSBAnalyzer to see if
anything's wrong, and it seems that from time to time the transmission
simply stops and gets reset after a few seconds (meaning that the board's
buffers overflowed, I guess), but I couldn't find a reason why this
happens. I have asked a colleague to increase the size of the buffers on
the FPGA, but that improved the situation only slightly... Is there any
architectural documentation explaining the behavior of UHD with a USB
device to see where the bottleneck could be (without having to delve into
the UHD code)?

- playing with filters I saw that, when the sampling rate is set below
16Msps, the clock rate is set at a multiple of the desired sampling rate
(for instance, 32MHz for 2Msps, 40MHz for 5Msps, ...). Actually, I realized
it only after having spent a whole morning wondering why a custom FIR
filter that was supposed to work nicely at 8Msps was not filtering at all
(I guess the messages printed on the console are there for a reason....
;)). What is the reason behind this choice? Is it imposed by the RFIC (I
couldn't find anything on the reference manual, but I might be
mistaken....) or by the board design? What is the rule that governs the
choice of the clock rate? Is there any documentation about it?

Thanks a lot in advance and have a nice day!
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171025/1caf4924/attachment-0001.html>

------------------------------

Message: 3
Date: Wed, 25 Oct 2017 11:16:53 -0700
From: Martin Braun <martin.braun at ettus.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] FLEX900 + USRP1 Rev2
Message-ID: <20171025181653.GA24257 at glad0s>
Content-Type: text/plain; charset="us-ascii"

I've attached a .tar.gz of the USRP-related wiki pages from the original
wiki. Does not include images, though.

-- M

On Mon, Oct 23, 2017 at 10:06:54PM +0000, Angilberto Muniz Sb via USRP-users wrote:
>    Hi Kyeong,
>    Thanks for the info.. I'll try to find the article..
>    Regards,
> 
>    Angilberto.
> 
>    Em segunda-feira, outubro 23, 2017, 5:08 PM, Kyeong Su Shin
>    <ksshin at uw.edu> escreveu:
> 
>      Hello Angilberto Muniz:
>      An alternative to this is to modify the USRP 1 motherboard (instead of
>      the dauthgerboard). There used to be a GNURadio wiki page about this
>      ("USRPSerialBelow500"), but it is apparently gone. You can still find
>      some old e-mail archives and Chinese articles (with images) regarding
>      this.
>      Regards,
>      Kyeong Su Shin
>      On Mon, Oct 23, 2017 at 11:16 AM, Angilberto Muniz Sb via USRP-users
>      <usrp-users at lists.ettus.com> wrote:
> 
>        Hi,
>        I have a USRP1 Rev2 board and a FLEX900 dboard. The flex900 works fine
>        with USRP1 Rev4.5, but wont work with USRP1 Rev2.
>        I read somewhere that I shoud modify the flex900 to make it work with
>        USRP1 Rev2. 
>        The problem is I read two different tips...
>        in "https://files.ettus.com/ manual/page_dboards.html# dboards_rfxmod"
>        it says:
>        "...move R35 to R36 and move R117 to R115..." 
>        in "https://lists.gnu.org/ archive/html/discuss-gnuradio/
>        2009-04/msg00518.html" it says:
>        ".. move R36 to R34 and move R115 to R116..."
>        Any help?
>        Thank you,
>        Angilberto. 
>        ______________________________ _________________
>        USRP-users mailing list
>        USRP-users at lists.ettus.com
>        http://lists.ettus.com/ mailman/listinfo/usrp-users_ lists.ettus.com

> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: usrp-wiki.tar.gz
Type: application/gzip
Size: 79727 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171025/65bf734f/attachment-0001.gz>
-------------- 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/20171025/65bf734f/attachment-0001.asc>

------------------------------

Message: 4
Date: Wed, 25 Oct 2017 19:38:40 +0000
From: Dario Pennisi <dario at iptronix.com>
To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>, Jade
    Anderson    <jade.anderson at averna.com>
Subject: Re: [USRP-users] systemverilog files in rfnoc block
Message-ID:
    <CF24FB8290C467BB.25d5f141-9ab7-4be0-94a4-dd57b4b91cbc at mail.outlook.com>
    
Content-Type: text/plain; charset="us-ascii"

Hi,
I pushed the fix on my fork:

https://github.com/<https://github.com/ipTronix/fpga/commit/b144fcb40eaa0e54dfa3c66bc4fc7cb42c54362c>ipTronix<https://github.com/ipTronix/fpga/commit/b144fcb40eaa0e54dfa3c66bc4fc7cb42c54362c>/<https://github.com/ipTronix/fpga/commit/b144fcb40eaa0e54dfa3c66bc4fc7cb42c54362c>fpga<https://github.com/ipTronix/fpga/commit/b144fcb40eaa0e54dfa3c66bc4fc7cb42c54362c>/commit/b144fcb40eaa0e54dfa3c66bc4fc7cb42c54362c<https://github.com/ipTronix/fpga/commit/b144fcb40eaa0e54dfa3c66bc4fc7cb42c54362c>

Dario Pennisi








On Wed, Oct 25, 2017 at 8:06 PM +0200, "Jade Anderson" <Jade.Anderson at averna.com<mailto:Jade.Anderson at averna.com>> wrote:


Hi,
Below is a question about sytemverilog support from August, that seems unresolved.
I found this workaround, but why does the scripted flow not support systemverilog design files?
Are there plans to make this change to support designs in sytemverilog?
  If not, then can you please point me to an example of how to include a synthesized netlist into a build?  I can synthesize my systemverilog module in Vivado for the  X310 with no problems.
All I need to do is then import it into the x310 build.

Thanks
Jade Anderson


Message: 5
Date: Fri, 25 Aug 2017 19:55:11 +0000
From: Dario Pennisi
To: "usrp-users at lists.ettus.com"
Subject: [USRP-users] systemverilog files in rfnoc block
Message-ID: <1503690911110.91061 at iptronix.com>
Content-Type: text/plain; charset="iso-8859-1"

hi,

i am trying to include a couple of systemverilog files in the list of sources for a custom rfnoc block.

if i do that i can see in the log that all files with .sv extension are ignored and of course their modules are not found. if i launch compilation in gui mode and then add files back it works...

is there any way of avoiding this manual step?

thanks,


Dario Pennisi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

------------------------------

Message: 6
Date: Fri, 25 Aug 2017 20:27:18 +0000
From: Dario Pennisi
To: "usrp-users at lists.ettus.com"
Subject: Re: [USRP-users] systemverilog files in rfnoc block
Message-ID: <1503692838342.55361 at iptronix.com>
Content-Type: text/plain; charset="iso-8859-1"

i think i found the issue...

tcl script file usrp3/tools/scripts/viv_utils.tcl actually contains instructions to add files to project based on their extensions and .sv is not listed so files are skipped.

adding a case for .sv works but it also includes axi_crossbar_intf.sv which seems to be a simulation file and won't compile so i had to exclude that file...

is there any reason why sv files are not included or is that just a lazy way to exclude simulation sources?

unfortunately i need to use some systemverilog constructs and with .v extension those seem not to be accepted...

thanks,


Dario Pennisi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171025/2a324db5/attachment-0001.html>

------------------------------

Message: 5
Date: Wed, 25 Oct 2017 18:06:35 +0000
From: Jade Anderson <Jade.Anderson at averna.com>
To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] systemverilog files in rfnoc block
Message-ID:
    <BLUPR15MB0434F27B0FD7533737D4AFBB90440 at BLUPR15MB0434.namprd15.prod.outlook.com>
    
Content-Type: text/plain; charset="us-ascii"

Hi, 
Below is a question about sytemverilog support from August, that seems unresolved.  
I found this workaround, but why does the scripted flow not support systemverilog design files?
Are there plans to make this change to support designs in sytemverilog?  
  If not, then can you please point me to an example of how to include a synthesized netlist into a build?  I can synthesize my systemverilog module in Vivado for the  X310 with no problems.  
All I need to do is then import it into the x310 build.

Thanks
Jade Anderson


Message: 5
Date: Fri, 25 Aug 2017 19:55:11 +0000
From: Dario Pennisi <dario at iptronix.com>
To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: [USRP-users] systemverilog files in rfnoc block
Message-ID: <1503690911110.91061 at iptronix.com>
Content-Type: text/plain; charset="iso-8859-1"

hi,

i am trying to include a couple of systemverilog files in the list of sources for a custom rfnoc block.

if i do that i can see in the log that all files with .sv extension are ignored and of course their modules are not found. if i launch compilation in gui mode and then add files back it works...

is there any way of avoiding this manual step?

thanks,


Dario Pennisi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170825/2e3e47c9/attachment-0001.html>

------------------------------

Message: 6
Date: Fri, 25 Aug 2017 20:27:18 +0000
From: Dario Pennisi <dario at iptronix.com>
To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] systemverilog files in rfnoc block
Message-ID: <1503692838342.55361 at iptronix.com>
Content-Type: text/plain; charset="iso-8859-1"

i think i found the issue...

tcl script file usrp3/tools/scripts/viv_utils.tcl actually contains instructions to add files to project based on their extensions and .sv is not listed so files are skipped.

adding a case for .sv works but it also includes axi_crossbar_intf.sv which seems to be a simulation file and won't compile so i had to exclude that file...

is there any reason why sv files are not included or is that just a lazy way to exclude simulation sources?

unfortunately i need to use some systemverilog constructs and with .v extension those seem not to be accepted...

thanks,


Dario Pennisi



------------------------------

Message: 6
Date: Wed, 25 Oct 2017 16:16:34 -0400
From: Anon Lister <listeranon at gmail.com>
To: robhhh6 at gmail.com
Cc: usrp-users <usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] B210 -- various questions on sampling/clock
    rates
Message-ID:
    <CAMp204R6q1mVfsBsMvS4PLDwbMA-gGMjxW67nF5dp_u14m92Hg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Try specrec to record data.

https://github.com/garverp/gr-analysis

As to why it works better see this presentation:
http://www.trondeau.com/grcon15-presentations#wednesday_Lincoln_Synchronized
(The link is down at the time of writing, perhaps it will be up again soon)

With it I am able to do 50Msample w/o overruns.

Search for master_clock_rate in the uhd documentation. Setting that will
allow you to manually set the master clock rate for the b2xx and e3xx
devices. As to why I believe oversampling has some benefits a more dsp
focused individual will be able to elaborate on. I believe the logic for
automatic choice is something like the highest multiple of the desired
sample rate that is less than the maximum clock rate.

-Anon

On Oct 25, 2017 12:12 PM, "Rob Heig via USRP-users" <
usrp-users at lists.ettus.com> wrote:

Hi,

I am experimenting a bit with the B210 board and I have a couple of
questions concerning sampling/clock rates:

- is it normal that, on a decent modern PC with plenty of cores, memory,
and working on a SSD, a simple program that dumps I/Q data on file gives
more often than not overflows ("OOOO" messages from UHD) starting at around
40Msps (sometimes, with a very lightweight charge of the CPU, even at
10-20)? I have been monitoring USB traffic using vUSBAnalyzer to see if
anything's wrong, and it seems that from time to time the transmission
simply stops and gets reset after a few seconds (meaning that the board's
buffers overflowed, I guess), but I couldn't find a reason why this
happens. I have asked a colleague to increase the size of the buffers on
the FPGA, but that improved the situation only slightly... Is there any
architectural documentation explaining the behavior of UHD with a USB
device to see where the bottleneck could be (without having to delve into
the UHD code)?

- playing with filters I saw that, when the sampling rate is set below
16Msps, the clock rate is set at a multiple of the desired sampling rate
(for instance, 32MHz for 2Msps, 40MHz for 5Msps, ...). Actually, I realized
it only after having spent a whole morning wondering why a custom FIR
filter that was supposed to work nicely at 8Msps was not filtering at all
(I guess the messages printed on the console are there for a reason....
;)). What is the reason behind this choice? Is it imposed by the RFIC (I
couldn't find anything on the reference manual, but I might be
mistaken....) or by the board design? What is the rule that governs the
choice of the clock rate? Is there any documentation about it?

Thanks a lot in advance and have a nice day!
Rob

_______________________________________________
USRP-users mailing list
USRP-users at lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171025/5a606ffa/attachment-0001.html>

------------------------------

Message: 7
Date: Thu, 26 Oct 2017 09:43:13 +1300
From: "John Shields" <john.shields at xtra.co.nz>
To: "Marcus D. Leech" <mleech at ripnet.com>
Cc: "usrp-users" <usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] 2 N200 MIMO system phase offset varies with
    frequency, have used timed_command with tune and also integer-N Tuning
    per Marcus M post of Feb 17, 2016
Message-ID: <21BE9496B5644CB3BB2D086F9CFD9515 at JohnsHPLaptop>
Content-Type: text/plain; charset="utf-8"

Thanks Marcus,
                        I take your advice re: ?calibration? and DRAO. 

                        I had hoped, however, that I would not be dealing with > 100 degree offset in an ideal environment i.e. same signal through a good quality splitter positioned right at the input to the SBXs. While it was immediately obvious when you mentioned that the MIMO implementation makes no correction for the delay (not even the roughest based on the length and velocity factor which would not cover eveerything), it does mean (to me at least) that I am dealing with a larger offset than I thought from the Ettus documentation with all the talk about synching SBX LO etc. and, while mentioning there are component factors which mean that the offset was not zero, not highlighting there is a deliberate frequency sensitive offset built in to the design of the ?'MIMO cable?.

                        Will ponder my next move. 

                                  Kind Regards,

                                            John

From: Marcus D. Leech 
Sent: Thursday, October 26, 2017 3:56 AM
To: John Shields 
Cc: usrp-users 
Subject: Re: [USRP-users] 2 N200 MIMO system phase offset varies with frequency, have used timed_command with tune and also integer-N Tuning per Marcus M post of Feb 17, 2016

On 10/25/2017 03:16 AM, John Shields wrote:

  Thanks very much Marcus for the thorough explanations. I looked at the phase change with frequency to see if there was a fixed delay and there didn?t appear to be but, effectively, the MIMO cable induces a frequency dependent uncorrected phase offset  which is eminently understandable but would appear to make a mockery of ?MIMO? claims. I realised that there will always be a phase offset but was disappointed by the magnitude as measured by the complex conjugate of both signals, a complex_to_arg block and decimating the result by 1K and plotting on Qt GUI Time Sink.
In commercial MIMO applications, the implementation corrects for phase-offset error, because it is (reasonably) expected that there will always be
  some amount of phase offset.  It's inevitable for there to be *some*.  For example, the DRAO synthesis array uses hardware to measure the
  phase length of each of their cables, and corrects for thermal-expansion effects in real-time.  Since phase-offset error (and drift) extends outwards
  away from the USRP envelope, it's not realistic to expect that all such effects are accounted for in the hardware (at least, not without a much
  higher price-tag).



  It would appear that if I wanted to try to get as close to zero phase offset (to correct for non-zero MIMO cable length at least), then I need an Octoclock-G but I don?t have the nearly  $NZD 3000.00 it costs so I wonder if there is a ?cheap? way to convert my existing GPSDO board into an Octoclock-G? I only need to be able to buffer the signal for 2 USRPs.
You could just try splitting the signal two ways.  Myself, I buffer such signals with 74HC04 inverters, but I'm handy with a soldering iron.  There are
  cheap GPSDOs out there now, so it's just a matter of buffering, and for only 2 units, you might be able to get away with just splitting them.




  Otherwise, I guess I could ?calibrate? the offset at various frequencies and then, at run time, apply a phase correction to one leg based on the fc? Seems a little inelegant.
That is *PRECISELY* what most MIMO applications do, and folks doing beam-forming, etc.  There will ALWAYS be some amount of phase offset--
  some of it fixed, some of it variable.  It is a *systemic* imperfection, which means that it has to be corrected for that account for all the systemic
  contributions, including hardware entirely outside of the USRP.




              Kind Regards,

                        John

  From: Marcus D. Leech 
  Sent: Wednesday, October 25, 2017 1:20 PM
  To: John Shields 
  Cc: usrp-users 
  Subject: Re: [USRP-users] 2 N200 MIMO system phase offset varies with frequency, have used timed_command with tune and also integer-N Tuning per Marcus M post of Feb 17, 2016

  On 10/24/2017 07:45 PM, John Shields wrote:

    Thanks Marcus,
                            So it appears that the synching of the SBX LOs doesn?t work; or perhaps I should say, it doesn?t work during my measurement period? The integer-N tuning doesn?t work either. 

                            I can say that, with some level of precision, the phase is fairly constant with center-frequency but if, for example, I had a 5 MHz spectrum how could I ?correct for that?? I be;ieve that there is the whole Hilbert transform issue when you wish to translate the phase/frequency of a band of signals to a different one ?is that what I should use?

                            From my point of view, there is quite a misinterpretation of what ?synchronistation? means; in particular for SBXs and their LOs which, as advertised, are supposed to be capable of such operation with a few simple Python commands!.

                            Realising that you would/should not express some shortcoming in the SBX,N200,MIMO in an Ettus product , if there is, I would dearly like to know from someone from Ettus!!!! Purely from an outside point of view, I thought that the ? we?ll transfer the Time Of Day contents to the Mate over MIMO cable ? doesn?t actually mean that they are in ?real time? synch, from my old DMS-100 days bit was willing to go along with the theory. Seriously, I have no issue with that but just want to know how to get 2 N200r4 streams with OB GPSDO & MIMO cable ?synchronised? 

                          I would love (but be embarrassed) to be told, that as a dummy, I made this mistake but in over a month of work I have not been able to establish that.

                          Kind Regards,

                                      John

  Set up a test transmitter in the far-field of your two antenna.

  With everything synchronized the way you think it should be, plot the low-pass-filtered (and decimate to taste) result of a conjugate multiply of
    the two sides.  This should produce a straight line, with small amounts of noise.  If it just produces random walks all over the place, the two
    oscillators aren't locked to the same reference.

  My point about component tolerances is that they'll have some group-delay that isn't perfectly matched on both sides, even if things like the
    LO are running in-phase, the analog pathways won't necessarily have precisely the same group delay on the two sides.  Just like two random
    pieces of coax that are cut to the same length won't, necessarily, have precisely the same phase length.  This effect gets worse with frequency.

  Further, in radio astronomy applications, the coherence bandwidth is, technically speaking, infinitely small, due to the emission mechanisms.
    But in *practice* a significant fractional bandwidth is possible without having to channelize the input bandwidth.

  The *other* issue, that seems to be causing consternation, is the ability to predict what the phase-offset between the two sides will be upon restart
    of the flow-graph in the presence of the various bits of hocus-pocus (timed commands, etc) to try for consistent phase offsets every time you
    start streaming.  It sounds like you have that, but the offset changes depending on tuned frequency.  I'd expect that.  Both due to analog-component
    group-delay variability, and because the MIMO cable is not of zero length.  I don't believe that there is *ANY* length compensation, so one N2XX will
    receive the reference clock at a "closer" phase distance than the other one, because the MIMO cable is of finite length.  That phase-length difference will
    have more effect at higher frequencies, because a PLL is a reference multiplier (which is why having exquisitely-low phase-noise on the reference is
    important, because that noise will get worse as the multiplier ratio of the PLL increases).





    From: mleech at ripnet.com 
    Sent: Wednesday, October 25, 2017 7:45 AM
    To: John Shields 
    Cc: usrp-users 
    Subject: Re: [USRP-users] 2 N200 MIMO system phase offset varies with frequency, have used timed_command with tune and also integer-N Tuning per Marcus M post of Feb 17, 2016

    I would expect component tolerance issues on the two sides to scale with frequency.  That may be what you're seeing?








    On 2017-10-24 14:28, John Shields via USRP-users wrote:

      Hi,
          Still struggling with the configuration ? 2x N200 r4, master O/B GPSDO, slave MIMO cable. Have put in python code to use timed commands and that produced a constant phase offset even over rerun of FG or power cycling on N200 which was great news.

          However, the relative offset changes with frequency. The splitter is a Mini-circuits ZRFSC-123S+ which is spec-ed to has a typical of phase unbalance of 1/2 a degree over the frequency ranges used. The results are independent of source NWT 4000-1 or an SBX using uhd_siggen. When I have checked the ref_locked flags etc. they are good. the gpsdo is 'locked' as is MIMO.

          In addition to using the timed_commands to synch the SBX LOs, I also implement the integer-N-tuning and no improvement.

          The results are roughly    Freq (MHz)    Phase offset (deg)
                                                  450                    -7
                                                  1450                -30
                                                  1950                -65
                                                  2450                -100

          When I switch the cables between the 2 N200, the phase offset doesn't change sign so I presume it is not cabling? What on earth, else, could it be?

                Kind Regards,

                        John

          Virus-free. www.avast.com 



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





---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171026/6b2bcc2f/attachment-0001.html>

------------------------------

Message: 8
Date: Wed, 25 Oct 2017 22:58:46 +0000
From: "Perelman, Nathan" <nperelman at LGSInnovations.com>
To: usrp-users <usrp-users at lists.ettus.com>
Subject: [USRP-users] USRP B210 time errors with high master clock
    rate
Message-ID: <335dc31c8f11448c99d44c765d1c83f9 at LGS-EX01.lgsdirect.com>
Content-Type: text/plain; charset="us-ascii"

I've seen some odd behavior with timestamps for samples from the B210 being
off by large fractions of a second from what I expected when setting the
time to GPS time. I wrote a program (see attached) that uses
get_time_last_pps() to attempt to validate that the time is being set
correctly. I discovered that when using a master clock rate of 61.44 MHz,
the time returned is sometimes off by a quarter second (see output from
running below). At a master clock rate of 16 MHz, I don't see this issue.
Testing was done with UHD 3.10.1.0. Is my program doing something wrong or
is this is an issue with the B200?

 

time_test--args type=b200,master_clock_rate=61.44e6

linux; GNU C++ version 5.2.1 20150902 (Red Hat 5.2.1-2); Boost_106000;
UHD_003.010.001.000-0-unknown

 

 

Creating the usrp device with: type=b200,master_clock_rate=30.72e6...

-- Detected Device: B210

-- Operating over USB 3.

-- Detecting internal GPSDO.... Found an internal GPSDO: GPSTCXO , Firmware
Rev 0.929a

-- Initialize CODEC control...

-- Initialize Radio control...

-- Performing register loopback test... pass

-- Performing register loopback test... pass

-- Performing CODEC loopback test... pass

-- Performing CODEC loopback test... pass

-- Asking for clock rate 61.440000 MHz... 

-- Actually got clock rate 61.440000 MHz.

-- Performing timer loopback test... pass

-- Performing timer loopback test... pass

Using Device: Single USRP:

  Device: B-Series Device

  Mboard 0: B210

  RX Channel: 0

    RX DSP: 0

    RX Dboard: A

    RX Subdev: FE-RX2

  RX Channel: 1

    RX DSP: 1

    RX Dboard: A

    RX Subdev: FE-RX1

  TX Channel: 0

    TX DSP: 0

    TX Dboard: A

    TX Subdev: FE-TX2

  TX Channel: 1

    TX DSP: 1

    TX Dboard: A

    TX Subdev: FE-TX1

 

Time set count 4 check 1/5: ERROR: Time difference at last PPS: 0.249037

Time set count 4 check 4/5: ERROR: Time difference at last PPS: 0.249999

Time set count 8 check 1/5: ERROR: Time difference at last PPS: 0.249999

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171025/fc932ee9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: time_test.cpp
Type: application/octet-stream
Size: 8733 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171025/fc932ee9/attachment-0001.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4513 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171025/fc932ee9/attachment-0001.p7s>

------------------------------

Message: 9
Date: Thu, 26 Oct 2017 07:35:58 +0200
From: Rob Heig <robhhh6 at gmail.com>
To: usrp-users <usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] B210 -- various questions on sampling/clock
    rates
Message-ID:
    <CAMpo1VJ9DHkeOsJTurCDP909yUsU0dgCYm7Swde=HhV1XwALYQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi,

Thanks a lot for your answer! The link you gave me is also full of very
very interesting material :)
Have a nice day!
Rob

On 25 October 2017 at 22:16, Anon Lister <listeranon at gmail.com> wrote:

> Try specrec to record data.
>
> https://github.com/garverp/gr-analysis
>
> As to why it works better see this presentation:
> http://www.trondeau.com/grcon15-presentations#
> wednesday_Lincoln_Synchronized
> (The link is down at the time of writing, perhaps it will be up again soon)
>
> With it I am able to do 50Msample w/o overruns.
>
> Search for master_clock_rate in the uhd documentation. Setting that will
> allow you to manually set the master clock rate for the b2xx and e3xx
> devices. As to why I believe oversampling has some benefits a more dsp
> focused individual will be able to elaborate on. I believe the logic for
> automatic choice is something like the highest multiple of the desired
> sample rate that is less than the maximum clock rate.
>
> -Anon
>
> On Oct 25, 2017 12:12 PM, "Rob Heig via USRP-users" <
> usrp-users at lists.ettus.com> wrote:
>
> Hi,
>
> I am experimenting a bit with the B210 board and I have a couple of
> questions concerning sampling/clock rates:
>
> - is it normal that, on a decent modern PC with plenty of cores, memory,
> and working on a SSD, a simple program that dumps I/Q data on file gives
> more often than not overflows ("OOOO" messages from UHD) starting at around
> 40Msps (sometimes, with a very lightweight charge of the CPU, even at
> 10-20)? I have been monitoring USB traffic using vUSBAnalyzer to see if
> anything's wrong, and it seems that from time to time the transmission
> simply stops and gets reset after a few seconds (meaning that the board's
> buffers overflowed, I guess), but I couldn't find a reason why this
> happens. I have asked a colleague to increase the size of the buffers on
> the FPGA, but that improved the situation only slightly... Is there any
> architectural documentation explaining the behavior of UHD with a USB
> device to see where the bottleneck could be (without having to delve into
> the UHD code)?
>
> - playing with filters I saw that, when the sampling rate is set below
> 16Msps, the clock rate is set at a multiple of the desired sampling rate
> (for instance, 32MHz for 2Msps, 40MHz for 5Msps, ...). Actually, I realized
> it only after having spent a whole morning wondering why a custom FIR
> filter that was supposed to work nicely at 8Msps was not filtering at all
> (I guess the messages printed on the console are there for a reason....
> ;)). What is the reason behind this choice? Is it imposed by the RFIC (I
> couldn't find anything on the reference manual, but I might be
> mistaken....) or by the board design? What is the rule that governs the
> choice of the clock rate? Is there any documentation about it?
>
> Thanks a lot in advance and have a nice day!
> Rob
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171026/53d19d0f/attachment-0001.html>

------------------------------

Message: 10
Date: Thu, 26 Oct 2017 17:07:28 +0800
From: liu Jong <jongliu1987 at gmail.com>
To: "USRP-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: [USRP-users] performance_data for TwinRx
Message-ID:
    <CAEui2n14FJSq7+JsNySPZEFVE1u3e3esWvuGeW9905mtwyTN0g at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi all,
Is there any thing about performance_data for TwinRx?where could i download
it?
thank you.

best regards
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171026/0ad4d1c9/attachment-0001.html>

------------------------------

Message: 11
Date: Thu, 26 Oct 2017 10:43:05 +0000
From: "Gilad Beeri (ApolloShield)" <gilad at apolloshield.com>
To: usrp-users <usrp-users at lists.ettus.com>
Subject: [USRP-users] B205mini: 0-value Samples When Switching Center
    Frequency
Message-ID:
    <CAF4UVpBdmdGjc2ehpqodOafQBrSac5iAa+m00RRCPUKrvEwngA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi,
Whenever I switch center frequency with a USRP B205mini (changing to a
nearby frequency), I get 3 milliseconds of 0 samples.


  1. What's the reason behind that?
  2. Can I make some changes that will reduce that timespan without data?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171026/77c1f26d/attachment-0001.html>

------------------------------

Message: 12
Date: Thu, 26 Oct 2017 15:01:26 +0200
From: Francois Quitin <fquitin at ulb.ac.be>
To: usrp-users at lists.ettus.com
Subject: [USRP-users] cross-compiling with external libraries on E310
Message-ID: <edf53ef35fb7402fdaac619c4ba222a7 at imapproxy.vub.ac.be>
Content-Type: text/plain; charset=UTF-8; format=flowed

Dear all,

I'm writing code for the USRP E310 using the SDK from 
http://files.ettus.com/e3xx_images/e3xx-release-4/  I've been able to 
write code, cross-compile it and execute it without any problems on the 
E310.

I'm trying to include external libraries (open-source ones, such as 
Armadillo) to my cross-compiling project. How can I "cleanly" include 
these libraries in my cross-compiling project?

Thanks,
Fran?ois

---




------------------------------

Message: 13
Date: Thu, 26 Oct 2017 15:21:49 +0200
From: Philip Balister <philip at opensdr.com>
To: Francois Quitin <fquitin at ulb.ac.be>, usrp-users at lists.ettus.com
Subject: Re: [USRP-users] cross-compiling with external libraries on
    E310
Message-ID: <287d22c8-4d7f-aa8c-3ed5-789b76a8fb23 at opensdr.com>
Content-Type: text/plain; charset=utf-8

On 10/26/2017 03:01 PM, Francois Quitin via USRP-users wrote:
> Dear all,
> 
> I'm writing code for the USRP E310 using the SDK from
> http://files.ettus.com/e3xx_images/e3xx-release-4/? I've been able to
> write code, cross-compile it and execute it without any problems on the
> E310.
> 
> I'm trying to include external libraries (open-source ones, such as
> Armadillo) to my cross-compiling project. How can I "cleanly" include
> these libraries in my cross-compiling project?

Look at:

https://wiki.gnuradio.org/index.php/Cross_compile_GNU_Radio_and_install_on_target

The key line for updating the sdk is:

$ sudo make install DESTDIR=/usr/local/oecore-x86_64/sysroots/armv7a-...

The guys working on GNSS-SDR have an OpenEmbedded layer with an
armadillo recipe:

http://layers.openembedded.org/layerindex/recipe/58748/

It should be possible to add this to the E310 image build and add it to
the sdk to avoid having to carry the local update to your sdk.

Philip



> 
> Thanks,
> Fran?ois
> 
> ---
> 
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




------------------------------

Message: 14
Date: Thu, 26 Oct 2017 16:07:45 +0200
From: Francois Quitin <fquitin at ulb.ac.be>
To: USRP-users at lists.ettus.com
Subject: Re: [USRP-users] cross-compiling with external libraries on
    E310
Message-ID: <265c9ea5c4c8d3c8939e09a1457f6c8f at imapproxy.vub.ac.be>
Content-Type: text/plain; charset=UTF-8; format=flowed

Dear Philip, EJ,

Thanks a lot for your replies. To keep things simple, I'm tying to 
manually cross-compile the Armadillo library. Unfortunately, there are a 
few dependencies that are not available on the default E310 image 
(OpenBLAS, LAPACK, ATLAS, SuperLU).

We've made quite a few changes to the E310 FPGA, so I'm a bit frisky at 
re-installing UHD using pybombs... I'd rather just include the libraries 
and dependencies I need to my current UHD version.

Anyway, with the clues you gave me I should be able to figure something 
out.

Thanks!
Fran?ois



On 26.10.2017 15:27, EJ Kreinar wrote:
> Hi Francois,?
> 
> I see Balister beat me to reply... I'm not a cross-compile expert, so
> he probably has better recommendations, but I'll add a couple
> thoughts. There's probably three feasible options:
> 
> 1. Manual cross compile: Manually compile the project of interest,
> sourcing the SDK environment and then building with cmake or whatever
> the project's build system is (armadillo looks like cmake). This is a
> decent introduction to using the SDK
> (http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html [3]).
> Then deploy the generated code to the E310. It's feasible, but could
> be a headache if the external project has other dependencies.
> 2. Pybombs cross compile: I just checked, and there's an armadillo
> recipe in gr-recipes... Assuming you're using the E310 SDK inside a
> pybombs prefix, it might be an easy solution to just pybombs install
> armadillo. Worth a shot! And if it doesnt work, it would be good to
> share how to fix this :D?
> 3. Open-embedded build: Because the E310 distro is built using
> openembedded (https://github.com/EttusResearch/meta-ettus/tree/jethro
> [4] -- the jethro branch is, I believe, the most recent build), you
> could bake the projects of interest into the rootfs from scratch. The
> good news is that it seems there's already an armadillo recipe
> available:?http://layers.openembedded.org/layerindex/recipe/58748/
> [5] If the image you build installs the armadillo recipe, it will
> automatically include any dependencies into the rootfs. Then, you can
> export the SDK and use that for your cross compile.?
> 
> If you're already using pybombs, it could be easy to do #2. If you
> roll your own rootfs and SDK using openembedded, then you have to
> maintain your personal SD image/SDK for everything, which has its own
> downsides.?
> 
> EJ
> 
> On Thu, Oct 26, 2017 at 9:01 AM, Francois Quitin via USRP-users
> <usrp-users at lists.ettus.com> wrote:
> 
>> Dear all,
>> 
>> I'm writing code for the USRP E310 using the SDK from
>> http://files.ettus.com/e3xx_images/e3xx-release-4/ [1]? I've been
>> able to write code, cross-compile it and execute it without any
>> problems on the E310.
>> 
>> I'm trying to include external libraries (open-source ones, such as
>> Armadillo) to my cross-compiling project. How can I "cleanly"
>> include these libraries in my cross-compiling project?
>> 
>> Thanks,
>> Fran?ois
>> 
>> ---
>> 
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> [2]
> 
> 
> 
> Links:
> ------
> [1] http://files.ettus.com/e3xx_images/e3xx-release-4/
> [2] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> [3] http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html
> [4] https://github.com/EttusResearch/meta-ettus/tree/jethro
> [5] http://layers.openembedded.org/layerindex/recipe/58748/

---
Francois QUITIN
Assistant Professor

BEAMS Dpt. ? Embedded Electronics
Brussels School of Engineering
Universit? Libre de Bruxelles (ULB)

Web  https://sites.google.com/site/fquitin2/
Phone +32 2 650 2829



------------------------------

Message: 15
Date: Thu, 26 Oct 2017 16:15:40 +0200
From: Philip Balister <philip at balister.org>
To: Francois Quitin <fquitin at ulb.ac.be>, USRP-users at lists.ettus.com
Subject: Re: [USRP-users] cross-compiling with external libraries on
    E310
Message-ID: <db915bd2-6b77-33df-a10d-2c2d79764fd9 at balister.org>
Content-Type: text/plain; charset=utf-8

On 10/26/2017 04:07 PM, Francois Quitin via USRP-users wrote:
> Dear Philip, EJ,
> 
> Thanks a lot for your replies. To keep things simple, I'm tying to
> manually cross-compile the Armadillo library. Unfortunately, there are a
> few dependencies that are not available on the default E310 image
> (OpenBLAS, LAPACK, ATLAS, SuperLU).

Yes, I'm aware that pain. I do need to look over what the gnss sdr guys
have done and see what I can do to make it easier for people in your
position.

Philip


> 
> We've made quite a few changes to the E310 FPGA, so I'm a bit frisky at
> re-installing UHD using pybombs... I'd rather just include the libraries
> and dependencies I need to my current UHD version.
> 
> Anyway, with the clues you gave me I should be able to figure something
> out.
> 
> Thanks!
> Fran?ois
> 
> 
> 
> On 26.10.2017 15:27, EJ Kreinar wrote:
>> Hi Francois,?
>>
>> I see Balister beat me to reply... I'm not a cross-compile expert, so
>> he probably has better recommendations, but I'll add a couple
>> thoughts. There's probably three feasible options:
>>
>> 1. Manual cross compile: Manually compile the project of interest,
>> sourcing the SDK environment and then building with cmake or whatever
>> the project's build system is (armadillo looks like cmake). This is a
>> decent introduction to using the SDK
>> (http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html [3]).
>> Then deploy the generated code to the E310. It's feasible, but could
>> be a headache if the external project has other dependencies.
>> 2. Pybombs cross compile: I just checked, and there's an armadillo
>> recipe in gr-recipes... Assuming you're using the E310 SDK inside a
>> pybombs prefix, it might be an easy solution to just pybombs install
>> armadillo. Worth a shot! And if it doesnt work, it would be good to
>> share how to fix this :D?
>> 3. Open-embedded build: Because the E310 distro is built using
>> openembedded (https://github.com/EttusResearch/meta-ettus/tree/jethro
>> [4] -- the jethro branch is, I believe, the most recent build), you
>> could bake the projects of interest into the rootfs from scratch. The
>> good news is that it seems there's already an armadillo recipe
>> available:?http://layers.openembedded.org/layerindex/recipe/58748/
>> [5] If the image you build installs the armadillo recipe, it will
>> automatically include any dependencies into the rootfs. Then, you can
>> export the SDK and use that for your cross compile.?
>>
>> If you're already using pybombs, it could be easy to do #2. If you
>> roll your own rootfs and SDK using openembedded, then you have to
>> maintain your personal SD image/SDK for everything, which has its own
>> downsides.?
>>
>> EJ
>>
>> On Thu, Oct 26, 2017 at 9:01 AM, Francois Quitin via USRP-users
>> <usrp-users at lists.ettus.com> wrote:
>>
>>> Dear all,
>>>
>>> I'm writing code for the USRP E310 using the SDK from
>>> http://files.ettus.com/e3xx_images/e3xx-release-4/ [1]? I've been
>>> able to write code, cross-compile it and execute it without any
>>> problems on the E310.
>>>
>>> I'm trying to include external libraries (open-source ones, such as
>>> Armadillo) to my cross-compiling project. How can I "cleanly"
>>> include these libraries in my cross-compiling project?
>>>
>>> Thanks,
>>> Fran?ois
>>>
>>> ---
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> [2]
>>
>>
>>
>> Links:
>> ------
>> [1] http://files.ettus.com/e3xx_images/e3xx-release-4/
>> [2] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> [3] http://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html
>> [4] https://github.com/EttusResearch/meta-ettus/tree/jethro
>> [5] http://layers.openembedded.org/layerindex/recipe/58748/
> 
> ---
> Francois QUITIN
> Assistant Professor
> 
> BEAMS Dpt. ? Embedded Electronics
> Brussels School of Engineering
> Universit? Libre de Bruxelles (ULB)
> 
> Web?? https://sites.google.com/site/fquitin2/
> Phone +32 2 650 2829
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



------------------------------

Message: 16
Date: Thu, 26 Oct 2017 10:26:17 -0400
From: "Marcus D. Leech" <mleech at ripnet.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] B205mini: 0-value Samples When Switching
    Center Frequency
Message-ID: <59F1F089.106 at ripnet.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

On 10/26/2017 06:43 AM, Gilad Beeri (ApolloShield) via USRP-users wrote:
> Hi,
> Whenever I switch center frequency with a USRP B205mini (changing to a 
> nearby frequency), I get 3 milliseconds of 0 samples.
>
>  1. What's the reason behind that?
>  2. Can I make some changes that will reduce that timespan without data?
>
>
The analog hardware takes a finite amount of time to switch 
frequencies.  During that time, there will inevitably be *some* type of 
glitch.

A PLL synthesizer will take some amount of time to change frequency.  
Every time you change frequency, you take it out of its converged state, and
  it has to re-converge.

https://electronics.stackexchange.com/questions/76197/pll-loop-bandwidth-lock-time-and-jitter


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171026/59061374/attachment-0001.html>

------------------------------

Message: 17
Date: Thu, 26 Oct 2017 17:49:38 +0200
From: Marcus M?ller <marcus.mueller at ettus.com>
To: discuss-gnuradio at gnu.org
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] [Discuss-gnuradio] Extra RF shielding?
Message-ID: <C54E01DE-E8C2-4542-9521-07D53E2B7A16 at ettus.com>
Content-Type: text/plain; charset="utf-8"

Hi Bahkshi, 


just for understanding purposes: are the TX and the RX antenna on the _same_ USRP?

Generally, I'd like to recommend you take this discussion to the usrp-users maling list (in CC:), because it's not really related to GNU Radio.


Best regards,

Marcus


On 2017-10-26 07:45, Bakshi, Arjun wrote:

I'd like to make a shield for my usrps. I have a significant direct path from the transmitting antenna to the receiving usrp case. I want to eliminate this path and receive only from the rx antenna.


Are there any hacks I can use to make a makeshift rf shield for my usrps? 


Thanks,


AB



_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio at gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171026/d6382051/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5240 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171026/d6382051/attachment-0001.p7s>

------------------------------

Message: 18
Date: Thu, 26 Oct 2017 16:58:24 +0100
From: Derek Kozel <derek.kozel at ettus.com>
To: Brais Ares <bares at gradiant.org>
Cc: usrp-users <usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] Advise on how to modifying HDL design E310
    to add custom blocks
Message-ID:
    <CAA+K=tv3bQaAdV-KpuW_nTVje9wGWBg1H8OawNoktbSnGxaN=A at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello Brais,

Sorry for the long delay. Yes, the B210 has a Spartan 6 which is not
supported by Vivado so the design uses ISE. This, and the smaller size of
the B210's FPGA, is why RFNoC support has not been added to it. All third
generation USRPs support RFNoC and so will all planned future USRPs.

I hope your project is going well and that it is a success.

Regards,
Derek

On Tue, Oct 3, 2017 at 6:22 PM, Brais Ares <bares at gradiant.org> wrote:

> Thank you Derek,
>
> I was playing around with E300 design, but we actually need to use B2X0
> devices, apparently not supported by RFNoC. Also we need to implement some
> complex decimation and filtering so that FIR block will not be enough.
>
> I guess, if I'm not mistaken, our only choice is to use Xilinx ISE to
> modify the hdl design.
>
> Regards,
> Brais.
>
>
>
> 2017-10-03 12:45 GMT+02:00 Derek Kozel <derek.kozel at ettus.com>:
>
>> Hello Brais,
>>
>> The HDL design does have a top block and is composed of usefully divided
>> sub blocks. It is not however designed using the graphical Vivado workflow,
>> but a source based one. Here is the top block:
>> https://github.com/EttusResearch/fpga/blob/maint/usrp3/top/e300/e310.v
>>
>> Your application however sounds exactly like what the RFNoC architecture
>> was designed for. This architecture, which the E310 implements, allows you
>> to add in a self contained block of functional logic wrapped by an
>> interface supplied by Ettus. I recommend reading this application note and
>> possibly watching this video which introduces the architecture and leads
>> through the creation of a sample RFNoC block.
>>
>> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>> https://www.youtube.com/watch?v=j-EfyPVpaJ8
>>
>> If you only want to add a filter or two there is already an FIR block
>> which you could either directly make use of or make hopefully minor
>> modifications to meet your needs.
>> https://github.com/EttusResearch/fpga/blob/6996ed662e5ae170e
>> 60ab8cb6de54c362cecf8d2/usrp3/lib/rfnoc/noc_block_fir_filter.v#L141
>>
>> Regards,
>> Derek
>>
>>
>> On Thu, Sep 21, 2017 at 4:48 PM, Brais Ares via USRP-users <
>> usrp-users at lists.ettus.com> wrote:
>>
>>> Hello,
>>>
>>> We want to add some blocks to HDL design in E310 device. We followed the
>>> instructions to build Vivado project and it worked okay.
>>>
>>> Thing is the built design when opened in Vivado looks this way
>>> <https://www.dropbox.com/s/5w7ari9xlpth4e9/hdl_hierarchy.JPG?dl=0> ...
>>> where design sources hierarchy is kind of complex. I was expecting a top
>>> module or at least not that much sources.
>>>
>>> Is there no way to see the design as a block design (like in a typical
>>> Vivado workflow)?
>>>
>>> Adding just a few filters to this design implies reverse-engineering
>>> what is going on in most of these source files...
>>>
>>> ?Any advice in how to proceed/start is appreciated.
>>> Regards,
>>> Brais.?
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
>
> --
>
> [image: logo_170x100px.png] <http://www.gradiant.org/>
>
> Brais Ares Fern?ndez
> Investigador - Desarrollador | ?rea de Comunicaciones Avanzadas
> Researcher - Developer | Advanced Communications Department
>
> Ph. (+34) 986 120 430 <+34%20986%2012%2004%2030>  Ext. 3019
> bares at gradiant.org  |  www.gradiant.org
>
> [image: Iconos Redes Sociales GRD Firma email-01]
> <https://www.facebook.com/GradiantNews/>  [image: Iconos Redes Sociales
> GRD Firma email-02] <https://twitter.com/Gradiant>  [image: Iconos Redes
> Sociales GRD Firma email-03]
> <https://www.linkedin.com/company-beta/769728>  [image: Iconos Redes
> Sociales GRD Firma email-04]
> <https://www.youtube.com/user/ComunicacionGRD>
> Take care of the environment. Try not to print this email.
> The information contained in this email message may be confidential
> information, and may also be the subject of legal professional privilege.
> If you are not the intended recipient, any use, interference with,
> disclosure or copying of this material is unauthorized and prohibited.
> Please inform us immediately and destroy the email. Thank you for your
> cooperation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171026/37f331a6/attachment-0001.html>

------------------------------

Subject: Digest Footer

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


------------------------------

End of USRP-users Digest, Vol 86, Issue 25
******************************************


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171026/d32d2578/attachment-0002.html>


More information about the USRP-users mailing list