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: Frequency translation works differently on N210 and B210.
(Urban Hakansson)
2. Re: Frequency translation works differently on N210 and B210.
([email protected])
3. Re: Frequency translation works differently on N210 and B210.
(Urban Hakansson)
4. Re: UHD Related (Michael West)
5. Help building UHD...? (Robert McIntyre)
6. Re: rx_samples_to_file issue (gsmandvoip)
7. Re: B210 UHD Error (Ralph A. Schmid, dk5ras)
8. Re: rx_samples_to_file issue (Peter Witkowski)
9. Re: rx_samples_to_file issue ([email protected])
10. Re: rx_samples_to_file issue (Marcus M?ller)
11. Re: rx_samples_to_file issue (Peter Witkowski)
----------------------------------------------------------------------
Message: 1
Date: Thu, 2 Oct 2014 14:08:10 -0400 (EDT)
From: Urban Hakansson <[email protected]>
To: Ian Buckley <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Frequency translation works differently on
N210 and B210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Ian,
I confirmed it on my B210. You are absolutely correct. For Fs = 1.66667 MHz
(5MHz/3), the alias component at fc-(Fs-f) starts to show up when f approaches
Fs/4 (~416KHz), and grows stronger the closer the frequency came to the Nyquist
frequency Fs/2(833.33kHz).
However I ran the same test on the N210 for Fs = 6.25 MHz (100MHz/16) and the
results were not good. First, there is No UHD warning about CIC rolloff or
using odd interpolation. I take it to mean that only the half-band filters in
the FPGA are used, and I expected only to see the desired sinsoid at fc+f.
Case 1) Fs = 6.25 MHz. fc = 800MHz, f = 2.4MHz
The spectrum analyzer clearly shows two components besides the LO, at
fc-f = 797.6MHz
fc+f = 802.4 MHz.
I swept f from 0Hz and upwards and saw two components at fc-f and fc+f. The
fc-f replica is ~15.5 dB below fc+f for f = 2.4MHz.
Please see attached image of the spectrum analyzer, N210_Fs6.25M_f2.4M.jpg.
Case 2) Fs = 6.25 MHz. fc = 800MHz, f = 2.8MHz.
As I increase f and approach the Nyquist frequency 3.125 MHz I see the same
thing happen that I observe on the B210.
The spectrum analyzer clearly shows four components besides the LO, at
fc-(Fs-f) = 796.55MHz
fc-f = 797.2MHz
fc+f = 802.8MHz
fc+(Fs-f) = 803.45MHz
See attached image of the spectrum analyzer, N210_Fs6.25M_f2.8M.jpg.
So in conclusion, I see two undesired phenomena on my N210 + SBX daughterboard
Rev 5.1.
1) I see a strong replica at fc-f in addition to the desired signal at fc+f for
all frequencies f from 0 to Fs/2 Hz.
2) I see two aliases show up at fc +/-(Fs-f) as the the frequency of the
complex exponential approaches the Nyquist frequency.
Could I be mismatching the fpga version(FPGA Version: 10.1), firmware version
(FW Version: 12.4), and UHD driver version(UHD_003.007.001-0-unknown)?
Regards,
Urban
----- Original Message -----
From: "Ian Buckley" <[email protected]>
To: "Urban Hakansson" <[email protected]>
Cc: "Marcus D. Leech" <[email protected]>, [email protected]
Sent: Thursday, October 2, 2014 1:32:58 AM
Subject: Re: [USRP-users] Frequency translation works differently on N210 and
B210.
What you are seeing is *exactly* as sampling theory would predict.
Your fc+f signal shows up on your spectrum analyzer at 800.625Mhz (Remember
your 750kHz became 750*1.6666/2.000)
Your "fc-f" image is not at fc-f (which would be 799.375MHz) but at 1.66666Mhz
- 0.625Mhz = 798.95Mhz
You see the alias so prominently because the pure CIC filter has terrible stop
band rejection which is why it's largely unsuitable as a generic interpolation
filter on it's own.
Sweep you CW frequency slowly and watch the direction the image appears
from?this is your clue where it's coming from, and a good practical technique
when looking at real world signals and there unexpected by-products.
If you select peak hold on your spectrum analyzer and sweep the frequency you
will plot the frequency response of the CIC filter. Try it with sample rate
2.5MHz and 1.25MHz and see the response of the small half band filter and then
the cascaded half band filters
Now if you turn up the gain some more you will see a true "fc-f" signal,
probably some 40-50db below your main signal and this will be due to the
residual IQ imbalance present in real world direct conversion receivers.
-Ian
On Oct 1, 2014, at 12:45 PM, Urban Hakansson <[email protected]> wrote:
> Yes, I deliberately requested a sample rate that would force the use of the
> FPGA CIC filters. Fs = 1.666667 MHz is fine. I expected roll-off but I did
> not expect the replica at fc-f. The CIC filters should not introduce that
> kind of error, at least that is my understanding.
>
> ----- Original Message -----FW Version: 12.4
> From: "Ian Buckley" <[email protected]>
> To: "Urban Hakansson" <[email protected]>
> Cc: "Marcus D. Leech" <[email protected]>, [email protected]
> Sent: Wednesday, October 1, 2014 2:53:04 PM
> Subject: Re: [USRP-users] Frequency translation works differently on N210 and
> B210.
>
> Did you note the warnings that this generates? The USRP's can not perform
> fractional rate conversions. Your sample rate was coerced to be compatible
> with a 5MHz master clock rate and up sampling was pure CIC filter based which
> has less than ideal spectra:
>
>
> UHD Warning:
> The requested interpolation is odd; the user should expect CIC rolloff.
> Select an even interpolation to ensure that a halfband filter is enabled.
> interpolation = dsp_rate/samp_rate -> 3 = (5.000000 MHz)/(2.000000 MHz)
>
> UHD Warning:
> The hardware does not support the requested TX sample rate:
> Target sample rate: 2.000000 MSps
> Actual sample rate: 1.666667 MSps
>
> UHD Warning:
> The requested interpolation is odd; the user should expect CIC rolloff.
> Select an even interpolation to ensure that a halfband filter is enabled.
> interpolation = dsp_rate/samp_rate -> 3 = (5.000000 MHz)/(2.000000 MHz)
>
> UHD Warning:
> The hardware does not support the requested TX sample rate:
> Target sample rate: 2.000000 MSps
> Actual sample rate: 1.666667 MSps
>
>
> On Oct 1, 2014, at 11:41 AM, Urban Hakansson <[email protected]> wrote:
>
>> Ian,
>>
>> Thanks for taking a look at this problem. There is no sample rate conversion
>> 2MHz->5MHz taking place. I executed the same flow graph for two different
>> sample rates. The master clock rate was set to 5 MHz in both cases.
>>
>> Case 1) The sample rate was set to 5 MHz (equal to the master clock rate).
>>
>> Case 2) The sample rate was set to 2 MHz (not equal to the master clock
>> rate).
>>
>> Urban
>>
>> ----- Original Message -----
>> From: "Ian Buckley" <[email protected]>
>> To: "Urban Hakansson" <[email protected]>
>> Cc: "Marcus D. Leech" <[email protected]>, [email protected]
>> Sent: Wednesday, October 1, 2014 2:20:34 PM
>> Subject: Re: [USRP-users] Frequency translation works differently on N210
>> and B210.
>>
>> Urban, a quick question?I just glanced at your flow graph, it's very
>> simple?I'm wondering where did the sample rate conversion occur (2MHz->5MHz)
>> in your example 2) quoted below? There is no re-sampling block instantiated
>> in your flow graph.
>>
>> On Oct 1, 2014, at 10:33 AM, Urban Hakansson via USRP-users
>> <[email protected]> wrote:
>>
>>> First, thank you for responding so promptly. I attach the Gnu Radio
>>> flow-graph and the generated python script. It contains two USRP sink
>>> objects, one configured for the B210 and the other for the N210. FYI, I use
>>> GnuRadio companinion 3.7.1.1 and 3.7.2.2.
>>>
>>> I also attach two example images from the spectrum analyzer looking at the
>>> spectrum from the B210.
>>>
>>> Image 1) B210 master clock rate = 5MHz, Sampling rate = 5 MHz, frequency of
>>> complex exponential = 1.2 MHz, center frequency = 800MHz.
>>> No replica at fc-f. As expected.
>>>
>>> Image 2) B210 master clock rate = 5MHz, Sampling rate = 2 MHz, frequency of
>>> complex exponential = 750 kHz, center frequency = 800MHz.
>>> Replica at fc-f.
>>>
>>> The result from the N210 is a replica at fc-f as well so I don't include a
>>> image.
>>>
>>> Regards,
>>>
>>> Urban Hakansson
>>>
>>> ----- Original Message -----
>>> From: "Marcus D. Leech via USRP-users" <[email protected]>
>>> To: [email protected]
>>> Sent: Tuesday, September 30, 2014 8:11:34 PM
>>> Subject: Re: [USRP-users] Frequency translation works differently on N210
>>> and B210.
>>>
>>> On 09/30/2014 06:20 PM, Urban Hakansson via USRP-users wrote:
>>>> Hi everybody,
>>>>
>>>> I have a problem. I include below 1) General information, 2) Introduction
>>>> to my problem 3) Detailed description of my problem.
>>>>
>>>> General background information about my environment:
>>>> Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5);
>>>> Boost_104800; UHD_003.007.001-0-unknown
>>>>
>>>> N210 informationfrom uhd_usrp_probe:
>>>> | Device: USRP2 / N-Series Device
>>>> | _____________________________________________________
>>>> | /
>>>> | | Mboard: N210r4
>>>> | | hardware: 2577
>>>> | | mac-addr: 00:80:2f:0a:e6:15
>>>> | | ip-addr: 192.168.2.199
>>>> | | subnet: 255.255.255.255
>>>> | | gateway: 255.255.255.255
>>>> | | gpsdo: none
>>>> | | serial: F4A09C
>>>> | | FW Version: 12.4
>>>> | | FPGA Version: 10.1
>>>>
>>>> B210 information from uhd_usrp_probe:
>>>> | Device: B-Series Device
>>>> | _____________________________________________________
>>>> | /
>>>> | | Mboard: B210
>>>> | | revision: 4
>>>> | | product: 2
>>>> | | serial: F571B5
>>>> | | FW Version: 4.0
>>>> | | FPGA Version: 3.0
>>>>
>>>>
>>>> Introduction/background: It is my understanding that outputting a
>>>> real-valued baseband signal x(t) = a*sin(2*pi*f*t) on an RF carrier fc
>>>> should result in two components at fc+f and fc-f, but outputting a
>>>> complex-valued baseband signal x(t) = exp(2*pi*f*t) should only result in
>>>> an fc+f component. The complex exponential can be used for frequency
>>>> translation but is causing me serious problems on the N210 + SBX
>>>> daughterboard.
>>>>
>>>> Detailed Problem Description: Using GnuRadio I output a simple baseband
>>>> complex exponential at frequency +f centered at the RF center frequency
>>>> fc. Now on the N210 in addition to the sinusoid at fc+f there is a
>>>> unexpected replica at fc-f about 13-14 dB below fc+f. When I run the same
>>>> script on the B210 and set master clock rate equal to the sample clock
>>>> rate, I only see the desired frequency component at fc+f. There is no
>>>> replica at fc-f as in the case of the N210. This is the correct behaviour
>>>> as I understand it. However, if I don't set the master clock rate equal to
>>>> the sample rate on the B210 I do get the undesired replica at fc-f 13-14
>>>> dB below the signal at fc+f just as I did on the N210.
>>>>
>>>> Why does it only work if the master clock rate is set equal to the sample
>>>> clock rate on the B210? I have read somewhere on the mailing list that the
>>>> FPGA including CIC and HB filters are bypassed in this case.
>>>>
>>>> Question: How can I output a simple complex-valued baseband signal x(t) =
>>>> exp(2*pi*f*t) on an RF carrier fc on the N210 and only get an fc+f
>>>> component so I can use this mechanism to perform frequency translation?
>>>>
>>>> Thanks for you consideration.
>>>>
>>>> Regards,
>>>>
>>>> Urban Hakansson
>>>>
>>>>
>>>>
>>>> This e-mail may contain privileged, confidential, copyrighted or other
>>>> legally protected information, and is intended exclusively for the
>>>> intended recipient. If you are not the intended recipient (even if the
>>>> e-mail address above is yours), you may not review, store, use, copy,
>>>> disclose or retransmit it in any form. If you are not the intended
>>>> recipient or otherwise have received this by mistake, please immediately
>>>> notify the sender by return e-mail (or [email protected]), then delete
>>>> the message in its entirety. Thank you.
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> Could you perhaps share your Gnu Radio flow-graph with us? It would
>>> help in seeing where your problems might originate.
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>
>>>
>>> This e-mail may contain privileged, confidential, copyrighted or other
>>> legally protected information, and is intended exclusively for the intended
>>> recipient. If you are not the intended recipient (even if the e-mail
>>> address above is yours), you may not review, store, use, copy, disclose or
>>> retransmit it in any form. If you are not the intended recipient or
>>> otherwise have received this by mistake, please immediately notify the
>>> sender by return e-mail (or [email protected]), then delete the message
>>> in its entirety. Thank
>>> you.grc>py>specA_Fs2MHz_750kHz.JPG>specA_Fs5MHz_f1.2MHz.JPG>_______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>> This e-mail may contain privileged, confidential, copyrighted or other
>> legally protected information, and is intended exclusively for the intended
>> recipient. If you are not the intended recipient (even if the e-mail
>> address above is yours), you may not review, store, use, copy, disclose or
>> retransmit it in any form. If you are not the intended recipient or
>> otherwise have received this by mistake, please immediately notify the
>> sender by return e-mail (or [email protected]), then delete the message in
>> its entirety. Thank you.
>
>
>
>
> This e-mail may contain privileged, confidential, copyrighted or other
> legally protected information, and is intended exclusively for the intended
> recipient. If you are not the intended recipient (even if the e-mail address
> above is yours), you may not review, store, use, copy, disclose or retransmit
> it in any form. If you are not the intended recipient or otherwise have
> received this by mistake, please immediately notify the sender by return
> e-mail (or [email protected]), then delete the message in its entirety.
> Thank you.
This
e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected]), then delete the message in its entirety. Thank you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: N210_Fs6.25M_f2.4M.JPG
Type: image/jpeg
Size: 129531 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141002/594d4b78/attachment-0002.JPG>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: N210_Fs6.25M_f2.8M.JPG
Type: image/jpeg
Size: 137894 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141002/594d4b78/attachment-0003.JPG>
------------------------------
Message: 2
Date: Thu, 02 Oct 2014 14:24:38 -0400
From: [email protected]
To: Urban Hakansson <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Frequency translation works differently on
N210 and B210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I have two quick things to offer:
Definitely update your UHD version if it's feasible.
Try reducing the magnitude of your baseband signal a little bit--to
perhaps 0.8 from 1.0.
On 2014-10-02 14:08, Urban Hakansson wrote:
> Ian,
>
> I confirmed it on my B210. You are absolutely correct. For Fs = 1.66667 MHz
> (5MHz/3), the alias component at fc-(Fs-f) starts to show up when f
> approaches Fs/4 (~416KHz), and grows stronger the closer the frequency came
> to the Nyquist frequency Fs/2(833.33kHz).
>
> However I ran the same test on the N210 for Fs = 6.25 MHz (100MHz/16) and the
> results were not good. First, there is No UHD warning about CIC rolloff or
> using odd interpolation. I take it to mean that only the half-band filters in
> the FPGA are used, and I expected only to see the desired sinsoid at fc+f.
>
> Case 1) Fs = 6.25 MHz. fc = 800MHz, f = 2.4MHz
> The spectrum analyzer clearly shows two components besides the LO, at
> fc-f = 797.6MHz
> fc+f = 802.4 MHz.
> I swept f from 0Hz and upwards and saw two components at fc-f and fc+f. The
> fc-f replica is ~15.5 dB below fc+f for f = 2.4MHz.
> Please see attached image of the spectrum analyzer, N210_Fs6.25M_f2.4M.jpg.
>
> Case 2) Fs = 6.25 MHz. fc = 800MHz, f = 2.8MHz.
> As I increase f and approach the Nyquist frequency 3.125 MHz I see the same
> thing happen that I observe on the B210.
> The spectrum analyzer clearly shows four components besides the LO, at
> fc-(Fs-f) = 796.55MHz
> fc-f = 797.2MHz
> fc+f = 802.8MHz
> fc+(Fs-f) = 803.45MHz
> See attached image of the spectrum analyzer, N210_Fs6.25M_f2.8M.jpg.
>
> So in conclusion, I see two undesired phenomena on my N210 + SBX
> daughterboard Rev 5.1.
>
> 1) I see a strong replica at fc-f in addition to the desired signal at fc+f
> for all frequencies f from 0 to Fs/2 Hz.
>
> 2) I see two aliases show up at fc +/-(Fs-f) as the the frequency of the
> complex exponential approaches the Nyquist frequency.
>
> Could I be mismatching the fpga version(FPGA Version: 10.1), firmware version
> (FW Version: 12.4), and UHD driver version(UHD_003.007.001-0-unknown)?
>
> Regards,
>
> Urban
> ----- Original Message -----
> From: "Ian Buckley" <[email protected]>
> To: "Urban Hakansson" <[email protected]>
> Cc: "Marcus D. Leech" <[email protected]>, [email protected]
> Sent: Thursday, October 2, 2014 1:32:58 AM
> Subject: Re: [USRP-users] Frequency translation works differently on N210 and
> B210.
>
> What you are seeing is *exactly* as sampling theory would predict.
> Your fc+f signal shows up on your spectrum analyzer at 800.625Mhz (Remember
> your 750kHz became 750*1.6666/2.000)
> Your "fc-f" image is not at fc-f (which would be 799.375MHz) but at
> 1.66666Mhz - 0.625Mhz = 798.95Mhz
>
> You see the alias so prominently because the pure CIC filter has terrible
> stop band rejection which is why it's largely unsuitable as a generic
> interpolation filter on it's own.
> Sweep you CW frequency slowly and watch the direction the image appears
> from...this is your clue where it's coming from, and a good practical
> technique when looking at real world signals and there unexpected by-products.
> If you select peak hold on your spectrum analyzer and sweep the frequency you
> will plot the frequency response of the CIC filter. Try it with sample rate
> 2.5MHz and 1.25MHz and see the response of the small half band filter and
> then the cascaded half band filters
>
> Now if you turn up the gain some more you will see a true "fc-f" signal,
> probably some 40-50db below your main signal and this will be due to the
> residual IQ imbalance present in real world direct conversion receivers.
>
> -Ian
>
> On Oct 1, 2014, at 12:45 PM, Urban Hakansson <[email protected]> wrote:
> Yes, I deliberately requested a sample rate that would force the use of the
> FPGA CIC filters. Fs = 1.666667 MHz is fine. I expected roll-off but I did
> not expect the replica at fc-f. The CIC filters should not introduce that
> kind of error, at least that is my understanding. ----- Original Message
> -----FW Version: 12.4 From: "Ian Buckley" <[email protected]> To: "Urban
> Hakansson" <[email protected]> Cc: "Marcus D. Leech" <[email protected]>,
> [email protected] Sent: Wednesday, October 1, 2014 2:53:04 PM
> Subject: Re: [USRP-users] Frequency translation works differently on N210 and
> B210. Did you note the warnings that this generates? The USRP's can not
> perform fractional rate conversions. Your sample rate was coerced to be
> compatible with a 5MHz master clock rate and up sampling was pure CIC filter
> based which has less than ideal spectra: UHD Warning: The requested
> interpolation is odd; the user should expect CIC rolloff. Select an even
> interpolation to ensure that a
halfband filter is enabled. interpolation = dsp_rate/samp_rate -> 3 = (5.000000
MHz)/(2.000000 MHz) UHD Warning: The hardware does not support the requested TX
sample rate: Target sample rate: 2.000000 MSps Actual sample rate: 1.666667
MSps UHD Warning: The requested interpolation is odd; the user should expect
CIC rolloff. Select an even interpolation to ensure that a halfband filter is
enabled. interpolation = dsp_rate/samp_rate -> 3 = (5.000000 MHz)/(2.000000
MHz) UHD Warning: The hardware does not support the requested TX sample rate:
Target sample rate: 2.000000 MSps Actual sample rate: 1.666667 MSps On Oct 1,
2014, at 11:41 AM, Urban Hakansson <[email protected]> wrote: Ian, Thanks
for taking a look at this problem. There is no sample rate conversion
2MHz->5MHz taking place. I executed the same flow graph for two different
sample rates. The master clock rate was set to 5 MHz in both cases. Case 1) The
sample rate was set to 5 MHz (equal to the master clock rate). Case 2)
The sample rate was set to 2 MHz (not equal to the master clock rate). Urban
----- Original Message ----- From: "Ian Buckley" <[email protected]> To:
"Urban Hakansson" <[email protected]> Cc: "Marcus D. Leech"
<[email protected]>, [email protected] Sent: Wednesday, October 1,
2014 2:20:34 PM Subject: Re: [USRP-users] Frequency translation works
differently on N210 and B210. Urban, a quick question...I just glanced at your
flow graph, it's very simple...I'm wondering where did the sample rate
conversion occur (2MHz->5MHz) in your example 2) quoted below? There is no
re-sampling block instantiated in your flow graph. On Oct 1, 2014, at 10:33 AM,
Urban Hakansson via USRP-users <[email protected]> wrote: First, thank
you for responding so promptly. I attach the Gnu Radio flow-graph and the
generated python script. It contains two USRP sink objects, one configured for
the B210 and the other for the N210. FYI, I use GnuRadio companinion 3.7.1.1
and 3.7.2.2. I also
attach two example images from the spectrum analyzer looking at the spectrum
from the B210. Image 1) B210 master clock rate = 5MHz, Sampling rate = 5 MHz,
frequency of complex exponential = 1.2 MHz, center frequency = 800MHz. No
replica at fc-f. As expected. Image 2) B210 master clock rate = 5MHz, Sampling
rate = 2 MHz, frequency of complex exponential = 750 kHz, center frequency =
800MHz. Replica at fc-f. The result from the N210 is a replica at fc-f as well
so I don't include a image. Regards, Urban Hakansson ----- Original Message
----- From: "Marcus D. Leech via USRP-users" <[email protected]> To:
[email protected] Sent: Tuesday, September 30, 2014 8:11:34 PM
Subject: Re: [USRP-users] Frequency translation works differently on N210 and
B210. On 09/30/2014 06:20 PM, Urban Hakansson via USRP-users wrote: Hi
everybody, I have a problem. I include below 1) General information, 2)
Introduction to my problem 3) Detailed description of my problem. General
background
information about my environment: Fedora 17 Linux; GNU C++ version 4.7.0
20120507 (Red Hat 4.7.0-5); Boost_104800; UHD_003.007.001-0-unknown N210
informationfrom uhd_usrp_probe: | Device: USRP2 / N-Series Device |
_____________________________________________________ | / | | Mboard: N210r4 |
| hardware: 2577 | | mac-addr: 00:80:2f:0a:e6:15 | | ip-addr: 192.168.2.199 | |
subnet: 255.255.255.255 | | gateway: 255.255.255.255 | | gpsdo: none | |
serial: F4A09C | | FW Version: 12.4 | | FPGA Version: 10.1 B210 information
from uhd_usrp_probe: | Device: B-Series Device |
_____________________________________________________ | / | | Mboard: B210 | |
revision: 4 | | product: 2 | | serial: F571B5 | | FW Version: 4.0 | | FPGA
Version: 3.0 Introduction/background: It is my understanding that outputting a
real-valued baseband signal x(t) = a*sin(2*pi*f*t) on an RF carrier fc should
result in two components at fc+f and fc-f, but outputting a complex-valued
baseband signal x(t) = exp(2*pi*f*t)
should only result in an fc+f component. The complex exponential can be used
for frequency translation but is causing me serious problems on the N210 + SBX
daughterboard. Detailed Problem Description: Using GnuRadio I output a simple
baseband complex exponential at frequency +f centered at the RF center
frequency fc. Now on the N210 in addition to the sinusoid at fc+f there is a
unexpected replica at fc-f about 13-14 dB below fc+f. When I run the same
script on the B210 and set master clock rate equal to the sample clock rate, I
only see the desired frequency component at fc+f. There is no replica at fc-f
as in the case of the N210. This is the correct behaviour as I understand it.
However, if I don't set the master clock rate equal to the sample rate on the
B210 I do get the undesired replica at fc-f 13-14 dB below the signal at fc+f
just as I did on the N210. Why does it only work if the master clock rate is
set equal to the sample clock rate on the B210? I have read somewhere on
the mailing list that the FPGA including CIC and HB filters are bypassed in
this case. Question: How can I output a simple complex-valued baseband signal
x(t) = exp(2*pi*f*t) on an RF carrier fc on the N210 and only get an fc+f
component so I can use this mechanism to perform frequency translation? Thanks
for you consideration. Regards, Urban Hakansson This e-mail may contain
privileged, confidential, copyrighted or other legally protected information,
and is intended exclusively for the intended recipient. If you are not the
intended recipient (even if the e-mail address above is yours), you may not
review, store, use, copy, disclose or retransmit it in any form. If you are not
the intended recipient or otherwise have received this by mistake, please
immediately notify the sender by return e-mail (or [email protected]), then
delete the message in its entirety. Thank you.
_______________________________________________ USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1] Could
you perhaps share your Gnu Radio flow-graph with us? It would help in seeing
where your problems might originate.
_______________________________________________ USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1] This
e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected]), then delete the message in its entirety. Thank
you.grc>py>specA_Fs2MHz_750kHz.JPG>specA_Fs5MHz_f1.2MHz.JPG>_______________________________________________
USRP-users mailing list [email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
This e-mail may contain privileged, confidential, copyrighted or other
legally protected information, and is intended exclusively for the
intended recipient. If you are not the intended recipient (even if the
e-mail address above is yours), you may not review, store, use, copy,
disclose or retransmit it in any form. If you are not the intended
recipient or otherwise have received this by mistake, please immediately
notify the sender by return e-mail (or [email protected]), then delete
the message in its entirety. Thank you. This e-mail may contain
privileged, confidential, copyrighted or other legally protected
information, and is intended exclusively for the intended recipient. If
you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it
in any form. If you are not the intended recipient or otherwise have
received this by mistake, please immediately notify the sender by return
e-mail (or [email protected]), then delete the message in its
entirety. Thank you.
This e-mail may contain privileged, confidential, copyrighted or other
legally protected information, and is intended exclusively for the
intended recipient. If you are not the intended recipient (even if the
e-mail address above is yours), you may not review, store, use, copy,
disclose or retransmit it in any form. If you are not the intended
recipient or otherwise have received this by mistake, please immediately
notify the sender by return e-mail (or [email protected]), then delete
the message in its entirety. Thank you.
Links:
------
[1] 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/20141002/de35e08b/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 2 Oct 2014 15:43:53 -0400 (EDT)
From: Urban Hakansson <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Frequency translation works differently on
N210 and B210.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Marcus,
I did set the baseband amplitude to 0.1 and the analog tx gain to 0dB, but That
does not change anything.
I did re-run the calibration scripts and that seemed to make things a little
better, especially the fc+(Fs-f) component almost disappeared completely.
I then tried increasing the sample rate to 12.5 MHz and that got rid of the
component at fc -(Fs-f) .
However the unexpected fc-f component still remains, albeit now ~22 dB below
the desired fc+f component, which II think is is an improvement due to
re-running the calibration scripts.
Urban
----- Original Message -----
From: [email protected]
To: "Urban Hakansson" <[email protected]>
Cc: "Ian Buckley" <[email protected]>, [email protected]
Sent: Thursday, October 2, 2014 2:24:38 PM
Subject: Re: [USRP-users] Frequency translation works differently on N210 and
B210.
I have two quick things to offer:
Definitely update your UHD version if it's feasible.
Try reducing the magnitude of your baseband signal a little bit--to perhaps 0.8
from 1.0.
On 2014-10-02 14:08, Urban Hakansson wrote:
Ian,
I confirmed it on my B210. You are absolutely correct. For Fs = 1.66667 MHz
(5MHz/3), the alias component at fc-(Fs-f) starts to show up when f approaches
Fs/4 (~416KHz), and grows stronger the closer the frequency came to the Nyquist
frequency Fs/2(833.33kHz).
However I ran the same test on the N210 for Fs = 6.25 MHz (100MHz/16) and the
results were not good. First, there is No UHD warning about CIC rolloff or
using odd interpolation. I take it to mean that only the half-band filters in
the FPGA are used, and I expected only to see the desired sinsoid at fc+f.
Case 1) Fs = 6.25 MHz. fc = 800MHz, f = 2.4MHz
The spectrum analyzer clearly shows two components besides the LO, at
fc-f = 797.6MHz
fc+f = 802.4 MHz.
I swept f from 0Hz and upwards and saw two components at fc-f and fc+f. The
fc-f replica is ~15.5 dB below fc+f for f = 2.4MHz.
Please see attached image of the spectrum analyzer, N210_Fs6.25M_f2.4M.jpg.
Case 2) Fs = 6.25 MHz. fc = 800MHz, f = 2.8MHz.
As I increase f and approach the Nyquist frequency 3.125 MHz I see the same
thing happen that I observe on the B210.
The spectrum analyzer clearly shows four components besides the LO, at
fc-(Fs-f) = 796.55MHz
fc-f = 797.2MHz
fc+f = 802.8MHz
fc+(Fs-f) = 803.45MHz
See attached image of the spectrum analyzer, N210_Fs6.25M_f2.8M.jpg.
So in conclusion, I see two undesired phenomena on my N210 + SBX daughterboard
Rev 5.1.
1) I see a strong replica at fc-f in addition to the desired signal at fc+f for
all frequencies f from 0 to Fs/2 Hz.
2) I see two aliases show up at fc +/-(Fs-f) as the the frequency of the
complex exponential approaches the Nyquist frequency.
Could I be mismatching the fpga version(FPGA Version: 10.1), firmware version
(FW Version: 12.4), and UHD driver version(UHD_003.007.001-0-unknown)?
Regards,
Urban
----- Original Message -----
From: "Ian Buckley" < [email protected] >
To: "Urban Hakansson" < [email protected] >
Cc: "Marcus D. Leech" < [email protected] >, [email protected] Sent:
Thursday, October 2, 2014 1:32:58 AM
Subject: Re: [USRP-users] Frequency translation works differently on N210 and
B210.
What you are seeing is *exactly* as sampling theory would predict.
Your fc+f signal shows up on your spectrum analyzer at 800.625Mhz (Remember
your 750kHz became 750*1.6666/2.000)
Your "fc-f" image is not at fc-f (which would be 799.375MHz) but at 1.66666Mhz
- 0.625Mhz = 798.95Mhz
You see the alias so prominently because the pure CIC filter has terrible stop
band rejection which is why it's largely unsuitable as a generic interpolation
filter on it's own.
Sweep you CW frequency slowly and watch the direction the image appears
from...this is your clue where it's coming from, and a good practical technique
when looking at real world signals and there unexpected by-products.
If you select peak hold on your spectrum analyzer and sweep the frequency you
will plot the frequency response of the CIC filter. Try it with sample rate
2.5MHz and 1.25MHz and see the response of the small half band filter and then
the cascaded half band filters
Now if you turn up the gain some more you will see a true "fc-f" signal,
probably some 40-50db below your main signal and this will be due to the
residual IQ imbalance present in real world direct conversion receivers.
-Ian
On Oct 1, 2014, at 12:45 PM, Urban Hakansson < [email protected] > wrote:
<blockquote>
Yes, I deliberately requested a sample rate that would force the use of the
FPGA CIC filters. Fs = 1.666667 MHz is fine. I expected roll-off but I did not
expect the replica at fc-f. The CIC filters should not introduce that kind of
error, at least that is my understanding. ----- Original Message -----FW
Version: 12.4 From: "Ian Buckley" < [email protected] > To: "Urban
Hakansson" < [email protected] > Cc: "Marcus D. Leech" < [email protected]
>, [email protected] Sent: Wednesday, October 1, 2014 2:53:04 PM
Subject: Re: [USRP-users] Frequency translation works differently on N210 and
B210. Did you note the warnings that this generates? The USRP's can not perform
fractional rate conversions. Your sample rate was coerced to be compatible with
a 5MHz master clock rate and up sampling was pure CIC filter based which has
less than ideal spectra: UHD Warning: The requested interpolation is odd; the
user should expect CIC rolloff. Select an even interpolation to ensure that
a halfband filter is enabled. interpolation = dsp_rate/samp_rate -> 3 =
(5.000000 MHz)/(2.000000 MHz) UHD Warning: The hardware does not support the
requested TX sample rate: Target sample rate: 2.000000 MSps Actual sample rate:
1.666667 MSps UHD Warning: The requested interpolation is odd; the user should
expect CIC rolloff. Select an even interpolation to ensure that a halfband
filter is enabled. interpolation = dsp_rate/samp_rate -> 3 = (5.000000
MHz)/(2.000000 MHz) UHD Warning: The hardware does not support the requested TX
sample rate: Target sample rate: 2.000000 MSps Actual sample rate: 1.666667
MSps On Oct 1, 2014, at 11:41 AM, Urban Hakansson < [email protected] >
wrote:
<blockquote>
Ian, Thanks for taking a look at this problem. There is no sample rate
conversion 2MHz->5MHz taking place. I executed the same flow graph for two
different sample rates. The master clock rate was set to 5 MHz in both cases.
Case 1) The sample rate was set to 5 MHz (equal to the master clock rate). Case
2) The sample rate was set to 2 MHz (not equal to the master clock rate). Urban
----- Original Message ----- From: "Ian Buckley" < [email protected] > To:
"Urban Hakansson" < [email protected] > Cc: "Marcus D. Leech" <
[email protected] >, [email protected] Sent: Wednesday, October 1,
2014 2:20:34 PM Subject: Re: [USRP-users] Frequency translation works
differently on N210 and B210. Urban, a quick question...I just glanced at your
flow graph, it's very simple...I'm wondering where did the sample rate
conversion occur (2MHz->5MHz) in your example 2) quoted below? There is no
re-sampling block instantiated in your flow graph. On Oct 1, 2014, at 10:33 AM,
Urban Hakansson v
ia USRP-users < [email protected] > wrote:
<blockquote>
First, thank you for responding so promptly. I attach the Gnu Radio flow-graph
and the generated python script. It contains two USRP sink objects, one
configured for the B210 and the other for the N210. FYI, I use GnuRadio
companinion 3.7.1.1 and 3.7.2.2. I also attach two example images from the
spectrum analyzer looking at the spectrum from the B210. Image 1) B210 master
clock rate = 5MHz, Sampling rate = 5 MHz, frequency of complex exponential =
1.2 MHz, center frequency = 800MHz. No replica at fc-f. As expected. Image 2)
B210 master clock rate = 5MHz, Sampling rate = 2 MHz, frequency of complex
exponential = 750 kHz, center frequency = 800MHz. Replica at fc-f. The result
from the N210 is a replica at fc-f as well so I don't include a image. Regards,
Urban Hakansson ----- Original Message ----- From: "Marcus D. Leech via
USRP-users" < [email protected] > To: [email protected] Sent:
Tuesday, September 30, 2014 8:11:34 PM Subject: Re: [USRP-users] Frequency
transla
tion works differently on N210 and B210. On 09/30/2014 06:20 PM, Urban
Hakansson via USRP-users wrote:
<blockquote>
Hi everybody, I have a problem. I include below 1) General information, 2)
Introduction to my problem 3) Detailed description of my problem. General
background information about my environment: Fedora 17 Linux; GNU C++ version
4.7.0 20120507 (Red Hat 4.7.0-5); Boost_104800; UHD_003.007.001-0-unknown N210
informationfrom uhd_usrp_probe: | Device: USRP2 / N-Series Device |
_____________________________________________________ | / | | Mboard: N210r4 |
| hardware: 2577 | | mac-addr: 00:80:2f:0a:e6:15 | | ip-addr: 192.168.2.199 | |
subnet: 255.255.255.255 | | gateway: 255.255.255.255 | | gpsdo: none | |
serial: F4A09C | | FW Version: 12.4 | | FPGA Version: 10.1 B210 information
from uhd_usrp_probe: | Device: B-Series Device |
_____________________________________________________ | / | | Mboard: B210 | |
revision: 4 | | product: 2 | | serial: F571B5 | | FW Version: 4.0 | | FPGA
Version: 3.0 Introduction/background: It is my understanding that outputting a
real-valued baseband signal x(t) =
a*sin(2*pi*f*t) on an RF carrier fc should result in two components at fc+f
and fc-f, but outputting a complex-valued baseband signal x(t) = exp(2*pi*f*t)
should only result in an fc+f component. The complex exponential can be used
for frequency translation but is causing me serious problems on the N210 + SBX
daughterboard. Detailed Problem Description: Using GnuRadio I output a simple
baseband complex exponential at frequency +f centered at the RF center
frequency fc. Now on the N210 in addition to the sinusoid at fc+f there is a
unexpected replica at fc-f about 13-14 dB below fc+f. When I run the same
script on the B210 and set master clock rate equal to the sample clock rate, I
only see the desired frequency component at fc+f. There is no replica at fc-f
as in the case of the N210. This is the correct behaviour as I understand it.
However, if I don't set the master clock rate equal to the sample rate on the
B210 I do get the undesired replica at fc-f 13-14 dB below the signal at
fc+f just as I did on the N210. Why does it only work if the master clock
rate is set equal to the sample clock rate on the B210? I have read somewhere
on the mailing list that the FPGA including CIC and HB filters are bypassed in
this case. Question: How can I output a simple complex-valued baseband signal
x(t) = exp(2*pi*f*t) on an RF carrier fc on the N210 and only get an fc+f
component so I can use this mechanism to perform frequency translation? Thanks
for you consideration. Regards, Urban Hakansson This e-mail may contain
privileged, confidential, copyrighted or other legally protected information,
and is intended exclusively for the intended recipient. If you are not the
intended recipient (even if the e-mail address above is yours), you may not
review, store, use, copy, disclose or retransmit it in any form. If you are not
the intended recipient or otherwise have received this by mistake, please
immediately notify the sender by return e-mail (or [email protected] ), then
delete the message in its entirety. Thank you.
_______________________________________________ USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Could you perhaps share your Gnu Radio flow-graph with us? It would help in
seeing where your problems might originate.
_______________________________________________ USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com This e-mail
may contain privileged, confidential, copyrighted or other legally protected
information, and is intended exclusively for the intended recipient. If you are
not the intended recipient (even if the e-mail address above is yours), you may
not review, store, use, copy, disclose or retransmit it in any form. If you are
not the intended recipient or otherwise have received this by mistake, please
immediately notify the sender by return e-mail (or [email protected] ), then
delete the message in its entirety. Thank
you.grc>py>specA_Fs2MHz_750kHz.JPG>specA_Fs5MHz_f1.2MHz.JPG>_______________________________________________
USRP-users mailing list [email protected] http://lists.ettus.com/ma
ilman/listinfo/usrp-users_lists.ettus.com
</blockquote>
This e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected] ), then delete the message in its entirety. Thank you.
</blockquote>
This e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected] ), then delete the message in its entirety. Thank you.
</blockquote>
This e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected] ), then delete the message in its entirety. Thank you.
</blockquote>
This
e-mail may contain privileged, confidential, copyrighted or other legally
protected information, and is intended exclusively for the intended recipient.
If you are not the intended recipient (even if the e-mail address above is
yours), you may not review, store, use, copy, disclose or retransmit it in any
form. If you are not the intended recipient or otherwise have received this by
mistake, please immediately notify the sender by return e-mail (or
[email protected]), then delete the message in its entirety. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141002/423d5282/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 2 Oct 2014 12:46:17 -0700
From: Michael West <[email protected]>
To: Abhinav Jadon <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD Related
Message-ID:
<cam4xkrpyytjim3vt5zejl3zmwfyglbthq8w3at7y9vvr1dh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The uhd_find_devices command does not initialize the device. Try running
uhd_usrp_probe. That will initialize the device including the reference
clock and PPS. The LINK LED is red and merely indicates that the host
computer is communicating with the device.
Regards,
Michael
On Thu, Oct 2, 2014 at 7:30 AM, Abhinav Jadon via USRP-users <
[email protected]> wrote:
> Hi all ,
>
> I have flashed the USRP with a GNU-Compatible FPGA image and installed
> PCI UHD Drivers . And i queried the uhd_find_devices program to check
> what device is connected to the system , if any. This yields me a
> result ( see attached screenshot) that should naturally imply that
> the driver is working correctly and the link layer level connection is
> successfully made but the link led is red and blinking and the rest
> (REF and PPS ) LEDs do not light up at all . This is contrary to the
> REF ,LINK and PPS LEDs turning green when connected to the system
> hosting NI-USRP driver . What inference should i draw from this
> observation ? Is something wrong ?
>
> Thanks
> --
> Abhinav PS Jadon
> 2012122
> Btech 2016-ECE
>
> _______________________________________________
> 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/20141002/f1efa7a4/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 2 Oct 2014 17:50:25 -0700
From: Robert McIntyre <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Help building UHD...?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Not sure what's going on here. Monday night, I was able to download and build
UHD following these instructions on a stock/updated Debian Testing system:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_build
The next night I tried to build gnuradio, and had to stop in the middle, and it
basically horked my system, so I just reinstalled the Debian Testing OS, and
updated, and then started over last night.
When I tried to build UHD again, I started getting CMAKE errors. Got
frustrated, flattened my system (it's a test system), and installed Debian
Stable (Wheezy), and tried again.
Still getting CMAKE errors, but they're different now. Pasted below.
Hoping someone can help decipher what I'm doing wrong. As far as I know, I've
done the same thing every time. I tried fiddling with some of the CMake
settings last night, but got nowhere. I took a look through the git repo
history, and nothing sticks out, but I'm not familiar with the code.
Thanks!
Robert
user@machine:/data/sources/uhd/host/build$ cmake ../
CMake Error: CMake was unable to find a build program corresponding to "Unix
Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a
different build tool.
CMake Error: Error required internal CMake variable not set, cmake may be not
be built correctly.
Missing variable is:
CMAKE_CXX_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may be not
be built correctly.
Missing variable is:
CMAKE_CXX_COMPILER
CMake Error: Could not find cmake module
file:/data/sources/uhd/host/build/CMakeFiles/CMakeCXXCompiler.cmake
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141002/3fbb70ef/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 3 Oct 2014 09:18:25 +0530
From: gsmandvoip <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] rx_samples_to_file issue
Message-ID:
<CADE+fGD6=iDcsX=29+iz37k+taeyqbwfzzxxdfrpqfeaeqo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Marcus for your replies. Yes O gone away.
On Thu, Oct 2, 2014 at 5:50 PM, Marcus D. Leech <[email protected]> wrote:
> with rx_samples_to_file without _4rx.rbf, Initially I tried on my i3,
> 4GB ram, it gave me
> some OOOO but was lesser than earlier, but I do not understand, my most of
> the ram capacity and processor was sitting idle while it shows OOOO, why is
> this strange behaviour
>
> The default format for uhd_rx_cfile is complex-float, thus doubling the
> amount of data written compared to rx_samples_to_file.
>
> You can't just use CPU usage as an indicator of loading--if you're writing
> to disk, the disk subsystem may be much slower than you think, so the
> "rate limiting step" is writes to the disk, not computational elements.
>
> Try using /dev/null as the file that you write to. If the 'O' go away,
> even at higher sampling rates, then it's your disk subsystem.
>
>
> using uhd_rx_cfile getting similar result, but strangely, why it is low,
> at 4M sampling rate it was higher???
>
>
> On Thu, Oct 2, 2014 at 9:27 AM, Marcus D. Leech <[email protected]> wrote:
>
>> On 10/01/2014 11:46 PM, gsmandvoip wrote:
>>
>> Yes I am running single channel, but when trying to achieve my desired
>> sampling rate without _4rx.rbf, it says, requested sampling rate is not
>> valid, adjusting to some 3.9M or so.
>> sorry for misleading info I gave earlier, I have i3, with 32 bit and i7
>> with 64 bit, but getting same result on both machines
>>
>> Here is my command to capture signal:
>>
>> ./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX"
>> --freq "$FC" --rate="$SR" $FILE --nsamps "$NSAMPLES"
>>
>> and here is its output:
>>
>> Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX...
>> -- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
>> -- Opening a USRP1 device...
>> -- Loading FPGA image: /usr/share/uhd/images/usrp1_fpga_4rx.rbf... done
>> -- Using FPGA clock rate of 52.000000MHz...
>> *Error: LookupError: IndexError: multi_usrp::get_tx_subdev_spec(0) failed
>> to make default spec - ValueError: The subdevice specification "A:0" is too
>> long.*
>> The user specified 1 channels, but there are only 0 tx dsps on mboard 0.
>>
>>
>> Don't use the _4rx image if you don't need it.
>>
>> The USRP1 only does strict-integer resampling, and with a master clock
>> (NON STANDARD FOR USRP1) of 52.000MHz, 4Msps is not a sample rate
>> that it can produce. Try 5.2Msps or 4.3333Msps.
>>
>> At 5.2Msps, it's recording at roughly 20.8Mbytes/second, so your system
>> needs to be able to sustain that for at least as long as the capture lasts.
>>
>>
>>
>
>
> --
> 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/20141003/5d15927c/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 3 Oct 2014 08:47:45 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Martin Braun'" <[email protected]>,
<[email protected]>
Subject: Re: [USRP-users] B210 UHD Error
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
One addition, it works for hours with no problem at 32 megasamples per second
when Windows is used. I am using the Balint Seeber-setup, ExtIO/HDSDR. Would it
be helpful to find out the exact versions of the firmware and image he is
using, or do you know this anyway?
Ralph.
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Martin Braun via USRP-users
> Sent: Tuesday, 30 September, 2014 18:11
> To: [email protected]
> Subject: Re: [USRP-users] B210 UHD Error
>
> Terry,
>
> thanks, this is useful information. We are currently working on this bug, but
> unfortunately, it only occurs with some B-Series boards,
> and any bug that occurs once every couple of hours is hard to debug.
>
> Could you please help us by providing additional info:
>
> - Is this behaviour rate-dependent? Does it happen more easily at high rates?
> - You are connected to USB 3, I presume?
> - Which rev board do you have?
> - Just to be sure: You have a B210, and not a B200, right?
>
> Thanks for your help with this -- any datapoint we get will accelerate any
> solution we can come up with.
>
> Cheers,
> m
>
> On 30.09.2014 07:39, Terry Stevenson via USRP-users wrote:
> > Hi,
> >
> > I'm using a USRP B210 and I've encountered what seems to be a driver
> > error. When running the uhd_fft program (packaged with GnuRadio) it
> > will run smoothly for a few minutes, then become very laggy, then
> > freeze and begin printing "UHD Error: The receive packet handler
> > caught an exception. RuntimeError: usb rx6 transfer status 5".
> >
> > At first I was using UHD 3.7.2, and I saw that another user had a
> > similar problem, so I reverted to 3.7.1. Now it will run for several
> > hours, but the same problem eventually occurs. My motherboard chipset
> > is Intel Z77 Express, if that helps.
> >
> > Thanks,
> > Terry
> >
> >
> > _______________________________________________
> > 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 --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141003/5afd7078/attachment-0001.sig>
------------------------------
Message: 8
Date: Fri, 3 Oct 2014 09:26:09 -0400
From: Peter Witkowski <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rx_samples_to_file issue
Message-ID:
<CAN1Qg3MABCrp++s7MmzdoJ4Vs2ehLQA_337GpFCuqP=obza...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
To say that the issue is just because the disk subsystem can't keep up is a
bit of cop-out.
I had issues writing to disk when the incoming stream was 400MB/s and my
RAID0 system was benchmarked at being much higher than that.
The issue that I've been seeing stems from the fact that it appears that
you cannot concurrently read/write from the data stream as its coming in.
In effect you have a main loop that reads from the device and then
immediately tries to write that buffer to file. If you do not complete
these operations in a timely fashion overflows occur.
One way to solve (or at least band aid the issue) is to set your
dirty_background_ratio to 0. I was able to get writing to disk working
somewhat with this setting as it is more predictable to directly write to
disk instead of having your write cache fill up and then having a large
amount of data to push to disk. That said, my RAID0 array is capable of
such speeds and even then I was getting a few (but much reduced) overflows.
The one surefire way I know of getting this working (even on a slow disk
system) is to buffer the data. The buffer can then be consumed by the disk
writing process while being concurrently added onto by the device reader.
The easiest way to test buffering (that I've found) is to simply set up a
GNURadio Companion program with a stream-to-vector block between the USRP
and file sink blocks. This is exactly what I am doing currently since even
with a very powerful system, I could not get data saved to disk quickly
enough given the aforementioned issues with the provided UHD software.
On Thu, Oct 2, 2014 at 11:48 PM, gsmandvoip via USRP-users <
[email protected]> wrote:
> Thanks Marcus for your replies. Yes O gone away.
>
> On Thu, Oct 2, 2014 at 5:50 PM, Marcus D. Leech <[email protected]> wrote:
>
>> with rx_samples_to_file without _4rx.rbf, Initially I tried on my i3,
>> 4GB ram, it gave me
>> some OOOO but was lesser than earlier, but I do not understand, my most
>> of the ram capacity and processor was sitting idle while it shows OOOO, why
>> is this strange behaviour
>>
>> The default format for uhd_rx_cfile is complex-float, thus doubling the
>> amount of data written compared to rx_samples_to_file.
>>
>> You can't just use CPU usage as an indicator of loading--if you're
>> writing to disk, the disk subsystem may be much slower than you think, so
>> the
>> "rate limiting step" is writes to the disk, not computational elements.
>>
>> Try using /dev/null as the file that you write to. If the 'O' go away,
>> even at higher sampling rates, then it's your disk subsystem.
>>
>>
>> using uhd_rx_cfile getting similar result, but strangely, why it is
>> low, at 4M sampling rate it was higher???
>>
>>
>> On Thu, Oct 2, 2014 at 9:27 AM, Marcus D. Leech <[email protected]>
>> wrote:
>>
>>> On 10/01/2014 11:46 PM, gsmandvoip wrote:
>>>
>>> Yes I am running single channel, but when trying to achieve my desired
>>> sampling rate without _4rx.rbf, it says, requested sampling rate is not
>>> valid, adjusting to some 3.9M or so.
>>> sorry for misleading info I gave earlier, I have i3, with 32 bit and i7
>>> with 64 bit, but getting same result on both machines
>>>
>>> Here is my command to capture signal:
>>>
>>> ./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX"
>>> --freq "$FC" --rate="$SR" $FILE --nsamps "$NSAMPLES"
>>>
>>> and here is its output:
>>>
>>> Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX...
>>> -- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
>>> -- Opening a USRP1 device...
>>> -- Loading FPGA image: /usr/share/uhd/images/usrp1_fpga_4rx.rbf... done
>>> -- Using FPGA clock rate of 52.000000MHz...
>>> *Error: LookupError: IndexError: multi_usrp::get_tx_subdev_spec(0)
>>> failed to make default spec - ValueError: The subdevice specification "A:0"
>>> is too long.*
>>> The user specified 1 channels, but there are only 0 tx dsps on mboard 0.
>>>
>>>
>>> Don't use the _4rx image if you don't need it.
>>>
>>> The USRP1 only does strict-integer resampling, and with a master clock
>>> (NON STANDARD FOR USRP1) of 52.000MHz, 4Msps is not a sample rate
>>> that it can produce. Try 5.2Msps or 4.3333Msps.
>>>
>>> At 5.2Msps, it's recording at roughly 20.8Mbytes/second, so your system
>>> needs to be able to sustain that for at least as long as the capture lasts.
>>>
>>>
>>>
>>
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Peter Witkowski
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141003/4a783eee/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 03 Oct 2014 09:34:15 -0400
From: [email protected]
To: Peter Witkowski <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] rx_samples_to_file issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
One has to keep firmly in mind that programs like rx_samples_to_file are
*examples* that show how to use
the underlying UHD API. They are not necessarily optimized for all
situations, and indeed, one could
restructure rx_samples_to_file to decouple UHD I/O from filesystem I/O,
using a large buffer between them.
The fact is that dynamic performance of high-speed, real-time, flows is
something that almost-invariably needs
tweaking for any particular situation. There's no way for an example
application to meet all those requirements.
But the fact also remains that for *some* systems, rx_samples_to_file
(and uhd_rx_cfile on the Gnu Radio side)
are able to stream high-speed data just fine as-is.
On 2014-10-03 09:26, Peter Witkowski via USRP-users wrote:
> To say that the issue is just because the disk subsystem can't keep up is a
> bit of cop-out.
>
> I had issues writing to disk when the incoming stream was 400MB/s and my
> RAID0 system was benchmarked at being much higher than that.
>
> The issue that I've been seeing stems from the fact that it appears that you
> cannot concurrently read/write from the data stream as its coming in. In
> effect you have a main loop that reads from the device and then immediately
> tries to write that buffer to file. If you do not complete these operations
> in a timely fashion overflows occur.
>
> One way to solve (or at least band aid the issue) is to set your
> dirty_background_ratio to 0. I was able to get writing to disk working
> somewhat with this setting as it is more predictable to directly write to
> disk instead of having your write cache fill up and then having a large
> amount of data to push to disk. That said, my RAID0 array is capable of such
> speeds and even then I was getting a few (but much reduced) overflows.
>
> The one surefire way I know of getting this working (even on a slow disk
> system) is to buffer the data. The buffer can then be consumed by the disk
> writing process while being concurrently added onto by the device reader. The
> easiest way to test buffering (that I've found) is to simply set up a
> GNURadio Companion program with a stream-to-vector block between the USRP and
> file sink blocks. This is exactly what I am doing currently since even with a
> very powerful system, I could not get data saved to disk quickly enough given
> the aforementioned issues with the provided UHD software.
>
> On Thu, Oct 2, 2014 at 11:48 PM, gsmandvoip via USRP-users
> <[email protected]> wrote:
>
> Thanks Marcus for your replies. Yes O gone away.
>
> On Thu, Oct 2, 2014 at 5:50 PM, Marcus D. Leech <[email protected]> wrote:
>
> with rx_samples_to_file without _4rx.rbf, Initially I tried on my i3, 4GB
> ram, it gave me
> some OOOO but was lesser than earlier, but I do not understand, my most of
> the ram capacity and processor was sitting idle while it shows OOOO, why is
> this strange behaviour The default format for uhd_rx_cfile is complex-float,
> thus doubling the amount of data written compared to rx_samples_to_file.
>
> You can't just use CPU usage as an indicator of loading--if you're writing to
> disk, the disk subsystem may be much slower than you think, so the
> "rate limiting step" is writes to the disk, not computational elements.
>
> Try using /dev/null as the file that you write to. If the 'O' go away, even
> at higher sampling rates, then it's your disk subsystem.
>
> using uhd_rx_cfile getting similar result, but strangely, why it is low, at
> 4M sampling rate it was higher???
>
> On Thu, Oct 2, 2014 at 9:27 AM, Marcus D. Leech <[email protected]> wrote:
>
> On 10/01/2014 11:46 PM, gsmandvoip wrote:
>
> Yes I am running single channel, but when trying to achieve my desired
> sampling rate without _4rx.rbf, it says, requested sampling rate is not
> valid, adjusting to some 3.9M or so. sorry for misleading info I gave
> earlier, I have i3, with 32 bit and i7 with 64 bit, but getting same result
> on both machines
>
> Here is my command to capture signal:
>
> ./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX" --freq
> "$FC" --rate="$SR" $FILE --nsamps "$NSAMPLES"
>
> and here is its output:
>
> Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX...
> -- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
> -- Opening a USRP1 device...
> -- Loading FPGA image: /usr/share/uhd/images/usrp1_fpga_4rx.rbf... done
> -- Using FPGA clock rate of 52.000000MHz...
> ERROR: LOOKUPERROR: INDEXERROR: MULTI_USRP::GET_TX_SUBDEV_SPEC(0) FAILED TO
> MAKE DEFAULT SPEC - VALUEERROR: THE SUBDEVICE SPECIFICATION "A:0" IS TOO LONG.
> The user specified 1 channels, but there are only 0 tx dsps on mboard 0.
>
> Don't use the _4rx image if you don't need it.
>
> The USRP1 only does strict-integer resampling, and with a master clock (NON
> STANDARD FOR USRP1) of 52.000MHz, 4Msps is not a sample rate
> that it can produce. Try 5.2Msps or 4.3333Msps.
>
> At 5.2Msps, it's recording at roughly 20.8Mbytes/second, so your system needs
> to be able to sustain that for at least as long as the capture lasts.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org [1]
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [2]
--
Peter Witkowski
[email protected]
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [2]
Links:
------
[1] http://www.sbrac.org
[2] 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/20141003/094d6cdd/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 03 Oct 2014 16:55:05 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] rx_samples_to_file issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I have to agree with Marcus on this. Also, keep in mind that storage is
really what an operating system should take care of in any "general
purpose" scenario, ie. that as long as I just write to a file, I'd
expect that the thing in charge of storage (my kernel / the filesystems
/ block device drivers) does the best it can to keep up. If I find
myself in a situation where my specific storage needs dictate a huge
write buffer, changing the application might be one way, but as I'm
responsible for my won storage subsystem, I could just as well increase
the cache buffer sizes, and let the operating system handle storage
operation. If your RAID is really performing as well as it is
benchmarked to, then this should not be one of your problems. All
rx_samples_to_file does is really sequentially writing out data at a
constant rate, which is the most basic write benchmark I can think of.
If your storage subsystem (filesystem + storage abstraction + raid
driver + interface driver + hard drive interface + hard drives +
hardware caches) can't keep up, it's failing to perform as specified,
simple as that. In this case, saying that the application needs to be
smarter when dealing with storage seems like a bit of a cop-out to me ;)
I'd like to point out that most benchmarks use heavily averaged numbers
for write speeds etc. UHD on the other hand kind of demands soft
real-time performance of a write subsystem, which is a lot harder to
fulfill. This comes up rather frequently, but I have to stress it: you
need a fast guaranteed write rate, not only an average one, and as soon
as your operating system has to postpone writing data[1], it has to have
enough performance to catch up whilst still meeting continued demand.
This is general purpose hardware running general purpose OS with dozens
of processes, and you can't just say "every single component is up to my
task, thus my system suffices", because everything potentially blocks
everything!
Greetings,
Marcus
[1] e.g. because the filesystems needs to calculate checksums, update
tables, another process gets scheduled, a device blocks your PCIe bus,
your platters randomly need a bit longer to seek, you reach the physical
end of an LVM volume and have to move across a disk, an interrupt does
what an interrupt does, some process is getting noticed on a changing
file descriptor, DBUS is happening in the kernel, token ring has run out
of tokens, thermal throttling, bitflips on SATA leading to
retransmission, some page getting fetched from swap...
On 03.10.2014 15:34, Marcus D. Leech via USRP-users wrote:
>
>
> One has to keep firmly in mind that programs like rx_samples_to_file are
> *examples* that show how to use
>
> the underlying UHD API. They are not necessarily optimized for all
> situations, and indeed, one could
>
> restructure rx_samples_to_file to decouple UHD I/O from filesystem I/O,
> using a large buffer between them.
>
> The fact is that dynamic performance of high-speed, real-time, flows is
> something that almost-invariably needs
>
> tweaking for any particular situation. There's no way for an example
> application to meet all those requirements.
>
> But the fact also remains that for *some* systems, rx_samples_to_file
> (and uhd_rx_cfile on the Gnu Radio side)
>
> are able to stream high-speed data just fine as-is.
>
> On 2014-10-03 09:26, Peter Witkowski via USRP-users wrote:
>
>> To say that the issue is just because the disk subsystem can't keep up is a
>> bit of cop-out.
>>
>> I had issues writing to disk when the incoming stream was 400MB/s and my
>> RAID0 system was benchmarked at being much higher than that.
>>
>> The issue that I've been seeing stems from the fact that it appears that you
>> cannot concurrently read/write from the data stream as its coming in. In
>> effect you have a main loop that reads from the device and then immediately
>> tries to write that buffer to file. If you do not complete these operations
>> in a timely fashion overflows occur.
>>
>> One way to solve (or at least band aid the issue) is to set your
>> dirty_background_ratio to 0. I was able to get writing to disk working
>> somewhat with this setting as it is more predictable to directly write to
>> disk instead of having your write cache fill up and then having a large
>> amount of data to push to disk. That said, my RAID0 array is capable of such
>> speeds and even then I was getting a few (but much reduced) overflows.
>>
>> The one surefire way I know of getting this working (even on a slow disk
>> system) is to buffer the data. The buffer can then be consumed by the disk
>> writing process while being concurrently added onto by the device reader.
>> The easiest way to test buffering (that I've found) is to simply set up a
>> GNURadio Companion program with a stream-to-vector block between the USRP
>> and file sink blocks. This is exactly what I am doing currently since even
>> with a very powerful system, I could not get data saved to disk quickly
>> enough given the aforementioned issues with the provided UHD software.
>>
>> On Thu, Oct 2, 2014 at 11:48 PM, gsmandvoip via USRP-users
>> <[email protected]> wrote:
>>
>> Thanks Marcus for your replies. Yes O gone away.
>>
>> On Thu, Oct 2, 2014 at 5:50 PM, Marcus D. Leech <[email protected]> wrote:
>>
>> with rx_samples_to_file without _4rx.rbf, Initially I tried on my i3, 4GB
>> ram, it gave me
>> some OOOO but was lesser than earlier, but I do not understand, my most of
>> the ram capacity and processor was sitting idle while it shows OOOO, why is
>> this strange behaviour The default format for uhd_rx_cfile is complex-float,
>> thus doubling the amount of data written compared to rx_samples_to_file.
>>
>> You can't just use CPU usage as an indicator of loading--if you're writing
>> to disk, the disk subsystem may be much slower than you think, so the
>> "rate limiting step" is writes to the disk, not computational elements.
>>
>> Try using /dev/null as the file that you write to. If the 'O' go away, even
>> at higher sampling rates, then it's your disk subsystem.
>>
>> using uhd_rx_cfile getting similar result, but strangely, why it is low, at
>> 4M sampling rate it was higher???
>>
>> On Thu, Oct 2, 2014 at 9:27 AM, Marcus D. Leech <[email protected]> wrote:
>>
>> On 10/01/2014 11:46 PM, gsmandvoip wrote:
>>
>> Yes I am running single channel, but when trying to achieve my desired
>> sampling rate without _4rx.rbf, it says, requested sampling rate is not
>> valid, adjusting to some 3.9M or so. sorry for misleading info I gave
>> earlier, I have i3, with 32 bit and i7 with 64 bit, but getting same result
>> on both machines
>>
>> Here is my command to capture signal:
>>
>> ./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX" --freq
>> "$FC" --rate="$SR" $FILE --nsamps "$NSAMPLES"
>>
>> and here is its output:
>>
>> Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX...
>> -- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
>> -- Opening a USRP1 device...
>> -- Loading FPGA image: /usr/share/uhd/images/usrp1_fpga_4rx.rbf... done
>> -- Using FPGA clock rate of 52.000000MHz...
>> ERROR: LOOKUPERROR: INDEXERROR: MULTI_USRP::GET_TX_SUBDEV_SPEC(0) FAILED TO
>> MAKE DEFAULT SPEC - VALUEERROR: THE SUBDEVICE SPECIFICATION "A:0" IS TOO
>> LONG.
>> The user specified 1 channels, but there are only 0 tx dsps on mboard 0.
>>
>> Don't use the _4rx image if you don't need it.
>>
>> The USRP1 only does strict-integer resampling, and with a master clock (NON
>> STANDARD FOR USRP1) of 52.000MHz, 4Msps is not a sample rate
>> that it can produce. Try 5.2Msps or 4.3333Msps.
>>
>> At 5.2Msps, it's recording at roughly 20.8Mbytes/second, so your system
>> needs to be able to sustain that for at least as long as the capture lasts.
>
>
> _______________________________________________
> 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/20141003/0bd1eaff/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 3 Oct 2014 11:44:34 -0400
From: Peter Witkowski <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rx_samples_to_file issue
Message-ID:
<can1qg3pzz4z93ycedwoegy3vnnoxf07ydzsvasay9bu1ndm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
So I'm confused.
You state that if I can't use rx_samples_to_file, my system is failing to
perform as specified to write data out, then you give an example of several
things that can happen to create a stochastic write speed (which I totally
understand and agree with). Given that writes can be stochastic, why is
there not a software buffer implemented in the UHD sample code to account
for such issues? I understand that it's meant to be an example, but I've
also seen it referenced as being used effectively as a debugger or test for
people having issues (i.e. recommendation to use the UHD programs in place
of GNURadio to resolve issues).
Also, in terms of benchmarking, I'm quoting minimum values, not averages.
I agree with you that average values are pointless, and in reality the disk
subsystem needs to perform when called up. My minimum values for a 4 disk
RAID0 with a dedicated controller are well within the data rate that I am
pushing.
Is there an example system that can handle sustained data capture from the
USRP at (or near the limits) of 10GigE or the PCIe interfaces (maybe the
requirement is enterprise class PCIe SSDs)? I'm running a two socket Xenon
system (two hex core processors) with 64GB of RAM. How much more hardware
should I throw at the problem to be able to sample/write at 100MS (half of
what is quoted on the website for bandwidth for the 10GigE kit) using the
provided code?
I think the issue here is that the code itself can't simply get through
it's main loop fast enough. There's a difference between data bandwidth
and CPU throughput. The sequential nature of the code means that if any
weird stuff happens (your example was a good set of kernel related hilarity
that can lead to stochastic timing) you will have overflows since you
cannot read fast enough. This is why a 90% solution for my application was
to just set the dirty_background_ratio to 0 and also why redirection to
/dev/null makes overflows go away. With either method I didn't have to
wait for a large write cache to flush before moving on to the next read
from the USRP. Note that there can also be things that happen on the read
side as well. Does this mean that I can only run the code on an RTOS?
As a final note, my understanding is that GNURadio and the USRP were
developed for domain experts in DSP to use. These users may or may not
have prior experience in software. As a result, I'd recommend perhaps
adding a buffered example or have the USRP GNURadio block allow for
buffering. Otherwise, I just don't see how you can advertise 200 MS/s
(maybe even a simple "buffer" block in GNURadio would do the trick?). I
understand that this is theoretical limit of the bus, but if there doesn't
exist a driver or other software to make use of this, the practical limit
becomes much, much smaller.
On Fri, Oct 3, 2014 at 10:55 AM, Marcus M?ller <[email protected]>
wrote:
> I have to agree with Marcus on this. Also, keep in mind that storage is
> really what an operating system should take care of in any "general
> purpose" scenario, ie. that as long as I just write to a file, I'd expect
> that the thing in charge of storage (my kernel / the filesystems / block
> device drivers) does the best it can to keep up. If I find myself in a
> situation where my specific storage needs dictate a huge write buffer,
> changing the application might be one way, but as I'm responsible for my
> won storage subsystem, I could just as well increase the cache buffer
> sizes, and let the operating system handle storage operation. If your RAID
> is really performing as well as it is benchmarked to, then this should not
> be one of your problems. All rx_samples_to_file does is really sequentially
> writing out data at a constant rate, which is the most basic write
> benchmark I can think of.
>
> If your storage subsystem (filesystem + storage abstraction + raid driver
> + interface driver + hard drive interface + hard drives + hardware caches)
> can't keep up, it's failing to perform as specified, simple as that. In
> this case, saying that the application needs to be smarter when dealing
> with storage seems like a bit of a cop-out to me ;)
>
> I'd like to point out that most benchmarks use heavily averaged numbers
> for write speeds etc. UHD on the other hand kind of demands soft real-time
> performance of a write subsystem, which is a lot harder to fulfill. This
> comes up rather frequently, but I have to stress it: you need a fast
> guaranteed write rate, not only an average one, and as soon as your
> operating system has to postpone writing data[1], it has to have enough
> performance to catch up whilst still meeting continued demand. This is
> general purpose hardware running general purpose OS with dozens of
> processes, and you can't just say "every single component is up to my task,
> thus my system suffices", because everything potentially blocks everything!
>
> Greetings,
> Marcus
>
> [1] e.g. because the filesystems needs to calculate checksums, update
> tables, another process gets scheduled, a device blocks your PCIe bus, your
> platters randomly need a bit longer to seek, you reach the physical end of
> an LVM volume and have to move across a disk, an interrupt does what an
> interrupt does, some process is getting noticed on a changing file
> descriptor, DBUS is happening in the kernel, token ring has run out of
> tokens, thermal throttling, bitflips on SATA leading to retransmission,
> some page getting fetched from swap...
>
>
> On 03.10.2014 15:34, Marcus D. Leech via USRP-users wrote:
>
>
>
> One has to keep firmly in mind that programs like rx_samples_to_file are
> *examples* that show how to use
>
> the underlying UHD API. They are not necessarily optimized for all
> situations, and indeed, one could
>
> restructure rx_samples_to_file to decouple UHD I/O from filesystem I/O,
> using a large buffer between them.
>
> The fact is that dynamic performance of high-speed, real-time, flows is
> something that almost-invariably needs
>
> tweaking for any particular situation. There's no way for an example
> application to meet all those requirements.
>
> But the fact also remains that for *some* systems, rx_samples_to_file
> (and uhd_rx_cfile on the Gnu Radio side)
>
> are able to stream high-speed data just fine as-is.
>
> On 2014-10-03 09:26, Peter Witkowski via USRP-users wrote:
>
>
> To say that the issue is just because the disk subsystem can't keep up is a
> bit of cop-out.
>
> I had issues writing to disk when the incoming stream was 400MB/s and my
> RAID0 system was benchmarked at being much higher than that.
>
> The issue that I've been seeing stems from the fact that it appears that you
> cannot concurrently read/write from the data stream as its coming in. In
> effect you have a main loop that reads from the device and then immediately
> tries to write that buffer to file. If you do not complete these operations
> in a timely fashion overflows occur.
>
> One way to solve (or at least band aid the issue) is to set your
> dirty_background_ratio to 0. I was able to get writing to disk working
> somewhat with this setting as it is more predictable to directly write to
> disk instead of having your write cache fill up and then having a large
> amount of data to push to disk. That said, my RAID0 array is capable of such
> speeds and even then I was getting a few (but much reduced) overflows.
>
> The one surefire way I know of getting this working (even on a slow disk
> system) is to buffer the data. The buffer can then be consumed by the disk
> writing process while being concurrently added onto by the device reader. The
> easiest way to test buffering (that I've found) is to simply set up a
> GNURadio Companion program with a stream-to-vector block between the USRP and
> file sink blocks. This is exactly what I am doing currently since even with a
> very powerful system, I could not get data saved to disk quickly enough given
> the aforementioned issues with the provided UHD software.
>
> On Thu, Oct 2, 2014 at 11:48 PM, gsmandvoip via USRP-users
> <[email protected]> <[email protected]> wrote:
>
> Thanks Marcus for your replies. Yes O gone away.
>
> On Thu, Oct 2, 2014 at 5:50 PM, Marcus D. Leech <[email protected]>
> <[email protected]> wrote:
>
> with rx_samples_to_file without _4rx.rbf, Initially I tried on my i3, 4GB
> ram, it gave me
> some OOOO but was lesser than earlier, but I do not understand, my most of
> the ram capacity and processor was sitting idle while it shows OOOO, why is
> this strange behaviour The default format for uhd_rx_cfile is complex-float,
> thus doubling the amount of data written compared to rx_samples_to_file.
>
> You can't just use CPU usage as an indicator of loading--if you're writing to
> disk, the disk subsystem may be much slower than you think, so the
> "rate limiting step" is writes to the disk, not computational elements.
>
> Try using /dev/null as the file that you write to. If the 'O' go away, even
> at higher sampling rates, then it's your disk subsystem.
>
> using uhd_rx_cfile getting similar result, but strangely, why it is low, at
> 4M sampling rate it was higher???
>
> On Thu, Oct 2, 2014 at 9:27 AM, Marcus D. Leech <[email protected]>
> <[email protected]> wrote:
>
> On 10/01/2014 11:46 PM, gsmandvoip wrote:
>
> Yes I am running single channel, but when trying to achieve my desired
> sampling rate without _4rx.rbf, it says, requested sampling rate is not
> valid, adjusting to some 3.9M or so. sorry for misleading info I gave
> earlier, I have i3, with 32 bit and i7 with 64 bit, but getting same result
> on both machines
>
> Here is my command to capture signal:
>
> ./rx_samples_to_file --args="fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX" --freq
> "$FC" --rate="$SR" $FILE --nsamps "$NSAMPLES"
>
> and here is its output:
>
> Creating the usrp device with: fpga=usrp1_fpga_4rx.rbf, subdev=DBSRX...
> -- Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
> -- Opening a USRP1 device...
> -- Loading FPGA image: /usr/share/uhd/images/usrp1_
> fpga_4rx.rbf... done
> -- Using FPGA clock rate of 52.000000MHz...
> ERROR: LOOKUPERROR: INDEXERROR: MULTI_USRP::GET_TX_SUBDEV_SPEC(0) FAILED TO
> MAKE DEFAULT SPEC - VALUEERROR: THE SUBDEVICE SPECIFICATION "A:0" IS TOO LONG.
> The user specified 1 channels, but there are only 0 tx dsps on mboard 0.
>
> Don't use the _4rx image if you don't need it.
>
> The USRP1 only does strict-integer resampling, and with a master clock (NON
> STANDARD FOR USRP1) of 52.000MHz, 4Msps is not a sample rate
> that it can produce. Try 5.2Msps or 4.3333Msps.
>
> At 5.2Msps, it's recording at roughly 20.8Mbytes/second, so your system needs
> to be able to sustain that for at least as long as the capture lasts.
>
>
>
> _______________________________________________
> USRP-users mailing
> [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
>
>
--
Peter Witkowski
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141003/e87a49f9/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 50, Issue 3
*****************************************
