[USRP-users] mimo sync and acceracy

iftah giladi g_iftah at yahoo.com
Sat Sep 6 11:09:15 EDT 2014


Hi Marcus and all,
Thanks for the quick answer.
In your answer you wrote:

>1.       What is the accuracy of this:
>tod = uhd::time_spec_t::get_system_time();
>usrp->set_time_now(tod);

The two USRPs should then be sample-synchronous. However, setting the
time without any trigger is not going to be very exact, give or take
10ms, because the USRP just sets its time when it receives the command.
If you want more accuracy, you need a pulse that will go up at the exact
time you want to set at the PPS input and use set_time_unknown_pps or
one of its sister methods. To be honest, though, when using the system
time, 10ms isn't that much, so "accuracy" is always relative.

And my new question now is:
If I don't have an external source, and I don't use a GPSDO, so were will
that pps will come from?
Actually what you saying if I got you right is that If I want both usrp to
have the same time with accuracy butter then 10msec, then I HAVE to either
use to GPSDO PPS or an external PPS
Or I won't get the accuracy in time between the two usrp, right?

And what if I won't use either? They will still be sample synced right? Only
the time base will be biased, right? 
Plus and that has nothing to do with the time issue the two channel  will
have a phase difference dew to the different PLL who created the A2D clock,
right?

Thanks again,
iftah
 



-----Original Message-----
From: USRP-users [mailto:usrp-users-bounces at lists.ettus.com] On Behalf Of
usrp-users-request at lists.ettus.com
Sent: Friday, September 05, 2014 7:00 PM
To: usrp-users at lists.ettus.com
Subject: USRP-users Digest, Vol 49, Issue 4

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. Not getting white noise in a USRP N210
      (Harold Daniel Moreno Urbina)
   2. Re: Not getting white noise in a USRP N210 (Ian Buckley)
   3. Re: Not getting white noise in a USRP N210 (Marcus M?ller)
   4. Re: Not getting white noise in a USRP N210 (Marcus M?ller)
   5. Re: Not getting white noise in a USRP N210
      (Harold Daniel Moreno Urbina)
   6. Re: Not getting white noise in a USRP N210 (Ian Buckley)
   7. Re: Not getting white noise in a USRP N210 (Marcus M?ller)
   8. Re: Help improving USRP B200 throughput (Jason Heym)
   9. Re: Not getting white noise in a USRP N210
      (Harold Daniel Moreno Urbina)
  10. Re: Not getting white noise in a USRP N210 (Marcus M?ller)
  11. Re: Not getting white noise in a USRP N210 (Marcus D. Leech)
  12. firmware USRP (steven camacho)
  13. Re: How to build customized USRP N2xx FPGA image? (Cheng Chi)
  14. mimo sync and acceracy (iftah giladi)
  15. Re: firmware USRP (Marcus M?ller)
  16. Re: mimo sync and acceracy (Marcus M?ller)
  17. full duplex infinity loop (TSAREGORODTSEV, Yury)
  18. Wireless switch for MIMO? (Cochenour, Brandon M CIV NAWCAD, 4.5.6)
  19. Re: Wireless switch for MIMO? (mleech at ripnet.com)


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

Message: 1
Date: Thu, 4 Sep 2014 13:24:23 -0600
From: Harold Daniel Moreno Urbina <haroldmk at gmail.com>
To: usrp-users at lists.ettus.com
Subject: [USRP-users] Not getting white noise in a USRP N210
Message-ID:
	<CABWUTVzCqDuWS-qMsckrVbe6gORzgSZBd7pV827S4NjSwOt7Mg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello,

When using USRP N210 without an antenna I would expect to receive white
noise, right?. But consistently I am getting signal at center frequency
well over 20 dB compared to other frequencies and 30 or dB over the signals
near the edge.

Anyone knows what is happening here? Is something wrong in the USRP or in
GNU Radio? or me? Thanks.


I am using USRP N210, GNU Radio 3.7.2.1 (version of last friday) over
Ubuntu 14.04.

I uploaded some screenshots of the FFT of the received signal, always
10Msps and getting about 5 minutes of signals. I used the example included
in GNU Radio uhd_fft.grc and a custom flowgraph icluding only a USRP source
and a FFT sink.

----------------------------------------------------
uhd_fft.grc
----------------------------------------------------

center frequency 2.45 GHz:
https://mega.co.nz/#!WFE3UTRZ!AO04usGbl9TBa5-mCUPz7FYW2IabY5nbo5zZqSWwaM4

center frequency 2.42 GHz:
https://mega.co.nz/#!Hc0UzBJA!fSfgScdXPJ_phKdIWUKcNseonlKQt3m64yvYMR0bDhs

----------------------------------------------------
Custom USPR2FFT
----------------------------------------------------

center frequency 2.45 GHz:
https://mega.co.nz/#!Hd9RyApS!FzsY5yxr5e6dJaAAO7Ww2O4BFefyCk6MDPN6ffcOs_g

center frequency 1.80 GHz:
https://mega.co.nz/#!LQcTkDjb!NQ7rIe1PDgRFCp547_U3mhxxxzsvQilPV-esTo7nHa4

center frequency 900 MHz:
https://mega.co.nz/#!eZ1TFbSY!nkt-n1mlC54aFfDwvqoJIJd7-a7gMB2GBLLhyclxxcs

center frequency 300 MHz (out of SBX used operational band):
https://mega.co.nz/#!mJ8EESwR!lI_0r4RvvTncxwwMnpEVAvrwsVhcHzLX7H6C7TA4Cj0
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/201
40904/a9d7fef7/attachment-0001.html>

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

Message: 2
Date: Thu, 4 Sep 2014 12:53:32 -0700
From: Ian Buckley <ianb at ionconcepts.com>
To: Harold Daniel Moreno Urbina <haroldmk at gmail.com>
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Not getting white noise in a USRP N210
Message-ID: <88944504-507E-48E3-A0BF-7E13FD7DFB7E at ionconcepts.com>
Content-Type: text/plain; charset="us-ascii"

Very likely it's a harmonic of the 100MHz clock used extensively in the
N210.
Try tuning to a frequency thats not a factor of 100MHz and see if it is
still there.

On Sep 4, 2014, at 12:24 PM, Harold Daniel Moreno Urbina via USRP-users
<usrp-users at lists.ettus.com> wrote:

> Hello, 
> 
> When using USRP N210 without an antenna I would expect to receive white
noise, right?. But consistently I am getting signal at center frequency well
over 20 dB compared to other frequencies and 30 or dB over the signals near
the edge.
> 
> Anyone knows what is happening here? Is something wrong in the USRP or in
GNU Radio? or me? Thanks.
> 
> 
> I am using USRP N210, GNU Radio 3.7.2.1 (version of last friday) over
Ubuntu 14.04.
> 
> I uploaded some screenshots of the FFT of the received signal, always
10Msps and getting about 5 minutes of signals. I used the example included
in GNU Radio uhd_fft.grc and a custom flowgraph icluding only a USRP source
and a FFT sink.
> 
> ----------------------------------------------------
> uhd_fft.grc
> ----------------------------------------------------
> 
> center frequency 2.45 GHz:
https://mega.co.nz/#!WFE3UTRZ!AO04usGbl9TBa5-mCUPz7FYW2IabY5nbo5zZqSWwaM4
> 
> center frequency 2.42 GHz:
https://mega.co.nz/#!Hc0UzBJA!fSfgScdXPJ_phKdIWUKcNseonlKQt3m64yvYMR0bDhs
> 
> ----------------------------------------------------
> Custom USPR2FFT
> ----------------------------------------------------
> 
> center frequency 2.45 GHz:
https://mega.co.nz/#!Hd9RyApS!FzsY5yxr5e6dJaAAO7Ww2O4BFefyCk6MDPN6ffcOs_g
> 
> center frequency 1.80 GHz:
https://mega.co.nz/#!LQcTkDjb!NQ7rIe1PDgRFCp547_U3mhxxxzsvQilPV-esTo7nHa4
> 
> center frequency 900 MHz:
https://mega.co.nz/#!eZ1TFbSY!nkt-n1mlC54aFfDwvqoJIJd7-a7gMB2GBLLhyclxxcs
> 
> center frequency 300 MHz (out of SBX used operational band):
https://mega.co.nz/#!mJ8EESwR!lI_0r4RvvTncxwwMnpEVAvrwsVhcHzLX7H6C7TA4Cj0
> _______________________________________________
> 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/201
40904/2a33f44f/attachment-0001.html>

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

Message: 3
Date: Thu, 04 Sep 2014 21:55:07 +0200
From: Marcus M?ller <marcus.mueller at ettus.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Not getting white noise in a USRP N210
Message-ID: <5408C39B.70009 at ettus.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi Harold,

>When using USRP N210 without an antenna I would expect to receive white
noise, right?. 

Not really; I'd expect you to see whatever that open port picks up --
which might actually be received by traces on the PCB, connectors...

