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: Wireshark dissectors (Nick Foster)
2. Re: Wireshark dissectors (Alexander Chemeris)
3. Re: USRP E100 segmentation faults (Xavier Clinquart)
4. Re: Wireshark dissectors (Dario Lombardo)
5. Re: Wireshark dissectors (Nick Foster)
6. Re: Wireshark dissectors (Alexander Chemeris)
7. Any card can give me four analog Rx channel? (Dan Zhao)
8. How to replace USRP1 XO ? (Dan Zhao)
9. Re: Any card can give me four analog Rx channel?
([email protected])
10. Why would usrp->get_rx_stream(stream_args) take forever? (mepard)
11. Re: Why would usrp->get_rx_stream(stream_args) take forever?
(Josh Blum)
12. Re: Why would usrp->get_rx_stream(stream_args) take forever?
(mepard)
13. Re: How to replace USRP1 XO ? (Mike Jameson)
14. Re: Problem using MIMO cable (Josh Blum)
15. Re: Wireshark dissectors (Dario Lombardo)
16. R2 N210 PPS input no longer functioning (Robert Watson)
17. Re: How long does USRP need to switch its center frequency
(Gong Zhang)
18. Re: How long does USRP need to switch its center frequency (lwei)
19. Re: Problem using MIMO cable (mepard)
----------------------------------------------------------------------
Message: 1
Date: Tue, 26 Mar 2013 09:40:19 -0700
From: Nick Foster <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Wireshark dissectors
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 03/26/2013 02:39 AM, Dario Lombardo wrote:
> Hello list!
> I'm pleased to announce you that both the dissectors for VRT/VITA 49
> and UHD have been accepted into the wireshark trunk. They are alredy
> available if you use the SVN version, while, to have them into you
> wireshark distribution package, you have to wait that the revision
> number 48550 is put into the distribution.
> Happy dissections!
> Dario
>
I don't want to make a big deal out of this as I'm sure it's a
miscommunication, but the copyright in the accepted VRT dissector reads:
* Copyright 2013, Alexander Chemeris ([email protected]),
Dario Lombardo ([email protected])
...whereas the original (which I wrote) says:
// Copyright 2012 Ettus Research LLC
There is no attribution to the original author or the original
repository in the Wireshark version, although Alexander's Github version
preserves attribution. The original can be found at:
https://github.com/bistromath/vrt-dissector
Dario, I trust you'll work to correct the attribution with the Wireshark
devs as you've been in communication with them already. I appreciate
your work in prepping the dissector for inclusion in Wireshark.
Thanks,
--n
>
> _______________________________________________
> 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/20130326/28698c43/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 26 Mar 2013 20:53:01 +0400
From: Alexander Chemeris <[email protected]>
To: Nick Foster <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Wireshark dissectors
Message-ID:
<CABmJbFXBn-V9ffvkMaskiqNysL1pdM=wpuUSt=asscyvgkj...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
That's certainly an error and should be fixed.
Dario, thank you for your efforts so far! I hope you could push this
last, but important change to the Wireshark trunk.
On Tue, Mar 26, 2013 at 8:40 PM, Nick Foster <[email protected]> wrote:
> On 03/26/2013 02:39 AM, Dario Lombardo wrote:
>
> Hello list!
> I'm pleased to announce you that both the dissectors for VRT/VITA 49 and UHD
> have been accepted into the wireshark trunk. They are alredy available if
> you use the SVN version, while, to have them into you wireshark distribution
> package, you have to wait that the revision number 48550 is put into the
> distribution.
> Happy dissections!
> Dario
>
> I don't want to make a big deal out of this as I'm sure it's a
> miscommunication, but the copyright in the accepted VRT dissector reads:
>
> * Copyright 2013, Alexander Chemeris ([email protected]), Dario
> Lombardo ([email protected])
>
> ...whereas the original (which I wrote) says:
>
> // Copyright 2012 Ettus Research LLC
>
> There is no attribution to the original author or the original repository in
> the Wireshark version, although Alexander's Github version preserves
> attribution. The original can be found at:
>
> https://github.com/bistromath/vrt-dissector
>
> Dario, I trust you'll work to correct the attribution with the Wireshark
> devs as you've been in communication with them already. I appreciate your
> work in prepping the dissector for inclusion in Wireshark.
>
> Thanks,
> --n
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru
------------------------------
Message: 3
Date: Tue, 26 Mar 2013 18:01:46 +0100
From: Xavier Clinquart <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP E100 segmentation faults
Message-ID:
<CAAYuUvSepZUqdUMrkEL7S7cZFTPLSgrwiTA=w8g-wgho2zf...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
2013/3/26 Philip Balister <[email protected]>
> On 03/26/2013 09:03 AM, Xavier Clinquart wrote:
> > Hello ,
> >
> >
> > I am Xavier Clinquart student at the Denayer institute Belgium. And I'm
> > currently working with the USRP E100 for my thesis .
> > Now i have been having this segmentation fault that keeps repeating
> itself
> > when i try to use the gnuradio-companion. Or when i try to minimise any
> > other window open at that current time.
> >
> > I am using the latest image and build from the ettus website and have not
> > made Any changes to it.
> >
> > is there anyone who had this problem and found a solution to it?
>
> >Can you send me the output for the console when it segfaults?
>
> >Philip
>
> ofcourse sorry i forgot to add it.
this is the error it outputs:
/usr/lib/python2.6/site-
packages/gnuradio/grc/gui/ActionHandler/py:69: GtKWarning:
IA_gdk_window_get_events: assertion 'GDK_IS_WINDOW (window)' failed
gtk.main
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130326/a2dfaf98/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 26 Mar 2013 18:15:59 +0100
From: Dario Lombardo <[email protected]>
To: Nick Foster <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Wireshark dissectors
Message-ID:
<caoyjjftvrh8n8k7yfdcm3oelfae2ypecbqlt0-nxb8rugk1...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Nick
I honestly don't remember why I changed that. Probably, as Alexander said,
it's something related to a bad cut/paste from somewhere. I didn't intend
to eat your credits :).
If you agree I can change it to
/* packet-vrt.c
* Routines for VRT (VITA 49) packet disassembly
* Copyright 2012 Ettus Research LLC - Nick Foster <[email protected]>
*
* Ported to wireshark by Dario Lombardo ([email protected]) - 2013
* Original dissector: https://github.com/bistromath/vrt-dissector
*
* $Id: packet-vrt.c 47974 2013-03-21 13:24:24Z eapache $
*
* Wireshark - Network traffic analyzer
* By Gerald Combs <[email protected]>
* Copyright 1998 Gerald Combs
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301, USA.
*/
Please Nick and Alexander notify me if it ok for you or if you'd like to
change something.
On Tue, Mar 26, 2013 at 5:40 PM, Nick Foster <[email protected]> wrote:
> On 03/26/2013 02:39 AM, Dario Lombardo wrote:
>
> Hello list!
> I'm pleased to announce you that both the dissectors for VRT/VITA 49 and
> UHD have been accepted into the wireshark trunk. They are alredy available
> if you use the SVN version, while, to have them into you wireshark
> distribution package, you have to wait that the revision number 48550 is
> put into the distribution.
> Happy dissections!
> Dario
>
> I don't want to make a big deal out of this as I'm sure it's a
> miscommunication, but the copyright in the accepted VRT dissector reads:
>
> * Copyright 2013, Alexander Chemeris ([email protected]),
> Dario Lombardo ([email protected])
>
> ...whereas the original (which I wrote) says:
>
> // Copyright 2012 Ettus Research LLC
>
> There is no attribution to the original author or the original repository
> in the Wireshark version, although Alexander's Github version preserves
> attribution. The original can be found at:
>
> https://github.com/bistromath/vrt-dissector
>
> Dario, I trust you'll work to correct the attribution with the Wireshark
> devs as you've been in communication with them already. I appreciate your
> work in prepping the dissector for inclusion in Wireshark.
>
> Thanks,
> --n
>
>
> _______________________________________________
> USRP-users mailing
> [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/20130326/9c10c5cc/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 26 Mar 2013 10:23:13 -0700
From: Nick Foster <[email protected]>
To: Dario Lombardo <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Wireshark dissectors
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 03/26/2013 10:15 AM, Dario Lombardo wrote:
> Hi Nick
> I honestly don't remember why I changed that. Probably, as Alexander
> said, it's something related to a bad cut/paste from somewhere. I
> didn't intend to eat your credits :).
>
> If you agree I can change it to
>
> /* packet-vrt.c
> * Routines for VRT (VITA 49) packet disassembly
> * Copyright 2012 Ettus Research LLC - Nick Foster <[email protected]
> <mailto:[email protected]>>
> *
> * Ported to wireshark by Dario Lombardo ([email protected]
> <mailto:[email protected]>) - 2013
> * Original dissector: https://github.com/bistromath/vrt-dissector
> *
> * $Id: packet-vrt.c 47974 2013-03-21 13:24:24Z eapache $
> *
> * Wireshark - Network traffic analyzer
> * By Gerald Combs <[email protected] <mailto:[email protected]>>
> * Copyright 1998 Gerald Combs
> *
> * This program is free software; you can redistribute it and/or
> * modify it under the terms of the GNU General Public License
> * as published by the Free Software Foundation; either version 2
> * of the License, or (at your option) any later version.
> *
> * This program is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU General Public License for more details.
> *
> * You should have received a copy of the GNU General Public License
> * along with this program; if not, write to the Free Software
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301, USA.
> */
>
> Please Nick and Alexander notify me if it ok for you or if you'd like
> to change something.
That's totally fine by me. Thanks Dario.
--n
>
> On Tue, Mar 26, 2013 at 5:40 PM, Nick Foster <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 03/26/2013 02:39 AM, Dario Lombardo wrote:
>> Hello list!
>> I'm pleased to announce you that both the dissectors for VRT/VITA
>> 49 and UHD have been accepted into the wireshark trunk. They are
>> alredy available if you use the SVN version, while, to have them
>> into you wireshark distribution package, you have to wait that
>> the revision number 48550 is put into the distribution.
>> Happy dissections!
>> Dario
>>
> I don't want to make a big deal out of this as I'm sure it's a
> miscommunication, but the copyright in the accepted VRT dissector
> reads:
>
> * Copyright 2013, Alexander Chemeris
> ([email protected]
> <mailto:[email protected]>), Dario Lombardo
> ([email protected] <mailto:[email protected]>)
>
> ...whereas the original (which I wrote) says:
>
> // Copyright 2012 Ettus Research LLC
>
> There is no attribution to the original author or the original
> repository in the Wireshark version, although Alexander's Github
> version preserves attribution. The original can be found at:
>
> https://github.com/bistromath/vrt-dissector
>
> Dario, I trust you'll work to correct the attribution with the
> Wireshark devs as you've been in communication with them already.
> I appreciate your work in prepping the dissector for inclusion in
> Wireshark.
>
> Thanks,
> --n
>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[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/20130326/77c17eba/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 26 Mar 2013 21:36:13 +0400
From: Alexander Chemeris <[email protected]>
To: Nick Foster <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Wireshark dissectors
Message-ID:
<cabmjbfvsj3curzfxc752kxnlnlezyqipn6tds6zgm8vfr_z...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Well, I'd like to get some credits as well. :)
Otherwise it's totally fine with me.
On Tue, Mar 26, 2013 at 9:23 PM, Nick Foster <[email protected]> wrote:
> On 03/26/2013 10:15 AM, Dario Lombardo wrote:
>
> Hi Nick
> I honestly don't remember why I changed that. Probably, as Alexander said,
> it's something related to a bad cut/paste from somewhere. I didn't intend to
> eat your credits :).
>
> If you agree I can change it to
>
> /* packet-vrt.c
> * Routines for VRT (VITA 49) packet disassembly
> * Copyright 2012 Ettus Research LLC - Nick Foster <[email protected]>
> *
> * Ported to wireshark by Dario Lombardo ([email protected]) - 2013
> * Original dissector: https://github.com/bistromath/vrt-dissector
> *
> * $Id: packet-vrt.c 47974 2013-03-21 13:24:24Z eapache $
> *
> * Wireshark - Network traffic analyzer
> * By Gerald Combs <[email protected]>
> * Copyright 1998 Gerald Combs
> *
> * This program is free software; you can redistribute it and/or
> * modify it under the terms of the GNU General Public License
> * as published by the Free Software Foundation; either version 2
> * of the License, or (at your option) any later version.
> *
> * This program is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU General Public License for more details.
> *
> * You should have received a copy of the GNU General Public License
> * along with this program; if not, write to the Free Software
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301, USA.
> */
>
> Please Nick and Alexander notify me if it ok for you or if you'd like to
> change something.
>
>
> That's totally fine by me. Thanks Dario.
>
> --n
>
>
>
> On Tue, Mar 26, 2013 at 5:40 PM, Nick Foster <[email protected]> wrote:
>>
>> On 03/26/2013 02:39 AM, Dario Lombardo wrote:
>>
>> Hello list!
>> I'm pleased to announce you that both the dissectors for VRT/VITA 49 and
>> UHD have been accepted into the wireshark trunk. They are alredy available
>> if you use the SVN version, while, to have them into you wireshark
>> distribution package, you have to wait that the revision number 48550 is put
>> into the distribution.
>> Happy dissections!
>> Dario
>>
>> I don't want to make a big deal out of this as I'm sure it's a
>> miscommunication, but the copyright in the accepted VRT dissector reads:
>>
>> * Copyright 2013, Alexander Chemeris ([email protected]),
>> Dario Lombardo ([email protected])
>>
>> ...whereas the original (which I wrote) says:
>>
>> // Copyright 2012 Ettus Research LLC
>>
>> There is no attribution to the original author or the original repository
>> in the Wireshark version, although Alexander's Github version preserves
>> attribution. The original can be found at:
>>
>> https://github.com/bistromath/vrt-dissector
>>
>> Dario, I trust you'll work to correct the attribution with the Wireshark
>> devs as you've been in communication with them already. I appreciate your
>> work in prepping the dissector for inclusion in Wireshark.
>>
>> Thanks,
>> --n
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru
------------------------------
Message: 7
Date: Tue, 26 Mar 2013 14:36:58 -0400
From: Dan Zhao <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Any card can give me four analog Rx channel?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi,
I would like to know if there any daughter card for USRP1 can give me four
independent four receive channel?
Best Regards,
Dan
------------------------------
Message: 8
Date: Tue, 26 Mar 2013 14:40:46 -0400
From: Dan Zhao <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] How to replace USRP1 XO ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Is there a step by step instruction to replace USRP1 XO with TCXO or OCXO? I
want use 1ppm TCXO in USRP1. Thanks
Best Regards,
Dan
------------------------------
Message: 9
Date: Tue, 26 Mar 2013 14:47:01 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] Any card can give me four analog Rx
channel?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 26 Mar 2013 14:36, Dan Zhao wrote:
> Hi,
>
> I would like to
know if there any daughter card for USRP1 can give me four independent
four receive channel?
>
> Best Regards,
> Dan
>
_______________________________________________
You have mentioned
frequency range.
But a USRP1 with the 4rx fpga image can give you 4
digitally-carved-out channels from analog bandwidth that doesn't exceed
32Mhz from one or two BASIC_RX cards.
But none of the USRP series have
4 independent analog receive chains.
There is the QR210, which is four
receive chains tied to a common LO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130326/7208d946/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 26 Mar 2013 14:16:43 -0500
From: mepard <[email protected]>
To: [email protected]
Subject: [USRP-users] Why would usrp->get_rx_stream(stream_args) take
forever?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
It's taking around 20 seconds.
-Marc
------------------------------
Message: 11
Date: Tue, 26 Mar 2013 15:08:48 -0500
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Why would usrp->get_rx_stream(stream_args)
take forever?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 03/26/2013 02:16 PM, mepard wrote:
> It's taking around 20 seconds.
>
Wow. It should probably be in milliseconds. Is this on the first run
after power cycle or subsequent runs?
I cant think of why. Perhaps the loop to flush the rx socket, if for
some reason it was being pounded with data faster than it could flush.
Or maybe you have a lot of streams and its arping for the destination
serially, but that would mean like over 20 streams.
This the the hook where the streamer is created:
http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/host/lib/usrp/usrp2/io_impl.cpp#L420
Are you able to put a few prints and see which line is just sitting
there for 20 seconds?
-josh
> -Marc
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 12
Date: Tue, 26 Mar 2013 15:31:51 -0500
From: mepard <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Why would usrp->get_rx_stream(stream_args)
take forever?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On Mar 26, 2013, at 3:08 PM, Josh Blum <[email protected]> wrote:
> Wow. It should probably be in milliseconds. Is this on the first run
> after power cycle or subsequent runs?
> ?
> Are you able to put a few prints and see which line is just sitting
> there for 20 seconds?
Never mind. It was some of my own code immediately following the get_rx_stream
call. It was just allocating the buffers, no need to print that step, of
course. Turns out they were Great Big Buffers. Much bigger than I intended.
Sorry.
-Marc
------------------------------
Message: 13
Date: Tue, 26 Mar 2013 22:25:57 +0000
From: Mike Jameson <[email protected]>
To: Dan Zhao <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] How to replace USRP1 XO ?
Message-ID:
<cajcjmismm8j+8rwlldoyd5vgczo56+7mzffjzihsge3r4zu...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Dan,
See:
http://code.google.com/p/clock-tamer/wiki/ClockTamerUSRPInstallation
and...
http://gnuradio.org/redmine/projects/gnuradio/wiki/OpenBTSClockModifications
and...
http://files.ettus.com/uhd_docs/manual/html/usrp1.html#external-clock-modification
Any questions, just ask.
Mike
--
Mike Jameson M0MIK BSc
Radio Communications Technology Specialist
Email: [email protected]
Web: http://scanoo.com
On 26 March 2013 18:40, Dan Zhao <[email protected]> wrote:
> Is there a step by step instruction to replace USRP1 XO with TCXO or OCXO?
> I want use 1ppm TCXO in USRP1. Thanks
>
> Best Regards,
> Dan
> _______________________________________________
> 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/20130326/8d318ec3/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 26 Mar 2013 17:41:30 -0500
From: Josh Blum <[email protected]>
To: mepard <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Problem using MIMO cable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 03/25/2013 10:50 AM, mepard wrote:
> (Was: [USRP-users] Disturbance in the force or Glitch in the
> matrix?)
>
> This is looking like a problem with MIMO cable support.
>
> This morning I removed the MIMO cable, put both N210s on the same
> reference and PPS, and updated the UHD USRP Source to use external
> clock and time sources for both motherboards. I've now done 10
> 70-second acquisitions in a row with no glitches at all. With the
> MIMO cable I never had two 70-second successes in a row and most
> 70-second acquisitions had 2 or 3 glitches.
>
> Now I suspect an issue keeping the FPGAs synchronized over the MIMO
> cable. Both N210s already had their own ethernet connection and the
> MIMO cable was only being used to synchronize samples times.
>
Thats really great that you have narrowed down the strange behaviour.
Can I ask, what does the network setup look like? Are there two distinct
ethernet subnets for ethernet network cards. I ask because if you happen
to have a switch on both USRP ethernet interfaces and a MIMO cable,
there could be routing loop issues.
-josh
> -Marc
>
>
> On Mar 21, 2013, at 6:01 PM, mepard <[email protected]> wrote:
>
>> On Mar 19, 2013, at 4:21 PM, mepard <[email protected]> wrote:
>>
>>> Increasing the MTU and recv_frame_size to 4096 and the spp
>>> (samples per packet) to 1000 seems to prevent the dropped
>>> samples.
>>
>> Turns out this wasn't the case -- it's an intermittent problem and
>> I just got lucky.
>>
>> I looked into how the packets from the two N210s are aligned and
>> added some instrumentation to super_recv_packet_handler.hpp
>> (enclosed). That's definitely where the samples are getting
>> dropped, but I'm still not sure what the root cause is. In
>> recv_packet_handler::alignment_check, I made it write a message
>> with the packet type when it is about to toss existing buffers due
>> to the time. Lost samples I see in the data correspond to these
>> messages. I also added a message when it (re)gains alignment.
>> Here's what a 70-second acquisition looks like:
>>
>> _A_000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000_A_000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000_A_000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000_A_000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000_A_0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000_A_
>>
>>
>>
The first _A_ is the initial alignment and the subsequent _A_s are when
it regains alignment after the zeros which represent dropped buffers due
to a PACKET_IF_DATA. Note there are no sequence errors. So far, that has
been the case every single time. I also added more one-letter messages
for other conditions and none of those are appearing either.
>>
>> I did find one thing a little suspicious. It looks like the trick
>> of swapping the current and next buffer info's when returning an
>> error could potentially break the relationship between current and
>> previous info's, triggering PACKET_TIMESTAMP_ERROR, but I have not
>> seen it actually happen.
>>
>> The usual sample rate is 12.5e6 sps, which is what I used with the
>> sequence above. When reduced, the packet drops still occur, but it
>> seems to take fewer dropped packets to recover with lower sample
>> rates.
>>
>> At 3125000 sps I got this:
>>
>> _A_0000000000000000000000000000000000000000_A_000000000000000000000000000000000000000000_A_0000000000000000000000000000000000000000_A_
>>
>>
>>
At 390625 sps, this:
>>
>> _A_0000_A_0000_A_0000_A_0000_A_
>>
>> Still no sequence errors or the like.
>>
>> I can understand how dropped packets from either box can cause
>> this, but why would it always be a multiple of 16 packets, thus
>> avoiding a PACKET_SEQUENCE_ERROR?
>>
>> Any ideas?
>>
>> -Marc
>>
>> <super_recv_packet_handler.hpp>_______________________________________________
>>
>>
USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 15
Date: Wed, 27 Mar 2013 09:34:36 +0100
From: Dario Lombardo <[email protected]>
To: Alexander Chemeris <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Wireshark dissectors
Message-ID:
<CAOYJJfucnGNxNT+UaRdYbrhyoqYBWvYu=O+gBr5n-dpkH=x...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I would post this version, if you both agree.
/* packet-vrt.c
* Routines for VRT (VITA 49) packet disassembly
* Copyright 2012 Ettus Research LLC - Nick Foster <[email protected]>:
original dissector
* Copyright 2013 Alexander Chemeris <[email protected]>:
dissector improvement
* Copyright 2013 Dario Lombardo ([email protected]): Official Wireshark port
*
* Original dissector repository:
https://github.com/bistromath/vrt-dissector
*
* $Id: packet-vrt.c 47974 2013-03-21 13:24:24Z eapache $
*
* Wireshark - Network traffic analyzer
* By Gerald Combs <[email protected]>
* Copyright 1998 Gerald Combs
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301, USA.
*/
On Tue, Mar 26, 2013 at 6:36 PM, Alexander Chemeris <
[email protected]> wrote:
> Well, I'd like to get some credits as well. :)
> Otherwise it's totally fine with me.
>
> On Tue, Mar 26, 2013 at 9:23 PM, Nick Foster <[email protected]> wrote:
> > On 03/26/2013 10:15 AM, Dario Lombardo wrote:
> >
> > Hi Nick
> > I honestly don't remember why I changed that. Probably, as Alexander
> said,
> > it's something related to a bad cut/paste from somewhere. I didn't
> intend to
> > eat your credits :).
> >
> > If you agree I can change it to
> >
> > /* packet-vrt.c
> > * Routines for VRT (VITA 49) packet disassembly
> > * Copyright 2012 Ettus Research LLC - Nick Foster <[email protected]>
> > *
> > * Ported to wireshark by Dario Lombardo ([email protected]) - 2013
> > * Original dissector: https://github.com/bistromath/vrt-dissector
> > *
> > * $Id: packet-vrt.c 47974 2013-03-21 13:24:24Z eapache $
> > *
> > * Wireshark - Network traffic analyzer
> > * By Gerald Combs <[email protected]>
> > * Copyright 1998 Gerald Combs
> > *
> > * This program is free software; you can redistribute it and/or
> > * modify it under the terms of the GNU General Public License
> > * as published by the Free Software Foundation; either version 2
> > * of the License, or (at your option) any later version.
> > *
> > * This program is distributed in the hope that it will be useful,
> > * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > * GNU General Public License for more details.
> > *
> > * You should have received a copy of the GNU General Public License
> > * along with this program; if not, write to the Free Software
> > * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > 02110-1301, USA.
> > */
> >
> > Please Nick and Alexander notify me if it ok for you or if you'd like to
> > change something.
> >
> >
> > That's totally fine by me. Thanks Dario.
> >
> > --n
> >
> >
> >
> > On Tue, Mar 26, 2013 at 5:40 PM, Nick Foster <[email protected]> wrote:
> >>
> >> On 03/26/2013 02:39 AM, Dario Lombardo wrote:
> >>
> >> Hello list!
> >> I'm pleased to announce you that both the dissectors for VRT/VITA 49 and
> >> UHD have been accepted into the wireshark trunk. They are alredy
> available
> >> if you use the SVN version, while, to have them into you wireshark
> >> distribution package, you have to wait that the revision number 48550
> is put
> >> into the distribution.
> >> Happy dissections!
> >> Dario
> >>
> >> I don't want to make a big deal out of this as I'm sure it's a
> >> miscommunication, but the copyright in the accepted VRT dissector reads:
> >>
> >> * Copyright 2013, Alexander Chemeris ([email protected]),
> >> Dario Lombardo ([email protected])
> >>
> >> ...whereas the original (which I wrote) says:
> >>
> >> // Copyright 2012 Ettus Research LLC
> >>
> >> There is no attribution to the original author or the original
> repository
> >> in the Wireshark version, although Alexander's Github version preserves
> >> attribution. The original can be found at:
> >>
> >> https://github.com/bistromath/vrt-dissector
> >>
> >> Dario, I trust you'll work to correct the attribution with the Wireshark
> >> devs as you've been in communication with them already. I appreciate
> your
> >> work in prepping the dissector for inclusion in Wireshark.
> >>
> >> Thanks,
> >> --n
> >>
> >>
> >> _______________________________________________
> >> USRP-users mailing list
> >> [email protected]
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >>
> >
> >
>
>
>
> --
> Regards,
> Alexander Chemeris.
> CEO, Fairwaves LLC / ??? ???????
> http://fairwaves.ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130327/d88a7677/attachment-0001.html>
------------------------------
Message: 16
Date: Wed, 27 Mar 2013 10:37:30 +0000
From: Robert Watson <[email protected]>
To: [email protected]
Subject: [USRP-users] R2 N210 PPS input no longer functioning
Message-ID:
<cap4wt-bqplh52tl7k1nxt--z0smzagpesxxb-puifd1yske...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi Folks,
I've just upgraded my R2 N210 and previously working external
PPS/10MHz arrangement and encountered a problem. In a nutshell, no
matter what I do I "test_pps_input" can't catch my PPS input. This was
a hardware setup that was previously working (I'm actually using a
Quartzlock E8-Y GPSDO). The PPS is there - I've checked on a 'scope
and its nice and clean.
My UHD was built from the git repo and the USRP flashed with the
latest images grabbed using uhd_images_downloader.py.
The UHD build is UHD_003.005.001-55-g8488eb09 and the images are
tagged 003.005.001-release. In GNURadio I can get the clock and time
to external but if I try and sync to PPS it fails. While the clock is
switched to external, if I remove the 10MHz, the PLL unlocks which is
what I'd expect so I believe it can see the 10MHz. I've tried using
the internal PPS2 SMA (J506) and tried switching the J510 jumper from
1-2 to 2-3 without success - plus all permutations of the above =)
Have I missed something? Is there anything I should try before rolling
back to some older UHD and images?
Many thanks,
Rob.
------------------------------
Message: 17
Date: Wed, 27 Mar 2013 20:18:46 +0800
From: Gong Zhang <[email protected]>
To: Nick Foster <[email protected]>, lwei <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] How long does USRP need to switch its center
frequency
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
2013/3/26 1:02, Nick Foster wrote:
> On 03/25/2013 06:44 AM, lwei wrote:
>> Hi all,
>>
>> I know this is a rather basic question, but I notice the function
>> usrp->set_rx_freq(freq); actually takes around 19 ms to return.
>>
>> So I then tried to use wireshark to capture the packets, the I notice
>> between there are 32 UDP packets, sent with 36 bytes payload...and the
>> time spent on those packets are about 19 ms, which corresponds with the
>> software delay I measured with cpp binary
>>
>> I am using Boost_104000, UHD_003.001.000-9f1e49e (ye..a bit out of date
>> I know, hope this is not where things go wrong).
>>
>> Does anyone know why it takes so long to set the frequency? is there
>> something I am doing wrong or is this issue already solved by a newer
>> uhd version?
>>
>> Kind regards,
>>
> Changing the RF frequency is slower and requiresSPI writes as well as
> waiting for the PLL to lock onto the new frequency. If you are hopping
> around within the 40MHz baseband bandwidth,you can tune the DDC/DUC in
> the FPGA much faster using the advanced tuning parameters.
>
> --n
From previous question,I notice that the tune time of WBX and SBX is
300us.What's your daughterboard?
And I have a basic question.What's the range of intermediate
frequency?And we can down convert the frequency-hopping signal in
FPGA.Is it correct?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130327/ecf8af0f/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 27 Mar 2013 13:43:10 +0100
From: lwei <[email protected]>
To: Gong Zhang <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] How long does USRP need to switch its center
frequency
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
I am using XCVR2450.
Maybe a question for gong, how did you measure the latency? What is the
UHD version you are using ?
I have never tried with the advanced tuning, what do you mean exactly
with "baseband tuning within 40MHz"
Thanks,
Wei
On Wed, 2013-03-27 at 20:18 +0800, Gong Zhang wrote:
> 2013/3/26 1:02, Nick Foster wrote:
>
> > On 03/25/2013 06:44 AM, lwei wrote:
> >
> > >
> > > Hi all,
> > >
> > > I know this is a rather basic question, but I notice the function
> > > usrp->set_rx_freq(freq); actually takes around 19 ms to return.
> > >
> > > So I then tried to use wireshark to capture the packets, the I notice
> > > between there are 32 UDP packets, sent with 36 bytes payload...and the
> > > time spent on those packets are about 19 ms, which corresponds with the
> > > software delay I measured with cpp binary
> > >
> > > I am using Boost_104000, UHD_003.001.000-9f1e49e (ye..a bit out of date
> > > I know, hope this is not where things go wrong).
> > >
> > > Does anyone know why it takes so long to set the frequency? is there
> > > something I am doing wrong or is this issue already solved by a newer
> > > uhd version?
> > >
> > > Kind regards,
> > >
> >
> > Changing the RF frequency is slower and requires SPI writes as well
> > as waiting for the PLL to lock onto the new frequency. If you are
> > hopping around within the 40MHz baseband bandwidth, you can tune the
> > DDC/DUC in the FPGA much faster using the advanced tuning
> > parameters.
> >
> > --n
>
> From previous question,I notice that the tune time of WBX and SBX is
> 300us.What's your daughterboard?
> And I have a basic question.What's the range of intermediate
> frequency?And we can down convert the frequency-hopping signal in
> FPGA.Is it correct?
--
Wei Liu
Researcher
Ghent University - IBBT
Department of Information Technology (INTEC)
Internet Based Communication Networks and Services (IBCN)
Zuiderpoort Office Park, Building C0
Gaston Crommenlaan 8 bus 201
9050 Gent, Belgium
http://www.ibcn.intec.ugent.be/
Phone: +32 (0)9 33 14946
Fax: +32 (0)9 33 14899
E-mail: [email protected]
Route: http://www.ibcn.intec.ugent.be/route.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130327/adec5eec/attachment-0001.html>
------------------------------
Message: 19
Date: Wed, 27 Mar 2013 08:15:56 -0500
From: mepard <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Problem using MIMO cable
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
On Mar 26, 2013, at 5:41 PM, Josh Blum <[email protected]> wrote:
> Thats really great that you have narrowed down the strange behaviour.
>
> Can I ask, what does the network setup look like? Are there two distinct
> ethernet subnets for ethernet network cards. I ask because if you happen
> to have a switch on both USRP ethernet interfaces and a MIMO cable,
> there could be routing loop issues.
No switch is involved. There's an ethernet port in the PC for each N210: one
onboard provided by the chipset with IPv4 address 192.168.30.1/25 and one Intel
PCIe card with IPv4 address 192.168.10.1/24. There's another chipset port
connected to the office network with DHCP-provided address 192.168.1.236/24.
One other surprise is that the system won't sustain 25 Msps on either port
individually or simultaneously; it gets an overrun after 3 packets. 12.5 Msps
is okay.
The system is running Ubuntu 12.10 on a Core i7-3820 at 3.6 GHz in an X79
motherboard with 64GB of RAM. The ethernet ports are handled by the e1000e
Intel? PRO/1000 Network Driver - 2.0.0-k, which I think is the latest.
-Marc
------------------------------
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 31, Issue 26
******************************************
