[USRP-users] USRP-users Digest, Vol 50, Issue 3

Abhijit Kulkarni abhisk.amey at gmail.com
Fri Oct 3 12:04:38 EDT 2014


I am unsubscribing from this mailing list. Do not send me anymore updates.
Thank you.
 On Oct 3, 2014 12:03 PM, <usrp-users-request at lists.ettus.com> wrote:

> Send USRP-users mailing list submissions to
>         usrp-users at lists.ettus.com
>
> 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
>         usrp-users-request at lists.ettus.com
>
> You can reach the person managing the list at
>         usrp-users-owner at lists.ettus.com
>
> 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.
>       (mleech at ripnet.com)
>    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 (mleech at ripnet.com)
>   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 <uhakansson at tecore.com>
> To: Ian Buckley <ianb at ionconcepts.com>
> Cc: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] Frequency translation works differently on
>         N210 and B210.
> Message-ID: <878459104.1456258.1412273290903.JavaMail.root at tecore.com>
> 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" <ianb at ionconcepts.com>
> To: "Urban Hakansson" <uhakansson at tecore.com>
> Cc: "Marcus D. Leech" <mleech at ripnet.com>, usrp-users at lists.ettus.com
> 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 <uhakansson at tecore.com>
> 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" <ianb at ionconcepts.com>
> > To: "Urban Hakansson" <uhakansson at tecore.com>
> > Cc: "Marcus D. Leech" <mleech at ripnet.com>, usrp-users at lists.ettus.com
> > 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 <uhakansson at tecore.com>
> 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" <ianb at ionconcepts.com>
> >> To: "Urban Hakansson" <uhakansson at tecore.com>
> >> Cc: "Marcus D. Leech" <mleech at ripnet.com>, usrp-users at lists.ettus.com
> >> 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 <
> usrp-users at lists.ettus.com> 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" <usrp-users at lists.ettus.com>
> >>> To: usrp-users at lists.ettus.com
> >>> 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 sysadmin at tecore.com), then delete
> the message in its entirety. Thank you.
> >>>>
> >>>> _______________________________________________
> >>>> USRP-users mailing list
> >>>> USRP-users at lists.ettus.com
> >>>> 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
> >>> USRP-users at lists.ettus.com
> >>> 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 sysadmin at tecore.com), then delete the message
> in its entirety. Thank
> you.grc>py>specA_Fs2MHz_750kHz.JPG>specA_Fs5MHz_f1.2MHz.JPG>_______________________________________________
> >>> USRP-users mailing list
> >>> USRP-users at lists.ettus.com
> >>> 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 sysadmin at tecore.com), 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 sysadmin at tecore.com), 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 sysadmin at tecore.com), 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: mleech at ripnet.com
> To: Urban Hakansson <uhakansson at tecore.com>
> Cc: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] Frequency translation works differently on
>         N210 and B210.
> Message-ID: <0f24891230adba2c685b440b6f27a3f9 at ripnet.com>
> 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" <ianb at ionconcepts.com>
> > To: "Urban Hakansson" <uhakansson at tecore.com>
> > Cc: "Marcus D. Leech" <mleech at ripnet.com>, usrp-users at lists.ettus.com
> > 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 <uhakansson at tecore.com>
> 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" <ianb at ionconcepts.com>
> To: "Urban Hakansson" <uhakansson at tecore.com> Cc: "Marcus D. Leech" <
> mleech at ripnet.com>, usrp-users at lists.ettus.com 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 <
> uhakansson at tecore.com> 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" <
> ianb at ionconcepts.com> To: "Urban Hakansson" <uhakansson at tecore.com> Cc:
> "Marcus D. Leech" <mleech at ripnet.com>, usrp-users at lists.ettus.com 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 <
> usrp-users at lists.ettus.com> 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" <usrp-users at lists.ettus.com> To: usrp-users at lists.ettus.com
> 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 sysadmin at tecore.com), then delete the message
> in its entirety. Thank you. _______________________________________________
> USRP-users mailing list USRP-users at lists.ettus.com
> 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
> USRP-users at lists.ettus.com
> 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 sysadmin at tecore.com), then delete the message
> in its entirety. Thank
> you.grc>py>specA_Fs2MHz_750kHz.JPG>specA_Fs5MHz_f1.2MHz.JPG>_______________________________________________
> USRP-users mailing list USRP-users at lists.ettus.com
> 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 sysadmin at tecore.com), 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 sysadmin at tecore.com), 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 sysadmin at tecore.com), 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 <uhakansson at tecore.com>
> To: mleech at ripnet.com
> Cc: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] Frequency translation works differently on
>         N210 and B210.
> Message-ID: <556772718.1460971.1412279033693.JavaMail.root at tecore.com>
> 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: mleech at ripnet.com
> To: "Urban Hakansson" <uhakansson at tecore.com>
> Cc: "Ian Buckley" <ianb at ionconcepts.com>, usrp-users at lists.ettus.com
> 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" < ianb at ionconcepts.com >
> To: "Urban Hakansson" < uhakansson at tecore.com >
> Cc: "Marcus D. Leech" < mleech at ripnet.com >, usrp-users at lists.ettus.com
> 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 < uhakansson at tecore.com >
> 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" < ianb at ionconcepts.com
> > To: "Urban Hakansson" < uhakansson at tecore.com > Cc: "Marcus D. Leech" <
> mleech at ripnet.com >, usrp-users at lists.ettus.com 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 < uhakansson at tecore.com >
> 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" <
> ianb at ionconcepts.com > To: "Urban Hakansson" < uhakansson at tecore.com >
> Cc: "Marcus D. Leech" < mleech at ripnet.com >, usrp-users at lists.ettus.com
> 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 <
> usrp-users at lists.ettus.com > 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" < usrp-users at lists.ettus.com
> > To: usrp-users at lists.ettus.com 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 sysadmin at tecore.com ), then delete
> the message in its entirety. Thank you.
> _______________________________________________ USRP-users mailing list
> USRP-users at lists.ettus.com
> 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
> USRP-users at lists.ettus.com
> 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 sysadmin at tecore.com ), then delete the
> message in its entirety. Thank
> you.grc>py>specA_Fs2MHz_750kHz.JPG>specA_Fs5MHz_f1.2MHz.JPG>_______________________________________________
> USRP-users mailing list USRP-users at lists.ettus.com
> 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 sysadmin at tecore.com ), 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 sysadmin at tecore.com ), 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 sysadmin at tecore.com ), 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 sysadmin at tecore.com), 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 <michael.west at ettus.com>
> To: Abhinav Jadon <abhinav12122 at iiitd.ac.in>
> Cc: "USRP-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] UHD Related
> Message-ID:
>         <
> CAM4xKrpyyTjiM3Vt5ZejL3zMWfYgLBTHq8W3AT7Y9vVR1Dh5XA at 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 <
> usrp-users at lists.ettus.com> 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
> > USRP-users at lists.ettus.com
> > 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 <rjmcinty at hotmail.com>
> To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: [USRP-users] Help building UHD...?
> Message-ID: <COL125-W316E5FFC00EEAB4150EFC3D3A60 at phx.gbl>
> 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 at 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 <gsmandvoip at gmail.com>
> To: "Marcus D. Leech" <mleech at ripnet.com>
> Cc: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] rx_samples_to_file issue
> Message-ID:
>         <CADE+fGD6=iDcsX=
> 29+iZ37k+TaeyQbwFZzXXDfRpQFeAeQOGpA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks Marcus for your replies. Yes O gone away.
>
> On Thu, Oct 2, 2014 at 5:50 PM, Marcus D. Leech <mleech at ripnet.com> 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 <mleech at ripnet.com>
> 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" <ralph at schmid.xxx>
> To: "'Martin Braun'" <martin.braun at ettus.com>,
>         <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] B210 UHD Error
> Message-ID: <011101cfded5$f04fddc0$d0ef9940$@schmid.xxx>
> 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:usrp-users-bounces at lists.ettus.com] On Behalf
> Of Martin Braun via USRP-users
> > Sent: Tuesday, 30 September, 2014 18:11
> > To: usrp-users at lists.ettus.com
> > 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
> > > USRP-users at lists.ettus.com
> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users at lists.ettus.com
> > 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 <pwitkowski at gmail.com>
> To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] rx_samples_to_file issue
> Message-ID:
>         <CAN1Qg3MABCrp++s7MmzdoJ4Vs2ehLQA_337GpFCuqP=
> oBzaO_Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> To say that the issue is just because the disk subsystem can't keep up is a
> bit of cop-out.
>
> I had issues writing to disk when the incoming stream was 400MB/s and my
> RAID0 system was benchmarked at being much higher than that.
>
> The issue that I've been seeing stems from the fact that it appears that
> you cannot concurrently read/write from the data stream as its coming in.
> In effect you have a main loop that reads from the device and then
> immediately tries to write that buffer to file.  If you do not complete
> these operations in a timely fashion overflows occur.
>
> One way to solve (or at least band aid the issue) is to set your
> dirty_background_ratio to 0.  I was able to get writing to disk working
> somewhat with this setting as it is more predictable to directly write to
> disk instead of having your write cache fill up and then having a large
> amount of data to push to disk.  That said, my RAID0 array is capable of
> such speeds and even then I was getting a few (but much reduced) overflows.
>
> The one surefire way I know of getting this working (even on a slow disk
> system) is to buffer the data.  The buffer can then be consumed by the disk
> writing process while being concurrently added onto by the device reader.
> The easiest way to test buffering (that I've found) is to simply set up a
> GNURadio Companion program with a stream-to-vector block between the USRP
> and file sink blocks.  This is exactly what I am doing currently since even
> with a very powerful system, I could not get data saved to disk quickly
> enough given the aforementioned issues with the provided UHD software.
>
> On Thu, Oct 2, 2014 at 11:48 PM, gsmandvoip via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
> > Thanks Marcus for your replies. Yes O gone away.
> >
> > On Thu, Oct 2, 2014 at 5:50 PM, Marcus D. Leech <mleech at ripnet.com>
> 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 <mleech at ripnet.com>
> >> 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
> > USRP-users at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
>
>
> --
> Peter Witkowski
> pwitkowski at gmail.com
> -------------- 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: mleech at ripnet.com
> To: Peter Witkowski <pwitkowski at gmail.com>
> Cc: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] rx_samples_to_file issue
> Message-ID: <6b0d552a0b4d726dbf31cd2ee37ad17a at ripnet.com>
> 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 <
> usrp-users at lists.ettus.com> wrote:
> >
> > Thanks Marcus for your replies. Yes O gone away.
> >
> > On Thu, Oct 2, 2014 at 5:50 PM, Marcus D. Leech <mleech at ripnet.com>
> 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 <mleech at ripnet.com>
> 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
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [2]
>
> --
> Peter Witkowski
> pwitkowski at gmail.com
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> 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 <marcus.mueller at ettus.com>
> To: usrp-users at lists.ettus.com
> Subject: Re: [USRP-users] rx_samples_to_file issue
> Message-ID: <542EB8C9.900 at ettus.com>
> 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 <
> usrp-users at lists.ettus.com> wrote:
> >>
> >> Thanks Marcus for your replies. Yes O gone away.
> >>
> >> On Thu, Oct 2, 2014 at 5:50 PM, Marcus D. Leech <mleech at ripnet.com>
> 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 <mleech at ripnet.com>
> 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
> > USRP-users at lists.ettus.com
> > 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 <pwitkowski at gmail.com>
> To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] rx_samples_to_file issue
> Message-ID:
>         <
> CAN1Qg3PzZ4z93YcEdwOegy3vnnOXF07YdZSvAsay9BU1NDm45g at 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 <usrp-users at lists.ettus.com
> >
> 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 <
> usrp-users at lists.ettus.com> <usrp-users at lists.ettus.com> wrote:
> >
> > Thanks Marcus for your replies. Yes O gone away.
> >
> > On Thu, Oct 2, 2014 at 5:50 PM, Marcus D. Leech <mleech at ripnet.com> <
> mleech at ripnet.com> 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 <mleech at ripnet.com> <
> mleech at ripnet.com> 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 listUSRP-users at lists.ettus.comhttp://
> lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
>
>
> --
> Peter Witkowski
> pwitkowski at gmail.com
> -------------- 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
> USRP-users at lists.ettus.com
> 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-0002.html>


More information about the USRP-users mailing list