> But consistently I am getting signal at center frequency
well over 20 dB compared to other frequencies and 30 or dB over the signals
near the edge.
> Anyone knows what is happening here? Is something wrong in the USRP or in
GNU Radio? or me? Thanks.

That would be the local oscillator. Every direct downconversion
architecture suffers from LO leakage; so there's nothing wrong with you,
the USRP, or GNU Radio.

Luckily, the USRPs give you the possibility to construct a
tune_request_t that specifies an RF frequency, where the LO will be, and
an offset, which it uses to digitally shift the signal; see the UHD
doxygen for tune_request_t for further details. An example:

uhd.tune_request(center_freq, rf_freq=(center_freq +
     lo_offset),rf_freq_policy=uhd.tune_request.POLICY_MANUAL)

To elaborate on this: the N210 always samples a 100MHz bandwidth; from
this 100MS/s it only extracts the sampling rate you request (up to
25MS/s, more doesn't fit through Gigabit). Simultaneously, it's able to
digitally shift the baseband signal (multiplication with complex sine)
in frequency to get you the sub-band you actually desire.

With best regards,
Marcus M?ller

On 04.09.2014 21:24, Harold Daniel Moreno Urbina via USRP-users wrote:
> Hello,
>
> When using USRP N210 without an antenna I would expect to receive white
> noise, right?. But consistently I am getting signal at center frequency
> well over 20 dB compared to other frequencies and 30 or dB over the
signals
> near the edge.
>
> Anyone knows what is happening here? Is something wrong in the USRP or in
> GNU Radio? or me? Thanks.
>
>
> I am using USRP N210, GNU Radio 3.7.2.1 (version of last friday) over
> Ubuntu 14.04.
>
> I uploaded some screenshots of the FFT of the received signal, always
> 10Msps and getting about 5 minutes of signals. I used the example included
> in GNU Radio uhd_fft.grc and a custom flowgraph icluding only a USRP
source
> and a FFT sink.
>
> ----------------------------------------------------
> uhd_fft.grc
> ----------------------------------------------------
>
> center frequency 2.45 GHz:
> https://mega.co.nz/#!WFE3UTRZ!AO04usGbl9TBa5-mCUPz7FYW2IabY5nbo5zZqSWwaM4
>
> center frequency 2.42 GHz:
> https://mega.co.nz/#!Hc0UzBJA!fSfgScdXPJ_phKdIWUKcNseonlKQt3m64yvYMR0bDhs
>
> ----------------------------------------------------
> Custom USPR2FFT
> ----------------------------------------------------
>
> center frequency 2.45 GHz:
> https://mega.co.nz/#!Hd9RyApS!FzsY5yxr5e6dJaAAO7Ww2O4BFefyCk6MDPN6ffcOs_g
>
> center frequency 1.80 GHz:
> https://mega.co.nz/#!LQcTkDjb!NQ7rIe1PDgRFCp547_U3mhxxxzsvQilPV-esTo7nHa4
>
> center frequency 900 MHz:
> https://mega.co.nz/#!eZ1TFbSY!nkt-n1mlC54aFfDwvqoJIJd7-a7gMB2GBLLhyclxxcs
>
> center frequency 300 MHz (out of SBX used operational band):
> https://mega.co.nz/#!mJ8EESwR!lI_0r4RvvTncxwwMnpEVAvrwsVhcHzLX7H6C7TA4Cj0
>
>
>
> _______________________________________________
> 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/201
40904/922c72ad/attachment-0001.html>

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

Message: 4
Date: Thu, 04 Sep 2014 21:56:51 +0200
From: Marcus M?ller <marcus.mueller at ettus.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Not getting white noise in a USRP N210
Message-ID: <5408C403.30204 at ettus.com>
Content-Type: text/plain; charset=ISO-8859-1

Ah! I missed the screenshots below; and thus, I agree with Ian. I
thought you were only seeing one peak ... please excuse my premature
reaction!
On 04.09.2014 21:55, Marcus M?ller wrote:
> Hi Harold,
>
>> When using USRP N210 without an antenna I would expect to receive white
> noise, right?. 
>
> Not really; I'd expect you to see whatever that open port picks up --
> which might actually be received by traces on the PCB, connectors...
>
>> But consistently I am getting signal at center frequency
> well over 20 dB compared to other frequencies and 30 or dB over the
signals
> near the edge.
>> Anyone knows what is happening here? Is something wrong in the USRP or in
> GNU Radio? or me? Thanks.
>
> That would be the local oscillator. Every direct downconversion
> architecture suffers from LO leakage; so there's nothing wrong with you,
> the USRP, or GNU Radio.
>
> Luckily, the USRPs give you the possibility to construct a
> tune_request_t that specifies an RF frequency, where the LO will be, and
> an offset, which it uses to digitally shift the signal; see the UHD
> doxygen for tune_request_t for further details. An example:
>
> uhd.tune_request(center_freq, rf_freq=(center_freq +
>      lo_offset),rf_freq_policy=uhd.tune_request.POLICY_MANUAL)
>
> To elaborate on this: the N210 always samples a 100MHz bandwidth; from
> this 100MS/s it only extracts the sampling rate you request (up to
> 25MS/s, more doesn't fit through Gigabit). Simultaneously, it's able to
> digitally shift the baseband signal (multiplication with complex sine)
> in frequency to get you the sub-band you actually desire.
>
> With best regards,
> Marcus M?ller
>
> On 04.09.2014 21:24, Harold Daniel Moreno Urbina via USRP-users wrote:
>> Hello,
>>
>> When using USRP N210 without an antenna I would expect to receive white
>> noise, right?. But consistently I am getting signal at center frequency
>> well over 20 dB compared to other frequencies and 30 or dB over the
signals
>> near the edge.
>>
>> Anyone knows what is happening here? Is something wrong in the USRP or in
>> GNU Radio? or me? Thanks.
>>
>>
>> I am using USRP N210, GNU Radio 3.7.2.1 (version of last friday) over
>> Ubuntu 14.04.
>>
>> I uploaded some screenshots of the FFT of the received signal, always
>> 10Msps and getting about 5 minutes of signals. I used the example
included
>> in GNU Radio uhd_fft.grc and a custom flowgraph icluding only a USRP
source
>> and a FFT sink.
>>
>> ----------------------------------------------------
>> uhd_fft.grc
>> ----------------------------------------------------
>>
>> center frequency 2.45 GHz:
>> https://mega.co.nz/#!WFE3UTRZ!AO04usGbl9TBa5-mCUPz7FYW2IabY5nbo5zZqSWwaM4
>>
>> center frequency 2.42 GHz:
>> https://mega.co.nz/#!Hc0UzBJA!fSfgScdXPJ_phKdIWUKcNseonlKQt3m64yvYMR0bDhs
>>
>> ----------------------------------------------------
>> Custom USPR2FFT
>> ----------------------------------------------------
>>
>> center frequency 2.45 GHz:
>> https://mega.co.nz/#!Hd9RyApS!FzsY5yxr5e6dJaAAO7Ww2O4BFefyCk6MDPN6ffcOs_g
>>
>> center frequency 1.80 GHz:
>> https://mega.co.nz/#!LQcTkDjb!NQ7rIe1PDgRFCp547_U3mhxxxzsvQilPV-esTo7nHa4
>>
>> center frequency 900 MHz:
>> https://mega.co.nz/#!eZ1TFbSY!nkt-n1mlC54aFfDwvqoJIJd7-a7gMB2GBLLhyclxxcs
>>
>> center frequency 300 MHz (out of SBX used operational band):
>> https://mega.co.nz/#!mJ8EESwR!lI_0r4RvvTncxwwMnpEVAvrwsVhcHzLX7H6C7TA4Cj0
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>




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

Message: 5
Date: Thu, 4 Sep 2014 14:04:33 -0600
From: Harold Daniel Moreno Urbina <haroldmk at gmail.com>
To: Ian Buckley <ianb at ionconcepts.com>
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Not getting white noise in a USRP N210
Message-ID:
	<CABWUTVx9P0i=hxz3D==n18ZO-WwDBoh-ocUFHbnQy10DN2b9Zg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

But neither 2.45 GHz nor 2.42 GHz are factor of 100 MHz. The other
frequencies used are (1.8 GHz, 900 and 300 MHz).


2014-09-04 13:53 GMT-06:00 Ian Buckley <ianb at ionconcepts.com>:

> Very likely it's a harmonic of the 100MHz clock used extensively in the
> N210.
> Try tuning to a frequency thats not a factor of 100MHz and see if it is
> still there.
>
> On Sep 4, 2014, at 12:24 PM, Harold Daniel Moreno Urbina via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
> Hello,
>
> When using USRP N210 without an antenna I would expect to receive white
> noise, right?. But consistently I am getting signal at center frequency
> well over 20 dB compared to other frequencies and 30 or dB over the
signals
> near the edge.
>
> Anyone knows what is happening here? Is something wrong in the USRP or in
> GNU Radio? or me? Thanks.
>
>
> I am using USRP N210, GNU Radio 3.7.2.1 (version of last friday) over
> Ubuntu 14.04.
>
> I uploaded some screenshots of the FFT of the received signal, always
> 10Msps and getting about 5 minutes of signals. I used the example included
> in GNU Radio uhd_fft.grc and a custom flowgraph icluding only a USRP
source
> and a FFT sink.
>
> ----------------------------------------------------
> uhd_fft.grc
> ----------------------------------------------------
>
> center frequency 2.45 GHz:
> https://mega.co.nz/#!WFE3UTRZ!AO04usGbl9TBa5-mCUPz7FYW2IabY5nbo5zZqSWwaM4
>
> center frequency 2.42 GHz:
> https://mega.co.nz/#!Hc0UzBJA!fSfgScdXPJ_phKdIWUKcNseonlKQt3m64yvYMR0bDhs
>
> ----------------------------------------------------
> Custom USPR2FFT
> ----------------------------------------------------
>
> center frequency 2.45 GHz:
> https://mega.co.nz/#!Hd9RyApS!FzsY5yxr5e6dJaAAO7Ww2O4BFefyCk6MDPN6ffcOs_g
>
> center frequency 1.80 GHz:
> https://mega.co.nz/#!LQcTkDjb!NQ7rIe1PDgRFCp547_U3mhxxxzsvQilPV-esTo7nHa4
>
> center frequency 900 MHz:
> https://mega.co.nz/#!eZ1TFbSY!nkt-n1mlC54aFfDwvqoJIJd7-a7gMB2GBLLhyclxxcs
>
> center frequency 300 MHz (out of SBX used operational band):
> https://mega.co.nz/#!mJ8EESwR!lI_0r4RvvTncxwwMnpEVAvrwsVhcHzLX7H6C7TA4Cj0
>  _______________________________________________
> 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/201
40904/95982a2d/attachment-0001.html>

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

Message: 6
Date: Thu, 4 Sep 2014 13:12:31 -0700
From: Ian Buckley <ianb at ionconcepts.com>
To: Harold Daniel Moreno Urbina <haroldmk at gmail.com>
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Not getting white noise in a USRP N210
Message-ID: <31AB188C-9DAE-43C3-AC53-1F548ADE6E2C at ionconcepts.com>
Content-Type: text/plain; charset="us-ascii"

Good point, I answered that very quickly without looking at the downloads.
Do you understand Marcus's point about direct conversion architectures? It
was perhaps more appropriate.



On Sep 4, 2014, at 1:04 PM, Harold Daniel Moreno Urbina <haroldmk at gmail.com>
wrote:

> But neither 2.45 GHz nor 2.42 GHz are factor of 100 MHz. The other
frequencies used are (1.8 GHz, 900 and 300 MHz).
> 
> 
> 2014-09-04 13:53 GMT-06:00 Ian Buckley <ianb at ionconcepts.com>:
> Very likely it's a harmonic of the 100MHz clock used extensively in the
N210.
> Try tuning to a frequency thats not a factor of 100MHz and see if it is
still there.
> 
> On Sep 4, 2014, at 12:24 PM, Harold Daniel Moreno Urbina via USRP-users
<usrp-users at lists.ettus.com> wrote:
> 
>> Hello, 
>> 
>> When using USRP N210 without an antenna I would expect to receive white
noise, right?. But consistently I am getting signal at center frequency well
over 20 dB compared to other frequencies and 30 or dB over the signals near
the edge.
>> 
>> Anyone knows what is happening here? Is something wrong in the USRP or in
GNU Radio? or me? Thanks.
>> 
>> 
>> I am using USRP N210, GNU Radio 3.7.2.1 (version of last friday) over
Ubuntu 14.04.
>> 
>> I uploaded some screenshots of the FFT of the received signal, always
10Msps and getting about 5 minutes of signals. I used the example included
in GNU Radio uhd_fft.grc and a custom flowgraph icluding only a USRP source
and a FFT sink.
>> 
>> ----------------------------------------------------
>> uhd_fft.grc
>> ----------------------------------------------------
>> 
>> center frequency 2.45 GHz:
https://mega.co.nz/#!WFE3UTRZ!AO04usGbl9TBa5-mCUPz7FYW2IabY5nbo5zZqSWwaM4
>> 
>> center frequency 2.42 GHz:
https://mega.co.nz/#!Hc0UzBJA!fSfgScdXPJ_phKdIWUKcNseonlKQt3m64yvYMR0bDhs
>> 
>> ----------------------------------------------------
>> Custom USPR2FFT
>> ----------------------------------------------------
>> 
>> center frequency 2.45 GHz:
https://mega.co.nz/#!Hd9RyApS!FzsY5yxr5e6dJaAAO7Ww2O4BFefyCk6MDPN6ffcOs_g
>> 
>> center frequency 1.80 GHz:
https://mega.co.nz/#!LQcTkDjb!NQ7rIe1PDgRFCp547_U3mhxxxzsvQilPV-esTo7nHa4
>> 
>> center frequency 900 MHz:
https://mega.co.nz/#!eZ1TFbSY!nkt-n1mlC54aFfDwvqoJIJd7-a7gMB2GBLLhyclxxcs
>> 
>> center frequency 300 MHz (out of SBX used operational band):
https://mega.co.nz/#!mJ8EESwR!lI_0r4RvvTncxwwMnpEVAvrwsVhcHzLX7H6C7TA4Cj0
>> _______________________________________________
>> 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/201
40904/f72ce13f/attachment-0001.html>

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

Message: 7
Date: Thu, 04 Sep 2014 22:33:12 +0200
From: Marcus M?ller <marcus.mueller at ettus.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Not getting white noise in a USRP N210
Message-ID: <5408CC88.9000501 at ettus.com>
Content-Type: text/plain; charset="iso-8859-1"

About the pictures: Would you mind uploading them somewhere else? It
really takes ages for me to see a single one, and it blocks parallely
waiting for multiples, so I must admit I only saw the first two before I
gave up. Maybe imgur.com?

Greetings,
Marcus
On 04.09.2014 22:12, Ian Buckley via USRP-users wrote:
> Good point, I answered that very quickly without looking at the downloads.
Do you understand Marcus's point about direct conversion architectures? It
was perhaps more appropriate.
>
>
>
> On Sep 4, 2014, at 1:04 PM, Harold Daniel Moreno Urbina
<haroldmk at gmail.com> wrote:
>
>> But neither 2.45 GHz nor 2.42 GHz are factor of 100 MHz. The other
frequencies used are (1.8 GHz, 900 and 300 MHz).
>>
>>
>> 2014-09-04 13:53 GMT-06:00 Ian Buckley <ianb at ionconcepts.com>:
>> Very likely it's a harmonic of the 100MHz clock used extensively in the
N210.
>> Try tuning to a frequency thats not a factor of 100MHz and see if it is
still there.
>>
>> On Sep 4, 2014, at 12:24 PM, Harold Daniel Moreno Urbina via USRP-users
<usrp-users at lists.ettus.com> wrote:
>>
>>> Hello, 
>>>
>>> When using USRP N210 without an antenna I would expect to receive white
noise, right?. But consistently I am getting signal at center frequency well
over 20 dB compared to other frequencies and 30 or dB over the signals near
the edge.
>>>
>>> Anyone knows what is happening here? Is something wrong in the USRP or
in GNU Radio? or me? Thanks.
>>>
>>>
>>> I am using USRP N210, GNU Radio 3.7.2.1 (version of last friday) over
Ubuntu 14.04.
>>>
>>> I uploaded some screenshots of the FFT of the received signal, always
10Msps and getting about 5 minutes of signals. I used the example included
in GNU Radio uhd_fft.grc and a custom flowgraph icluding only a USRP source
and a FFT sink.
>>>
>>> ----------------------------------------------------
>>> uhd_fft.grc
>>> ----------------------------------------------------
>>>
>>> center frequency 2.45 GHz:
https://mega.co.nz/#!WFE3UTRZ!AO04usGbl9TBa5-mCUPz7FYW2IabY5nbo5zZqSWwaM4
>>>
>>> center frequency 2.42 GHz:
https://mega.co.nz/#!Hc0UzBJA!fSfgScdXPJ_phKdIWUKcNseonlKQt3m64yvYMR0bDhs
>>>
>>> ----------------------------------------------------
>>> Custom USPR2FFT
>>> ----------------------------------------------------
>>>
>>> center frequency 2.45 GHz:
https://mega.co.nz/#!Hd9RyApS!FzsY5yxr5e6dJaAAO7Ww2O4BFefyCk6MDPN6ffcOs_g
>>>
>>> center frequency 1.80 GHz:
https://mega.co.nz/#!LQcTkDjb!NQ7rIe1PDgRFCp547_U3mhxxxzsvQilPV-esTo7nHa4
>>>
>>> center frequency 900 MHz:
https://mega.co.nz/#!eZ1TFbSY!nkt-n1mlC54aFfDwvqoJIJd7-a7gMB2GBLLhyclxxcs
>>>
>>> center frequency 300 MHz (out of SBX used operational band):
https://mega.co.nz/#!mJ8EESwR!lI_0r4RvvTncxwwMnpEVAvrwsVhcHzLX7H6C7TA4Cj0
>>> _______________________________________________
>>> 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 --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/201
40904/fbb600db/attachment-0001.html>

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

Message: 8
Date: Thu, 4 Sep 2014 15:57:53 -0500
From: Jason Heym <jpheym at gmail.com>
To: usrp-users <usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] Help improving USRP B200 throughput
Message-ID:
	<CAK4g06snboirWj=X_794KMRAQ6WVmrYi7YYj4ApEFXyJsi0PBg at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Bumping this thread...

Any suggestions?

On Fri, Aug 29, 2014 at 6:47 PM, Jason Heym <jpheym at gmail.com> wrote:
> I have been testing a recently-purchased USRP B200 with an Asus G750
laptop.
>
> My goal is full duplex 32 million samples/second TX and RX.
> Reliability is very important. This is for some radar experiments that
> need maximum TX and RX bandwidth continuously for periods of several
> minutes.
>
> Please see the attached test results.
>
> Note I'm doing TX and RX of 50M samples for each run. So each run
> represents a few seconds of TX and RX. Fewer samples per run will have
> less chance of interruption and produce higher success rates. But my
> goal is interruption-free operation over at least a few minutes.
>
> Basically for 2 to 8 MSPS symmetric (TX and RX) reliability is around
> 50% to 60%. At 16 MSPS reliability drops to 25%. At 32 MSPS there is
> total failure. Reducing the RX data rate while keeping the TX rate
> fixed can improve success rates. However the opposite (reducing TX
> data rate and keeping RX fixed) does not help. I do need symmetric
> data rates.
>
> What can I do to improve the throughput or better diagnose and address
> the problem?
>
> I prefer a laptop for portable / field operation. This laptop performs
> well with a Point Grey Grasshopper3 USB 3.0 camera, achieving 350
> MB/second error-free for extended periods (a few hours). Obviously
> this is mostly camera-to-host throughput, not symmetric full duplex.
>
> The B200 and AD9361 have enormous potential. I just need to improve
> the throughput situation. I recognize that USB 3.0 SuperSpeed has its
> challenges, probably especially for full-duplex symmetric throughput.
>
> Thank you!
> Jason Heym



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

Message: 9
Date: Thu, 4 Sep 2014 15:02:53 -0600
From: Harold Daniel Moreno Urbina <haroldmk at gmail.com>
To: Marcus M?ller <marcus.mueller at ettus.com>
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Not getting white noise in a USRP N210
Message-ID:
	<CABWUTVw17T0qaXURoZgLSni2pj2kDsb4ZAy374PiR554rWKbng at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Sure Marcus,

----------------------------------------------------
uhd_fft.grc
----------------------------------------------------

center frequency 2.45 GHz: *http://imgur.com/mmsdO0v
<http://imgur.com/mmsdO0v>*

center frequency 2.42 GHz: *http://imgur.com/K526vsc
<http://imgur.com/K526vsc>*

----------------------------------------------------
Custom USPR2FFT
----------------------------------------------------

center frequency 2.45 GHz: *http://imgur.com/3Ukz1F8
<http://imgur.com/3Ukz1F8>*

center frequency 1.80 GHz: *http://imgur.com/CkZsFyN
<http://imgur.com/CkZsFyN>*

center frequency 900 MHz: *http://imgur.com/MfVe34m
<http://imgur.com/MfVe34m>*

center frequency 300 MHz (out of SBX used operational band):
*http://imgur.com/zSlv6PD
<http://imgur.com/zSlv6PD>*


----------------------------------------------------
Tried with other frequencies and sample rate
I looked to have a center frequency not a factor
of sample rate
----------------------------------------------------

Center freqency 452 MHz, Sample Rate 9 MSps: http://imgur.com/oLgXmqN

Center freqency 2759 MHz, Sample Rate 9 MSps: http://imgur.com/edysiBb


----------------------------------------------------
I used a second USRP N210
----------------------------------------------------

Center freqency 2759 MHz, Sample Rate 9 MSps: http://imgur.com/pwFFCPB

Center freqency 2760 MHz, Sample Rate 9 MSps: http://imgur.com/NrBbugz

Center freqency 2760 MHz, Sample Rate 10 MSps: http://imgur.com/2NTmi2f

Center freqency 2760 MHz, Sample Rate 10 MSps: http://imgur.com/CZ4oHOF


I can see that when I use 10 MSps the signals is much more flat than the
signals captured with 9 or 11 MSps.



2014-09-04 14:33 GMT-06:00 Marcus M?ller <usrp-users at lists.ettus.com>:

>  About the pictures: Would you mind uploading them somewhere else? It
> really takes ages for me to see a single one, and it blocks parallely
> waiting for multiples, so I must admit I only saw the first two before I
> gave up. Maybe imgur.com?
>
> Greetings,
> Marcus
>
> On 04.09.2014 22:12, Ian Buckley via USRP-users wrote:
>
> Good point, I answered that very quickly without looking at the downloads.
Do you understand Marcus's point about direct conversion architectures? It
was perhaps more appropriate.
>
>
>
> On Sep 4, 2014, at 1:04 PM, Harold Daniel Moreno Urbina
<haroldmk at gmail.com> <haroldmk at gmail.com> wrote:
>
>
>  But neither 2.45 GHz nor 2.42 GHz are factor of 100 MHz. The other
frequencies used are (1.8 GHz, 900 and 300 MHz).
>
>
> 2014-09-04 13:53 GMT-06:00 Ian Buckley <ianb at ionconcepts.com>
<ianb at ionconcepts.com>:
> Very likely it's a harmonic of the 100MHz clock used extensively in the
N210.
> Try tuning to a frequency thats not a factor of 100MHz and see if it is
still there.
>
> On Sep 4, 2014, at 12:24 PM, Harold Daniel Moreno Urbina via USRP-users
<usrp-users at lists.ettus.com> <usrp-users at lists.ettus.com> wrote:
>
>
>  Hello,
>
> When using USRP N210 without an antenna I would expect to receive white
noise, right?. But consistently I am getting signal at center frequency well
over 20 dB compared to other frequencies and 30 or dB over the signals near
the edge.
>
> Anyone knows what is happening here? Is something wrong in the USRP or in
GNU Radio? or me? Thanks.
>
>
> I am using USRP N210, GNU Radio 3.7.2.1 (version of last friday) over
Ubuntu 14.04.
>
> I uploaded some screenshots of the FFT of the received signal, always
10Msps and getting about 5 minutes of signals. I used the example included
in GNU Radio uhd_fft.grc and a custom flowgraph icluding only a USRP source
and a FFT sink.
>
> ----------------------------------------------------
> uhd_fft.grc
> ----------------------------------------------------
>
> center frequency 2.45 GHz:
https://mega.co.nz/#!WFE3UTRZ!AO04usGbl9TBa5-mCUPz7FYW2IabY5nbo5zZqSWwaM4
>
> center frequency 2.42 GHz:
https://mega.co.nz/#!Hc0UzBJA!fSfgScdXPJ_phKdIWUKcNseonlKQt3m64yvYMR0bDhs
>
> ----------------------------------------------------
> Custom USPR2FFT
> ----------------------------------------------------
>
> center frequency 2.45 GHz:
https://mega.co.nz/#!Hd9RyApS!FzsY5yxr5e6dJaAAO7Ww2O4BFefyCk6MDPN6ffcOs_g
>
> center frequency 1.80 GHz:
https://mega.co.nz/#!LQcTkDjb!NQ7rIe1PDgRFCp547_U3mhxxxzsvQilPV-esTo7nHa4
>
> center frequency 900 MHz:
https://mega.co.nz/#!eZ1TFbSY!nkt-n1mlC54aFfDwvqoJIJd7-a7gMB2GBLLhyclxxcs
>
> center frequency 300 MHz (out of SBX used operational band):
https://mega.co.nz/#!mJ8EESwR!lI_0r4RvvTncxwwMnpEVAvrwsVhcHzLX7H6C7TA4Cj0
> _______________________________________________
> USRP-users mailing
listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-u
sers_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing
listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-u
sers_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 --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/201
40904/2dbb38b8/attachment-0001.html>

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

Message: 10
Date: Fri, 05 Sep 2014 00:01:20 +0200
From: Marcus M?ller <marcus.mueller at ettus.com>
To: Harold Daniel Moreno Urbina <haroldmk at gmail.com>
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Not getting white noise in a USRP N210
Message-ID: <5408E130.5010405 at ettus.com>
Content-Type: text/plain; charset=UTF-8

Hi Harold,
Thanks! Let me comment on this.

On 04.09.2014 23:02, Harold Daniel Moreno Urbina wrote:
> Sure Marcus,
>
> ----------------------------------------------------
> uhd_fft.grc
> ----------------------------------------------------
>
> center frequency 2.45 GHz: *http://imgur.com/mmsdO0v
> <http://imgur.com/mmsdO0v>*
Not too sure what to make of this, but I'll come back to it later
>
> center frequency 2.42 GHz: *http://imgur.com/K526vsc
> <http://imgur.com/K526vsc>*
This is the classical LO leakage: Incredibly sharp, centered at the RF
frequency.
>
> ----------------------------------------------------
> Custom USPR2FFT
> ----------------------------------------------------
>
> center frequency 2.45 GHz: *http://imgur.com/3Ukz1F8
> <http://imgur.com/3Ukz1F8>*
>
> center frequency 1.80 GHz: *http://imgur.com/CkZsFyN
> <http://imgur.com/CkZsFyN>*
>
> center frequency 900 MHz: *http://imgur.com/MfVe34m
> <http://imgur.com/MfVe34m>*
>
> center frequency 300 MHz (out of SBX used operational band):
> *http://imgur.com/zSlv6PD
> <http://imgur.com/zSlv6PD>*
These look pretty clean to me, nicely located LO leakage. I don't know
what exactly happened when you set the frequency to 300MHz, but UHD
won't let you do that, because it's physically impossible, so it usually
prints a warning saying what it tuned to instead.
>
> ----------------------------------------------------
> Tried with other frequencies and sample rate
> I looked to have a center frequency not a factor
> of sample rate
> ----------------------------------------------------
>
> Center freqency 452 MHz, Sample Rate 9 MSps: http://imgur.com/oLgXmqN
>
> Center freqency 2759 MHz, Sample Rate 9 MSps: http://imgur.com/edysiBb
On the N210, sampling rates must be integer fractions of the 100MHz
master clock rate.
Most probably, UHD prints a warning telling you that it used an adjacent
possible rate -- 10MHz or 9.0909..MHz or so.

But that aside, that's very plausible.
So tuning with a N210 happens in two steps:
1. The driver looks up a frequency that the LO synthesizer can
physically generate, and configures it accordingly,
2. The FPGA eliminates the remaining frequency offset by multiplication
with exp(2*pi*j*delta_f*n) digitally.

So, for some frequencies, the LO is right in the middle where you see it
in all of your screenshots, for others, that can not be the case.
Actually, the synth of the SBX is quite flexible and you most probably
won't be able to distinguish between the target frequency hitting a
physically possible LO frequency, and the target frequency being right
in the middle between two possible LO frequencies at your spectral
resolution.

So, this explains why the LO can be completely shifted out of your 10MHz
bandwidth: just manually specify that you want to tune with an |offset|
> bandwidth/2, and the LO will be out of band.

Comparing the 452 and 2759 MHZ spectra reveals that they look really
really much alike (which is really comforting to me) but that 2.7GHz
spectrum is about 4dB lower -- which doesn't surprise much, considering
that nothing analog really works exactly frequency-independent. So this
is actually a sign for the USRP being a nice platform, and the SBX being
a sensitive analog frontend with a wideband input with only little
distortion.
> ----------------------------------------------------
> I used a second USRP N210
> ----------------------------------------------------
>
> Center freqency 2759 MHz, Sample Rate 9 MSps: http://imgur.com/pwFFCPB
>
> Center freqency 2760 MHz, Sample Rate 9 MSps: http://imgur.com/NrBbugz
>
> Center freqency 2760 MHz, Sample Rate 10 MSps: http://imgur.com/2NTmi2f
>
> Center freqency 2760 MHz, Sample Rate 10 MSps: http://imgur.com/CZ4oHOF
>
>
> I can see that when I use 10 MSps the signals is much more flat than the
> signals captured with 9 or 11 MSps.
That could be the CIC filter's rolloff that you can only see with odd
decimations (10MS/p is 1/10 of the 100MHz master clock rate, 9.091MS/s
is 1/11).
Maybe that's again where Ian could throw in his experience

Greetings,
Marcus


PS: regarding the first picture: yes, there are more peaks than the LO,
but they seem to be so random and the current PSD seems so uncorrelated
that I daresay that I cannot say anything.
> 2014-09-04 14:33 GMT-06:00 Marcus M?ller <usrp-users at lists.ettus.com>:
>
>>  About the pictures: Would you mind uploading them somewhere else? It
>> really takes ages for me to see a single one, and it blocks parallely
>> waiting for multiples, so I must admit I only saw the first two before I
>> gave up. Maybe imgur.com?
>>
>> Greetings,
>> Marcus
>>
>> On 04.09.2014 22:12, Ian Buckley via USRP-users wrote:
>>
>> Good point, I answered that very quickly without looking at the
downloads. Do you understand Marcus's point about direct conversion
architectures? It was perhaps more appropriate.
>>
>>
>>
>> On Sep 4, 2014, at 1:04 PM, Harold Daniel Moreno Urbina
<haroldmk at gmail.com> <haroldmk at gmail.com> wrote:
>>
>>
>>  But neither 2.45 GHz nor 2.42 GHz are factor of 100 MHz. The other
frequencies used are (1.8 GHz, 900 and 300 MHz).
>>
>>
>> 2014-09-04 13:53 GMT-06:00 Ian Buckley <ianb at ionconcepts.com>
<ianb at ionconcepts.com>:
>> Very likely it's a harmonic of the 100MHz clock used extensively in the
N210.
>> Try tuning to a frequency thats not a factor of 100MHz and see if it is
still there.
>>
>> On Sep 4, 2014, at 12:24 PM, Harold Daniel Moreno Urbina via USRP-users
<usrp-users at lists.ettus.com> <usrp-users at lists.ettus.com> wrote:
>>
>>
>>  Hello,
>>
>> When using USRP N210 without an antenna I would expect to receive white
noise, right?. But consistently I am getting signal at center frequency well
over 20 dB compared to other frequencies and 30 or dB over the signals near
the edge.
>>
>> Anyone knows what is happening here? Is something wrong in the USRP or in
GNU Radio? or me? Thanks.
>>
>>
>> I am using USRP N210, GNU Radio 3.7.2.1 (version of last friday) over
Ubuntu 14.04.
>>
>> I uploaded some screenshots of the FFT of the received signal, always
10Msps and getting about 5 minutes of signals. I used the example included
in GNU Radio uhd_fft.grc and a custom flowgraph icluding only a USRP source
and a FFT sink.
>>
>> ----------------------------------------------------
>> uhd_fft.grc
>> ----------------------------------------------------
>>
>> center frequency 2.45 GHz:
https://mega.co.nz/#!WFE3UTRZ!AO04usGbl9TBa5-mCUPz7FYW2IabY5nbo5zZqSWwaM4
>>
>> center frequency 2.42 GHz:
https://mega.co.nz/#!Hc0UzBJA!fSfgScdXPJ_phKdIWUKcNseonlKQt3m64yvYMR0bDhs
>>
>> ----------------------------------------------------
>> Custom USPR2FFT
>> ----------------------------------------------------
>>
>> center frequency 2.45 GHz:
https://mega.co.nz/#!Hd9RyApS!FzsY5yxr5e6dJaAAO7Ww2O4BFefyCk6MDPN6ffcOs_g
>>
>> center frequency 1.80 GHz:
https://mega.co.nz/#!LQcTkDjb!NQ7rIe1PDgRFCp547_U3mhxxxzsvQilPV-esTo7nHa4
>>
>> center frequency 900 MHz:
https://mega.co.nz/#!eZ1TFbSY!nkt-n1mlC54aFfDwvqoJIJd7-a7gMB2GBLLhyclxxcs
>>
>> center frequency 300 MHz (out of SBX used operational band):
https://mega.co.nz/#!mJ8EESwR!lI_0r4RvvTncxwwMnpEVAvrwsVhcHzLX7H6C7TA4Cj0
>> _______________________________________________
>> USRP-users mailing
listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-u
sers_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing
listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-u
sers_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>




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

Message: 11
Date: Thu, 04 Sep 2014 22:23:50 -0400
From: "Marcus D. Leech" <mleech at ripnet.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Not getting white noise in a USRP N210
Message-ID: <54091EB6.3050302 at ripnet.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

On 09/04/2014 04:33 PM, Marcus M?ller via USRP-users wrote:
> About the pictures: Would you mind uploading them somewhere else? It 
> really takes ages for me to see a single one, and it blocks parallely 
> waiting for multiples, so I must admit I only saw the first two before 
> I gave up. Maybe imgur.com?
>
> Greetings,
> Marcus
Also, if the input isn't terminated, it's not getting precisely thermal 
noise.  An open connector is like a little tiny, inefficient antenna, so 
there'll
   be some lumpiness in the spectral distribution that isn't random.


> On 04.09.2014 22:12, Ian Buckley via USRP-users wrote:
>> Good point, I answered that very quickly without looking at the
downloads. Do you understand Marcus's point about direct conversion
architectures? It was perhaps more appropriate.
>>
>>
>>
>> On Sep 4, 2014, at 1:04 PM, Harold Daniel Moreno
Urbina<haroldmk at gmail.com>  wrote:
>>
>>> But neither 2.45 GHz nor 2.42 GHz are factor of 100 MHz. The other
frequencies used are (1.8 GHz, 900 and 300 MHz).
>>>
>>>
>>> 2014-09-04 13:53 GMT-06:00 Ian Buckley<ianb at ionconcepts.com>:
>>> Very likely it's a harmonic of the 100MHz clock used extensively in the
N210.
>>> Try tuning to a frequency thats not a factor of 100MHz and see if it is
still there.
>>>
>>> On Sep 4, 2014, at 12:24 PM, Harold Daniel Moreno Urbina via
USRP-users<usrp-users at lists.ettus.com>  wrote:
>>>
>>>> Hello,
>>>>
>>>> When using USRP N210 without an antenna I would expect to receive white
noise, right?. But consistently I am getting signal at center frequency well
over 20 dB compared to other frequencies and 30 or dB over the signals near
the edge.
>>>>
>>>> Anyone knows what is happening here? Is something wrong in the USRP or
in GNU Radio? or me? Thanks.
>>>>
>>>>
>>>> I am using USRP N210, GNU Radio 3.7.2.1 (version of last friday) over
Ubuntu 14.04.
>>>>
>>>> I uploaded some screenshots of the FFT of the received signal, always
10Msps and getting about 5 minutes of signals. I used the example included
in GNU Radio uhd_fft.grc and a custom flowgraph icluding only a USRP source
and a FFT sink.
>>>>
>>>> ----------------------------------------------------
>>>> uhd_fft.grc
>>>> ----------------------------------------------------
>>>>
>>>> center frequency 2.45
GHz:https://mega.co.nz/#!WFE3UTRZ!AO04usGbl9TBa5-mCUPz7FYW2IabY5nbo5zZqSWwaM
4
>>>>
>>>> center frequency 2.42
GHz:https://mega.co.nz/#!Hc0UzBJA!fSfgScdXPJ_phKdIWUKcNseonlKQt3m64yvYMR0bDh
s
>>>>
>>>> ----------------------------------------------------
>>>> Custom USPR2FFT
>>>> ----------------------------------------------------
>>>>
>>>> center frequency 2.45
GHz:https://mega.co.nz/#!Hd9RyApS!FzsY5yxr5e6dJaAAO7Ww2O4BFefyCk6MDPN6ffcOs_
g
>>>>
>>>> center frequency 1.80
GHz:https://mega.co.nz/#!LQcTkDjb!NQ7rIe1PDgRFCp547_U3mhxxxzsvQilPV-esTo7nHa
4
>>>>
>>>> center frequency 900
MHz:https://mega.co.nz/#!eZ1TFbSY!nkt-n1mlC54aFfDwvqoJIJd7-a7gMB2GBLLhyclxxc
s
>>>>
>>>> center frequency 300 MHz (out of SBX used operational
band):https://mega.co.nz/#!mJ8EESwR!lI_0r4RvvTncxwwMnpEVAvrwsVhcHzLX7H6C7TA4
Cj0
>>>> _______________________________________________
>>>> 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
>
>
>
> _______________________________________________
> 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/201
40904/e952770c/attachment-0001.html>

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

Message: 12
Date: Thu, 4 Sep 2014 21:51:04 -0500
From: steven camacho <stevenacamacho at hotmail.com>
To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: [USRP-users] firmware USRP
Message-ID: <SNT146-W34EBE7569496472009DE1BDBC20 at phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"

I want to know if i can change the code of firmware, and if possible in
which is the programming language of the firmware
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/201
40904/46e43264/attachment-0001.html>

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

Message: 13
Date: Fri, 5 Sep 2014 13:33:49 +0800
From: Cheng Chi <ch0004hi at e.ntu.edu.sg>
To: Ian Buckley <ianb at ionconcepts.com>
Cc: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: Re: [USRP-users] How to build customized USRP N2xx FPGA
	image?
Message-ID:
	<CAJeUUe5y-kGw-cUdaF5StZBxNMpMvjs2h9REB5Y1Y5=uCVj5ow at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi,

I switched to another computer with 32-bit Ubuntu 10.04 LTS and ISE 12.1.
The build process is successful.

Best regards,
Cheng Chi


On Wed, Sep 3, 2014 at 2:01 PM, Cheng Chi <ch0004hi at e.ntu.edu.sg> wrote:

> Hi Ian,
>
> The custom module I am including:
> https://gist.github.com/anonymous/2ac26c650ff3b87b6c61
>
> The makefile I am using:
> https://gist.github.com/anonymous/13d361d0e63133754ff9
>
> The shell output:
> https://gist.github.com/anonymous/67f7a221032f7fbba749
>
> The build.log:
> https://gist.github.com/anonymous/f4b1133e538f84668256
>
> Bash script I am using:
> ```
> #! /bin/bash
>
> export LM_LICENSE_FILE=/home/usrp/Downloads/Xilinx.lic
> export XILINXD_LICENSE_FILE=/home/usrp/Downloads/Xilinx.lic
>
> cd /opt/Xilinx/12.2/ISE_DS
> source ./settings64.sh     # sets up path and other shell variables
>
> LD_LIBRARY_PATH=/usr/lib:/lib:${LD_LIBRARY_PATH}
>
> cd /home/usrp/uhd/fpga/usrp2/top/N2x0
> make -f Makefile.custom 2>&1 | tee logfile
> ```
>
> I didn't write any custom module, all the files were from UHD source
> files. I have no problem sharing the code you need.
>
> Best regards,
> Cheng Chi
>
>
>
> On Wed, Sep 3, 2014 at 1:02 AM, Ian Buckley via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
>> Cheng Chi,
>> I'm curious to know if you see any error messages about shared library
>> problems ?these will not appear in build.log because they are sent to
>> STDERR not STDOUT. They will look like this snippet:
>>
>> 2ac237c49000-2ac237c5d000 r-xp 00000000 08:01 15090915
>> /opt/Xilinx/12.1/ISE_DS/ISE/lib/lin64/libHdcC_PartitionHelper.so
>> 2ac237c5d000-2ac237d5c000 ---p 00014000 08:01 15090915
>> /opt/Xilinx/12.1/ISE_DS/ISE/lib/lin64/libHdcC_PartitionHelper.so
>> 2ac237d5c000-2ac237d5e000 rw-p 00013000 08:01 15090915
>> /opt/Xilinx/12.1/ISE_DS/ISE/lib/lin64/libHdcC_PartitionHelper.so
>> 2ac237f5f000-2ac238360000 rw-p 00000000 00:00 0
>> 7fffbb676000-7fffbb773000 rw-p 00000000 00:00 0
>>  [stack]
>> 7fffbb7d6000-7fffbb7d7000 r-xp 00000000 00:00 0
>>  [vdso]
>> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
>>  [vsyscall]
>> INFO:TclTasksC:1850 - process run : Generate Programming File is done.
>> lk/wr_rst_reg_0)            | 2     |
>>
u2p_c/simple_gemac_wrapper/tx_2clk_fifo/fifo_2clock/..fifo_xlnx_512x36_2clk/
BU2/U0/grf.rf/rstblk/wr_rst_comb(u2p_c/simple_gemac_wrapper/tx_2clk_fifo/fif
o_2clock/..fifo_xlnx_512x36_2clk/BU2/U0/grf.rf/rstblk/wr_rst_comb1:O)
>> |
>>
NONE(u2p_c/simple_gemac_wrapper/tx_2clk_fifo/fifo_2clock/..fifo_xlnx_512x36_
2clk/BU2/U0/grf.rf/rstblk/wr_rst_reg_0)
>>           | 2     |
>> u2p_c/sysctrl/POR(u2p_c/sysctrl/POR:Q)
>>
>>
|
>> NONE(u2p_c/sysctrl/ram_loader_rst_o)
>>
>> You will see them in the shell or you can capture to file using:
>>
>> make -f Makefile.N210R4 2>&1 | tee logfile
>>
>> -Ian
>>
>> p.s We can only help with you verilog syntax error if you share the code
>> that has the error
>>
>>
>> On Sep 1, 2014, at 10:45 PM, Cheng Chi <ch0004hi at e.ntu.edu.sg> wrote:
>>
>> Hi Ian,
>>
>> Thanks for your reply.
>>
>> I found an earlier discussion on the mailing list, someone solved the
>> problem by removing the #(.WIDTH(WIDTH)) reference from the line. Is it
the
>> right way to do? (I am not familiar with verilog syntax)
>>
>>
>> I just ran another test. I didn't include any custom module, and ran
>> `make -f Makefile.N200R4 bin`. I only changed the BUILD_DIR for
>> Makefile.N200R4 bin as below. I am still having the same Process
>> "Synthesize - XST" failed. But this time, I didn't see the syntax error
as
>> last time.
>>
>> ##################################################
>> # Project Setup
>> ##################################################
>> TOP_MODULE = u2plus
>> # BUILD_DIR = $(abspath build$(ISE)-N200R4)
>> BUILD_DIR = /home/usrp/uhd/fpga/usrp2/top/N2x0/build-custom
>>
>> # set me in a custom makefile
>> CUSTOM_SRCS =
>> CUSTOM_DEFS =
>>
>> The output of bash terminal:
>> https://gist.github.com/anonymous/97dacf1b758727ae6b1a
>>
>> The build.log file:
>> https://gist.github.com/anonymous/1ce58109a930ee338e6a
>>
>> Best regards,
>> Cheng Chi
>>
>>
>> On Tue, Sep 2, 2014 at 12:12 PM, Ian Buckley via USRP-users <
>> usrp-users at lists.ettus.com> wrote:
>>
>>> Cheng Chi,
>>> The clue is here:
>>>
>>> ERROR:HDLCompiler:806 -
"/home/usrp/uhd/fpga/usrp2/sdr_lib/dsp_rx_glue.v" Line
>>>    66: Syntax error near "#".
>>> ERROR:HDLCompiler:806 -
"/home/usrp/uhd/fpga/usrp2/sdr_lib/dsp_rx_glue.v" Line
>>>    96: Syntax error near "endgenerate".
>>>
>>> -Ian
>>>
>>>
>>>
>>>
>>> On Sep 1, 2014, at 8:56 PM, Cheng Chi via USRP-users <
>>> usrp-users at lists.ettus.com> wrote:
>>>
>>> Hi,
>>>
>>> I am trying to build custom image for N200 with the following setup:
>>> - Ubuntu 12.04, 64 bit
>>> - ISE 12.2
>>> - Free license download from Xilinx website
>>>
>>> However, after several minutes of compiling, there is this error Process
>>> "Synthesize - XST" failed - Xilinx.
>>>
>>> The detail build log is uploaded here:
>>> https://gist.github.com/anonymous/1ed97d93fbf879990500
>>>
>>> The Makefile.custom I am using:
>>> https://gist.github.com/anonymous/3049cc02064250f80d6b
>>>
>>>
>>> I am following this guide for building customized image:
>>>
>>>
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2013-April/00655
8.html
>>>
>>> The PATH environment:
>>>
>>>
/opt/Xilinx/12.2/ISE_DS/common/bin/lin64:/opt/Xilinx/12.2/ISE_DS/PlanAhead/b
in:/opt/Xilinx/12.2/ISE_DS/ISE/bin/lin64:/opt/Xilinx/12.2/ISE_DS/ISE/sysgen/
util:/opt/Xilinx/12.2/ISE_DS/EDK/bin/lin64:/usr/lib/lightdm/lightdm:/usr/loc
al/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
>>>
>>> The bash file I am using for building:
>>> #! /bin/bash
>>>
>>> export LM_LICENSE_FILE=/home/usrp/Downloads/Xilinx.lic
>>> export XILINXD_LICENSE_FILE=/home/usrp/Downloads/Xilinx.lic
>>>
>>> LD_LIBRARY_PATH=/usr/lib:/lib:${LD_LIBRARY_PATH}
>>>
>>> cd /opt/Xilinx/12.2/ISE_DS
>>> source ./settings64.sh     # sets up path and other shell variables
>>> cd /home/usrp/uhd/fpga/usrp2/top/N2x0
>>> make -f Makefile.custom bin
>>>
>>> Thanks for any help you can provide in this situation.
>>>
>>> Best regards,
>>> Cheng Chi
>>>
>>>
>>>  _______________________________________________
>>> 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
>>>
>>>
>>
>>
>> _______________________________________________
>> 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/201
40905/9750b2f0/attachment-0001.html>

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

