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. NVIDIA Jetson or other ARM Cortex-A15 as host for B200
(David Watt)
2. B210 UHD FPGA (Konstantin)
3. Re: USRP-users Digest, Vol 50, Issue 3 (Abhijit Kulkarni)
4. Re: NVIDIA Jetson or other ARM Cortex-A15 as host for B200
(Tom Tsou)
5. Re: NVIDIA Jetson or other ARM Cortex-A15 as host for B200
([email protected])
6. Fwd: First time UHD build (Kalen Williams)
7. Confused about the definition of naming pins in FPGA code
(Isen I-Chun Chao)
8. Re: Confused about the definition of naming pins in FPGA code
(Ashish Chaudhari)
9. Re: rx_samples_to_file issue (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Fri, 3 Oct 2014 01:16:18 +0000
From: David Watt <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] NVIDIA Jetson or other ARM Cortex-A15 as host
for B200
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi, I'm wondering if anyone could share if it's possible to host the B200 from
an ARM Cortex-A15 type CPU, and how it compares to hosting from an Intel PC.
I'd like to try hosting it from the NVIDIA Jetson development kit, for example.
David Watt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141003/ae1c057b/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 03 Oct 2014 16:22:24 +0300
From: Konstantin <[email protected]>
To: [email protected]
Subject: [USRP-users] B210 UHD FPGA
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Dear Sirs,
I'm dealing with Ettus B210 board and I have the following problem.
I built the B210 FPGA source code and it worked well a few month ago.
Thereafter I update local copy of repository and I can see there are few
changes in repository during some months.
Now I can build FPGA source code for B210 board but when I try to start
FPGA bin image I have the next error
> sudo ./rx_ascii_art_dft --freq 24000000 --gain 30 --rate 4000000
Creating the usrp device with: ...
-- Loading firmware image:
/usr/local/share/uhd/images/usrp_b200_fw.hex... done
-- Loading FPGA image: /usr/local/share/uhd/images/usrp_b210_fpga.bin...
done
-- Operating over USB 2.
Error: AssertionError: accum_timeout < _timeout
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at /home/cubie/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:232
I try to start it on Linux and Windows but I have the same error.
Could you check this error on B210 or B200 board ?
--
Thanks
Konstantin
------------------------------
Message: 3
Date: Fri, 3 Oct 2014 12:04:38 -0400
From: Abhijit Kulkarni <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP-users Digest, Vol 50, Issue 3
Message-ID:
<CABXHTfMzAQMWB05UD3Y5KvJ5W6dNBpCPhZzyBbx-YCkPevr+=a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am unsubscribing from this mailing list. Do not send me anymore updates.
Thank you.
On Oct 3, 2014 12:03 PM, <[email protected]> wrote:
> 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 via 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 translation 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/mailman/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=
> [email protected]>
> 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=
> [email protected]>
> 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]://
> 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
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141003/1573a0bf/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 3 Oct 2014 09:25:38 -0700
From: Tom Tsou <[email protected]>
To: David Watt <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] NVIDIA Jetson or other ARM Cortex-A15 as
host for B200
Message-ID:
<CAATyM+YF1Eyq=hOJx0ATqx4=-Pjbu2zSah-qYJ=eG=pj4eh...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Thu, Oct 2, 2014 at 6:16 PM, David Watt via USRP-users
<[email protected]> wrote:
> Hi, I?m wondering if anyone could share if it?s possible to host the B200
> from an ARM Cortex-A15 type CPU, and how it compares to hosting from an
> Intel PC. I?d like to try hosting it from the NVIDIA Jetson development kit,
> for example.
I've been running B200 on an Arndale A15 board for a while now.
Receive rates in excess of 30 Msps are possible, though, of course,
processing that amount of data is still a challenge.
-TT
------------------------------
Message: 5
Date: Fri, 03 Oct 2014 12:29:00 -0400
From: [email protected]
To: Tom Tsou <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] NVIDIA Jetson or other ARM Cortex-A15 as
host for B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I'll be doing some experiments in this direction next week on an Odroid
XU3, which is a A15/A7 octacore.
On 2014-10-03 12:25, Tom Tsou via USRP-users wrote:
> On Thu, Oct 2, 2014 at 6:16 PM, David Watt via USRP-users
> <[email protected]> wrote:
>
>> Hi, I'm wondering if anyone could share if it's possible to host the B200
>> from an ARM Cortex-A15 type CPU, and how it compares to hosting from an
>> Intel PC. I'd like to try hosting it from the NVIDIA Jetson development kit,
>> for example.
>
> I've been running B200 on an Arndale A15 board for a while now.
> Receive rates in excess of 30 Msps are possible, though, of course,
> processing that amount of data is still a challenge.
>
> -TT
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
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/20141003/9672d6ca/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 3 Oct 2014 12:20:49 -0500
From: Kalen Williams <[email protected]>
To: [email protected]
Subject: [USRP-users] Fwd: First time UHD build
Message-ID:
<CAPTvN3=0wk1iazxbmmn5akd5wfcpydxqzc1kcqswxkbp_fg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I'm trying to build UHD for the first time to use with the Ettus USRP X310,
but I'm having issues with the Boost find function. Not sure what to do. I
found a forum comment online somewhere that recommended manually overriding
that function but I'd rather not do that.
Configuring the python interpreter...
Python interpreter: C:/Python26/python.exe
Override with: -DPYTHON_EXECUTABLE=<path-to-python>
Configuring Boost C++ Libraries...
CMake Error at C:/Program Files
(x86)/CMake/share/cmake-3.0/Modules/FindBoost.cmake:683 (file):
file STRINGS file
"C:/Users/Matt/Desktop/UHD-Clone/uhd/host/Boost_INCLUDE_DIR=c:\local\boost_1_56_0/boost/version.hpp"
cannot be read.
Call Stack (most recent call first):
CMakeLists.txt:161 (FIND_PACKAGE)
Could NOT find Boost
Boost include directories: Boost_INCLUDE_DIR=c:\local\boost_1_56_0
Boost library directories:
Boost libraries:
Python checking for Python version 2.6 or greater
Python checking for Python version 2.6 or greater - found
Python checking for Cheetah templates 2.0.0 or greater
Python checking for Cheetah templates 2.0.0 or greater - found
Configuring LibUHD support...
Dependency Boost_FOUND = 0
Dependency HAVE_PYTHON_PLAT_MIN_VERSION = TRUE
Dependency HAVE_PYTHON_MODULE_CHEETAH = TRUE
Disabling LibUHD support.
Override with -DENABLE_LIBUHD=ON/OFF
Configuring Examples support...
Dependency ENABLE_LIBUHD = OFF
Disabling Examples support.
Override with -DENABLE_EXAMPLES=ON/OFF
Configuring Utils support...
Dependency ENABLE_LIBUHD = OFF
Disabling Utils support.
Override with -DENABLE_UTILS=ON/OFF
Configuring Tests support...
Dependency ENABLE_LIBUHD = OFF
Disabling Tests support.
Override with -DENABLE_TESTS=ON/OFF
Configuring Manual support...
Dependency DOXYGEN_FOUND = YES
Enabling Manual support.
Override with -DENABLE_MANUAL=ON/OFF
Configuring API/Doxygen support...
Dependency DOXYGEN_FOUND = YES
Enabling API/Doxygen support.
Override with -DENABLE_DOXYGEN=ON/OFF
Could NOT find GZip (missing: GZIP_EXECUTABLE)
Configuring Man Pages support...
Dependency GZIP_FOUND = FALSE
Dependency NOT_WIN32 =
Disabling Man Pages support.
Override with -DENABLE_MAN_PAGES=ON/OFF
######################################################
# UHD enabled components
######################################################
* Manual
* API/Doxygen
######################################################
# UHD disabled components
######################################################
* LibUHD
* Examples
* Utils
* Tests
* Man Pages
Building version: 003.007.002-87-gc3acbb87
Using install prefix: C:/Program Files/UHD
Compatible images can be downloaded from:
http://files.ettus.com/binaries/master_images/archive/uhd-images_003.007.002-440-gb290682b.zip
Configuring incomplete, errors occurred!
See also "C:/Users/Matt/Desktop/UHD-build/CMakeFiles/CMakeOutput.log".
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141003/342e0e04/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMakeOutput.log
Type: application/octet-stream
Size: 31491 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141003/342e0e04/attachment-0001.log>
------------------------------
Message: 7
Date: Fri, 3 Oct 2014 15:27:04 -0400
From: Isen I-Chun Chao <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Confused about the definition of naming pins in
FPGA code
Message-ID:
<CAEG73KoggoDvWwzVFjFXZOLGkRBu3dE6=V=mrdqe1cpjhod...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi
I am digging into the '*radio.v*' of X310 FPGA code. When I traced it into
module '*axi_fifo_short*', I am so confused about the definition of "
*i_tvalid*", "*o_tready*", which are inputs, and "*i_tready*", "*o_tvalid*",
which are outputs. This four signals are used throughout radio module.
Also, if the range of the register '*a*' is from 0 to 30, is that mean this
FIFO (*axi_fifo_short*) is only 31 length?
Thanks.
*Best Regards,Isen I-Chun Chao*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141003/ec06c451/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 3 Oct 2014 16:33:09 -0700
From: Ashish Chaudhari <[email protected]>
To: Isen I-Chun Chao <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Confused about the definition of naming pins
in FPGA code
Message-ID:
<CAOzXT+ACoWx5xRh4adiH24A3BNHVNQR=a_7r5_d1vwjaw0r...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Isen,
The signals that you are looking at are a part of the AMBA AXI4-Stream
Interface [1] that is used widely in the X3x0 design. Several signals have
to come together to form a "stream" and they are not in the same direction.
For instance, if you have an AXI stream going from A to B then you would
have the following signals:
- tdata: Data asserted by A for consumption by B
- tvalid: If asserted then the data on the "tdata" bus is valid
- tlast: If asserted then this is the last word in the burst/packet/frame
- tready: If asserted then B is ready to consume more data from A
tdata, tvalid and tlast go from A->B and tready goes from B->A. Data is
only transferred when tvalid and tready are both asserted. The "i_" and
"o_" prefixes on the data just indicate the direction of the stream where
'i' means input and 'o' means output. For example, i_tvalid refers to the
tvalid signal for the input stream for a particular block, and it should be
an "input" port. Similarly o_tready refers to the tready signal for the
output stream which is also an input port.
Hope that helps clear things up.
[1]
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0051a/index.html
*Ashish Chaudhari* | Senior Software Engineer | High Frequency Measurements
- RF
Ettus Research, *A National Instruments Company*
[email protected]
On Fri, Oct 3, 2014 at 12:27 PM, Isen I-Chun Chao via USRP-users <
[email protected]> wrote:
> Hi
> I am digging into the '*radio.v*' of X310 FPGA code. When I traced it
> into module '*axi_fifo_short*', I am so confused about the definition of "
> *i_tvalid*", "*o_tready*", which are inputs, and "*i_tready*", "*o_tvalid*",
> which are outputs. This four signals are used throughout radio module.
>
>
> Also, if the range of the register '*a*' is from 0 to 30, is that mean
> this FIFO (*axi_fifo_short*) is only 31 length?
>
> Thanks.
>
>
>
> *Best Regards,Isen I-Chun Chao*
>
> _______________________________________________
> 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/65d69c76/attachment-0001.html>
------------------------------
Message: 9
Date: Sat, 04 Oct 2014 15:14:25 +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"
Hi Peter,
didn't mean to confuse you! Actually, my job is doing the opposite (ie.
providing useful information), and thus let me just shortly follow up on
this:
On 03.10.2014 17:44, Peter Witkowski via USRP-users wrote:
> 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?
Well, because that's, in my opinion, an operating system's job. Being a
code example, rx_samples_to_file just *musn't* contain the complexity
introduced when you try to implement buffering functionality smarter
than what your OS can do. And, I do think it's nearly impossible to be
smarter than the linux kernel when optimizing writes -- *but* you'll
have to tell your kernel what you want, as a user. The kernel, as it is
configured by any modern distribution by default, won't do enormous
write buffers, because that's not what the user usually wants,
increasing the risk of data loss in case of system failure, and because
you usually don't want to spend all of your RAM on filesystem buffers.
In your 64GB RAM case, though, default buffer sizes should suffice, I
guess, so I'm a bit out of clues here.
It is definitely not very hard to increase these buffers' sizes[1], so I
encourage you to try it and see if that solves your problem. Now, I must
admit that up to here I was always assuming you hadn't already played
around with these values, if this is not the case, please accept my
apologies!
> 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).
...and it's done many users and thus Ettus a great job of supplying
basic functionality! The fact that it works in almost any situation with
this very minimalistic approach (repeated recv->write) proves that UHD
is in fact a rather nice driver interface, IMHO. The fact that GNU Radio
sometimes solves issues that rx_samples_to_file can't indicates exactly
the buffering approach to be helpful. But in that case, buffering is not
increased by increasing kernel buffer sizes, but by introducing GNU
Radio buffers between blocks. The USRP source (Martin, scold me if I say
something stupid) is not really much smarter than rx_samples_to_file: It
recv()s a packet of samples, and returns these samples from the work
function, and then GNU Radio takes care of shuffling and buffering that
data. Basically, GNU Radio behaves much like an operating system from
the source block's point of view.
>
> 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.
Well, I'll kind of disagree with you: If your minimum write rate of your
system was bigger than the rate rx_samples_to_file causes, then you
wouldn't see the problem. The point, I believe, here is that the storage
system does not only consist of the hardware side of your RAID, but also
on your complete operating environment. Something slows down how fast
data is written to the RAID.
I think we both would expect the following to happen:
repeatedly:
rx_samples_to_file:
uhd::rx_streamer::recv
(blocks until a packet of samples has arrived. Instantly returns if
it has before the call)
write(file_handle, recv_buff)
(instantly returns, because writing should hit a buffer that the
operating system transparently pushes out to a disk. If buffer is full,
then block until enough space in buffer -- unless your filesystem is
mounted with some sync option...)
Now, if your RAID is definitely fast enough, the write buffer should
never get full. My hypothesis here is that either, your buffer size is
just to small, and a block of samples doesn't fit and has to be written
out instantly (which is unlikely), or something else occupies your
system. That might be just the fact that 400MB/s (are we talking about
an X3x0?) inevitably places a heavy load on things like PCIe busses and
CPUs, and that introduces a bottleneck in your storage chain which isn't
there if you "just" benchmark without the USRP. Also, the rather
smallish sizes of network packets dictate that journalling file systems
introduce a very bad overhead -- I don't know if you benchmarked with
files on a journaling file system and a (network packet size - header)
block size...
>
> 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?
Definitely a nice system! I must admit that I don't have access to a
comparable setup, and thus I can't really offer you any first-hand
experience. Maybe others can.
> 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.
This is interesting, as dirty_background_ratio is the percentage at
which the kernel should start writing out dirty pages in the background.
Now, I'm the one who's confused, because I would have expected this to
negatively impact performance. On the other hand, 0 (at least in my
head) does not make very much sense, maybe it's semantically identical
to 100%? Are you swapping (64GB would tell me you shouldn't have swap or
extremly low swappiness)?
On the other hand, it might really be that storage is not the bottleneck
here, and in fact maybe the CPU gets saturated. Now, you said that
writing to /dev/null solves your problem. Do your RAID or filesystem
consume a lot of CPU cycles? This is an interesting mystery...
> 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?
No :) UHD has it's own incoming buffer handlers, but as you already
said, in this high performance scenario, you might be totally right, and
our single-threaded approach just doesn't cut it. Maybe dropping in some
asynchronous storage IO would help -- but I hate seeing that blowing up
in example users' faces, so I guess the fact that it doesn't work with a
system as potent as yours with the sample rates as high as you demand
might actually be a shortcoming of the examples that isn't going to be
fixed.
> As a final note, my understanding is that GNURadio and the USRP were
> developed for domain experts in DSP to use.
These are SDR frameworks and devices, respectively. The idea is to offer
people with the opportunity to build awesome DSP systems using
universally usable SDR blocks (GNU Radio) and universal software radio
peripherals, so well, they certainly address DSP people, but they
shouldn't be hard 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.
That is something we might consider. On the other hand, when someone
goes as far as you do, maybe having an example that does the buffering
in a separate thread (or even process) isn't worth that much -- in the
end, one will want to write one's own high performance application, and
that will include handling such data rates.
> 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?).
Well, the devices support these rates, and our driver is able to
withstand these rates and sustain them without hitting CPU barriers due
to having too much overhead. That's awesome (ok, I might be biased, but
*I* think it's awesome). I don't feel ashamed because on your specific
setup, we can't find a way to make any of our generic examples deliver
the full rate of rx streams to storage -- we sell RF hardware, and not
storage infrastructure, and the point of the examples is demonstrating
the usage of UHD, and not holding a lecture on high performance storage
handling. I wish, though, that we could solve your problem.
Now, GNU Radio/gr-uhd does in fact come with an application called
uhd_rx_cfile, which is more or less a clone of rx_samples_to_file using
gr-uhd and GNU Radio instead of raw UHD. Does that work out for you?
> 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.
Well, UHD seems to be able to sustain these rates, if you write to
/dev/null, right? So the practical limit for UHD is definitely not being
hit.
I have another --maybe even practical-- suggestion to make: Roll your
own buffer!
mkfifo /tmp/mybuffer #assuming tmpfs is in ram
dd if=/tmp/mybuffer of=/mount/raid_volume/data.dat & #start in
background; you could play around with block sizes using the bs= option
of dd
rx_samples_to_file --file /tmp/mybuffer [all the other options]
By the way: Thanks for bringing this up! We know that recording samples
is a core concern of many users.
Greetings,
Marcus
[1] https://www.kernel.org/doc/Documentation/sysctl/vm.txt
>
> 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
>>
>>
>
>
>
> _______________________________________________
> 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/20141004/ce3d5392/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 4
*****************************************
