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. Request Ebook SDR (ZaInzAiN Jj)
2. Delay introduced by N210 (Tomasz Jackowski)
3. Re: Delay introduced by N210 ([email protected])
4. Re: [Discuss-gnuradio] Reliable Ethernet controllers and
laptops for USRP N210 ? (Balint Seeber)
5. Re: Delay introduced by N210 (Marcus D. Leech)
6. GNU radio benchmark code: Tail after end of packet (Tarun Bansal)
7. Re: GNU radio benchmark code: Tail after end of packet
(Tarun Bansal)
8. Request Ebook SDR (ZaInzAiN Jj)
9. Re: powering N210 with batteries (Ian Buckley)
10. hopping (Nuria Ibrahim)
11. Low Level Signal Issue (ZaInzAiN Jj)
12. Re: GNU radio benchmark code: Tail after end of packet (Josh Blum)
13. Re: hopping (Josh Blum)
----------------------------------------------------------------------
Message: 1
Date: Wed, 12 Dec 2012 01:05:23 +0800 (SGT)
From: ZaInzAiN Jj <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Request Ebook SDR
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Dear,
Does anyone have file Software Defined Radio: with GNU Radio and USRP
[Hardcover] Corey Clark Book?
If you have, please give me link for download or send me to
[email protected] .I need it for my thesis research reference.
Thanks,
Ahmad Zainudin,
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121212/81a4c9b9/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 11 Dec 2012 21:43:26 +0100
From: Tomasz Jackowski <[email protected]>
To: [email protected]
Subject: [USRP-users] Delay introduced by N210
Message-ID:
<CAN1R1r=ObWoRKD9e6QYAsQc+XB=EsO=bmxvfjtm9sqtczzv...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Dear All,
I am currently developing FMCW radar, using USRP N210 with RFX2400
daughterboard. I use GRC and UHD.
FMCW concept is based on comparision between transmitted and received
signals' frequencies.
I have a problem with delay introduced by USRP - it is different every time
I run a simulation for specified sample rate.
I measured it as if I was measuring delay introduced by waves propagation -
I connected TX/RX and RX2 ports of RFX2400 and started radar's program in
GRC. I suppose that delay introduced by GRC is constant for a given
samp_rate.
What can I say for sure now, delay varies in frames of 1 ms - probably it
is bigger, but my measurement method operates "modulo 1 ms".
Delay is different every time I start the program, it is stable during
simulation, or chages in a moment to completely different value, (after at
least 60 sec.)
If there is a method of decreasing this delay jitter?
With best regards
--
Tomasz Jackowski
student of
Poznan University of Technology
Poland
www.et.put.poznan.pl
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121211/06c28429/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 11 Dec 2012 15:48:47 -0500
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] Delay introduced by N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 11 Dec 2012 15:43, Tomasz Jackowski wrote:
> Dear All,
>
> I
am currently developing FMCW radar, using USRP N210 with RFX2400
daughterboard. I use GRC and UHD.
> FMCW concept is based on comparision
between transmitted and received signals' frequencies.
>
> I have a
problem with delay introduced by USRP - it is different every time I run
a simulation for specified sample rate.
>
> I measured it as if I was
measuring delay introduced by waves propagation - I connected TX/RX and
RX2 ports of RFX2400 and started radar's program in GRC. I suppose that
delay introduced by GRC is constant for a given samp_rate.
>
> What
can I say for sure now, delay varies in frames of 1 ms - probably it is
bigger, but my measurement method operates "modulo 1 ms".
> Delay is
different every time I start the program, it is stable during
simulation, or chages in a moment to completely different value, (after
at least 60 sec.)
>
> If there is a method of decreasing this delay
jitter?
>
> With best regards
> --
>
> Tomasz Jackowski
> student
of
> Poznan University of Technology
> Poland
> www.et.put.poznan.pl
[1]
> [email protected] [2]
If your "measurement
plane" for taking jitter measurements is way up in applications land
inside an operating system that isn't designed to minimize scheduling
jitter, you're going to see a lot of jitter at the timescales you're
talking about.
If latency consistency is really important, you'll have
to look into implementing inside the FPGA on the device.
General-purpose OS do a rather poor job of controlling latency
variability. It's their nature. It's like a physical constant of the
Universe :-)
Links:
------
[1] http://www.et.put.poznan.pl
[2]
mailto:[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121211/5821d78a/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 11 Dec 2012 12:53:17 -0800
From: Balint Seeber <[email protected]>
To: Rickard Radio <[email protected]>
Cc: [email protected], GNURadio Discussion List
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] Reliable Ethernet
controllers and laptops for USRP N210 ?
Message-ID:
<CAPcb_2rdE5CQPLfu1etLyj=wvbbxtjuz0cjuxbe9z6zzt5a...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Richard,
Thanks for reporting on your experiments! I have doing a few lately myself
(specifically in regards to USRP latency).
I have a Thinkpad T430s with a 82579LM. The benchmark_rate reports zero
underflows/overflows for unidirectional streaming. Bi-directional results
in some TX underflows with the default MTU, however increasing this results
in *no* underflows, e.g.
sudo ifconfig eth0 mtu 9000
sudo /usr/local/share/uhd/examples/benchmark_rate --rx_rate 25e6 --tx_rate
25e6 --duration 30 --args="recv_frame_size=3792,send_frame_size=3792"
Remember the 'sudo' will help by enabling 'real-time' (SCHED_FIFO)
scheduling in the Linux kernel.
Benchmark rate summary:
Num received samples: 749991475
Num dropped samples: 0
Num overflows detected: 0
Num transmitted samples: 749969786
Num sequence errors: 0
Num underflows detected: 0
I have found a number of parameters can be tweaked to change general
N-series communication behaviour with the Intel NIC (specifically interrupt
moderation, MTU [above], etc):
sudo modprobe -r e1000e
sudo modprobe e1000e debug=16 InterruptThrottleRate=0 TxAbsIntDelay=0
TxIntDelay=0 RxAbsIntDelay=0 RxIntDelay=0
Changing CPU governor to 'performance' on all cores may also help in
certain situations.
Please take a look at this document I've been putting together for more
details: http://code.ettus.com/redmine/ettus/projects/public/wiki/Latency
Let us know if any of the above tips improve your results.
Hope that helps,
Balint
On Tue, Dec 11, 2012 at 8:26 AM, Rickard Radio <[email protected]>wrote:
> OK, I just tried this on a colleagues brand new Thinkpad T430s and it
> works without any packet drops or other Ethernet problems on that laptop
> (at least for a minute or so). It has the Intel 82579LM Ethernet chip so
> that chip doesn't seem too bad after all (like the Artheros 8151 which I
> have problems with).
>
> Rickard
>
> On Dec 11, 2012, at 12:51 PM, Rickard Radio <[email protected]>
> wrote:
>
> Hi all,
>
> Can anyone please try this on a laptop, preferably a Lenovo Thinkpad, with
> a N210 and report what you get:
> "/uhd/examples/benchmark_rate --rx_rate 25e6"
>
>
> Thanks
> Rickard
>
> On Dec 7, 2012, at 3:32 PM, Rickard <[email protected]> wrote:
>
> I wonder which GigE controllers (manufacturer & versions) and laptop
> computers are working hassle free, without dropping packets etc., at the
> highest sampling rates with the USRP N210 which results in 800 Mbit/s raw
> data (or about 835 Mbit/s total UDP) ?!
>
> Please test your laptop with "/uhd/examples/benchmark_rate --rx_rate
> 25e6" or "uhd_fft -s 25e6" and report your findings!
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121211/de7101d6/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 11 Dec 2012 17:19:12 -0500
From: "Marcus D. Leech" <[email protected]>
To: Tomasz Jackowski <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Delay introduced by N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Thank you for reply, Marcus.
>
> I am not going to measure jitter - I hoped to measure delay introduced
> by USRP, and then compensate it. It would be possible, if it was
> constant.
>
> Question - if there is a way to give UHD and GRC highest priority in
> system (Ubuntu 12.04), what would make this randomness smaller?
> Another method may be using timestamps - I only heard about it, thusI
> am newbie in software defined radio topic. - Do they contain
> information about time-of-reception of particular sample (or group of
> samples) in USRP device?
>
> Tomasz
You can turn on real-time scheduling in your application. This helps,
but isn't a magic bullet.
If you want to use scheduled-transmission, and timestamps on reception
that can help.
WIth scheduled transmission you can schedule your TX burst to being at a
specific time, as seen by the USRP hardware.
Similarly, the USRP hardware can timestamp incoming samples as they are
presented to the VITA subsystem for transmission to
the host. Since the group delay is fixed and constant for any given
decimation setting, you can easily calibrate that out, and
arrive at a "measurement plane" of the antenna input to the USRP.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 6
Date: Tue, 11 Dec 2012 19:00:46 -0500
From: Tarun Bansal <[email protected]>
To: [email protected]
Subject: [USRP-users] GNU radio benchmark code: Tail after end of
packet
Message-ID:
<CALLhJtQC+Shuirp4LYq=d0aJOw0poz1GsxX87=bcarm6s8o...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
We are using USRP N210 R4 and latest gnuradio code. I am also using
benchmark_tx.py and benchmark_rx.py from gr-digital/examples/narrowband/.
The receiver receives most of the packets correctly. I also used filesink
to record the received samples and then viewed them using gr_plot_float.
When I do that, I see that the receiver also receives some extra samples
after the end of the packet. The extra samples form a tail (See the image
here: http://goo.gl/lSNG3).
Can anybody please explain why the receiver sees a tail at the end of the
packet and is it possible to remove it?
Thanks
Tarun
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121211/96463464/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 11 Dec 2012 19:03:05 -0500
From: Tarun Bansal <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GNU radio benchmark code: Tail after end of
packet
Message-ID:
<callhjts_t0cdu6waidcrmoduizuczqnnjkhrdyyd2ne+uct...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Forgot to mention that I am using WBX daughterboard on both transmitter and
receiver.
On Tue, Dec 11, 2012 at 7:00 PM, Tarun Bansal <[email protected]>wrote:
> Hi,
>
> We are using USRP N210 R4 and latest gnuradio code. I am also using
> benchmark_tx.py and benchmark_rx.py from gr-digital/examples/narrowband/.
> The receiver receives most of the packets correctly. I also used filesink
> to record the received samples and then viewed them using gr_plot_float.
> When I do that, I see that the receiver also receives some extra samples
> after the end of the packet. The extra samples form a tail (See the image
> here: http://goo.gl/lSNG3).
>
> Can anybody please explain why the receiver sees a tail at the end of the
> packet and is it possible to remove it?
>
> Thanks
> Tarun
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121211/3f6ad3a4/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 12 Dec 2012 09:10:09 +0800 (SGT)
From: ZaInzAiN Jj <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Request Ebook SDR
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Dear,
Does anyone have file Software Defined Radio: with GNU Radio and USRP
[Hardcover] Corey Clark Book?
If you have, please give me link for download or send me to
[email protected] .I need it for my thesis research reference.
Thanks,
Ahmad Zainudin,
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121212/7378fa41/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 11 Dec 2012 17:29:40 -0800
From: Ian Buckley <[email protected]>
To: Nick Foster <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] powering N210 with batteries
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Seth,
I haven't got much more to add to Nick's summary?last time I looked at this
the limiting componant was the level shifter used for external PPS input on the
USRP2 which was a little out of spec for the batteries I used.
I have used this battery pack
(http://www.all-battery.com/li-ion1865074v7800mahflatrechargeablebatterymodulewithpcbandbareleadscustomize.aspx)
for an internal E100 battery conversion I did, but the volume was pushing the
envelope of the standard USRP case
(http://ianbuckley.net/E100_battery_powered.jpg), and something a little
slimmer would have been much better.
-Ian
On Dec 7, 2012, at 2:40 PM, Nick Foster <[email protected]> wrote:
> On 12/07/2012 02:15 PM, Seth Hollar wrote:
>> How tolerant is the N210 to being powered by a battery pack? I was looking
>> at using NiMH batteries originally intended for RC cars, but I know the
>> voltage can vary a bit ... roughly 7V to 5V. Would that adversely affect
>> the N210?
>>
>> In general, what is the recommended battery solution?
>>
>> For example, I was looking at something like this:
>> http://www.all-battery.com/6v3300mahnimhhumpbatteryreceiverpackswithtamiyaandjrconnector11109.aspx
>>
>
> N210 passes the input voltage unregulated to the daughterboard, which
> regulates down to 5, 3.3, etc. to power the RF circuitry. In general, you're
> probably OK to do this, but it would be best to regulate. You will need to
> keep the input to at least 5.6-5.7 volts in order for the 5V linear
> regulators on (for instance) WBX to have adequate headroom. This might limit
> how much charge you can draw from the batteries.
>
> In general, 7V won't harm the N210, although we don't specify it to operate
> at that voltage. Don't operate it much above 7V. Heat dissipation in the
> linear regulators will go up as input voltage increases. The best solution is
> probably to power it off of a 6V supply that can operate off whatever battery
> voltage you might use.
>
> --n
>
>>
>> Thanks in advance,
>> Seth
>>
>> _______________________________________________
>> 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/20121211/2e731c18/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 11 Dec 2012 22:33:24 -0800 (PST)
From: Nuria Ibrahim <[email protected]>
To: usrp users forum <[email protected]>
Subject: [USRP-users] hopping
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hican I implement hopping from host(with fixed LO frequency and capturing
entire GSM900 band) using gnuradio block- the polyphase filter bank channelizer?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121211/9d8ecfcc/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 12 Dec 2012 23:14:07 +0800 (SGT)
From: ZaInzAiN Jj <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Low Level Signal Issue
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Dear,
I using :
- USRP1
- ubuntu 10.10
- gnuradio-3.3.0
- openbts 2.6.0
- single Daughterboard RFX1800, I change RFX900
- Frequency 900 MHz
- Clock 64 MHz
when I run
cd /usr/local/bin./usrp_fft.py
The result like picture at attachment, level signal in spectrum is low.
hanphone can find SID OpenBTS with name 00101.but handphone can't register with
openbts, why?Is associated with a clock
64 MHz?and what I can do to increse level signal OpenBTS in spectrum, may be
can connect to OpenBTS easely?
Thanks,
Ahmad Zainudin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121212/1dbc1d89/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: USRP FFT_004.png
Type: image/png
Size: 72439 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121212/1dbc1d89/attachment-0001.png>
------------------------------
Message: 12
Date: Wed, 12 Dec 2012 09:15:32 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GNU radio benchmark code: Tail after end of
packet
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 12/11/2012 06:00 PM, Tarun Bansal wrote:
> Hi,
>
> We are using USRP N210 R4 and latest gnuradio code. I am also using
> benchmark_tx.py and benchmark_rx.py from gr-digital/examples/narrowband/.
> The receiver receives most of the packets correctly. I also used filesink
> to record the received samples and then viewed them using gr_plot_float.
> When I do that, I see that the receiver also receives some extra samples
> after the end of the packet. The extra samples form a tail (See the image
> here: http://goo.gl/lSNG3).
>
> Can anybody please explain why the receiver sees a tail at the end of the
> packet and is it possible to remove it?
>
You might be seeing the result of underflow. Those examples are missing
things like ending the burst, so the USRP is left in underflow state
until a timeout, then shuts off TX mode.
There is some pretty cool working precog that basically uses those
blocks and creates a MAC layer. It also does proper end of burst for
transmit packets: https://github.com/buoyboy/pre-cog
-josh
> Thanks
> Tarun
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 13
Date: Wed, 12 Dec 2012 09:21:28 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] hopping
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 12/12/2012 12:33 AM, Nuria Ibrahim wrote:
> Hican I implement hopping from host(with fixed LO frequency and capturing
> entire GSM900 band) using gnuradio block- the polyphase filter bank
> channelizer?
>
In this case, you only want to select one frequency range at any given
time? I think it would be easier to just use the frequency translating
filter.
-josh
PS - I think gnuradio mailing list could be more helpful for gnuradio
specific advice.
>
>
> _______________________________________________
> USRP-users mailing list
> [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 28, Issue 11
******************************************
