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: [Discuss-gnuradio] Reliable Ethernet controllers and
laptops for USRP N210 ? (Johnathan Corgan)
2. Re: [Discuss-gnuradio] Reliable Ethernet controllers and
laptops for USRP N210 ? (Rickard Radio)
3. Re: [Discuss-gnuradio] Reliable Ethernet controllers and
laptops for USRP N210 ? (Rickard Radio)
4. Re: Request Ebook SDR (Sakib Chowdhury)
5. Re: [Discuss-gnuradio] Reliable Ethernet controllers and
laptops for USRP N210 ? (Balint Seeber)
6. Re: [Discuss-gnuradio] Reliable Ethernet controllers and
laptops for USRP N210 ? ([email protected])
7. Re: [Discuss-gnuradio] Reliable Ethernet controllers and
laptops for USRP N210 ? (Balint Seeber)
8. Re: [Discuss-gnuradio] Reliable Ethernet controllers and
laptops for USRP N210 ? ([email protected])
9. Intel Atom CPU (Damien Serant)
10. Re: Intel Atom CPU (Marcus D. Leech)
11. Re: Intel Atom CPU (Damien Serant)
12. Matlab's Automatic Gain Control (Fernando Quivira)
13. Re: Matlab's Automatic Gain Control (Marcus D. Leech)
14. Re: [Discuss-gnuradio] Reliable Ethernet controllers and
laptops for USRP N210 ? (Ian Buckley)
15. Simulink Modeling 16 QAM with USRP (zhangfan)
16. Re: Simulink Modeling 16 QAM with USRP (Mike McLernon)
17. Passing control messages between blocks
(Juan Daniel Fernandez Martinez)
18. Re: Passing control messages between blocks (Josh Blum)
19. NBFM block gnu radio (Jos? Mar?a Valencia)
----------------------------------------------------------------------
Message: 1
Date: Wed, 12 Dec 2012 09:19:48 -0800
From: Johnathan Corgan <[email protected]>
To: Ian Buckley <[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:
<caloxbzvedt4bbgotufsq3_np5apeuawhyexnp2vaapr7u0s...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, Dec 11, 2012 at 11:17 PM, Ian Buckley <[email protected]> wrote:
> I ran benchmark_rate with the same parameters tonight on an Intel 82574L
> and and Intel 82579V, also with flawless results.
>
I've had some issues with a laptop-based 82579V failing to negotiate 1000M
with the N210 when the laptop was on battery power, but working normally
when the laptop was plugged into its AC adapter.
Johnathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121212/bac55d0f/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 12 Dec 2012 18:22:20 +0100
From: Rickard Radio <[email protected]>
To: Balint Seeber <[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: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Thanks!
This is really valuable information. Also your new document with lots of useful
info and explanations what happens behind the scenes.
However, on my problematic Acer Aspire 8820T laptop with AR8151 NIC and "atl1c"
driver (instead of the Intel "e100e" driver below) , nothing of this has an
effect. For example, sudoing has no effect as well no effect of changing the
frame sizes, CPU governor, receive buffer size, etc. Played with most of this
before (see thread http://www.ruby-forum.com/topic/3949213 )
> 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"
For this to have an effect of frame size, I need also to specify the ip-address
(otherwise the arguments seem to be ignored):
sudo /usr/local/share/uhd/examples/benchmark_rate --rx_rate 25e6 --tx_rate 25e6
--duration 30 --args="addr=192.168.10.2,
recv_frame_size=3792,send_frame_size=3792"
In any case, connection stalls/hangs with repeated "Error code 1: Unexpected
error on recv, continuing?" messages with the "benchmark_rate" test. Similar
thing if I run uhf_fft at the same samp rate, it just stalls, orange LED starts
rapidly blinking and the "C" LED goes off, and the FFT plot just freeze since
no more samples are coming from the N210.
So I suppose something is terrible wrong with the AR8151 NIC, or internally
further down the pipe at high sampling rates. I have now finally given up on
those Acer machines for these high samp rates.
Now writing to "SDR Santa" to bring me more powerful Lenovo Thinkpad T430s
needed for my high sample rate experiments and projects.
Rickard
On Dec 11, 2012, at 9:53 PM, Balint Seeber <[email protected]> wrote:
> 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/20121212/c5c7c0cc/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 12 Dec 2012 18:38:06 +0100
From: Rickard Radio <[email protected]>
To: Johnathan Corgan <[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: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
OK, interesting. Yesterday I tried a brand new Lenovo T430s (direct out of box
and with Intel 82579LM) with and without power supply connected and both worked
flawlessly.
That test was under Windows running Ettus precompiled UHD binaries. No extras,
just "benchmark_rate --rx_rate 25e6 --duration 60".
Under Windows, this test give me exactly the same problem on my Acer Aspire
3820T with AR8151 NIC as under Linux Ubuntu 12.04. Same version of UHD (late
November).
Rickard
PS. In my previous email the laptop model was "Acer Aspire 3820T" not "8820T".
On Dec 12, 2012, at 6:19 PM, Johnathan Corgan <[email protected]> wrote:
> On Tue, Dec 11, 2012 at 11:17 PM, Ian Buckley <[email protected]> wrote:
>
> I ran benchmark_rate with the same parameters tonight on an Intel 82574L and
> and Intel 82579V, also with flawless results.
>
> I've had some issues with a laptop-based 82579V failing to negotiate 1000M
> with the N210 when the laptop was on battery power, but working normally when
> the laptop was plugged into its AC adapter.
>
> Johnathan
> _______________________________________________
> 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/20121212/0ef23f75/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 12 Dec 2012 13:01:00 -0500
From: Sakib Chowdhury <[email protected]>
To: ZaInzAiN Jj <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Request Ebook SDR
Message-ID:
<cacmxc5dknyy-5bxi1e9rkagt6gtjt0no70uszs_kdxja6yv...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
Actually that book has never been printed. It was cancelled.
Thanks.
-- Sakib
On Tue, Dec 11, 2012 at 8:10 PM, ZaInzAiN Jj <[email protected]> wrote:
> 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,
>
> _______________________________________________
> 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/20121212/2ed4d747/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 12 Dec 2012 10:16:11 -0800
From: Balint Seeber <[email protected]>
To: [email protected], GNURadio Discussion List
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] Reliable Ethernet
controllers and laptops for USRP N210 ?
Message-ID:
<capcb_2q331klga1zr4rx8-ijzs8jl681x0ti7hphs9sjs6n...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
In case this might be causing issues for anyone else:
I have on two occasions seen an Intel NIC's failure to negotiate a link
with an N-series device (and also many SFP connectors) while under Linux
using the e1000e driver (Windows has been fine).
To remedy this, I have created a patch for e1000e 2.1.4 that allows you to
change negotiation parameters via module arguments.
More info/instructions/patch can be found here:
http://code.ettus.com/redmine/ettus/projects/public/wiki/Intel_NIC_Notes
On Wed, Dec 12, 2012 at 9:19 AM, Johnathan Corgan
<[email protected]>wrote:
> On Tue, Dec 11, 2012 at 11:17 PM, Ian Buckley <[email protected]>wrote:
>
>
>> I ran benchmark_rate with the same parameters tonight on an Intel 82574L
>> and and Intel 82579V, also with flawless results.
>>
>
> I've had some issues with a laptop-based 82579V failing to negotiate 1000M
> with the N210 when the laptop was on battery power, but working normally
> when the laptop was plugged into its AC adapter.
>
> Johnathan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121212/6e699241/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 12 Dec 2012 13:23:06 -0500
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] Reliable Ethernet
controllers and laptops for USRP N210 ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 12 Dec 2012 13:16, Balint Seeber wrote:
> In case this might be
causing issues for anyone else:
>
> I have on two occasions seen an
Intel NIC's failure to negotiate a link with an N-series device (and
also many SFP connectors) while under Linux using the e1000e driver
(Windows has been fine).
>
> To remedy this, I have created a patch for
e1000e 2.1.4 that allows you to change negotiation parameters via module
arguments.
>
> More info/instructions/patch can be found here:
http://code.ettus.com/redmine/ettus/projects/public/wiki/Intel_NIC_Notes
[2]
>
> On Wed, Dec 12, 2012 at 9:19 AM, Johnathan Corgan
<[email protected] [3]> wrote:
>
>> On Tue, Dec 11, 2012 at
11:17 PM, Ian Buckley <[email protected] [1]> wrote:
>>
>>> I ran
benchmark_rate with the same parameters tonight on an Intel 82574L and
and Intel 82579V, also with flawless results.
>> I've had some issues
with a laptop-based 82579V failing to negotiate 1000M with the N210 when
the laptop was on battery power, but working normally when the laptop
was plugged into its AC adapter.
>>
>> Johnathan
I used to work at a
company that did 1/10/40/100 GiGE PHYs and MACs. What I found in the lab
was that 1GiGE autonegotiation among various vendors products was
somewhat "spotty". I *often* had to ask my laptop NIC to "nail" the link
speed to 1000Mbit and turn off autonegotiation, and it became more
reliable. This same approach seemed to be useful for some of our
prototypes as well, that were using Broadcom PHY chips -- turn off
autonegotiation, nail it at 1000Mbit, and everything was fine.
Links:
------
[1] mailto:[email protected]
[2]
http://code.ettus.com/redmine/ettus/projects/public/wiki/Intel_NIC_Notes
[3]
mailto:[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121212/32599900/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 12 Dec 2012 10:55:10 -0800
From: Balint Seeber <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] Reliable Ethernet
controllers and laptops for USRP N210 ?
Message-ID:
<CAPcb_2rupjNQ_zcOWqE=-lbuau+-voz50jv5fs1cz4oaqnh...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Indeed, I tried this first on the Intel NIC (fixing link speed, etc)
however there are, from what I saw, various driver inadequacies that
prevent you from doing this under Linux (i.e. you cannot change most of the
important parameters with 'ethtool' without an exist link up - crazy
right?). This is why I had to delve deeper and change the auto-neg loop
timing to match the behaviour of the other connected device...
On Wed, Dec 12, 2012 at 10:23 AM, <[email protected]> wrote:
> **
>
> On 12 Dec 2012 13:16, Balint Seeber wrote:
>
> In case this might be causing issues for anyone else:
>
> I have on two occasions seen an Intel NIC's failure to negotiate a link
> with an N-series device (and also many SFP connectors) while under Linux
> using the e1000e driver (Windows has been fine).
>
> To remedy this, I have created a patch for e1000e 2.1.4 that allows you to
> change negotiation parameters via module arguments.
>
> More info/instructions/patch can be found here:
> http://code.ettus.com/redmine/ettus/projects/public/wiki/Intel_NIC_Notes
>
> On Wed, Dec 12, 2012 at 9:19 AM, Johnathan Corgan <
> [email protected]> wrote:
>
>> On Tue, Dec 11, 2012 at 11:17 PM, Ian Buckley <[email protected]>wrote:
>>
>>
>>> I ran benchmark_rate with the same parameters tonight on an Intel 82574L
>>> and and Intel 82579V, also with flawless results.
>>>
>> I've had some issues with a laptop-based 82579V failing to negotiate
>> 1000M with the N210 when the laptop was on battery power, but working
>> normally when the laptop was plugged into its AC adapter.
>>
>> Johnathan
>>
> I used to work at a company that did 1/10/40/100 GiGE PHYs and MACs.
> What I found in the lab was that 1GiGE autonegotiation among various
> vendors products was somewhat "spotty". I *often* had to ask my laptop NIC
> to "nail" the link speed to 1000Mbit and turn off autonegotiation, and it
> became more reliable. This same approach seemed to be useful for some of
> our prototypes as well, that were using Broadcom PHY chips -- turn off
> autonegotiation, nail it at 1000Mbit, and everything was fine.
>
>
>
>
> _______________________________________________
> 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/20121212/8bcd46e3/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 12 Dec 2012 13:57:56 -0500
From: [email protected]
To: Balint Seeber <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] Reliable Ethernet
controllers and laptops for USRP N210 ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 12 Dec 2012 13:55, Balint Seeber wrote:
> Indeed, I tried this
first on the Intel NIC (fixing link speed, etc) however there are, from
what I saw, various driver inadequacies that prevent you from doing this
under Linux (i.e. you cannot change most of the important parameters
with 'ethtool' without an exist link up - crazy right?). This is why I
had to delve deeper and change the auto-neg loop timing to match the
behaviour of the other connected device...
e100e -- Unsafe at any Speed
(tm)
:-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121212/e6a7e4c1/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 13 Dec 2012 00:48:28 +0100
From: Damien Serant <[email protected]>
To: USRP List <[email protected]>
Subject: [USRP-users] Intel Atom CPU
Message-ID:
<CAM=tnln87qev_jm1wzowm6noqawvpg8qwo7wcaq5xtr--e7...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi List,
Does anyone try to use an USRP with an intel atom CPU . Which sampling
frequency is achievable ?
Thanks,
Damien
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121213/d9c5e3be/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 12 Dec 2012 19:44:31 -0500
From: "Marcus D. Leech" <[email protected]>
To: Damien Serant <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Intel Atom CPU
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 12/12/2012 06:48 PM, Damien Serant wrote:
> Hi List,
>
> Does anyone try to use an USRP with an intel atom CPU . Which sampling
> frequency is achievable ?
>
> Thanks,
>
> Damien
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
I know someone who uses simple_fm_rcv at 250ksps (not with a USRP, but
that shouldn't matter that much), on an ATOM N570 at 1.66GHz.
He still has CPU left over for doing "ordinary things".
The question isn't terribly meaningful without knowing what it is you're
doing to each sample. Pulling samples in and dropping them on the floor
is quite cheap, and an ATOM (which model/speed?) would be quite
capable of handling such a thing at high rates. But as soon as you start
"doing things" to the samples, CPU usage starts to climb,
proportional to the *number of "things"* you're doing to each sample.
Filtering, demodulating, detecting, decoding, snarfoodling, spindling,
and mutilating, all have some cost, in terms of FLOPS (Floating-point
Operations
per Second). For a given fixed processing chain a CPU with higher
G-FLOPS is going to be able to handle higher sample rates than one with
lower G-FLOPS.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121212/38fd7f14/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 13 Dec 2012 02:48:54 +0100
From: Damien Serant <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Intel Atom CPU
Message-ID:
<CAM=tNL=qksmttli4d3swihdnczcu7wafioygnmvrypgxx4w...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks for the answer.
My idea was just to record samples on HDD or equivalently transmit samples
stored on HDD, using for instance an Atom D525 (Dual core 1.8 Ghz) as it
can be found in Zotac Mini-PCs.
Damien
2012/12/13 Marcus D. Leech <[email protected]>
> **
> On 12/12/2012 06:48 PM, Damien Serant wrote:
>
> Hi List,
>
> Does anyone try to use an USRP with an intel atom CPU . Which sampling
> frequency is achievable ?
>
> Thanks,
>
> Damien
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> I know someone who uses simple_fm_rcv at 250ksps (not with a USRP, but
> that shouldn't matter that much), on an ATOM N570 at 1.66GHz.
> He still has CPU left over for doing "ordinary things".
>
>
> The question isn't terribly meaningful without knowing what it is you're
> doing to each sample. Pulling samples in and dropping them on the floor
> is quite cheap, and an ATOM (which model/speed?) would be quite capable
> of handling such a thing at high rates. But as soon as you start
> "doing things" to the samples, CPU usage starts to climb, proportional
> to the *number of "things"* you're doing to each sample.
>
> Filtering, demodulating, detecting, decoding, snarfoodling, spindling, and
> mutilating, all have some cost, in terms of FLOPS (Floating-point Operations
> per Second). For a given fixed processing chain a CPU with higher
> G-FLOPS is going to be able to handle higher sample rates than one with
> lower G-FLOPS.
>
>
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121213/72c962ec/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 12 Dec 2012 22:11:14 -0500
From: Fernando Quivira <[email protected]>
To: [email protected]
Subject: [USRP-users] Matlab's Automatic Gain Control
Message-ID:
<CAD6+UKLnVTnY4UozETHqRZc=-w2u0x0oq2-3evgvsodjp5t...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Dear list:
Does anybody know what algorithm is used in Matlab's Automatic Gain Control
code (FRSGMRSDemoAGC.p)? The routine is p-coded. Does anybody know if the
AGC code in GNURadio is the same as Matlab's?
Thank you for your help
- Fernando
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121212/713e063e/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 12 Dec 2012 22:13:28 -0500
From: "Marcus D. Leech" <[email protected]>
To: Fernando Quivira <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Matlab's Automatic Gain Control
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 12/12/2012 10:11 PM, Fernando Quivira wrote:
> Dear list:
>
> Does anybody know what algorithm is used in Matlab's Automatic Gain
> Control code (FRSGMRSDemoAGC.p)? The routine is p-coded. Does anybody
> know if the AGC code in GNURadio is the same as Matlab's?
>
> Thank you for your help
>
> - Fernando
There are several different AGC implementations in Gnu Radio. All of
which are open-source, so you can inspect them for yourself.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 14
Date: Tue, 11 Dec 2012 23:17:31 -0800
From: Ian Buckley <[email protected]>
To: Balint Seeber <[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: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I ran benchmark_rate with the same parameters tonight on an Intel 82574L and
and Intel 82579V, also with flawless results.
On Dec 11, 2012, at 12:53 PM, Balint Seeber <[email protected]> wrote:
> 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
>
>
> _______________________________________________
> 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/94c34034/attachment-0001.html>
------------------------------
Message: 15
Date: Thu, 13 Dec 2012 17:43:12 +0800
From: zhangfan <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Simulink Modeling 16 QAM with USRP
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gb2312"
Hallo everyone,
I am using the Simulink Model QPSK-Receiver and QPSK-Transmitter.
Right now i am trying to replace the modulation methode QPSK with 16 QAM
and 64 QAM. Although i have borrowed the book < Digital
Communications - A Discrete-Time Approach > from Micheal Rice, it
didn?t really help me. As written in the book, the Structure of the time
synchronization and phase synchronization of the MQAM is the same as of
QPSK, there are just short kapitels related to the MQAM and i can?t
find enough informations. I have given some thoughts about this problem,
My guess is that i have to alter the parameters of those funktion
blocks, like AGC, Fine Frequence Compensation and Time Recovery.
The problem i have right now is, i can?t get to understand, how those
parameters such as ?desired amplitude?, ?fine frequence compasition
gain?,?kp?,?k0?,?k1? and so on, get to influnce the performance of the
PLL for the phase and time synchronization, and which values i should
choose.
I am very thankful when someone can give me some advices.
Thanks in advanceFan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121213/e7c28f0b/attachment-0001.html>
------------------------------
Message: 16
Date: Thu, 13 Dec 2012 13:24:41 +0000
From: Mike McLernon <[email protected]>
To: zhangfan <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Simulink Modeling 16 QAM with USRP
Message-ID:
<e3879be9a282cb45aab7ce258a9ae48f21832...@exmb-01-ah.ad.mathworks.com>
Content-Type: text/plain; charset="us-ascii"
Hi Fan,
The QPSK Transmitter and QPSK Receiver models do depend on the fact that QPSK
is being used as the modulation. You would need to change the coarse frequency
compensator, the fine frequency compensator, and the timing recovery loop. The
Rice book goes into great detail on such techniques for PSK signals, but also
provides references for how to extend those techniques to QAM signals. For
instance, see section 7.9.2 of the Rice book.
Also, chapter 7 of the Rice book defines kp, k0, k1, etc. for those loops.
Hth,
Mike
From: USRP-users [mailto:[email protected]] On Behalf Of
zhangfan
Sent: Thursday, December 13, 2012 4:43 AM
To: [email protected]
Subject: [USRP-users] Simulink Modeling 16 QAM with USRP
Hallo everyone,
I am using the Simulink Model QPSK-Receiver and QPSK-Transmitter. Right now i
am trying to replace the modulation methode QPSK with 16 QAM and 64 QAM.
Although i have borrowed the book < Digital Communications - A Discrete-Time
Approach > from Micheal Rice, it didnt really help me. As written in the book,
the Structure of the time synchronization and phase synchronization of the MQAM
is the same as of QPSK, there are just short kapitels related to the MQAM and i
cant find enough informations. I have given some thoughts about this problem,
My guess is that i have to alter the parameters of those funktion blocks, like
AGC, Fine Frequence Compensation and Time Recovery. The problem i have right
now is, i cant get to understand, how those parameters such as desired
amplitude, fine frequence compasition gain,kp,k0,k1 and so on, get to influnce
the performance of the PLL for the phase and time synchronization, and which
values i should choose. I am very thankful when someone can give me some
advices.
Thanks in advance
Fan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121213/7ccbe8f3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 476 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121213/7ccbe8f3/attachment-0001.sig>
------------------------------
Message: 17
Date: Thu, 13 Dec 2012 15:44:27 +0000
From: Juan Daniel Fernandez Martinez <[email protected]>
To: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: [USRP-users] Passing control messages between blocks
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi everyone,
I am working on a block that needs to be notified in order to work properly. I
had tought in using a block that generates information -a simple source- that
change each 6 minutes (some sort of flag), but I think this will consume
resources that might be needed. Is there any way to pass control messages
between blocks?
Thanks a lot :)
________________________________
Este documento puede contener informaci?n privilegiada o confidencial. Por
tanto, usar esta informaci?n y sus anexos para prop?sitos ajenos a los de la
Universidad Icesi, divulgarla a personas a las cuales no se encuentre destinado
este correo o reproducirla total o parcialmente, se encuentra prohibido en
virtud de la legislaci?n vigente. La universidad no asumir? responsabilidad
sobre informaci?n, opiniones o criterios contenidos en este correo que no est?n
directamente relacionados con la Icesi. Si usted no es el destinatario
autorizado o por error recibe este mensaje, por favor informe al remitente y
posteriormente b?rrelo de su sistema sin conservar copia del mismo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121213/559cafbb/attachment-0001.html>
------------------------------
Message: 18
Date: Thu, 13 Dec 2012 10:00:48 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Passing control messages between blocks
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 12/13/2012 09:44 AM, Juan Daniel Fernandez Martinez wrote:
> Hi everyone, I am working on a block that needs to be notified in
> order to work properly. I had tought in using a block that generates
> information -a simple source- that change each 6 minutes (some sort
> of flag), but I think this will consume resources that might be
> needed. Is there any way to pass control messages between blocks?
>
You may find this helpful:
https://github.com/guruofquality/grextras/wiki#wiki-feature-message-passing
-josh
------------------------------
Message: 19
Date: Thu, 13 Dec 2012 10:17:55 -0600
From: Jos? Mar?a Valencia <[email protected]>
To: <[email protected]>
Subject: [USRP-users] NBFM block gnu radio
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Anybody can me explain me what internally does the NBFM block in gnu radio
??
The output of this block is a complex signal??
Thanks for your help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121213/47a587f8/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 28, Issue 12
******************************************
