Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Receive FPGA pipeline overflow? (Mike Jameson)
2. Re: Receive FPGA pipeline overflow? (Marcus D. Leech)
3. Re: Receive FPGA pipeline overflow? (Matt Ettus)
4. Re: Still problems with USRP time from GPSDO (Josh Blum)
5. LFRX antialiasing (mepard)
6. Re: LFRX antialiasing (Marcus D. Leech)
7. Re: LFRX antialiasing (Matt Ettus)
8. Re: LFRX antialiasing (mepard)
9. Re: LFRX antialiasing (Matt Ettus)
10. Re: Receive FPGA pipeline overflow? (Per Zetterberg)
----------------------------------------------------------------------
Message: 1
Date: Tue, 30 Apr 2013 17:58:02 +0100
From: Mike Jameson <[email protected]>
To: Per Zetterberg <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Receive FPGA pipeline overflow?
Message-ID:
<cajcjmitjwl8ot7njy-b6ujbku4fjy1hrogrcqvha-0eqhpu...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
My understanding is that if your signal is within the range of the ADC then
it will processed by the Ettus N210's FPGA without issue. If you are
having an issue with sampling the strong signal in question then could this
be due to harmonics lying outside the passband. Using an Ettus USRP N210
with a LFRX daughterboard (0 - 30MHz frequency range) you can sample with
an RF bandwidth of 25MHz (14 bit samples) or 30MHz (8 bit samples). With
the LFRX, strong signals above the passband will alias and fold over
themselves if you don't have a lowpass filter in place.
Mike
--
Mike Jameson M0MIK BSc MIET
Email: [email protected]
Web: http://scanoo.com
On 30 April 2013 08:38, Per Zetterberg <[email protected]> wrote:
>
> Hi List,
>
>
> If I have a strong signal, connected to say LFRX (i.e a base-band signal).
> Is it then possible (on the USRP N210) that the FPGA pipeline may overflow.
> I mean the analog signal is still within the range of the ADC but the
> digital stages overflow somewhere. Is there anything I can do about it? for
> instance post-correction?
>
> BR/
> Per
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130430/3fd587f7/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 30 Apr 2013 13:12:15 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Receive FPGA pipeline overflow?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 04/30/2013 03:38 AM, Per Zetterberg wrote:
> Hi List,
>
>
> If I have a strong signal, connected to say LFRX (i.e a base-band signal). Is
> it then possible (on the USRP N210) that the FPGA pipeline may overflow. I
> mean the analog signal is still within the range of the ADC but the digital
> stages overflow somewhere. Is there anything I can do about it? for instance
> post-correction?
>
> BR/
> Per
>
I don't believe that integer overflow is a possibility in the FPGA
signal chain, even with "bit growth" due to the CIC decimators, that's
all accounted
for.
If you're sampling strong signals, you can get into non-linear operating
regions in the analog bits -- there's a differential amplifier on the
LF_RX for example.
Also, if you aren't band-limiting your input to handily-below the
Nyquist frequency (50Mhz, in the case of the N210, because the ADC
samples at
100Msps), then you'll get aliases folded into the signals after
they're sampled.
If your signals are so strong that you're worried about overflow, use an
attenuator in front of the daughtercard.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 3
Date: Tue, 30 Apr 2013 10:45:58 -0700
From: Matt Ettus <[email protected]>
To: Per Zetterberg <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Receive FPGA pipeline overflow?
Message-ID:
<CAN=1kn9hxr6p9s+ez6+rvyof2q06smqymfk0zzsy3crmb77...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
The long story.
Others have answered well, but I will add some detail. If a signal is
overrange, the ADCs will have correct clipping behavior, meaning anything
higher than max positive amplitude will register as maximum positive, and
the same for negative. You don't want to put in too strong of a signal
because you could blow something, of course.
All of the subsequent digital processing stages fall into one of 2 types of
behavior:
- No matter what the input signal, the output cannot overflow (i.e. they
are inherently safe). The CORDIC and CIC fall in to this category, for
example.
- Some strong signals could cause overflow, but it is very unlikely, AND we
handle those cases by clipping properly. DC offset and IQ balance
correction fall in this category.
It would only be a problem if we allowed strong signals to overflow without
clipping, which could have all sorts of bad results, like negative output
when the signal is really a strong positive, random noise, etc. This will
not occur in the standard DSP blocks we ship.
Matt
On Tue, Apr 30, 2013 at 12:38 AM, Per Zetterberg <[email protected]> wrote:
>
> Hi List,
>
>
> If I have a strong signal, connected to say LFRX (i.e a base-band signal).
> Is it then possible (on the USRP N210) that the FPGA pipeline may overflow.
> I mean the analog signal is still within the range of the ADC but the
> digital stages overflow somewhere. Is there anything I can do about it? for
> instance post-correction?
>
> BR/
> Per
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130430/368c6226/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 30 Apr 2013 13:53:44 -0500
From: Josh Blum <[email protected]>
To: Sivan Toledo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Still problems with USRP time from GPSDO
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
> GPS Locked
> USRP Locked to GPSDO 10 MHz Reference.
>
> GPS and UHD Device time are NOT aligned. Try re-running the program. Double
> check 1 PPS connection from GPSDO.
>
> Printing available NMEA strings:
> PS_GPGGA:
> $GPGGA,131823.00,3206.7878,N,3448.4199,E,2,09,1.0,59.3,M,17.6,M,,*6B
> PS_GPRMC: $GPRMC,131824.00,A,3206.7878,N,3448.4199,E,0.3,0.0,300413,,*01
> GPS epoch time: 1367327902 seconds
> UHD Device time: 1367327902 seconds
>
So, notice the times 1367327902 are the same, but you see the error
above. Thats actually a floating point rounding thing where the
fractional seconds are nominally one. This check was a simple one line
fix for this app, so its nothing to worry about:
https://github.com/EttusResearch/uhd/commit/2b2b9464f64b03c9ae7317555c7db9ec29aa8fcd
> Done!
>
> 1367327904
>
Is this print 1367327904 the result of time(NULL)? If so, I think some
of the extra time comes from the fact that GPGGA and GPRMC are queried
after the time is read and before the time is printed. This may account
for one second, even two -> since the messages are scheduled to come
form the gpsdo @ PPS.
Now in another email it looked like the utc time on your system may have
been one second off:
> usrp->get_time_now(): 1367237083:0.517574
> usrp->get_time_last_pps(): 1367237082:1.000000
> metadata time stamp of recent RX samples: 1367237083:0.510384
> utime() on Linux: 1367237084:0.517167
So it looks like there is perhaps a difference of about 1 second in the
time reported by UTC PC clock vs GPRMC value from the GPSDO. I cant say
that I have seen this. Could you perhaps run the same app but with this
code from the master branch? It has the UTC time print added. I wonder
if there is a one second offset in this case as well...
https://github.com/EttusResearch/uhd/blob/master/host/utils/query_gpsdo_sensors.cpp
Thanks!
-josh
------------------------------
Message: 5
Date: Tue, 30 Apr 2013 14:31:59 -0500
From: mepard <[email protected]>
To: [email protected]
Subject: [USRP-users] LFRX antialiasing
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
In the "Receive FPGA pipeline overflow?" thread, on Apr 30, 2013, at 12:12 PM,
Marcus D. Leech <[email protected]> wrote:
> Also, if you aren't band-limiting your input to handily-below the Nyquist
> frequency (50Mhz, in the case of the N210, because the ADC samples at
> 100Msps), then you'll get aliases folded into the signals after they're
> sampled.
So we need external filtering for the LFRX board? I knew this was true for the
BasicRX (1 - 250 MHz), but I had the impression this wasn't necessary for the
LFRX (0 - 30 MHz).
-Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130430/315a93bf/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 30 Apr 2013 15:37:51 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] LFRX antialiasing
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 04/30/2013 03:31 PM, mepard wrote:
>
> In the "Receive FPGA pipeline overflow?" thread, on Apr 30, 2013, at
> 12:12 PM, Marcus D. Leech <[email protected]
> <mailto:[email protected]>> wrote:
>
>> Also, if you aren't band-limiting your input to handily-below the
>> Nyquist frequency (50Mhz, in the case of the N210, because the ADC
>> samples at
>> 100Msps), then you'll get aliases folded into the signals after
>> they're sampled.
>
> So we need external filtering for the LFRX board? I knew this was true
> for the BasicRX (1 - 250 MHz), but I had the impression this wasn't
> necessary for the LFRX (0 - 30 MHz).
>
> -Marc
>
There is a 30Mhz low-pass on the output of the LF_RX differential
amplifiers, but I'm not sure that the out-of-band attenuation is all
that terribly deep.
If there's a possibility of strong signals above 30Mhz, I'd put in an
external filter.
The main "draw" of the LF_RX is that it goes down to DC on the input,
whereas on the BASIC_RX, its response starts to roll off quite a bit
below about
1Mhz.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130430/df0a427c/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 30 Apr 2013 12:38:20 -0700
From: Matt Ettus <[email protected]>
To: mepard <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] LFRX antialiasing
Message-ID:
<CAN=1kn8sqzi9s2g2hq5e14weanotr6okt+jpmaqwhp9n94+...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
The LFRX has its own antialiasing. You don't need to add any unless you
need a much steeper rolloff.
Matt
On Tue, Apr 30, 2013 at 12:31 PM, mepard <[email protected]> wrote:
>
> In the "Receive FPGA pipeline overflow?" thread, on Apr 30, 2013, at 12:12
> PM, Marcus D. Leech <[email protected]> wrote:
>
> Also, if you aren't band-limiting your input to handily-below the Nyquist
> frequency (50Mhz, in the case of the N210, because the ADC samples at
> 100Msps), then you'll get aliases folded into the signals after they're
> sampled.
>
>
> So we need external filtering for the LFRX board? I knew this was true for
> the BasicRX (1 - 250 MHz), but I had the impression this wasn't necessary
> for the LFRX (0 - 30 MHz).
>
> -Marc
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130430/ee612d43/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 30 Apr 2013 15:24:58 -0500
From: mepard <[email protected]>
To: Matt Ettus <[email protected]>, [email protected]
Subject: Re: [USRP-users] LFRX antialiasing
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
On Apr 30, 2013, at 2:38 PM, Matt Ettus <[email protected]> wrote:
> The LFRX has its own antialiasing. You don't need to add any unless you need
> a much steeper rolloff.
We're trying to calculate the rolloff.
Is the schematic at http://code.ettus.com/redmine/ettus/documents/4 current? We
have LFRX Rev 2.2.
Are you referring to R10, R11, R4, R5 with C25, C26, C22, C23, respectively?
-Marc
------------------------------
Message: 9
Date: Tue, 30 Apr 2013 13:29:25 -0700
From: Matt Ettus <[email protected]>
To: mepard <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] LFRX antialiasing
Message-ID:
<CAN=1kn-4rx7qinry6i0zr-hqp4nggensro6gyiftblbbiu7...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Yes it is current
On Apr 30, 2013 3:24 PM, "mepard" <[email protected]> wrote:
> On Apr 30, 2013, at 2:38 PM, Matt Ettus <[email protected]> wrote:
>
> > The LFRX has its own antialiasing. You don't need to add any unless you
> need a much steeper rolloff.
>
>
> We're trying to calculate the rolloff.
>
> Is the schematic at http://code.ettus.com/redmine/ettus/documents/4current?
> We have LFRX Rev 2.2.
>
> Are you referring to R10, R11, R4, R5 with C25, C26, C22, C23,
> respectively?
>
> -Marc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130430/706b33c6/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 1 May 2013 13:49:43 +0000
From: Per Zetterberg <[email protected]>
To: Matt Ettus <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Receive FPGA pipeline overflow?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Thanks all answering my question, and subsequent discussion :-)
BR/
Per
________________________________________
From: Matt Ettus [[email protected]]
Sent: Tuesday, April 30, 2013 7:45 PM
To: Per Zetterberg
Cc: usrp-users
Subject: Re: [USRP-users] Receive FPGA pipeline overflow?
The long story.
Others have answered well, but I will add some detail. If a signal is
overrange, the ADCs will have correct clipping behavior, meaning anything
higher than max positive amplitude will register as maximum positive, and the
same for negative. You don't want to put in too strong of a signal because you
could blow something, of course.
All of the subsequent digital processing stages fall into one of 2 types of
behavior:
- No matter what the input signal, the output cannot overflow (i.e. they are
inherently safe). The CORDIC and CIC fall in to this category, for example.
- Some strong signals could cause overflow, but it is very unlikely, AND we
handle those cases by clipping properly. DC offset and IQ balance correction
fall in this category.
It would only be a problem if we allowed strong signals to overflow without
clipping, which could have all sorts of bad results, like negative output when
the signal is really a strong positive, random noise, etc. This will not occur
in the standard DSP blocks we ship.
Matt
On Tue, Apr 30, 2013 at 12:38 AM, Per Zetterberg
<[email protected]<mailto:[email protected]>> wrote:
Hi List,
If I have a strong signal, connected to say LFRX (i.e a base-band signal). Is
it then possible (on the USRP N210) that the FPGA pipeline may overflow. I mean
the analog signal is still within the range of the ADC but the digital stages
overflow somewhere. Is there anything I can do about it? for instance
post-correction?
BR/
Per
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 33, Issue 1
*****************************************