Message: 14
Date: Fri, 5 Sep 2014 10:06:44 +0300
From: "iftah giladi" <g_iftah at yahoo.com>
To: <usrp-users at lists.ettus.com>
Cc: oded75 at 012.net.il
Subject: [USRP-users] mimo sync and acceracy
Message-ID: <008201cfc8d7$f5b530d0$e11f9270$@yahoo.com>
Content-Type: text/plain; charset="us-ascii"

Hi everyone,

 

I have 2 USRP N200, I wrote my own code using the help of the examples.

I am connecting the 2 USRP's together using the MIMO cable.

And The sync is done via this procedure:

1.       The slave program set's the time & clk to the mimo:

usrp -> set_time_source("mimo",0);

usrp -> set_clock_source("mimo",0);

and then it is sets all the other channel parameter(freq,gain,etc) 

2.       The master program set's clock source to internal :

usrp -> set_clock_source(ref);

And then sets all the other channel parameter(freq,gain,etc)  

3.       Then the master program gets time from local machine and set the
usrp time to it:

tod = uhd::time_spec_t::get_system_time();

usrp->set_time_now(tod);

4.       As I understand at that point both usrp has the same time and clk.
Then the master program sets a rx_stream

uhd::stream_args_t stream_args("sc16", wirefmt);

uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);

 

using this sequence of stream_cmd:

uhd::stream_cmd_t stream_cmd((total_num_samps == 0)?

        uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:

        uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE

    );

    stream_cmd.num_samps = total_num_samps;

    stream_cmd.stream_now = false;

       stream_cmd.time_spec = uhd::time_spec_t(tod + seconds_in_future );

    rx_stream->issue_stream_cmd(stream_cmd);

 

5.       Mean time the slave program wait to receive a time file from the
master program with the stream_cmd.time_spec which is sent via TCP sockt to
the slave program

6.       In the slave program the file is received and then a stream commend
sequence using it is done:

uhd::stream_args_t stream_args(cpu_format,wire_format);

uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);

 

uhd::stream_cmd_t stream_cmd((num_requested_samples == 0)?

        uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:

        uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE

    );

    stream_cmd.num_samps = num_requested_samples;

    stream_cmd.stream_now = false;

 

    stream_cmd.time_spec = uhd::time_spec_t(full_sec + frac_sec); // in the
slave device this should be recived from the master host via lan

    rx_stream->issue_stream_cmd(stream_cmd);

7.  Then they both wait for the time = tod + seconds_in_future, and then
they both sample and create a file.

8.  Later on I get this file to the same computer to process with MATLAB.

 

I would really like to get answers to a few question:

 

