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: UHD driver segault (Josh Blum)
2. Re: UHD driver segault (Youri Westerman)
3. GPSDO loss of lock (Sivan Toledo)
4. Seq Error in Burst (Tim Schuschies)
5. Re: GPSDO loss of lock (Marcus D. Leech)
----------------------------------------------------------------------
Message: 1
Date: Wed, 10 Apr 2013 18:55:05 -0500
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD driver segault
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/10/2013 03:29 AM, Youri Westerman wrote:
> Hi,
>
> I'm trying to get the uhd driver working properly in combination with a
> B100 USRP. Unfortnuately when using the gnuradio block "UHD: USRP Sink" and
> setting the send_frame_size=1023 (or any other value I've tried) libuhd
Try to keep the frame sizes to powers of two. Non powers of two may make
issues somewhere in the USB stack.
-josh
------------------------------
Message: 2
Date: Thu, 11 Apr 2013 11:07:26 +0200
From: Youri Westerman <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] UHD driver segault
Message-ID:
<CAFSNd_Q+Du-47HueR3TuPQr2AjPTTyPVHL_RQENVSE=+zle...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Josh,
I've also tried 64, 128, 256 as values. Unfortunately that produces the
same segfault.
Youri
2013/4/11 Josh Blum <[email protected]>
>
>
> On 04/10/2013 03:29 AM, Youri Westerman wrote:
> > Hi,
> >
> > I'm trying to get the uhd driver working properly in combination with a
> > B100 USRP. Unfortnuately when using the gnuradio block "UHD: USRP Sink"
> and
> > setting the send_frame_size=1023 (or any other value I've tried) libuhd
>
> Try to keep the frame sizes to powers of two. Non powers of two may make
> issues somewhere in the USB stack.
>
> -josh
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Youri Westerman
Developer
Pluxbox
Sumatralaan 45
Mediapark - Studio 21
t: 035-7606060
e: [email protected]
w: http://www.pluxbox.nl
Pluxbox
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130411/436a6d23/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 11 Apr 2013 14:40:42 +0300
From: Sivan Toledo <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] GPSDO loss of lock
Message-ID:
<CAOL_ruHX0k5=gevkoifzpfcpvsfdjdwhjgvsjlensrxxzvy...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
We are trying to accurately measure time-of-arrival in two identical USRPs
(N200 with WBX), both with the built-in GPSDO. We see differences in
time-of-arrival between the two receivers, even at excellent SNRs, and we
are trying to track the reason for this. Both receivers are connected to
the same antenna through a T connector with identical cables.
One thing that we checked is the GPS lock, the LO lock, and the REF lock.
We test for all 3 every 64 packets of samples we get from UHD. We found
that the LO and REF are locked all the time, but the gps_locked sensor
reports loss of lock every 2 to 3 seconds. It then locks and unlocks a
couple of times (usually 4) in quick succession, then locks for 2-3 more
seconds, and so on.
The GPS antennas seem fine and the GGA sentence reports that the receiver
sees 11 satellites. So I don't think that flaky GPS reception is the
problem. This happens to both units.
We have 2 questions:
1. Why does the gps_locked reports no lock for a short period every few
seconds?
2. How does this affect the 10MHz clock to which the sampling clock and the
LO are locked? Can GPS loss of lock cause a significant drift or increased
phase noise in the 10MHz reference and the clocks that are locked to it?
Thanks, Sivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130411/4e2b8cd4/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 11 Apr 2013 15:18:52 +0200
From: Tim Schuschies <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Seq Error in Burst
Message-ID:
<caov+zhsle6o4vxqqwbgily9v3bvv2ertrg67xqxh9amq+o0...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi All,
I got a problem after I've adapted the VITA protocol header. I added some
fields to that header and now I got the Seq Error in Burst respond if I
want to send something via my USRP N210. Is it possible that expending the
VITA49 header influences the Sequence Number ?
Can I probably log the sequence numbers somehow ?
I tried to use a Xilinx Debugger and chipscope but that seems to be too
slow. Even if I use DSP clock as clock source for triggering. At start of a
transmission the actual Sequence Number is FFFFFFFF. When I start
transmitting something I'm only able to log the last used Sequence number.
If I'm sending without using my added fields in VITA header everything
works fine. The Last Sequence number i'm logging and the next expected
Sequence Number seems to be OK (i.e. 38h and 39h or 8Ch and 8Dh).
But if I use my newly implemented header I got somewhere an error. I think
I know that it occurs in line 125 of VITA TX Deframer (if i comment I don't
get the error).
There the sequence number and the expected sequence number doesn't match. I
don't know why. Does anyone have an idea ?
If I log the sequence numbers I get the same numbers at the end, so I don't
think that that's really a packet loss. What else could probably cause that
error ?
Thanks a lot
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130411/95f26a5a/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 11 Apr 2013 11:14:55 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GPSDO loss of lock
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> We are trying to accurately measure time-of-arrival in two identical
> USRPs (N200 with WBX), both with the built-in GPSDO. We see
> differences in time-of-arrival between the two receivers, even at
> excellent SNRs, and we are trying to track the reason for this. Both
> receivers are connected to the same antenna through a T connector with
> identical cables.
>
> One thing that we checked is the GPS lock, the LO lock, and the REF
> lock. We test for all 3 every 64 packets of samples we get from UHD.
> We found that the LO and REF are locked all the time, but the
> gps_locked sensor reports loss of lock every 2 to 3 seconds. It then
> locks and unlocks a couple of times (usually 4) in quick succession,
> then locks for 2-3 more seconds, and so on.
>
> The GPS antennas seem fine and the GGA sentence reports that the
> receiver sees 11 satellites. So I don't think that flaky GPS reception
> is the problem. This happens to both units.
>
> We have 2 questions:
> 1. Why does the gps_locked reports no lock for a short period every
> few seconds?
> 2. How does this affect the 10MHz clock to which the sampling clock
> and the LO are locked? Can GPS loss of lock cause a significant drift
> or increased phase noise in the 10MHz reference and the clocks that
> are locked to it?
>
> Thanks, Sivan
I can't tell you why the gps_locked sensor is coming and going.
But the oscillator on board the GPSDO is of high quality, and the servo
in the GPSDO takes a "long view", so loss-of-lock won't necessarily cause
any really bad issues with clock stability, as long as it's getting
good timing data on a regular basis.
Which version of UHD and firmware are you using?
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
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 8
*****************************************
