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: Extended multipath (10 ms) at an indoor environment.
(Matt Ettus)
2. Re: Still problems with USRP time from GPSDO (Josh Blum)
3. Re: Still problems with USRP time from GPSDO (Sean Nowlan)
4. Re: Still problems with USRP time from GPSDO (Josh Blum)
5. Re: Still problems with USRP time from GPSDO (Marcus D. Leech)
6. Re: Still problems with USRP time from GPSDO (Josh Blum)
7. Re: Still problems with USRP time from GPSDO (Marcus D. Leech)
8. Re: USRP N210 low pass filter (Marc Bauduin)
9. Receive FPGA pipeline overflow? (Per Zetterberg)
10. Re: Still problems with USRP time from GPSDO (Sivan Toledo)
----------------------------------------------------------------------
Message: 1
Date: Mon, 29 Apr 2013 09:12:35 -0700
From: Matt Ettus <[email protected]>
To: Ian Song <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Extended multipath (10 ms) at an indoor
environment.
Message-ID:
<CAN=1kn_xmcmdqktzprw0-odueadnu+ya9veuj+hycd6alnv...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Ian,
I think you may be seeing IQ imbalance which will cause fake responses.
Have you run the IQ Balance calibration utility?
Matt
On Thu, Apr 25, 2013 at 8:39 AM, Ian Song <[email protected]> wrote:
> I used USRPB100+WBX daughter board to transmit linear modulated frequency
> (LFM) signals at the center frequency fc (fc=80 or fc=83 MHz). The LFM
> signal sweeps from fc-16 kHz to fc+16 kHz in 0.05 or 0.5 s. The other
> USRPB100 +WBX daughter board did the reception. The two devices were placed
> in a large room, separated by variable distances (20 cm to a couple of
> meters). I also changed the gain in both the source and the receiver
> (varying gain from -5 to 20 dB for both).
>
> Then I examined the received LFM signals through matched-filtering
> operations. The part that I do not understand that the calculated impulse
> responses also had extended multipath. I can see four or five strong
> multipaths, always with one dominating path. The channel time span was 10
> ms. To me, it seems impossible to have such a long mutlipath. Can everyone
> explain the long delayed multipath? Is it real or due to the device
> distortion? Any suggestions?
>
>
> Many thanks,
>
>
> Ian
>
> _______________________________________________
> 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/20130429/c7f00194/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 29 Apr 2013 13:37:44 -0500
From: Josh Blum <[email protected]>
To: [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
On 04/29/2013 07:10 AM, Sivan Toledo wrote:
> I think that my previous message was wrong, but I still have problems with
> the GPSDO times from the USRP. Here is a printout from a UHD program that
> queries the time in 4 different ways:
>
> 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
>
> As you can see there is a difference of a whole second between the time on
> the PC, which is derived from NTP using ntpd and should be accurate to at
> least 10ms or so, and the times on the USRP.
>
> The USRP is an N200 with a GPSDO fitted.
>
> We've experienced errors by whole seconds in two different units. Is this a
> bug in the firmware or image?
>
Hey,
Sorry for the trouble.
Can I ask what version of UHD you are running? A few weeks ago I fixed a
bug on the master branch related to GPSDO time, it sounds roughly like
you describe. If you are running a stale version of master, that could
potentially be the cause. However, if this is code from maint or a
release then Im not sure.
Can you send the output of
<install prefix>/share/uhd/utils/query_gpsdo_sensors
I think that will be revealing.
-josh
------------------------------
Message: 3
Date: Mon, 29 Apr 2013 14:56:46 -0400
From: Sean Nowlan <[email protected]>
To: <[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"; Format="flowed"
On 04/29/2013 02:37 PM, Josh Blum wrote:
> Can I ask what version of UHD you are running? A few weeks ago I fixed a
> bug on the master branch related to GPSDO time,
Hi Josh, can you point me to that commit? was it just a fix to
query_gpsdo_sensors or something in the driver/gpsdo control code?
>
> -josh
>
>
Thanks,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130429/2a318945/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 29 Apr 2013 15:08:10 -0500
From: Josh Blum <[email protected]>
To: Sean Nowlan <[email protected]>
Cc: [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
On 04/29/2013 01:56 PM, Sean Nowlan wrote:
> On 04/29/2013 02:37 PM, Josh Blum wrote:
>> Can I ask what version of UHD you are running? A few weeks ago I fixed a
>> bug on the master branch related to GPSDO time,
> Hi Josh, can you point me to that commit? was it just a fix to
> query_gpsdo_sensors or something in the driver/gpsdo control code?
It was a fix to the gpsdo control code:
https://github.com/EttusResearch/uhd/commit/31f0e964aa54a2c8e4d299432513623d2c49bbf0
-josh
------------------------------
Message: 5
Date: Mon, 29 Apr 2013 16:51:02 -0400
From: "Marcus D. Leech" <[email protected]>
To: [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; format=flowed
On 04/29/2013 04:08 PM, Josh Blum wrote:
>
> On 04/29/2013 01:56 PM, Sean Nowlan wrote:
>> On 04/29/2013 02:37 PM, Josh Blum wrote:
>>> Can I ask what version of UHD you are running? A few weeks ago I fixed a
>>> bug on the master branch related to GPSDO time,
>> Hi Josh, can you point me to that commit? was it just a fix to
>> query_gpsdo_sensors or something in the driver/gpsdo control code?
> It was a fix to the gpsdo control code:
>
> https://github.com/EttusResearch/uhd/commit/31f0e964aa54a2c8e4d299432513623d2c49bbf0
>
> -josh
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
Is it not the case that GPS time is strictly-linear, whereas UTC (which
is what is carried by NTPD) has leap-second compensation. Or do the GPSDO
units produce a leapsecond-corrected timestamp?
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 6
Date: Mon, 29 Apr 2013 15:55:14 -0500
From: Josh Blum <[email protected]>
To: [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
On 04/29/2013 03:51 PM, Marcus D. Leech wrote:
> On 04/29/2013 04:08 PM, Josh Blum wrote:
>>
>> On 04/29/2013 01:56 PM, Sean Nowlan wrote:
>>> On 04/29/2013 02:37 PM, Josh Blum wrote:
>>>> Can I ask what version of UHD you are running? A few weeks ago I
>>>> fixed a
>>>> bug on the master branch related to GPSDO time,
>>> Hi Josh, can you point me to that commit? was it just a fix to
>>> query_gpsdo_sensors or something in the driver/gpsdo control code?
>> It was a fix to the gpsdo control code:
>>
>> https://github.com/EttusResearch/uhd/commit/31f0e964aa54a2c8e4d299432513623d2c49bbf0
>>
>>
>> -josh
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
> Is it not the case that GPS time is strictly-linear, whereas UTC (which
> is what is carried by NTPD) has leap-second compensation. Or do the GPSDO
> units produce a leapsecond-corrected timestamp?
>
The time in seconds in the GPGGA string as reported by the GPSDO unit is
UTC time. So it should match the PC clock to the second. However, the
GPS time is actually about 16 seconds off compared to UTC because it
doesnt adapt with leap seconds.
-josh
>
>
------------------------------
Message: 7
Date: Mon, 29 Apr 2013 17:01:17 -0400
From: "Marcus D. Leech" <[email protected]>
To: [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; format=flowed
On 04/29/2013 04:55 PM, Josh Blum wrote:
>
> On 04/29/2013 03:51 PM, Marcus D. Leech wrote:
>> On 04/29/2013 04:08 PM, Josh Blum wrote:
>>> On 04/29/2013 01:56 PM, Sean Nowlan wrote:
>>>> On 04/29/2013 02:37 PM, Josh Blum wrote:
>>>>> Can I ask what version of UHD you are running? A few weeks ago I
>>>>> fixed a
>>>>> bug on the master branch related to GPSDO time,
>>>> Hi Josh, can you point me to that commit? was it just a fix to
>>>> query_gpsdo_sensors or something in the driver/gpsdo control code?
>>> It was a fix to the gpsdo control code:
>>>
>>> https://github.com/EttusResearch/uhd/commit/31f0e964aa54a2c8e4d299432513623d2c49bbf0
>>>
>>>
>>> -josh
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>> Is it not the case that GPS time is strictly-linear, whereas UTC (which
>> is what is carried by NTPD) has leap-second compensation. Or do the GPSDO
>> units produce a leapsecond-corrected timestamp?
>>
> The time in seconds in the GPGGA string as reported by the GPSDO unit is
> UTC time. So it should match the PC clock to the second. However, the
> GPS time is actually about 16 seconds off compared to UTC because it
> doesnt adapt with leap seconds.
>
> -josh
>
Here are some interesting notes with respect to GPS time-keeping
functions on typical recievers, vs UTC (as delivered by NTPD). Now, this
makes me wonder how GPSD on Linux deals with this.
http://gpsinformation.net/main/gpstime.htm
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 8
Date: Tue, 30 Apr 2013 09:23:00 +0200
From: Marc Bauduin <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP N210 low pass filter
Message-ID:
<ca+ekp-zbrqvy0dumdffrjv17chjz+e+pk8kvesh+jnb0bsg...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I used an odd decimation factor, so the filter I observe should be the CIC
filter. I will check with an even decimation factor.
Thanks for your help
2013/4/29 Matt Ettus <[email protected]>
>
> If you choose an odd decimation ratio, you will have rolloff due to the
> CIC filters. You need to choose an even decimation ratio to get a flat
> passband.
>
> Matt
>
>
> On Mon, Apr 29, 2013 at 12:21 AM, Marc Bauduin <[email protected]>wrote:
>
>>
>> Hy everyone,
>>
>> I have 2 USRP N210 with a daughterbourd RFX2400 and I pilot them with
>> Matlab. When I make a narrowband communication, I don't observe a flat
>> channel but I also observe the spectrum of a filter. I searched in
>> documentation but I did'nt see the characteristic of the baseband filter of
>> the system. What are the characteristic of this filter? Is it a RRC filter?
>>
>> Thanks for your answer,
>> 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/6105d3ed/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 30 Apr 2013 07:38:36 +0000
From: Per Zetterberg <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Receive FPGA pipeline overflow?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
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
------------------------------
Message: 10
Date: Tue, 30 Apr 2013 16:21:35 +0300
From: Sivan Toledo <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Still problems with USRP time from GPSDO
Message-ID:
<caol_rugz2ieb0e0cbxpnkfzlzg0pkpek+so13myeubqmo8j...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Josh,
Yes, here is the output from the two units. For the record, I reported this
as possible bug, but I found a way around this in my software so it does
not bother me too much. But if it's a bug it would be good to fix this.
Here are the two outputs:
pc-sivan-09:~/Projects/atlas/uhd>
../../uhd/host/build/utils/query_gpsdo_sensors ; date +%s
linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.005.001-0-unknown
Creating the USRP device with: ...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO.... Found a Jackson Labs GPS
-- found
-- Setting references to the internal GPSDO
-- Initializing time to the internal GPSDO
Using Device: Single USRP:
Device: USRP2 / N-Series Device
Mboard 0: N200r4
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: WBXv3 RX+GDB
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: WBXv3 TX+GDB
**************************************Helpful Notes on Clock/PPS
Selection**************************************
As you can see, the default 10 MHz Reference and 1 PPS signals are now from
the GPSDO.
If you would like to use the internal reference(TCXO) in other
applications, you must configure that explicitly.
You can no longer select the external SMAs for 10 MHz or 1 PPS signaling.
****************************************************************************************************************
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
Done!
1367327904
---------------------------------------------------
pc-sivan-09:~/Projects/atlas/uhd>
../../uhd/host/build/utils/query_gpsdo_sensors ; date +%s
linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.005.001-0-unknown
Creating the USRP device with: ...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO.... Found a Jackson Labs GPS
-- found
-- Setting references to the internal GPSDO
-- Initializing time to the internal GPSDO
UHD Warning:
get_time: ValueError: get_nmea(): no $GPRMC message found
Using Device: Single USRP:
Device: USRP2 / N-Series Device
Mboard 0: N200r4
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: SBXv3 RX
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: SBXv3 TX
**************************************Helpful Notes on Clock/PPS
Selection**************************************
As you can see, the default 10 MHz Reference and 1 PPS signals are now from
the GPSDO.
If you would like to use the internal reference(TCXO) in other
applications, you must configure that explicitly.
You can no longer select the external SMAs for 10 MHz or 1 PPS signaling.
****************************************************************************************************************
GPS Locked
USRP Locked to GPSDO 10 MHz Reference.
UHD Warning:
get_time: ValueError: get_nmea(): no $GPRMC message found
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,131822.00,3206.7913,N,3448.4214,E,1,07,1.6,49.0,M,17.6,M,,*69
PS_GPRMC: $GPRMC,131823.00,A,3206.7910,N,3448.4214,E,0.2,0.0,300413,,*0E
GPS epoch time: 1367327901 seconds
UHD Device time: 1367327901 seconds
Done!
1367327903
On Mon, Apr 29, 2013 at 9:37 PM, Josh Blum <[email protected]> wrote:
>
>
> On 04/29/2013 07:10 AM, Sivan Toledo wrote:
> > I think that my previous message was wrong, but I still have problems
> with
> > the GPSDO times from the USRP. Here is a printout from a UHD program that
> > queries the time in 4 different ways:
> >
> > 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
> >
> > As you can see there is a difference of a whole second between the time
> on
> > the PC, which is derived from NTP using ntpd and should be accurate to at
> > least 10ms or so, and the times on the USRP.
> >
> > The USRP is an N200 with a GPSDO fitted.
> >
> > We've experienced errors by whole seconds in two different units. Is
> this a
> > bug in the firmware or image?
> >
>
> Hey,
>
> Sorry for the trouble.
>
> Can I ask what version of UHD you are running? A few weeks ago I fixed a
> bug on the master branch related to GPSDO time, it sounds roughly like
> you describe. If you are running a stale version of master, that could
> potentially be the cause. However, if this is code from maint or a
> release then Im not sure.
>
> Can you send the output of
> <install prefix>/share/uhd/utils/query_gpsdo_sensors
>
> I think that will be revealing.
>
> -josh
>
> _______________________________________________
> 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/e6de99a1/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 32, Issue 23
******************************************