1.       What is the accuracy of this:

tod = uhd::time_spec_t::get_system_time();

usrp->set_time_now(tod);

2.       What is the process or how those the time and clock are now
transfer to the other usrp and what is the latency of that process?

3.       Is there a time stamp that is passing from the master usrp to the
slave usrp every clock or those this happen once and then we rely on the
fact that the clock is the same?

4.       And if there is a time massage that is passing from one usrp to the
other then what is the latency of that massage?

5.       About the sample clock, is it based on the same 10MHZ that is
passing on the mimo cable? How does this 10M get synthesized to the sample
frequency at the A2D? and what would be the latency between the 2 different
A2D sample Signal?

Any help would be very appreciated,

 

Thank's,

iftah

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

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

Message: 15
Date: Fri, 05 Sep 2014 11:00:24 +0200
From: Marcus M?ller <marcus.mueller at ettus.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] firmware USRP
Message-ID: <54097BA8.4070809 at ettus.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi Steven,
>I want to know if i can change the code of firmware,
yes, you can. All our devices have open source firmware, which can be
found in the uhd repository of EttusResearch on github.

>which is the programming language of the firmware
The Firmware generally is written in C, and Ettus does its RTL
development in Verilog.

Generally, often people are a little disappointed what they can do with
the firmware: It's not doing any signal processing, but is only used to
set up the device and control it. Depending on which USRP we're looking
at, this includes bringing up the port controller, initializing the
FPGA, setting up the RF hardware etc. The actual signal processing,
being as high rate at it is at master clock rates of 32, 56, 100, 200MHz
(typical default rates of B100, B2x0, N2x0, and X3x0 USRPs), this can't
be done with a humble ARM or ZPU, so it's written in Verilog.

