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: Sequence Errors on USRP N200 (Josh Blum)
2. Re: UDP Socket, SO_RCVBUF (Josh Blum)
3. Re: UDP Socket, SO_RCVBUF (Simon HB9DRV)
4. Re: LiveUSB SDR Environment (Dan)
5. Re: Sequence Errors on USRP N200 (Jahshan Bhatti)
6. Re: Sequence Errors on USRP N200 (Jahshan Bhatti)
7. Re: Sequence Errors on USRP N200 (Jahshan Bhatti)
8. Re: Sequence Errors on USRP N200 (Josh Blum)
9. Re: Sequence Errors on USRP N200 (Jahshan Bhatti)
10. Re: Sequence Errors on USRP N200 (Jahshan Bhatti)
11. Re: Sequence Errors on USRP N200 (Jahshan Bhatti)
12. Re: Sequence Errors on USRP N200 (Jahshan Bhatti)
13. Problem with multi-channel UHD version 003.004.001 (Paola Madonna)
----------------------------------------------------------------------
Message: 1
Date: Sun, 24 Jun 2012 09:21:24 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Sequence Errors on USRP N200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/23/2012 09:59 PM, Jahshan Bhatti wrote:
> Hi all,
>
> I'm writing a program to delay and playback received samples continuously
> with the USRP N200. Everything seems to be working fine, except for the
> occasional sequence error. Why does this happen? Is the network layer
> dropping or reordering packets?
>
Correct, this would probably be a dropped packet.
You might expect packets to get re-ordered and even dropped when UDP is
sent out into the internet and taking different paths to get to the
destination, etc.
But this is a direct point to point link. So, you might have one of
those less than perfect ethernet cards that on occasion, drop packets.
Some applications would re-send, some would silently drop (like skype),
USRP is just one of the few devices that reports the event.
-josh
------------------------------
Message: 2
Date: Sun, 24 Jun 2012 09:23:49 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UDP Socket, SO_RCVBUF
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/24/2012 01:34 AM, Simon HB9DRV wrote:
> Hi,
>
>
>
> Is a handle to the UDP socket available? I would like to change the buffer
> size with SO_RCVBUF. I've searched through the source but am not at all
> sure.
>
The constructor takes arbitrary key/value pairs. One possible key is the
"recv_buff_size". By default this is 50MB. See docs here:
http://files.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buffers
-josh
>
>
> Simon Brown, HB9DRV
> http://dit-dit-dit.com
>
>
>
> Not sent from an iPhone: I don't have one and I don't want one.
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Sun, 24 Jun 2012 18:36:10 +0200
From: "Simon HB9DRV" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] UDP Socket, SO_RCVBUF
Message-ID: <[email protected]>
Content-Type: text/plain; charset="US-ASCII"
Thanks, 50MB is fine so I'll use the defaults.
Simon Brown, HB9DRV
http://dit-dit-dit.com
You are standing at the end of a road before a small brick building. Around
you is a forest.
A small stream flows out of the building and down a gully. The sunspot count
is 285.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Josh Blum
The constructor takes arbitrary key/value pairs. One possible key is the
"recv_buff_size". By default this is 50MB. See docs here:
http://files.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buf
fers
------------------------------
Message: 4
Date: Sun, 24 Jun 2012 18:52:07 +0200
From: Dan <[email protected]>
To: Stan Gamla <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] LiveUSB SDR Environment
Message-ID:
<ca+no3fg6vag1ge8zygksix-ajshbb1g_whcpcqgzo1xa6sg...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I have downloaded the tar.gz file. How do I make my USB drive bootable. Is
there any software that I can use to make my flash drive bootable. I will
really appreciate it.
Regards,
Daniel Mwasi
On Sat, Jun 23, 2012 at 10:24 AM, Stan Gamla <[email protected]> wrote:
> **
>
> Matt,
>
> Nice idea--perhaps to be shipped with each USRP as standard in the
> future..?
>
> " ** A .tar.gz file with the file system can be downloaded
> http://files.ettus.com/liveusb/casper-rw.tar.gz. "
>
> In connection with the GZIP-archive that is available at the address given
> in the link above, could you please post instructions on how to create ones
> own USB bootable drive?
>
> Thanks in advance.
>
> Stan
>
> -----Original Message-----
> From: [email protected] [
> mailto:[email protected]<[email protected]>]
> On Behalf Of Matt Ettus
> Sent: 18 June 2012 22:57
> To: [email protected]
> Subject: [USRP-users] Announcing the LiveUSB SDR Environment
>
> Ettus Research has released the LiveUSB SDR Environment - a 16 GB bootable
> USB 3.0 drive, which comes pre-installed with Ubuntu 11.10, UHD (USRP
> Hardware Driver), GNU Radio, OpenBTS, and associated documentation. The SDR
> Environment enables users to get up and running with the USRP product
> family quickly and easily, and lets users familiarize themselves with the
> included software before installing it on their own. Additionally, the
> portability of the LiveUSB file system can be used to deploy standard
> configurations in classrooms, R&D labs, or other USRP installations.
>
> https://www.ettus.com/product/details/LiveUSB
>
> Features:
> * Ubuntu 11.10, 64-bit
> * Pre-installed Software: USRP Hardware Driver (UHD), GNU Radio, OpenBTS
> * Documentation Included on Drive
> * 16 GB
> * USB 3.0 Read/Write Speeds - fast boot times and RF record/playback
> capability
> * USB 2.0 Fallback
> * Persistent File system - save files, configurations, and other
> customizations
> * Portability - take your projects with you and boot on any PC
>
> The LiveUSB includes the most recent release of UHD, GNU Radio, and
> OpenBTS. UHD is compatible with all USRP devices, and allows applications
> to be easily ported across different USRP models. The UHD installation
> includes documentation and examples. GNU Radio is an easy-to-use,
> open-source, DSP toolbox that comes with GNU Radio Companion, a graphical
> development tool. OpenBTS is an open-source GSM air-interface
> implementation, which can be used with the USRP product family to assemble
> a fully functional cellular base station.
>
> The LiveUSB Ubuntu OS is pre-configured to install UHD and GNU Radio from
> the Ettus Research 'apt' repositories. This allows users to update the
> software without manually downloading, building, and installing the source
> code.
>
> This drive is compatible with USB 2.0 ports, but the system will take
> longer to boot, load programs, and respond to user interaction.
>
> Now, developing with the USRP product family is as easy as plugging in the
> LiveUSB SDR Environment and booting up!
>
> You can buy a USB 3 Flash Drive with the environment on it here:
>
> https://www.ettus.com/product/details/LiveUSB
>
> Matt Ettus
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> 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/20120624/55141562/attachment-0001.html>
------------------------------
Message: 5
Date: Sun, 24 Jun 2012 13:32:51 -0500
From: Jahshan Bhatti <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Sequence Errors on USRP N200
Message-ID:
<cajome11tx7khztbbozfshccr8wgjvyfheydaktgmn-pyxbd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Sun, Jun 24, 2012 at 11:21 AM, Josh Blum <[email protected]> wrote:
>
>
> On 06/23/2012 09:59 PM, Jahshan Bhatti wrote:
> > Hi all,
> >
> > I'm writing a program to delay and playback received samples continuously
> > with the USRP N200. Everything seems to be working fine, except for the
> > occasional sequence error. Why does this happen? Is the network layer
> > dropping or reordering packets?
> >
>
> Correct, this would probably be a dropped packet.
>
> You might expect packets to get re-ordered and even dropped when UDP is
> sent out into the internet and taking different paths to get to the
> destination, etc.
>
> But this is a direct point to point link. So, you might have one of
> those less than perfect ethernet cards that on occasion, drop packets.
> Some applications would re-send, some would silently drop (like skype),
> USRP is just one of the few devices that reports the event.
>
> -josh
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
Thanks Josh. I've got the USRP plugged through a router, and I was able to
correlate the sequence errors with increased network traffic. I guess I'll
have to use a direct point to point link.
~Jahshan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120624/650d17c9/attachment-0001.html>
------------------------------
Message: 6
Date: Sun, 24 Jun 2012 17:41:42 -0500
From: Jahshan Bhatti <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Sequence Errors on USRP N200
Message-ID:
<cajome12t5wznzur8sokdyd10gyje7nlpc8s+grupzacgzhy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
>
> On 06/23/2012 09:59 PM, Jahshan Bhatti wrote:
> > Hi all,
> >
> > I'm writing a program to delay and playback received samples continuously
> > with the USRP N200. Everything seems to be working fine, except for the
> > occasional sequence error. Why does this happen? Is the network layer
> > dropping or reordering packets?
> >
>
>
Regarding my delay and playback app, how well does the USRP obey the
time_spec commands? I tried to delay the samples by one second, and it
seems like the actual delay is off by around 4 ms (and the delay is not
consistent). I need within 50 nanosecond precision for my application.
Thanks,
~Jahshan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120624/17e4e2ef/attachment-0001.html>
------------------------------
Message: 7
Date: Sun, 24 Jun 2012 17:45:45 -0500
From: Jahshan Bhatti <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Sequence Errors on USRP N200
Message-ID:
<CAJOme13fEK2v3T+_gjvDm4X8+2XmGAGU47-5e1Za0k7ALe=m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Sun, Jun 24, 2012 at 5:41 PM, Jahshan Bhatti <[email protected]>wrote:
>
>
> Regarding my delay and playback app, how well does the USRP obey the
> time_spec commands? I tried to delay the samples by one second, and it
> seems like the actual delay is off by around 4 ms (and the delay is not
> consistent). I need within 50 nanosecond precision for my application.
>
> Thanks,
> ~Jahshan
>
If I can recover the precise delay (basically know the exact start time of
the rx burst and tx burst) after the fact, that would be acceptable too.
~Jahshan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120624/f2e4f782/attachment-0001.html>
------------------------------
Message: 8
Date: Sun, 24 Jun 2012 16:08:01 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Sequence Errors on USRP N200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/24/2012 03:41 PM, Jahshan Bhatti wrote:
>>
>> On 06/23/2012 09:59 PM, Jahshan Bhatti wrote:
>>> Hi all,
>>>
>>> I'm writing a program to delay and playback received samples continuously
>>> with the USRP N200. Everything seems to be working fine, except for the
>>> occasional sequence error. Why does this happen? Is the network layer
>>> dropping or reordering packets?
>>>
>>
>>
> Regarding my delay and playback app, how well does the USRP obey the
> time_spec commands? I tried to delay the samples by one second, and it
> seems like the actual delay is off by around 4 ms (and the delay is not
> consistent). I need within 50 nanosecond precision for my application.
>
On tx, the timespec is converted to an absolute tick count. When the
USRP gets a packet with a timestamp, it waits waits until that time in
the packet matches its current time. All subsequent data is
backpressured the timestamp'd packet in the front.
Since N200 has a 100 MHz clock, the timespec can specify a clock cycle,
which is on the order of 10 nanoseconds.
-josh
------------------------------
Message: 9
Date: Sun, 24 Jun 2012 19:06:45 -0500
From: Jahshan Bhatti <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Sequence Errors on USRP N200
Message-ID:
<CAJOme13yOSh_sxi-1Ea9_yV8S4W_SFGVY7q_v=sjioyscyf...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Sun, Jun 24, 2012 at 6:08 PM, Josh Blum <[email protected]> wrote:
>
> On tx, the timespec is converted to an absolute tick count. When the
> USRP gets a packet with a timestamp, it waits waits until that time in
> the packet matches its current time. All subsequent data is
> backpressured the timestamp'd packet in the front.
>
> Since N200 has a 100 MHz clock, the timespec can specify a clock cycle,
> which is on the order of 10 nanoseconds.
>
> -josh
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Hmm. I've issued a stream command with a certain timestamp and as soon
as the rx data comes in, I send the data (with appropriate buffering).
The first packet of my tx burst has a timestamp that is some delay
later (10 ms, 100 ms, or 1000 ms). Yet I don't seem to get the delay
I'm expecting (which varies with different delays). As a test, I'm
delaying the GPS signal and feeding the authentic and delayed signal
into two timing receievers and monitoring the PPS. Is there some delay
inside the USRP that isn't accounted for?
~Jahshan
------------------------------
Message: 10
Date: Sun, 24 Jun 2012 19:12:42 -0500
From: Jahshan Bhatti <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Sequence Errors on USRP N200
Message-ID:
<CAJOme13K2ZpML_=kZhYZ0-3T7bWCe+61FscdPi_e=objnc0...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Sun, Jun 24, 2012 at 7:06 PM, Jahshan Bhatti <[email protected]> wrote:
>
> into two timing receievers and monitoring the PPS. Is there some delay
> inside the USRP that isn't accounted for?
On the order of milliseconds of course.
~Jahshan
------------------------------
Message: 11
Date: Sun, 24 Jun 2012 19:18:25 -0500
From: Jahshan Bhatti <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Sequence Errors on USRP N200
Message-ID:
<cajome11ds6jt0ead_yw4t989znisdnvs0v4dyl+vtkcf_jz...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Sun, Jun 24, 2012 at 7:12 PM, Jahshan Bhatti <[email protected]> wrote:
> On Sun, Jun 24, 2012 at 7:06 PM, Jahshan Bhatti <[email protected]> wrote:
>>
>> into two timing receievers and monitoring the PPS. Is there some delay
>> inside the USRP that isn't accounted for?
>
> On the order of milliseconds of course.
>
Would the difference of the delay between when the signal enters the
RX connector to RX timestamp (thru downcoversion and digitization) and
the delay between the TX timestamp to when the signal leaves the TX
connector (thru signal generation and upconversion) be on that order?
~Jahshan
------------------------------
Message: 12
Date: Sun, 24 Jun 2012 20:26:29 -0500
From: Jahshan Bhatti <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Sequence Errors on USRP N200
Message-ID:
<cajome11eqprwpnunqnnc3y_7uv+xd8oc5kvivatvb0fvpa0...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Sun, Jun 24, 2012 at 7:18 PM, Jahshan Bhatti <[email protected]> wrote:
> On Sun, Jun 24, 2012 at 7:12 PM, Jahshan Bhatti <[email protected]> wrote:
>> On Sun, Jun 24, 2012 at 7:06 PM, Jahshan Bhatti <[email protected]> wrote:
>>>
>>> into two timing receievers and monitoring the PPS. Is there some delay
>>> inside the USRP that isn't accounted for?
>>
>> On the order of milliseconds of course.
>>
>
> Would the difference of the delay between when the signal enters the
> RX connector to RX timestamp (thru downcoversion and digitization) and
> the delay between the TX timestamp to when the signal leaves the TX
> connector (thru signal generation and upconversion) be on that order?
>
> ~Jahshan
Ok, instead of using the timing receivers, I simply cross-correlated
the signals with a MIMO set of USRP N200s. From the cross-correlation,
I can see that the delay is stable on multiple runs but not exact.
Here are my results:
command 50 ms delay @ 5 MS/s results in error of -5.75 us
command 50 ms delay @ 4 MS/s results in error of -4.75 us
command 100 ms delay @ 5 MS/s results in error of -5.75 us
command 100 ms delay @ 4 MS/s results in error of -4.75 us
command 200 ms delay @ 5 MS/s results in error of 121.75 us
command 200 ms delay @ 4 MS/s results in error of 154.5 us
The resolution of my cross-correlation is 0.25 us.
~Jahshan
------------------------------
Message: 13
Date: Mon, 25 Jun 2012 16:48:42 +0200
From: "Paola Madonna" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Problem with multi-channel UHD version
003.004.001
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi Josh,
I downloaded the UHD master version 003.004.001 to work with 16MSps with
DBSRX2+USRP1 in order to acquire GALILEO signals on a single-channel.
I have analyzed the file generated using this UHD version for single channel
and that's ok. Then I updated to the new UHD version my old file developed
to acquire both GPS and GLONASS signals, but I have the following problem:
* the file which should contain glonass samples stores gps samples and
viceversa
I observed the same problem with the UHD version 003.001.000 and then this
bug was fixed in the UHD version 003.002.003.
Thanks in advance,
__________________
Paola Madonna
Senior SW Engineer
Space&Navigation Unit
TRS S.p.A.
Via Giulio Cesare 105
c/o Selex-SI, Stab. Fusaro
80070 Bacoli (NA)
Italy
Ph.: +39 081 0050 829
Fax: +39 081 52 72 828
Tecnologie nelle Reti e nei Sistemi T.R.S. SpA
Via della Bufalotta, 378 - 00139 Roma
Tel +39.06.87.28.1.1 - Fax +39.06.87.28.1.550
-------------------------------------------------------
Ai sensi del D.Lgs. 196/2003 si precisa che le informazioni contenute in questo
messaggio
sono riservate ed a uso esclusivo del destinatario. Qualora il messaggio in
parola Le
fosse pervenuto per errore, la preghiamo di eliminarlo senza copiarlo e di non
inoltrarlo
a terzi, dandocene gentilmente comunicazione. Grazie.
This message, for the law 196/2003, may contain confidential and/or privileged
information.
If you are not the addressee or authorized to receive this for the addressee,
you must not
use, copy, disclose or take any action based on this message or any information
herein.
If you have received this message in error, please advise the sender
immediately by reply
e-mail and delete this message. Thank you for your cooperation.
-------------------------------------------------------
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120625/617a1653/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature_trs.png
Type: image/png
Size: 1506 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120625/617a1653/attachment-0001.png>
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 22, Issue 25
******************************************