Greetings,
Marcus

On 05.09.2014 04:51, steven camacho via USRP-users wrote:
> I want to know if i can change the code of firmware, and if possible in
which is the programming language of the firmware
>  		 	   		  
>
>
> _______________________________________________
> 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/201
40905/6251ee7d/attachment-0001.html>

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

Message: 16
Date: Fri, 05 Sep 2014 11:13:22 +0200
From: Marcus M?ller <marcus.mueller at ettus.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] mimo sync and acceracy
Message-ID: <54097EB2.5040505 at ettus.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi Iftah,
answering your question really shortly, sorry:

>1.       What is the accuracy of this:
>tod = uhd::time_spec_t::get_system_time();
>usrp->set_time_now(tod);

The two USRPs should then be sample-synchronous. However, setting the
time without any trigger is not going to be very exact, give or take
10ms, because the USRP just sets its time when it receives the command.
If you want more accuracy, you need a pulse that will go up at the exact
time you want to set at the PPS input and use set_time_unknown_pps or
one of its sister methods. To be honest, though, when using the system
time, 10ms isn't that much, so "accuracy" is always relative.

>2.       What is the process or how those the time and clock are now
>transfer to the other usrp and what is the latency of that process?

The slave USRP gets a timestamp from the master via the mimo cable, and
transfers that timestamp into its own time register upon a
master-generated pulse. This answers 4., too.
Latency thus should effectively be eliminated.

>3.       Is there a time stamp that is passing from the master usrp to the
>slave usrp every clock or those this happen once and then we rely on the
>fact that the clock is the same?

Once. Doing something else would be unwise, unless we don't trust our
FPGA to count up.

>5.       About the sample clock, is it based on the same 10MHZ that is
>passing on the mimo cable? 

Exactly. That is the main purpose of the MIMO cable.

>How does this 10M get synthesized to the sample
>frequency at the A2D?

The other way around. This applies to any reference clock, no matter if
it comes from the MIMO cable, internal oscillator, GPSDO, or wherever:
The USRP has an on-board ADC clock generator, which takes the 10MHz
reference as reference and generates the ADC clock, which is then phase
locked.

> and what would be the latency between the 2 different
>A2D sample Signal?

Ideally, none. You have to account for analog circuitry though, which
implies that e.g. the phase of most (not all) the LOs used to mix down
the RF signal to complex baseband is random upon tuning. A phase shift
is a time delay, too...

Greetings,
Marcus


On 05.09.2014 09:06, iftah giladi via USRP-users wrote:
> Hi everyone,
>
>  
>
> I have 2 USRP N200, I wrote my own code using the help of the examples.
>
> I am connecting the 2 USRP's together using the MIMO cable.
>
> And The sync is done via this procedure:
>
> 1.       The slave program set's the time & clk to the mimo:
>
> usrp -> set_time_source("mimo",0);
>
> usrp -> set_clock_source("mimo",0);
>
> and then it is sets all the other channel parameter(freq,gain,etc) 
>
> 2.       The master program set's clock source to internal :
>
> usrp -> set_clock_source(ref);
>
> And then sets all the other channel parameter(freq,gain,etc)  
>
> 3.       Then the master program gets time from local machine and set the
> usrp time to it:
>
> tod = uhd::time_spec_t::get_system_time();
>
> usrp->set_time_now(tod);
>
> 4.       As I understand at that point both usrp has the same time and
clk.
> Then the master program sets a rx_stream
>
> uhd::stream_args_t stream_args("sc16", wirefmt);
>
> uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
>
>  
>
> using this sequence of stream_cmd:
>
> uhd::stream_cmd_t stream_cmd((total_num_samps == 0)?
>
>         uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:
>
>         uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE
>
>     );
>
>     stream_cmd.num_samps = total_num_samps;
>
>     stream_cmd.stream_now = false;
>
>        stream_cmd.time_spec = uhd::time_spec_t(tod + seconds_in_future );
>
>     rx_stream->issue_stream_cmd(stream_cmd);
>
>  
>
> 5.       Mean time the slave program wait to receive a time file from the
> master program with the stream_cmd.time_spec which is sent via TCP sockt
to
> the slave program
>
> 6.       In the slave program the file is received and then a stream
commend
> sequence using it is done:
>
> uhd::stream_args_t stream_args(cpu_format,wire_format);
>
> uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
>
>  
>
> uhd::stream_cmd_t stream_cmd((num_requested_samples == 0)?
>
>         uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:
>
>         uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE
>
>     );
>
>     stream_cmd.num_samps = num_requested_samples;
>
>     stream_cmd.stream_now = false;
>
>  
>
>     stream_cmd.time_spec = uhd::time_spec_t(full_sec + frac_sec); // in
the
> slave device this should be recived from the master host via lan
>
>     rx_stream->issue_stream_cmd(stream_cmd);
>
> 7.  Then they both wait for the time = tod + seconds_in_future, and then
> they both sample and create a file.
>
> 8.  Later on I get this file to the same computer to process with MATLAB.
>
>  
>
> I would really like to get answers to a few question:
>
>  
>
> 1.       What is the accuracy of this:
>
> tod = uhd::time_spec_t::get_system_time();
>
> usrp->set_time_now(tod);
>
> 2.       What is the process or how those the time and clock are now
> transfer to the other usrp and what is the latency of that process?
>
> 3.       Is there a time stamp that is passing from the master usrp to the
> slave usrp every clock or those this happen once and then we rely on the
> fact that the clock is the same?
>
> 4.       And if there is a time massage that is passing from one usrp to
the
> other then what is the latency of that massage?
>
> 5.       About the sample clock, is it based on the same 10MHZ that is
> passing on the mimo cable? How does this 10M get synthesized to the sample
> frequency at the A2D? and what would be the latency between the 2
different
> A2D sample Signal?
>
> Any help would be very appreciated,
>
>  
>
> Thank's,
>
> iftah
>
>
>
>
> _______________________________________________
> 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/201
40905/d7bac39e/attachment-0001.html>

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

Message: 17
Date: Fri, 5 Sep 2014 15:26:22 +0000 (UTC)
From: "TSAREGORODTSEV, Yury" <yury at bridgecommunication.co.uk>
To: usrp-users at lists.ettus.com
Subject: [USRP-users] full duplex infinity loop
Message-ID:
	
<1843338444.76452.1409930782288.JavaMail.zimbra at bridgecommunication.co.uk>
	
Content-Type: text/plain; charset="utf-8"

Hello, 
can anyone suggest how to prevent infinity loop in case of full duplex RX/TX
on same frequency ? 
Any ideas? 

GRC example: 
UHD source -> GMSK DEMOD -> packet decoder -> packet encoder -> GMSK MOD ->
UHD SINK 

but in this case of course its gonna be infinity loop, 
any suggestion how to avoid this? 


Thx. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/201
40905/0a933b7b/attachment-0001.html>

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

Message: 18
Date: Fri, 5 Sep 2014 15:36:19 +0000
From: "Cochenour, Brandon M CIV NAWCAD, 4.5.6"
	<brandon.cochenour at navy.mil>
To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
Subject: [USRP-users] Wireless switch for MIMO?
Message-ID:
	
<7F21D015A200A944BD9AC84A9E1030AB0FD7A9DB at NAEAPAXRXM01V.nadsusea.nads.navy.m
il>
	
Content-Type: text/plain; charset="iso-8859-1"

I've used wired Ethernet switches to combine a bunch of USRP data streams
together.  The Netgear models have a plenty big "pipe" in which to carry
several streams at "low enough" sample rates back to the host PC.

I have an application though in which I might not be able to get to my USRPs
with a CAT-5 cable (a floating buoy!), and was considering an wireless
switch (one on the buoy with the USRPs, another back with the PC).  However,
it doesn't seem like the wireless devices have the same throughput.

Has anybody tried something like this?  What's the biggest pipe I can expect
if I can't connect to my remote USRPs directly with a CAT-5 and two gigabit
Ethernet switches?

Thanks!

---
Brandon






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

Message: 19
Date: Fri, 05 Sep 2014 11:51:33 -0400
From: mleech at ripnet.com
To: "Cochenour, Brandon M CIV NAWCAD, 4.5.6"
	<brandon.cochenour at navy.mil>
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Wireless switch for MIMO?
Message-ID: <31c8d1104f86923d05a3ad0818602659 at ripnet.com>
Content-Type: text/plain; charset="us-ascii"

 

Typical performance of a WiFi segment for 802.11n is about 130Mbit,
which is profoundly lower than 1000Mbit.... 

On 2014-09-05 11:36, Cochenour, Brandon M CIV NAWCAD, 4.5.6 via
USRP-users wrote: 

> I've used wired Ethernet switches to combine a bunch of USRP data streams
together. The Netgear models have a plenty big "pipe" in which to carry
several streams at "low enough" sample rates back to the host PC.
> 
> I have an application though in which I might not be able to get to my
USRPs with a CAT-5 cable (a floating buoy!), and was considering an wireless
switch (one on the buoy with the USRPs, another back with the PC). However,
it doesn't seem like the wireless devices have the same throughput.
> 
> Has anybody tried something like this? What's the biggest pipe I can
expect if I can't connect to my remote USRPs directly with a CAT-5 and two
gigabit Ethernet switches?
> 
> Thanks!
> 
> ---
> Brandon
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
 

Links:
------
[1] 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/201
40905/eac05bff/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 49, Issue 4
*****************************************





More information about the USRP-users mailing list