Re: v3.7 End of Maintenance

[Matt Ettus]

Glen,

If SDRPlay doesn't support newer versions of GR then the problem is SDRPlay
(a for-profit company that you gave money to) and their drivers (which I
believe are proprietary?), not the free software involved.

In any case, GR 3.7 will be available forever and nobody can take that away
from you.

Matt

On Thu, Nov 18, 2021 at 3:06 PM Glen Langston 
wrote:

> Thanks for all your efforts.
>
> However still there are MANY external packages that don’t work beyond 3.7,
> so we're stuck in 3.7 world.  (We have inched to 3.8 but SDRPlay was not
> well supported).
>
> I know this is difficult, but please try to ADD capabilities without
> destroying
> old capabilities.  From the Nubi point of view, it is easier for an expert
> to enable
> both SWIG and PYBIND than it is to figure out the transition, when the
> Nubi does not
> care a bit what the difference is.
>
> Thanks again,
>
> Glen
>
>
> > On Nov 18, 2021, at 5:32 PM, Jeff Long  wrote:
> >
> > We are officially ending maintenance of v3.7. There will be no further
> v3.7.X.X releases, and pull requests will no longer be accepted for the
> maint-3.7 branch.
> >
> > The last v3.7 release (v3.7.14.0) was over 18 months ago and there are
> only a handful of unreleased commits on the maint-3.7 branch.
> Packagers/distributions have moved on to newer versions. Additionally, we
> are not set up to do automated testing on maint-3.7 and need to apply our
> development/maintenance efforts to v3.8, v3.9 and the upcoming v3.10.
> >
> > Of course, this is open source, so there is no End of Life if packagers
> are still interested in v3.7. If you still package v3.7, please let us know.
> >
>
>
>

Re: [Discuss-gnuradio] Probable pulsar observing success at CCERA

[Matt Ettus]

That's awesome work!  Thanks for sharing it.  How much bandwidth are you
observing and did you also use de-dispersion?

Matt

On Thu, Dec 1, 2016 at 10:45 AM, Marcus D. Leech  wrote:

> One of the many goals we set for ourselves at the Canadian Centre for
> Experimental Radio Astronomy was to successfully observe
>   pulsar B0329+54 before spring.  This pulsar is the only one bright
> enough for a small observatory in the northern hemisphere to
>   observe.
>
> See our update:
>
> http://www.ccera.ca/uncategorized/success-in-observing-pulsar-b032954/
>
> The software is available via github:
>
> https://github.com/ccera-astro/pulsar_pfb _display
>
> No custom blocks required--just a modern Gnu Radio install, and ideally,
> pyephem.
>
> Doing this with Gnu Radio was so very easy...
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Interleaved sampling without interleaved clocks?

[Matt Ettus]

Lou,

Many high-speed data converters actually interleave samples from multiple
lower speed ADCs.  They delay clock, rather than the signal, which is much
easier.  Even then, unless the delay is perfect, you get really bad spurs.
Mismatches in delay on the order of 100 fs can be a big problem.

So what you want to try should be possible, but the results aren't going to
be stellar.  The ADCs are set up for simultaneous sampling at 200 MHz or
5ns.  You would need to split the signal and then delay one leg by 2.5ns.
No hilbert transforms or phasing networks are required.

You *might* also be able to get the clock generator chip to generate an
inverted clock to the 2nd ADC chip, in which case you wouldn't need the
delay.

In both cases, you're going to need to do some FPGA work to get the samples
lined up in the right order.

Matt

On Wed, Jul 20, 2016 at 12:32 PM, madengr  wrote:

> Posting this to GR (as opposed to USRP) since it seems more theory.
>
> Say I have an X300 and want to get DC - 200 MHz BW from a single daughter
> card by combining two real sampled streams.  The X300 ADCs (or within the
> dual channel ADCs themselves) clocks can't be interleaved.
>
> An argument is that one of the two RF input channels can simply be delayed
> 90 degrees with a length of coax.  This gives 90 degree shift at 200 MHz,
> 45
> at 100 MHz, etc, with the argument being the lower frequencies become more
> over-sampled, so no information is lost. Seems too simple, but I can't
> mathematically show it won't work, since the oversampling makes some sense.
>
> My argument is that this won't work, and it would require a nasty SSB
> phasing network on one of two input channels (analog equivalent of Hilbert
> transform) to provide a constant 90 degree shift over the entire band
> (since
> sample clocks can't be quadrature), with equivalent delay on the other.
> Then a Hilbert transform at baseband in GR before they are summed into a
> 200
> MHz complex baseband.
>
> In either case the anti-aliasing filters would need cutoff increased.
>
> Lou
>
>
>
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Interleaved-sampling-without-interleaved-clocks-tp60986.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Renaming PyBOMBS

[Matt Ettus]

On Tue, Dec 22, 2015 at 12:31 PM, Richard Bell 
wrote:

> GRAB = Gnu RAdio Basic installer
>
> Then we can say things like "Go GRAB it" when referring to a needed module
>

+1.  Short, not used by any other project, pronounceable.

It could also stand for GNU Radio Application Bundles.   Or Bombs.

Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Gradual loss of amplitude as flowgraph runs

[Matt Ettus]

Take a look at the phase rotator in the frequency translating FIR filter.
Is it done with sine/cos lookups or is it a rotating phasor?  Rotating
phasors can lose amplitude due to finite precision effects.

Matt

On Fri, Aug 14, 2015 at 1:57 PM, John Ackermann N8UR  wrote:

> Still working with the polyphase channelizer program.  While everything
> "works", there is something very strange: the output amplitude slowly drops
> the longer the program runs.  As near I can tell, this happens in or
> following the frequency translating FFT block.
>
> To test, I stripped the flowgraph down to the bare minimum and put a
> frequency display at the output of the UHD block, and another at the output
> of the fx fft block.
>
> By using the "max hold" feature of the display, I can easily monitor
> amplitude drop during the program run.  I'm using a signal generator to
> feed the USRP a known signal level (162.475 MHz at -70dBm).
>
> In the attached screenshot, the left display is the UHD output, and the
> right is the fx fft output.  The flowgraph had been running for about 5
> minutes.  The signal out of the fx fft has dropped 20+ dB while the UHD
> signal level remains the same.  The longer the program runs, the further
> the fx fft output drops.
>
> I'm not seeing any error messages on the console to indicate overrun,
> underrun, or other issues.  Due to size limits, I attach only the fft
> screenshot, but here are all the relevant files:
>
> http://www.febo.com/pages/gr-projects/amplitude_loss_test.grc
> http://www.febo.com/pages/gr-projects/amplitude_loss_test.py
> http://www.febo.com/pages/gr-projects/amplitude_loss_test_fft.png
> http://www.febo.com/pages/gr-projects/amplitude_loss_test_flowgraph.png
>
> Any idea what could lead to this kind of problem?  It seems like some sort
> of accumulating error, but I'm lost as to what.
>
> Thanks,
> John
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Optimum decimation for maximizing dynamic range

[Matt Ettus]

Yes, you are thinking about it correctly.  You should decimate as
little as possible in hardware, and do the rest in software in
floating point.

Matt

On Thu, Jul 16, 2015 at 10:44 AM, madengr  wrote:
> Is there an optimum hardware decimation to maximize receiver dynamic range?
>
> For example, if I have an X310 at 200 Msps with 14 bit ADC receiving a low
> frequency tone (LFRX board), those samples are truncated to 16 bits prior to
> Ethernet.  If I'm decimating by 800 (from 200 Msps to 250 ksps) in the
> hardware, then I have gained an ~5 additional bits for a total of 19 ENOB.
> Thus I lose 3 bits from the truncation.
>
> If I hardware decimate by 16 (from 200 Msps to 12.5 Msps) then I have gained
> just 2 bits for a total of 16 ENOB.  I could then decimate to 250 ksps in GR
> where it's floating point, and possibly preserve the full 19 ENOB.
>
> Am I thinking this out correctly, or is it not worth the trouble?  I assume
> the 32-bit floating point decimation in GR will have the range to preserve
> 19 ENOB?
>
> Thanks,
> Lou
>
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Optimum-decimation-for-maximizing-dynamic-range-tp54831.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Most affordable UHD compatible SW transmitter

[Matt Ettus]

B200 is the lowest cost.
On Jun 1, 2015 9:24 AM, "Rafael Diniz"  wrote:

> Hi people,
> Do you know which is the current state of art regarding (low) price of SW
> SDR
> transmitter compatible with UHD?
> It's for a project for Digital Radio broadcast using DRM standard (10kHz of
> bandwidth) here in Brazil.
>
> Best regards,
> Rafael Diniz
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Getting together in Korea to talk SDR

[Matt Ettus]

Friends in the Seoul area,

I will be visiting between June 2nd and June 7th, and will have some
free time.  I would love to get together with USRP and GNU Radio users
while I'm there.  I'd be up for anything from talking about SDR over
lunch/dinner, all the way through giving a presentation about USRPs
and RFNoC to a group at your university, club, or company.

Please contact me off list if you'd be interested in getting together!
 This is my first time in Korea, and I am excited to be going.

Thanks,
Matt Ettus

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to control latency

[Matt Ettus]

Daniele,

GNU Radio tries to maximize the size of the chunks of data it deals with.
Clearly that works well for high rate data, but not low rate data.  There
are some handles to control buffer sizes and things within GNU Radio, but
you may have better luck just using a much higher sample rate.  If you just
decimate less, and have a sample rate of about 10 kHz you won't have this
problem.  You'll use more CPU, but it will still be a tiny amount.

Matt

On Tue, Mar 31, 2015 at 11:20 AM, Daniele Nicolodi 
wrote:

> Hello,
>
> I have a system where I acquire a signal through an Ettus N210 at 200
> kHz and I process it through a few GNURadio blocks. Those blocks include
> a first low pass filtering and decimation to 1 kHz sampling rate and
> further resampling down to 10 Hz or so.
>
> In this configuration the output samples are delivered to the last block
> of the flow-graph bunched in packets so that a packet is received every
> 3 seconds.
>
> This does not seem to depend on the last resampling neither on the
> maximum buffer site (set calling `tb.run(size)` where `tb` is the top
> block of the flow-graph). I also tried to change the UHD frame size with
> the `recv_frame_size`, but it had no effect on the latency.
>
> As I'm trying to implement a control loop, I would like to obtain data
> at a real 10 Hz rate from my last block. I think the system should be
> able to handle the computing overhead just fine.
>
> How can I accomplish this?
>
> Thank you. Cheers,
> Daniele
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Difference between USRP RIO and Ettus USRP X310

[Matt Ettus]

Jay,

The USRP RIO is an X310 with 2 daughterboards included.  That covers part
of the price difference.  The USRP RIO also includes some LabVIEW software
and local support from NI people in your country.  If you intend to use GNU
Radio, you are probably better off getting the Ettus Research version.

Matt


On Tue, Feb 24, 2015 at 9:13 AM, Jay Prakash 
wrote:

> I am planning to test some of my physical layer algorithms on SDR.
> I compared these two USRPs , though Ettus is part of NI now and features
> of these devices are almost same, still there is huge variation almost
> double in price which I am not able to justify!
>
> What are additional benfits of NI USRP RIO over X310?
>
>
>
>
> Jay
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] RFNoC -- Making FPGA design easy from GNU Radio

[Matt Ettus]

Ettus Research is very excited to announce the release of RFNoC!

Modern FPGAs, like the Xilinx Kintex-7 and ZYNQ used in third generation
USRPs have incredible computational capability, but taking advantage of
that capability is difficult at best when using traditional FPGA design
flows.

RFNoC (which stands for RF Network on Chip) provides the capability to
create FPGA applications as easily as you create GNU Radio flowgraphs. This
includes the ability to seamlessly transfer data to & from an FPGA in your
application, dramatically improving the ease of FPGA off-loading.

Here is an example of an RFNoC flowgraph built using the GNU Radio
Companion. With four blocks, data is being generated on the host,
off-loaded to the FPGA for filtering, and then brought back to the host for
plotting:

[image: Inline image 1]

Signal processing algorithms are encapsulated in easy-to-use wrappers which
allow them to be dynamically connected and used as needed.  Fixed routing
is eliminated.  Mixing and matching host-based and FPGA-based processing is
transparent to the user, and that processing can scale across multiple
FPGAs and devices across a network.  You can now make custom FPGA designs
without ever needing to write Verilog or VHDL!

RFNoC has been integrated into UHD for our third generation USRPs
(X300-series, E300-series, and future devices), enabling you to share FPGA
designs across devices easily.  Additionally, we have integrated support
for RFNoC into GNU Radio and GRC, so you can now graphically design mixed
host- and FPGA-based flowgraphs.


Watch an RFNoC presentation and demo from GRCon14:  (long, but HIGHLY
recommended as an intro)

  https://www.youtube.com/watch?v=9oPxIFtwyb8

All documentation and links to the source code can be found here:

  https://github.com/EttusResearch/uhd/wiki/RFNoC:-Getting-Started

A paper from ACM SIGCOMM with more background:

  http://conferences.sigcomm.org/sigcomm/2013/papers/srif/p45.pdf

If you have any questions, please don't hesitate to ask.  We plan to hold
most of the RFNoC-related discussion on the usrp-users mailing list.

Matt Ettus
President, Ettus Research
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FFT scaling consistency

[Matt Ettus]

I normalized the wx complex display a long time ago.  As you have
discovered, windowing affects this, but in two separate ways.  First,
windowing reduces total signal power because most bins are less than 1.  We
normalize for that, so the total energy remains constant.  You will see
that if you run with awgn.

The second issue is spreading energy into adjacent bins. This will affect
anything you expected to remain in one bin, like a sine wave.  There isn't
any way to fix this as its not broken.  To find the power in a sine you'll
need to add the power of several adjacent bins.

Matt
On Nov 26, 2014 3:08 AM, "Sylvain Munaut" <246...@gmail.com> wrote:

> Hi,
>
> > Then: no, QT GUI does that, see [1] (generated by [2]). The tone at
> > samp_rate / fft_length * 10 has a power of 0 dB; also, Gaussian noise
> > with an amplitude of 1 has an average (picture is heavily averaged)
> > power of -20 dB == 1/fft_length. Perfect!
>
> Oh, that's interesting.
>
> I didn't see that when I did the test here. Turns out it's the window
> selection, if you select Rectangular, you have 0dB and it's consistent
> between WX and Qt.
>
> If you select something else, then it's no longer 0dB and it becomes
> inconsistent between the WX and Qt widgets.
> Now obviously windowing will have some effect on the peak value, but:
>  - I didn't expect it to be this large, I expected more like a few
> tenth of dB, not precisely 3 or 6dB.
>  - I certainly don't see why Wx or Qt would make a difference
>
>
> > To the complex vs. real discussion: Picture [3] tells me that I see
> > the noise at -23 dB; now, this will get extremely philosophical
> > whether when observing a real signal this should be -20 dB instead.
>
> Yes, it's definitely more of a philosophical question than anything else.
> Honestly I don't really care either way, I just though I'd bring this
> up at the same time and see if there was a "convention" that was
> expected.
>
> Cheers,
>
> Sylvain
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Source Block - Flow Control

[Matt Ettus]

You'll probably want to make a block to do the padding, or mux in zeros.

Matt

On Thu, Oct 16, 2014 at 3:00 PM, David Halls 
wrote:

>  Thanks Matt. is this likely to be the cause of the Us at the beginning?
> How can I pad simply in GNU radio? can i add padding to every burst? if so
> that seems straightforward. I can just mux some zeros in.
>
>  Also should the padding be included in the burst length?
>
>
>  Original message 
> From: Matt Ettus
> Date:2014/10/16 22:54 (GMT+00:00)
> To: David Halls
> Cc: John Malsbury ,GNURadio
> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>
>
> On TX, if you need your first sample to be valid and everything settled in
> the radio, you should zero pad ahead of it.  If you need your last sample
> to go out clean, you should zero pad after it.  In both cases, a few
> microseconds worth is usually fine.  This flushes buffers and filters, but
> also gives physical devices like antenna switches to settle.
>
>  Matt
>
> On Thu, Oct 16, 2014 at 2:46 PM, David Halls  > wrote:
>
>>
>>
>>   Original message 
>> From: Matt Ettus
>>  Date:2014/10/16 22:42 (GMT+00:00)
>> To: John Malsbury
>> Cc: David Halls ,GNURadio
>> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>>
>>
>>
>>  On Thu, Oct 16, 2014 at 8:40 AM, John Malsbury <
>> jmalsbury.perso...@gmail.com> wrote:
>>
>>>  I'm happy this is working for you, David.  So do I understand
>>> correctly, that the adding tx_time finally made the MIMO case work?
>>>
>>>  I'd never done burst transmission with multiple USRP outputs.  I'm not
>>> totally surprised but I wasn't sure what would happen.
>>>
>>> Maybe someone from Ettus can comment on this?  Since UHD is trying to do
>>> time alignment in the multi_usrp class, what happens to time alignemt in
>>> the non-continuous-streaming case if you *don't* include a tx_time tag?
>>>
>>
>>
>>  Noncontinuous streaming means there is some amount of down time.  If
>> you don't include tx_time tags, the device doesn't know when to start back
>> up again, so each antenna is going to start at a different time.
>>
>>  Matt
>>
>>
>>   That seemed exactly the kind of behaviour I saw where sync between the
>> two streams was lost. Matt, can you comment on whether I need to put dummy
>> padding items before the first burst? to flush buffers and is there a
>> delicate way to do this?
>>
>>
>> --
>>
>> NOTE: The information in this email and any attachments may be
>> confidential and/or legally privileged. This message may be read, copied
>> and used only by the intended recipient. If you are not the intended
>> recipient, please destroy this message, delete any copies held on your
>> system and notify the sender immediately.
>>
>> Toshiba Research Europe Limited, registered in England and Wales
>> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
>> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
>>
>>
>>
>>  --
>> This email has been scanned for email related threats and delivered
>> safely by Mimecast.
>> For more information please visit http://www.mimecast.com
>> --
>>
>
>
> --
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read, copied
> and used only by the intended recipient. If you are not the intended
> recipient, please destroy this message, delete any copies held on your
> system and notify the sender immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
>
>
>
> --
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> --
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] High Flowgraph Latency in 3.6.4.1

[Matt Ettus]

Yes, there were multiple issues in the thread, and what I said only applies
to TX.  Certainly on the receive side there should be no latency issues, as
every block should do all computations they can on whatever data they
receive, since that is exactly what is tripping up the TX guys :)

Matt

On Fri, Oct 17, 2014 at 10:25 AM, John Malsbury <
jmalsbury.perso...@gmail.com> wrote:

> Matt,
>
> BTW - in this particular case, this was *all* in the receive direction -
> its a lowrate demodulator.  So I was a bit surprised to see the issue at
> all - 'cause I've never seen such high latency on a receive flowgraph.  We
> have a "closed" loop approach to managing transmit latency through the USRP
> without timestamps or relying on a source stream for throttling.  But I do
> think the advice you provide is useful for other's who are trying to solve 
> *transmitter
> latency by shrinking buffers.*
>
> Per the email above - it turned out that buffer sizes were not an issue.
> Something else was weird was happening - see (2) on my prev email if you're
> interested.
>
> Thanks for following up on this thread.
>
> -John
>
> On Fri, Oct 17, 2014 at 10:16 AM, Matt Ettus  wrote:
>
>>
>> We see this issue a lot with applications that only transmit, and which
>> transmit continuously.  The problem is that you end up generating samples
>> far in advance of when you really know what you want to transmit, because
>> there is no rate-limiting on the production side.
>>
>> Some general principles -- Large buffers *allow* you to deal with high
>> latency.  Large buffers do not *create* high latency unless the application
>> is not designed properly.  A properly designed application will work with
>> infinitely large buffers as well as it does with minimally sized ones.
>>
>> Shrinking buffers may allow your application to work, but that isn't
>> really the best way to solve this problem.  The best way to solve the
>> problem is to modify your head-end source block to understand wall-clock
>> time.  The easiest way to do that if you are using a USRP is to instantiate
>> a UHD source (i.e. a receiver) at a relatively low sample rate and feed it
>> into the source you have created.
>>
>> Your source block should then look at timestamps on the incoming samples
>> (it can throw the samples themselves away).  It should generate only enough
>> samples to cover the maximum latency you want, and it should timestamp
>> those transmit samples.  For example, if it receives samples timestamped
>> with T1, it should generate samples with timestamps from T1+L1 to T1+L1+L2,
>> where L1 is the worst-case flowgraph and device latency, and L2 is the
>> worst case reaction time you are looking for.  Thus, if you suddenly get a
>> message from your operator to send a message, you know that you will never
>> need to wait for more than L2 seconds.  Thus, you can bound your worst case
>> reaction time.
>>
>> It should be noted that in two-way application like GSM or LTE, you would
>> never run into these problems and they are naturally avoided because you
>> won't generate samples until you've seen what you receive.  It only is an
>> issue in TX-only apps.
>>
>> I think we should generate an example app to do this, because the issue
>> comes up periodically, especially among the space communications crowd.  It
>> is a design pattern we really should document.
>>
>> Matt
>>
>>
>> On Fri, Oct 10, 2014 at 5:20 PM, Vanush Vaswani  wrote:
>>
>>> I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The
>>> only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in
>>> flat_flowgraph.cc.
>>> This is regarded as a dodgy hack by all the GR developers here, but it
>>> worked for me (and I read the article on latency). I believe the guy
>>> who wrote GMSKSpacecraftGroundstation had the same problem, and found
>>> it in one of his old threads.
>>>
>>> On Sat, Oct 11, 2014 at 5:55 AM, Dan CaJacob 
>>> wrote:
>>> > Hey John,
>>> >
>>> > I am way out of my depth here, but while working on a custom python
>>> block
>>> > the other day, I saw some weird behavior in 3.7.5 that was similar.
>>> Setting
>>> > the global max output had no effect, but setting the just-upstream
>>> block(s)
>>> > min/max output buffer size(s) low fixed my apparent slowliness.
>>> >
>>> > Very Respectfully,
>>> >
>>> > Dan CaJacob
>>> >
>>> > On Fr

Re: [Discuss-gnuradio] High Flowgraph Latency in 3.6.4.1

[Matt Ettus]

We see this issue a lot with applications that only transmit, and which
transmit continuously.  The problem is that you end up generating samples
far in advance of when you really know what you want to transmit, because
there is no rate-limiting on the production side.

Some general principles -- Large buffers *allow* you to deal with high
latency.  Large buffers do not *create* high latency unless the application
is not designed properly.  A properly designed application will work with
infinitely large buffers as well as it does with minimally sized ones.

Shrinking buffers may allow your application to work, but that isn't really
the best way to solve this problem.  The best way to solve the problem is
to modify your head-end source block to understand wall-clock time.  The
easiest way to do that if you are using a USRP is to instantiate a UHD
source (i.e. a receiver) at a relatively low sample rate and feed it into
the source you have created.

Your source block should then look at timestamps on the incoming samples
(it can throw the samples themselves away).  It should generate only enough
samples to cover the maximum latency you want, and it should timestamp
those transmit samples.  For example, if it receives samples timestamped
with T1, it should generate samples with timestamps from T1+L1 to T1+L1+L2,
where L1 is the worst-case flowgraph and device latency, and L2 is the
worst case reaction time you are looking for.  Thus, if you suddenly get a
message from your operator to send a message, you know that you will never
need to wait for more than L2 seconds.  Thus, you can bound your worst case
reaction time.

It should be noted that in two-way application like GSM or LTE, you would
never run into these problems and they are naturally avoided because you
won't generate samples until you've seen what you receive.  It only is an
issue in TX-only apps.

I think we should generate an example app to do this, because the issue
comes up periodically, especially among the space communications crowd.  It
is a design pattern we really should document.

Matt


On Fri, Oct 10, 2014 at 5:20 PM, Vanush Vaswani  wrote:

> I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The
> only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in
> flat_flowgraph.cc.
> This is regarded as a dodgy hack by all the GR developers here, but it
> worked for me (and I read the article on latency). I believe the guy
> who wrote GMSKSpacecraftGroundstation had the same problem, and found
> it in one of his old threads.
>
> On Sat, Oct 11, 2014 at 5:55 AM, Dan CaJacob 
> wrote:
> > Hey John,
> >
> > I am way out of my depth here, but while working on a custom python block
> > the other day, I saw some weird behavior in 3.7.5 that was similar.
> Setting
> > the global max output had no effect, but setting the just-upstream
> block(s)
> > min/max output buffer size(s) low fixed my apparent slowliness.
> >
> > Very Respectfully,
> >
> > Dan CaJacob
> >
> > On Fri, Oct 10, 2014 at 2:14 PM, John Malsbury
> >  wrote:
> >>
> >> Default scheduler.
> >>
> >> tb.start(1024), with different values, etc, etc.
> >>
> >> Most of the downstream blocks are stock GNU Radio blocks - a delay block
> >> (max delay is 1 sample), logical operators, etc.  I guess I'll add some
> >> printf debugging?
> >>
> >> -John
> >>
> >>
> >>
> >>
> >> On Fri, Oct 10, 2014 at 11:07 AM, Marcus Müller <
> marcus.muel...@ettus.com>
> >> wrote:
> >>>
> >>> Hi John,
> >>> On 10.10.2014 19:33, John Malsbury wrote:
> >>>
> >>> Toward the end of the receive chain, there are a multitude of blocks
> that
> >>> are used for Viterbi node synchronization. I've found that the number
> of
> >>> blocks in series (3-5), combined with the low datarates at this point
> in
> >>> the flowgraph, lead to latencies on the order of 1-2 minutes.  That is
> to
> >>> say, once the node synchronization is accomplished, it takes 1-2
> minutes
> >>> to
> >>> flush these blocks and get the fresh, good data through.  This is
> >>> measured
> >>> with function probes on the state of the sync process, and BERT
> analysis
> >>> of
> >>> the demodulator output [through TCP/IP socket].
> >>>
> >>> I see you found the hidden interplanetary signal delay simulator.
> >>> Congrats! Watch out for the red shift in downstream samples.
> >>>
> >>> No, seriously, that sounds like a lot.
> >>> You are using 3.6.4.1 with the default scheduler, tpb?
> >>>
> >>>- I've tried messing around with the output buffer size option in
> the
> >>>flowgraph, but this seems l to have a negligible impact.
> >>>
> >>> That surprises me. How did you mess around? top_block->run(1024)?
> >>>  Do your blocks really get called with smaller input item sizes? (do a
> >>> little printf-debugging)
> >>>
> >>>- I can write some custom blocks to reduce the overall block count,
> >>> but
> >>>I have demonstrated that this provides a linear improvement, rather
> >>> than
> >>>the two-order-magnitude impr

Re: [Discuss-gnuradio] Source Block - Flow Control

[Matt Ettus]

On TX, if you need your first sample to be valid and everything settled in
the radio, you should zero pad ahead of it.  If you need your last sample
to go out clean, you should zero pad after it.  In both cases, a few
microseconds worth is usually fine.  This flushes buffers and filters, but
also gives physical devices like antenna switches to settle.

Matt

On Thu, Oct 16, 2014 at 2:46 PM, David Halls 
wrote:

>
>
>   Original message 
> From: Matt Ettus
> Date:2014/10/16 22:42 (GMT+00:00)
> To: John Malsbury
> Cc: David Halls ,GNURadio
> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>
>
>
> On Thu, Oct 16, 2014 at 8:40 AM, John Malsbury <
> jmalsbury.perso...@gmail.com> wrote:
>
>>  I'm happy this is working for you, David.  So do I understand
>> correctly, that the adding tx_time finally made the MIMO case work?
>>
>>  I'd never done burst transmission with multiple USRP outputs.  I'm not
>> totally surprised but I wasn't sure what would happen.
>>
>> Maybe someone from Ettus can comment on this?  Since UHD is trying to do
>> time alignment in the multi_usrp class, what happens to time alignemt in
>> the non-continuous-streaming case if you *don't* include a tx_time tag?
>>
>
>
>  Noncontinuous streaming means there is some amount of down time.  If you
> don't include tx_time tags, the device doesn't know when to start back up
> again, so each antenna is going to start at a different time.
>
>  Matt
>
>
>  That seemed exactly the kind of behaviour I saw where sync between the
> two streams was lost. Matt, can you comment on whether I need to put dummy
> padding items before the first burst? to flush buffers and is there a
> delicate way to do this?
>
>
> --
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read, copied
> and used only by the intended recipient. If you are not the intended
> recipient, please destroy this message, delete any copies held on your
> system and notify the sender immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
>
>
>
> --
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> --
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Source Block - Flow Control

[Matt Ettus]

On Thu, Oct 16, 2014 at 8:40 AM, John Malsbury  wrote:

> I'm happy this is working for you, David.  So do I understand correctly,
> that the adding tx_time finally made the MIMO case work?
>
> I'd never done burst transmission with multiple USRP outputs.  I'm not
> totally surprised but I wasn't sure what would happen.
>
> Maybe someone from Ettus can comment on this?  Since UHD is trying to do
> time alignment in the multi_usrp class, what happens to time alignemt in
> the non-continuous-streaming case if you *don't* include a tx_time tag?
>


Noncontinuous streaming means there is some amount of down time.  If you
don't include tx_time tags, the device doesn't know when to start back up
again, so each antenna is going to start at a different time.

Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Source Block - Flow Control

[Matt Ettus]

No, if you don't have anything useful to output in a source block, you can
(and should) block while you wait.  If you have something useful, but not
as much as requested, you can output only what you have.  There is no need
to generate filler in GNU Radio.

Matt


On Tue, Oct 14, 2014 at 2:43 PM, David Halls 
wrote:

>  Matt,
>
>  In my source block I can limit the calls to the DB ok, but I will still
> need to output something from the block, won't I? This will then propagate
> and fill the buffers?
>
>  Thanks,
>
>  David
>
>
> ---- Original message 
> From: Matt Ettus
> Date:2014/10/14 19:09 (GMT+00:00)
> To: Jeff Long
> Cc: GNURadio
> Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
>
>
> Jeff,
>
>  If there is a hardware device like a USRP in the chain, then you should
> not use a throttle block.  What you are seeing is the initial startup
> burst.  When everything starts up, all the buffers are empty, and GNU Radio
> will generate data until something backs up.  Once they fill up, you are
> seeing the rate settle down.  This is all normal.
>
>  If you really need to rate limit what gets requested of the database
> during the initial transient (which I don't recommend), you should do that
> within your source block.
>
>  Matt
>
>
> On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long  wrote:
>
>> Should have mentioned ... set the throttle rate just slightly higher than
>> what the chain would consume at steady state when all the buffers are
>> filled and the USRP is transmitting. How well this works depends on what
>> the rest of the chain looks like.
>>
>> - Jeff
>>
>>
>> On 10/14/2014 05:52 PM, Jeff Long wrote:
>>
>>> Use a throttle block immediately after your source block, setting the
>>> vector size to match your source.
>>>
>>> - Jeff
>>>
>>> On 10/14/2014 04:34 PM, David Halls wrote:
>>>
>>>> Dear All,
>>>>
>>>> I am wondering how to add some flow control to a source block, so that
>>>> it doesn’t fire out items so quickly.
>>>>
>>>> Later stages of my flow graph are slowed by various bits of processing
>>>> and combining, before transmission via USRP, with bursts being
>>>> transmitted every few seconds.
>>>>
>>>> What happens is that the block fires out 1,000s of vectors, and then
>>>> seems to slow down and settle into sync with the rest of the flow graph
>>>> after a few seconds. As my source block is reading in from a Database, I
>>>> want to slow this initial rate significantly.
>>>>
>>>> The block outputs vectors of bytes (v_len=144). Any ideas?
>>>>
>>>> Regards,
>>>>
>>>> David
>>>>
>>>> ---
>>>>
>>>> David Halls Ph.D.
>>>>
>>>> Research Engineer
>>>>
>>>> Toshiba Research Europe Limited
>>>>
>>>> 32 Queen Square, Bristol, BS1 4ND, UK
>>>>
>>>> Tel: +44 (0) 117 906 0790
>>>>
>>>>
>>>> 
>>>> 
>>>>
>>>> NOTE: The information in this email and any attachments may be
>>>> confidential and/or legally privileged. This message may be read, copied
>>>> and used only by the intended recipient. If you are not the intended
>>>> recipient, please destroy this message, delete any copies held on your
>>>> system and notify the sender immediately.
>>>>
>>>> Toshiba Research Europe Limited, registered in England and Wales
>>>> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
>>>> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
>>>>
>>>>
>>>>
>>>> 
>>>> 
>>>> This email has been scanned for email related threats and delivered
>>>> safely by Mimecast.
>>>> For more information please visit http://www.mimecast.com
>>>> 
>>>> 
>>>>
>>>>
>>>> ___
>>>> Discuss-gnuradio mailing list
>>>> Discuss-gnuradio@gnu.org
>>>> https://lists.gnu.org/mailman/

Re: [Discuss-gnuradio] Source Block - Flow Control

[Matt Ettus]

Jeff,

If there is a hardware device like a USRP in the chain, then you should not
use a throttle block.  What you are seeing is the initial startup burst.
When everything starts up, all the buffers are empty, and GNU Radio will
generate data until something backs up.  Once they fill up, you are seeing
the rate settle down.  This is all normal.

If you really need to rate limit what gets requested of the database during
the initial transient (which I don't recommend), you should do that within
your source block.

Matt


On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long  wrote:

> Should have mentioned ... set the throttle rate just slightly higher than
> what the chain would consume at steady state when all the buffers are
> filled and the USRP is transmitting. How well this works depends on what
> the rest of the chain looks like.
>
> - Jeff
>
>
> On 10/14/2014 05:52 PM, Jeff Long wrote:
>
>> Use a throttle block immediately after your source block, setting the
>> vector size to match your source.
>>
>> - Jeff
>>
>> On 10/14/2014 04:34 PM, David Halls wrote:
>>
>>> Dear All,
>>>
>>> I am wondering how to add some flow control to a source block, so that
>>> it doesn’t fire out items so quickly.
>>>
>>> Later stages of my flow graph are slowed by various bits of processing
>>> and combining, before transmission via USRP, with bursts being
>>> transmitted every few seconds.
>>>
>>> What happens is that the block fires out 1,000s of vectors, and then
>>> seems to slow down and settle into sync with the rest of the flow graph
>>> after a few seconds. As my source block is reading in from a Database, I
>>> want to slow this initial rate significantly.
>>>
>>> The block outputs vectors of bytes (v_len=144). Any ideas?
>>>
>>> Regards,
>>>
>>> David
>>>
>>> ---
>>>
>>> David Halls Ph.D.
>>>
>>> Research Engineer
>>>
>>> Toshiba Research Europe Limited
>>>
>>> 32 Queen Square, Bristol, BS1 4ND, UK
>>>
>>> Tel: +44 (0) 117 906 0790
>>>
>>>
>>> 
>>>
>>> NOTE: The information in this email and any attachments may be
>>> confidential and/or legally privileged. This message may be read, copied
>>> and used only by the intended recipient. If you are not the intended
>>> recipient, please destroy this message, delete any copies held on your
>>> system and notify the sender immediately.
>>>
>>> Toshiba Research Europe Limited, registered in England and Wales
>>> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
>>> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
>>>
>>>
>>>
>>> 
>>> This email has been scanned for email related threats and delivered
>>> safely by Mimecast.
>>> For more information please visit http://www.mimecast.com
>>> 
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Arbitrary ADC resolution at the receiver

[Matt Ettus]

The n200 and n210 have 14 bit ADCs.

In any case, you can fake fewer bits by zeroing the low order bits in the
fpga.

Matt
On Jun 30, 2014 10:38 AM, "Leonardo S. Cardoso"  wrote:

> Hello everyone,
>
> I excuse myself on advance by my noob question...
>
> I have an N210 with an SBX front end, and I want to experiment with
> decoding signals at a lower resolution, rather than the default 12 bits
> provided by the N210 ADCs. Does anyone know if (and how) can I limit the
> resolution of the ADCs arbitrarily?
>
> I am aware that I can reduce the resolution afterwards, mapping the
> signals to a lower resolution in base band, but I'd really like to do that
> before the DDC at the FPGA.
>
> Cheers to everyone!
>
> Leonardo S. Cardoso
> leo...@gmail.com
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Phase unwrapping

[Matt Ettus]

Daniele,

The problem with phase unwrapping is that it is unbounded, and will tend to
infinity.  Once it gets very big, when you try to add a small number to a
very big number, floating point loses precision.  Eventually, adding small
to extremely big returns the big number unchanged.  This isn't that useful.

Matt



On Mon, Jun 16, 2014 at 2:40 PM, Daniele Nicolodi 
wrote:

> Hello,
>
> I just started to work with GNU radio for my very basic needs, so please
> excuse my naive questions and probably my inappropriate use of the jargon.
>
> My first trivial application of GNU radio is to simply measure the phase
> of a phase modulated signal with an Ettus Research USRP N210 and a LFRX
> daughter-board.
>
> Everything works as expected, but I haven't found a way to do phase
> unwrapping (removing the 2pi ambiguity in the phase obtained from the
> arctan function looking at discontinuities in the phase data). Is this
> functionality offered somewhere, and I missed it, or should I look into
> implementing it myself?
>
> Thanks. Cheers,
> Daniele
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio discussion in Poland

[Matt Ettus]

I'm going to be in Krakow on Friday and Saturday.  If anyone is interested
in getting together to discuss USRPs or GNU Radio over food and/or drinks,
send me an email.

I'm also giving a talk on Friday morning at AGH in Krakow in building D6
room 201 at 9:30 if you'd like to hear about some exciting new technologies
we're working on.

Pozdrawiam,
Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] (no subject)

[Matt Ettus]

Full duplex implies simultaneous transmission and reception, almost always
on different frequencies.  In the cellular world this is called frequency
division duplexing, or FDD.  Full duplex on a USRP implies transmitting on
one connector (TX/RX) and receiving on the other (RX2).

Half duplex means you never TX and RX simultaneously.

Matt


On Wed, May 14, 2014 at 11:09 AM, jason sam  wrote:

>
> I am confused about the terms full duplex and half duplex in context of
> USRP...If i am using two antennas attached on the same channel on B210(one
> on TX/RX and other on RX2).I am Rxing through one antenna and
> retransmitting the signal with the other antenna..Am i operating on full
> duplex or half duplex??
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] regd: IIP3 and OIP3 measurements for USRPN210

[Matt Ettus]

Gayathri,

You can find IIP2, IIP3, and NF data for the N210 with WBX (on the receive
side) here:

http://files.ettus.com/performance_data/wbx/wbx_imd_and_nf_vs_gain.pdf

Please let me know if you have any questions about the data.

Thanks,
Matt


On Wed, Apr 16, 2014 at 10:22 AM, Gayathri Ramasubramanian
wrote:

> Hi
>
> My project is dealing with Tx/Rx Characterization. I wanted to know if
> anyone has tried finding the IIP3 and OIP3 for the USRP N210 with WBX and
> SBX daughter-boards.
> I did an experiment on Tx side ( USRP behaving as a TX, with the GRC on
> host generating the two tones & output from USRP goes to an attenuator of
> 10 db before going to a spectrum analyzer) and got the following results.
> (as in the excel sheet attached.)
> I am planning to do this for the RX side using Two signal generators
> instead of the GRC flow graph. However I had a few questions:
>
> 1. I found the IIP3 for SBX to be given as 0 dBm & for WBX as 50 ~ 100 dBm
> on receive, What is it for Tx?
> 2. Usually IIP3 and OIP3 are said to have more importance on the RX side,
> to measure non-linearity. Do IIP3 and OIP3 hold same significance on TX
> side? if not, what could be judged as a good measure of non linearity for
> TX side.
> 3. In this test, When I increase the amplitude of the signals, o/p varies.
> But for SBX the Inter-mods appear at 250mV while for WBX it is ard 550mv,
> and here the plot is very unsteady, and the NF is seen as curving.
> however if I do the test with attenuation as 30 dB before the spectrum
> analyzer, The plot has a steady NF. Also after a certain point, I see a lot
> of spurious signals. Is there a specific amplitude range I should
> constraint myself to, to get the IIP3 and OIP3 points.
>
>
>
> Thanks
> Gayathri
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] X300 PCIe issues

[Matt Ettus]

You are using ubuntu 14.4 which has  a new kernel.   It will take us a
little while to get our kernel module working with it.  In the mean time,
going to an older kernel or distribution will fix it.   This does not
affect ethernet connections.

Matt
On Apr 25, 2014 11:38 PM, "Robert McGwier"  wrote:

> I have my new x300's.  The NI ExpressCard-8360B is recognized by my Intel
> 5, Lenovo, 64 bit machine running U 14.04 LTS.
>
> I naively assumed that given the way things had gone before, that this
> would be a low impact out of the box experience.  uhd_find_devices finds
> nothing.
>
> So I go and dig and find I need to do some things first.
>
> http://code.ettus.com/redmine/ettus/projects/uhd/wiki/NI_USRP_RIO_Linux
>
> The installer:
>
>
>
> sudo niusrprio-installer/INSTALL
>
> appears to work, but something is missing still.
>
> Unfortunately,  the enabling and disabling usage lines don't work because
> some module the device is looking for has NOT been added to the kernel,
> much less done with automated update for the next kernel.
>
> Anyone who has faced and solved this issue, and gotten their PCIe
> interface to the x300 to work, please email, because I cannot afford to
> waste the weekend looking at TV.
>
> Bob
>
>
> --
> Bob McGwier
> Co-Owner and Technical Director, Federated Wireless, LLC
> Professor Virginia Tech
> Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
> Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Reference Clock power level for Ettus N210

[Matt Ettus]

We posted those numbers because they are the numbers we know will work
reliably.  -15dBm is unlikely to work well, but you won't damage anything
by trying.

Matt


On Wed, Apr 23, 2014 at 3:43 PM, Antonio Petrolino
wrote:

> Thank you Marcus,
> I will wait for some answers from usrp-us...@lists.ettus.com before
> proceeding.
>
> Best regards,
> Antonio
>
>
>
> On 04/23/2014 03:31 PM, Marcus Müller wrote:
>
>> Hi,
>> looking at the N200 schematics from files.ettus.com, I'd say:
>> stick to the 0dBm, your clock signal has to pass a transformer and some
>> safety/matching circuitry and still ought to be more accurate than the
>> on-board VCTCXO; the clock multiplexer
>> (http://www.micrel.com/index.php/en/products/clock-timing/
>> clock-data-distribution/multiplexers/article/29-sy89545l.html)
>> datasheet says it needs at least a voltage swing of 0.1V after that.
>> I'm not very much of a circuits person, but I think you won't
>> deteriorate much of your clock accuracy by using a clock buffer, which
>> are quite inexpensive (if you need but one and are not afraid to
>> solder... TI gives away samples for free).
>> Then again, you're trying to achieve a better clock performance than the
>> on-board 10MHz ref clock, so I guess you shouldn't start introducing
>> cheap hardware in the clock signal path...
>>
>> Greetings,
>> Marcus
>>
>> PS: maybe the usrp-us...@lists.ettus.com mailing list is better suited
>> for this... I've added that to CC:
>>
>> On 04/23/2014 03:07 PM, Antonio Petrolino wrote:
>>
>>> Hi,
>>>
>>> I'm using a USRP N210 and I need a 10 MHz reference clock. From
>>> ettus.com I got:
>>>
>>> "
>>> Ref Clock - 10 MHz
>>>
>>> Using an external 10 MHz reference clock, a square wave will offer the
>>> best phase noise performance, but a sinusoid is acceptable. The
>>> reference clock requires the following power level:
>>>
>>> USRP2 5 to 15 dBm
>>> N2XX 0 to 15 dBm
>>> "
>>>
>>> So in my case (N210) I should have a minimum 0 dBm signal.
>>> Can someone confirm this information (N2XX 0 to 15 dBm) for N210? The
>>> bad news for me is I have a -15dBm 10 MHz available...
>>>
>>> Thank you,
>>> Antonio
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Terminology Translation

[Matt Ettus]

The most straightforward way is to use a normal FIR filter with all taps
set to 1.  This is not terribly efficient, but will get you what you want.

Matt



On Mon, Apr 7, 2014 at 8:37 AM, Ed Criscuolo wrote:

> Being more of an implementer than a mathematical theorist, I'm
> having trouble "translating" the "language" spoken by our
> local Matlab/Simulink boffins.
>
> What's the proper way to implement an "Integrate and Dump"
> operation in GnuRadio.  I've come across several mutually
> contradictory suggestions.
>
> @(^.^)@  Ed
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Transmit from RF1, receive from RF2

[Matt Ettus]

Which daughterboard are you using?  The only ones where you can receive 2
signals at once are BasicRX, LFRX, and TVRX2.  The others only allow you to
receive from one antenna port at a time.

Matt


On Mon, Mar 10, 2014 at 3:54 PM, Dimitris Siafarikas
wrote:

> Hi list,
>
>
>
> here is the thing. I would like to know, how I can create a flow with
> blocks in GNU Radio companion, in order to receive a signal from the RF1
> port of my URSP N210 and simultaneously , receive another signal from the
> RF2 port of the same USRP.
>
>
>
> Is there any option defining the port of the USRP when selecting USRP
> source/sink block?
>
>
>
> Thank you in advance.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Bypassing CIC and half-band filter on N2x0

[Matt Ettus]

You could only do that by modifying the FPGA.  It would be a very minor
mod, though.  Hook up the undecimated ADC values to where the output of the
decimators go, and leave everything else intact.  Then just set the
decimators as normal and you will get the rate you request.

Matt


On Tue, Feb 25, 2014 at 12:20 PM, Juha Vierinen  wrote:

> Is there any way to bypass the CIC and the HBF on the USRP N200 to just
> stream decimated (no integration) real samples off the 100 MHz ADC? I'd
> like to eg., record every 25th sample arriving on the ADC. I'd like to
> avoid compiling my own fpga is necessary.
>
> Is there any configuration of  calc_cic_filter_word  and
> calc_cordic_word_and_update in the firmware that would magically do this?
>
> juha
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Idea of a USRP UHD block that fills gaps in transmission from USRP

[Matt Ettus]

That's true.  You can fix some of the issues by using preemptible kernels
and setting RTPRIO, but there can still be glitches.  Certainly a block
which reads the streams tags and inserts zeros would not be too hard.

Matt



On Thu, Feb 13, 2014 at 10:20 AM, Sylvain Munaut <246...@gmail.com> wrote:

> Hi,
>
> > One problem is that if you cannot keep up, adding in all-zeros data will
> > just make it harder to keep up.  In general, modern PCs should be able to
> > keep up with 25 MS/s without problem unless you are doing a lot of
> > processing.  We are actually able to keep up with 300 MS/s on the X300.
>  So
> > the question is more about why the app can't keep up.
>
> Well, sometimes the issue isn't so much throughput but latency. Like
> you have some ultra high priority task that decides to block all
> processing for like 100 ms and some buffer fill up and you miss one
> packet ever few minutes. I have that kind of stuff all the time on a
> USRP1. It's not a real time OS so it's always better IMHO to be able
> to cope gracefully with theses little glitches.
>
> And if you're app expects a continuous stream of data to maintain
> alignement, filling with zero is easy enough.
>
> Cheers,
>
> Sylvain
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Idea of a USRP UHD block that fills gaps in transmission from USRP

[Matt Ettus]

Piotr,

One problem is that if you cannot keep up, adding in all-zeros data will
just make it harder to keep up.  In general, modern PCs should be able to
keep up with 25 MS/s without problem unless you are doing a lot of
processing.  We are actually able to keep up with 300 MS/s on the X300.  So
the question is more about why the app can't keep up.

An alternative might be to stream to a file.  That should keep up without
dropping as long as you have a fast drive.  Then you can process samples
from that file at the pace your app can keep up with.

Matt



On Sun, Feb 9, 2014 at 1:19 AM, Perper  wrote:

> Hi all,
>
> Interruptions transmission over Gigabit Ethernet when receiving samples
> from USRP can happen at highest data rates no matter how many tricks you
> use with your network card (I have experience with N200/N210).
>
> The loss of part of the signal results with synchronization loss in data
> transmission systems. There is possibility to handle this problem by
> catching rx_time stream tags.
>
> But there might be a solution to keep synchronization that might work
> quite well with gr-blocks that don't handle stream tags.
>
> What if USRP UHD Source gave user an option to fill all of the gaps in
> signal with exact number of lost samples (for example with zeros).
> Additionally it could produce stream tags with position and length of
> each gap so it would be easy to store a file with continuous signal
> stream paired with a file containing metadata describing where and for
> how long the signal samples were lost.
>
> Is it possible to do exactly what I'm describing with current gnuradio
> blocks?
> In my case it would often make many things I do easier.
>
> --
> Best Regards,
> Piotr Krysik
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] is the USRP-hw still available now?

[Matt Ettus]

The .pcb files for rfx were created with PADS.

Matt


On Wed, Dec 18, 2013 at 7:41 PM, 王永刚  wrote:

> hi,everyone:
>   as i am new to RF pcb layout , i want the USRP daughter board PCB file
> to reference,i found a floder at "/root/usrp-hw"(
> http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/8c8eeca9e2ae26c30f186bef23411d345acbc3f6/show/usrp-hw
> )
>
> but i found some of those pcb files are created by gEDA(like tvrf.pcb).but
> others like rfx900.pcb,i wonder they are created by which tool?
> as i tried,they are not created by those tools: altium
> designer/protel/gEDA/powerPCB.
>
> plz help me if you know how to open them,thank you.
>
> nail.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] USRP N210 Signal Phase Issue

[Matt Ettus]

It could be the usrp digitally clipping, not the analyzer.

Matt


On Tue, Jan 7, 2014 at 5:17 PM, Jonathan Fox <31...@cardinalmail.cua.edu>wrote:

> On Tue, Jan 7, 2014 at 7:11 PM, Marcus D. Leech  wrote:
>
>>
>> Try reducing the amplitude to 0.7.  Another possibility is that your
>> computer can't keep up.  If you are using one of the standard programs, are
>> there U's printing in the terminal?
>>
>>  Matt
>>
>>  Also, what RF gain are you setting?  Does it exceed the maximum input
>> level of the spectrum analyser?
>>
>> Are you connected directly, or with an antenna?
>>
>>
>>
>> On Tue, Jan 7, 2014 at 3:03 PM, Jonathan Fox 
>> <31...@cardinalmail.cua.edu>wrote:
>>
>>>  A colleague and I are sending a simple signal in GNU Radio (sine wave,
>>> 1 MHz, amplitude of 1) to the USRP sink and have the center frequency at
>>> 500 MHz. The N210 USRP is hooked up to an Agilent spectrum analyzer. On the
>>> analyzer we are seeing a weird phenomena every two seconds. At first we see
>>> the carrier frequency and two sidebands from the sine wave (see attached
>>> normal.gif). Then after two seconds we get two bursts of multiple harmonics
>>> (see odd.gif).
>>>
>>>  The question is, why is this happening? Does the phase of the 1
>>> KHz signal become discontinuous before or after being sent to the USRP?
>>>
>>>  Thanks,
>>>
>>>  Jon Fox
>>>
>>> ___
>>> USRP-users mailing list
>>> usrp-us...@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> I don't recall seeing any U's but I can recheck tomorrow. The gain on the
> USRP was set to -2. The USRP was connected directly with an SMA cable. The
> analyzer is an Agilent E4440A, the Analyzer is rated for at least 1 Watt on
> average, 100 Watt on a peak pulse (with the built-in attenuator in use).
> While I am not ruling out the maximum input I thought the N210 tops out at
> 0.5 Watts due to FCC regulations.
>
> Thanks
>
> Jon
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] USRP N210 Signal Phase Issue

[Matt Ettus]

Try reducing the amplitude to 0.7.  Another possibility is that your
computer can't keep up.  If you are using one of the standard programs, are
there U's printing in the terminal?

Matt


On Tue, Jan 7, 2014 at 3:03 PM, Jonathan Fox <31...@cardinalmail.cua.edu>wrote:

> A colleague and I are sending a simple signal in GNU Radio (sine wave, 1
> MHz, amplitude of 1) to the USRP sink and have the center frequency at 500
> MHz. The N210 USRP is hooked up to an Agilent spectrum analyzer. On the
> analyzer we are seeing a weird phenomena every two seconds. At first we see
> the carrier frequency and two sidebands from the sine wave (see attached
> normal.gif). Then after two seconds we get two bursts of multiple harmonics
> (see odd.gif).
>
> The question is, why is this happening? Does the phase of the 1 KHz signal
> become discontinuous before or after being sent to the USRP?
>
> Thanks,
>
> Jon Fox
>
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FFT --> IFFT

[Matt Ettus]

The purpose of a window is to lower bin-to-bin leakage.  It is only useful
when the FFT is the final product, since it changes the signal.  Think of
it this way -- you are multiplying a signal in the time domain when you
window.  If you window, then FFT, then IFFT, you will get back the windowed
signal, not the original signal.

Matt


On Mon, Nov 18, 2013 at 5:33 AM, Tom Rondeau  wrote:

> On Mon, Nov 18, 2013 at 8:22 AM, Robert James 
> wrote:
> > On 11/18/13, Marcus Müller  wrote:
> >> Hi Robert!
> >>
> >> This is strange -- but could be explained by the fact that numerical
> >> inaccuracy don't allow us to *exactly* recreate all values during
> fft-ifft
> >> operation.
> >> Also, make sure you use a rectangular window.
> >
> > Wow, switching to a rectangular window of fft_size solved it! I'm
> > baffled: I know windows are a way of pretransforming the wave prior to
> > FFT, to eliminate artifacts.  I just used the default window.  Why did
> > I need a rectangular window here? In what other cases do I need it?
>
> Were both windows the same or different? I've often seen people trying
> this experiment using a window on the forward FFT but no window on the
> inverse FFT. That would obviously cause different output results.
>
> > Now, the only discrepancy I see is that the FFT->IFFT ended up
> > *increasing* the amplitutde by a constant (not sure why or what the
> > constant is).
>
> The constant is N for an N-point FFT. It's part of the common
> algorithms for computing FFTs to grow the value without scaling it
> back, since that's an added extra step and we want our FFTs to be
> fast. You can use a multiply_const_cc block with constant (1.0/fftlen)
> after the vector-to-stream block to rescale it yourself.
>
> Tom
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] R: R: Re: R: R: Re: around empty subcarrier in 802.11n implementation

[Matt Ettus]

Thanks for the update!  I know that getting the exact right bins in the
right place can be hard since every FFT inplementation is slightly
different.

Matt


On Mon, Oct 14, 2013 at 8:43 AM, xe...@libero.it  wrote:

> Hi guys,
>
> just for letting you know. No offset correction is needed. The problem was
> elsewhere in my implementation of 802.11. It was how I was calling the ifft
> function in the transmitter side. By putting the correct parameters, I
> obtained a perfect spectrum.
>
> Regards
>
> Francesca
>
>
>
>
>
>  Messaggio originale
> Da: xe...@libero.it
> Data: 09/10/2013 16.55
> A: , 
> Ogg: [Discuss-gnuradio] R: Re: R: R: Re: around empty subcarrier in
> 802.11n implementation
>
>
> Ok, I was supposing that.
>
>
> So in the python code of the receiver I've put:
>
>
> tr=uhd.tune_request(self._freq,self._offset)
>
> self.uhd_usrp_source_0.set_center_freq(tr)
>
>
> where freq and offset are passed as parameters. In this way I got no error.
>
>
> Now, the question is: which values are good for "offset"? Hz? KHz? MHz?
>
> I've tried small values, like 50 Hz, but nothing changes.
>
> Is there a way  to find it?
>
>
> I'm sorry, but really I have not idea
>
> Thank you again for your support
>
> francesca
>
>
>
>
>
>
>  Messaggio originale
> Da: mle...@ripnet.com
> Data: 09/10/2013 16.31
> A: 
> Ogg: Re: [Discuss-gnuradio] R: R: Re: around empty subcarrier in 802.11n
> implementation
>
> On 10/09/2013 09:55 AM, xe...@libero.it wrote:
>
> Hi guys,
>
>
>  I've tried to follow the suggested procedure. I guess the problem is
> inside the uhd driver I'm using (UHD_003.005.001), since the set_rx_freq()
> gives the following error:
>
>
>  AttributeError: 'uhd_usrp_source_sptr' object has no attribute
> 'set_rx_freq'
>
>
>  Or, maybe, the problem is the daughterboard, which is of type XCVR2450.
>
>
>  Is there another way to set dc offset?
>
>
>  Any hint will be greatly appreciated.
>
> Francesca
>
>
>
>
>  Messaggio originale
> Da: xe...@libero.it
> Data: 09/10/2013 10.52
> A:  
> Ogg: [Discuss-gnuradio] R: Re: around empty subcarrier in 802.11n
> implementation
>
> Thanks for your answer.
>
>
>  I'm a computer scientist, so I'm not so aware of what DC-offset exactly
> means, but I'm going to try this tuning. I'll let you know if I solve the
> problem.
>
>
>  Best regards
>
> Francesca
>
>
>
>
>  Messaggio originale
> Da: mle...@ripnet.com
> Data: 08/10/2013 16.22
> A:  
> Ogg: Re: [Discuss-gnuradio] around empty subcarrier in 802.11n
> implementation
>
> Likely, if it's the central tones, you're looking at DC-offset (or the
> removal thereof) interfering.
>
>
> You can use offset tuning in the hardware to slide the DC offset outside
> of your passband.
>
> http://files.ettus.com/uhd_docs/manual/html/general.html#tuning-notes
>
>
> on Oct 08, 2013, *xe...@libero.it*  wrote:
>
> Hi list,
>
> I'm using gnuradio 3.6.0 together with USRPs N210 for implementing OFDM
> 802.11
> n communications, just SISO for the moment (in the future it would be
> MIMO). I
> have properly modified parameters such as FFT size, number of occupied
> tones
> and so on. I have also included all preambles (STF, LTF...) and I have
> accordingly modified the "correlate" and "calculate_equalizer" functions
> in
> ofdm_frame_acquisition. FEC is also included in the chain. In the
> ofdm_frame_sink file I've added a function that computes SNR in a
> per-carrier
> basis.
>
> Everything is working fine, I obtain about 80% of correct packets, but
> I've
> noticed from the snr plotting, that the carriers around the central empty
> one
> (3 subcarriers before and 3 subcarriers after) have very poor snr values.
> So
> I've investigated about this effect, and I've realized that the all
> transmission errors are in those subcarriers and, in most cases, FEC is
> able to
> recover, but I would like to understand why this happens.
>
> I conducted some searches in the web but unfortunately I didn't find an
> answer.
> Let me know if you need some other information about my implementation.
>
> Thanks for your attention
> francesca
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>  Since you're likely using the Gnu Radio interface that is a wrapper for
> UHD, you'd use the set_center_freq() method.
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
>
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listin

Re: [Discuss-gnuradio] [USRP-users] USRP N210 Rev 4.0 generation/architecture

[Matt Ettus]

Yes to both questions.

Matt


On Sun, Sep 1, 2013 at 10:28 PM, Sam mite  wrote:

> Does USRP N210 Rev 4.0 belongs to 2nd generation USRP architecture? Does
> the picture attached rightly depicts the USRP N210 Rev 4.0 architecture?
>
>
> --
>
> Sam
>
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] LFRX as IF stage questions

[Matt Ettus]

I just realized the LFRX does not have the clock pin.  The BasicRX does,
and should also work the same way for your application.  So if you need the
clock output, the BasicRX is a better choice.

Matt


On Wed, Aug 14, 2013 at 7:25 AM, Matt Ettus  wrote:

>
> The LFRX has 2 inputs.  For your application you only need to use one of
> them, since you have a real IF and not complex IQ baseband.  The signal
> will then be downconverted from 10 MHz by the DDCs, and you will have a
> complex baseband signal.
>
> The LFRX has a clock output pin.  You will need to explicitly turn that
> pin on and set the divider to 10 in order to get a 10 MHz reference output
> for your system.
>
> Matt
>
>
> On Fri, Aug 9, 2013 at 5:25 PM, Nemanja Savic  wrote:
>
>> Hi all guys,
>>
>> I have designed a small board based on Ti's CC1000 transciever, which I
>> want to use as my RF front end. The board provides 10.7 MHz IF signal at
>> one of the pins. After connecting everything I come to the point where I
>> don't understand what's going on after LFTX.
>> In the "documentation" about LFTX on ettus website it is written that it
>> can be used for one complex baseband rx channel or two real valued rx
>> chains. I which way i can get only real valued signal from RX-A (taking
>> only the real part from the signal coming from usrp source?)
>> I suppose that signal is downconverted to baseband using DDCs. Do they
>> make quadrature signal from the input and make complex baseband at the end?
>>
>> Is there any stable clk signal at the board with frequency between 10 MHz
>> and 14 MHz that I can use as clock reference for my board?
>>
>> Cheers,
>>
>> --
>> Nemanja Savić
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] LFRX as IF stage questions

[Matt Ettus]

The LFRX has 2 inputs.  For your application you only need to use one of
them, since you have a real IF and not complex IQ baseband.  The signal
will then be downconverted from 10 MHz by the DDCs, and you will have a
complex baseband signal.

The LFRX has a clock output pin.  You will need to explicitly turn that pin
on and set the divider to 10 in order to get a 10 MHz reference output for
your system.

Matt


On Fri, Aug 9, 2013 at 5:25 PM, Nemanja Savic  wrote:

> Hi all guys,
>
> I have designed a small board based on Ti's CC1000 transciever, which I
> want to use as my RF front end. The board provides 10.7 MHz IF signal at
> one of the pins. After connecting everything I come to the point where I
> don't understand what's going on after LFTX.
> In the "documentation" about LFTX on ettus website it is written that it
> can be used for one complex baseband rx channel or two real valued rx
> chains. I which way i can get only real valued signal from RX-A (taking
> only the real part from the signal coming from usrp source?)
> I suppose that signal is downconverted to baseband using DDCs. Do they
> make quadrature signal from the input and make complex baseband at the end?
>
> Is there any stable clk signal at the board with frequency between 10 MHz
> and 14 MHz that I can use as clock reference for my board?
>
> Cheers,
>
> --
> Nemanja Savić
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] See a demo of our new USRP as DEFCON

[Matt Ettus]

Yes, it will fall back to USB 2.0, which reduces the bandwidth.

Matt

On Fri, Aug 2, 2013 at 12:07 PM, Tom Rondeau  wrote:

> On Thu, Aug 1, 2013 at 8:10 PM, Matt Ettus  wrote:
> >
> > For those lucky enough to be going to DEFCON, Balint Seeber (our
> > applications engineer) will be presenting "All Your RFz Are Belong to Me
> --
> > Hacking the Wireless World with SDR", in Track 4 from 10 AM to 11:45.  He
> > will be running all of his demos on the USRP B200, which we are going to
> > release very soon.
> >
> > The low-cost B200 has frequency coverage of 50 MHz to 6 GHz, with 56 MHz
> of
> > instantaneous bandwidth (at 61.44 MS/s) over a USB 3 interface.  The B210
> > adds 2x2 MIMO capability and a bigger FPGA.  The device is bus-powered so
> > there is no need for an external power supply.  It *already* runs GNU
> Radio,
> > OpenBTS, LTE, and anything else that runs on our other USRPs.
> >
> > Balint's talks are always very exciting, so be sure to check it out if
> you
> > are at the conference.  He is going to demonstrate RFID hacking (on
> FastTrak
> > toll passes), LTE, OpenBTS, and numerous other applications he has
> > developed.
> >
> > For those not lucky enough to be there, here is a brief taste of it:
> >
> > http://t.co/GyCijVunPx
> >
> > Matt
>
>
> Matt,
>
> That's great! I'm really looking forward to seeing it in action.
>
> Just a question that I'm sure you've addressed somewhere already, but
> is there any fall-back support to work off USB 2.0?
>
> --
> Tom
> Visit us at GRCon13 Oct. 1 - 4
> http://www.trondeau.com/grcon13
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] See a demo of our new USRP as DEFCON

[Matt Ettus]

For those lucky enough to be going to DEFCON, Balint Seeber (our
applications engineer) will be presenting "All Your RFz Are Belong to Me --
Hacking the Wireless World with SDR", in Track 4 from 10 AM to 11:45.  He
will be running all of his demos on the USRP B200, which we are going to
release very soon.

The low-cost B200 has frequency coverage of 50 MHz to 6 GHz, with 56 MHz of
instantaneous bandwidth (at 61.44 MS/s) over a USB 3 interface.  The B210
adds 2x2 MIMO capability and a bigger FPGA.  The device is bus-powered so
there is no need for an external power supply.  It *already* runs GNU
Radio, OpenBTS, LTE, and anything else that runs on our other USRPs.

Balint's talks are always very exciting, so be sure to check it out if you
are at the conference.  He is going to demonstrate RFID hacking (on
FastTrak toll passes), LTE, OpenBTS, and numerous other applications he has
developed.

For those not lucky enough to be there, here is a brief taste of it:

http://t.co/GyCijVunPx

Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 802.22 implementation on Gnu Radio?

[Matt Ettus]

I don't know of any 802.22 implementations at all, on GNU Radio or
otherwise.  Are people still working on 802.22?

Matt


On Tue, Jun 11, 2013 at 3:57 AM, M. Ranganathan  wrote:

> Hello!
>
> I am wondering if there are any implementations of 802.22 on GR. Any
> pointers would be appreciated.
>
> Thank you
>
> Ranga
>
> --
> M. Ranganathan
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] How to Travel Commercial Airlines with USRP

[Matt Ettus]

These days you will have more trouble with a screwdriver than with the
usrp.  We fly with them all the time.

Matt
 On Jun 9, 2013 12:27 PM, "Bruce Penswick"  wrote:

> Hello:
>
> Quick question: I'm flying commercial for a work-trip, American Airlines
> from Los Angeles to Dallas, and I need to bring my USRP N200. How can I
> bring it with me? Does anyone have any experience flying commercial
> airlines with USRPs? Should I put it into my checked-in luggage? I'm afraid
> it would get flagged as something dangerous, and they'd rip open my
> luggage. Do you think I could carry it on-board the plane, after security
> makes me open it and they look inside it? Or is it just going to create too
> many problems, and would I be better off just mailing it to Dallas ahead of
> my trip?
>
> Any thoughts, advice, experiences would be much appreciated!!
> Thanks for your help!!
>
> Best Regards,
> Bruce P.
>
>
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Question about UHD driver

[Matt Ettus]

Are you saying that it is better to always make copies of the data rather
than just make copies when you need them?

In any case, I think you misunderstand both how GNU Radio works and how UHD
interacts with it.  UHD provides a single copy of data to GNU Radio  for
two reasons -- first, that is the most efficient thing to do, and second,
UHD can't possibly know what GNU Radio plans to do with the data.  GNU
Radio passes pointers of the data to every block that needs it.  Blocks are
not allowed to modify their inputs, only their outputs.  This is
fundamental to how GNU Radio operates.

Matt




On Thu, May 16, 2013 at 9:02 PM, Mark McCarron wrote:

> There is a performance issue with this.  If your program needs to
> manipulate the raw data, but at the same time provide that raw data to
> another branch(es), a copy much be made.  If this is the case, then it
> would make more sense to duplicate the data in parallel as it enters the
> system.  This should be more efficient than memcopy.
>
> I am looking into DMA to see if this is possible.
>
> Regards,
>
> Mark McCarron
>
> --
> From: m...@ettus.com
> Date: Thu, 16 May 2013 20:51:32 -0700
> Subject: Re: [Discuss-gnuradio] Question about UHD driver
> To: mark.mccar...@live.co.uk
> CC: discuss-gnuradio@gnu.org
>
>
>
> There is no need to create multiple copies.  The consuming blocks are each
> given a pointer to the same data, and the memory is not freed until all the
> consuming blocks indicate they are done with it.
>
> Matt
>
>
> On Thu, May 16, 2013 at 11:00 AM, Mark McCarron 
> wrote:
>
> I am wondering if the UHD driver has the ability to create multiple copies
> of the stream in memory???
>
> Let's say I have a flow-graph that has two branches, the first pushes
> complex data to an FFT, whereas the second demodulates a portion of that
> data into AM.
>
> Does the driver supply a single stream, which is then copied by the
> application?  Or does it create two copies of the stream and allow each
> branch of the flow-graph to manipulate the data via pointers?
>
> I'm digging into DMA to see if this is possible, I would be surprised if
> there was a limitation here.
>
> Regards,
>
> Mark McCarron
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Question about UHD driver

[Matt Ettus]

There is no need to create multiple copies.  The consuming blocks are each
given a pointer to the same data, and the memory is not freed until all the
consuming blocks indicate they are done with it.

Matt


On Thu, May 16, 2013 at 11:00 AM, Mark McCarron wrote:

> I am wondering if the UHD driver has the ability to create multiple copies
> of the stream in memory???
>
> Let's say I have a flow-graph that has two branches, the first pushes
> complex data to an FFT, whereas the second demodulates a portion of that
> data into AM.
>
> Does the driver supply a single stream, which is then copied by the
> application?  Or does it create two copies of the stream and allow each
> branch of the flow-graph to manipulate the data via pointers?
>
> I'm digging into DMA to see if this is possible, I would be surprised if
> there was a limitation here.
>
> Regards,
>
> Mark McCarron
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio in Brazil

[Matt Ettus]

Hi everyone.  I'm traveling in Sao Paulo this week for NI Days Brasil (
http://brasil.ni.com/nidays ), and I have some free time.  If you would
like to get together to talk about GNU Radio and USRPs, what is coming from
Ettus Research, or anything else SDR, send me an email.  If you have a
group and some space on Friday, I can even do a presentation and show you a
cool prototype system we've been working on.

Muito obrigado,
Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Any one know rfx board i q imbalance value

[Matt Ettus]

The imbalance will vary board to board, which is why we provide the ability
to calibrate the IQ balance.  Running the calibration utility will get you
the best performance.

Matt


On Fri, Mar 8, 2013 at 5:54 PM, James Jordan wrote:

> Hi list,
> Anyone know rfx board i q phase imbalance value and amplititude imbalance
> value,
> I do not have equiment to measure these value.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM - real RF output vs. expected output

[Matt Ettus]

You are probably using an odd interpolation ratio.  You need to use an even
rate in order to get a flat passband.

The WBX does not have adjustable filtering.

Matt


On Wed, Feb 13, 2013 at 10:42 PM, Ralph A. Schmid, dk5ras
wrote:

> Hi,
>
> I use an USRP1 together with gnuradio/GRC and would like to transmit an
> OFDM
> signal, abt. 1 MHz bandwidth at 433 MHz. The FFT display block within GRC
> shows the power mask as expected, a flat line over the bandwidth, and steep
> drops at both ends. What a real spectrum analyzer at the output shows is
> something totally different, like a Gaussian distribution of the emitted
> energy, with highest amplitude in the center, bandwidth as configured, but
> the amplitude is dropping continuously towards the ends for about 70 dB or
> so. Adjusting the channel bandwidth in the sink block has no influence,
> maybe the WBX anyway does not support adjustable filtering?!
>
> Even the simplest possible setup, like random source, OFDM modulator and
> URSP, shows this behavior.
>
> What am I doing wrong?
>
> Btw., the spectrum analyzer is a professional device and out of any doubt
> :)
> LTE, DAB and DVB-T is shown as expected.
>
> Ralph.
>
>
> --
>
> Ralph A. Schmid
> Mondstr. 10
> 90762 Fürth
> +49-171-3631223
> ra...@schmid.xxx
> http://www.bclog.de/
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Unknown cause of Latency with USRP

[Matt Ettus]

There is your problem.  If you have a stream with approximately 45kbps that
you are trying to put through one at 45kbps, then you will eventually build
up an infinite backlog.  Set your transmitter and receiver to something
like 50 kbps and this won't happen.

Matt


On Wed, Jan 23, 2013 at 10:40 AM, Tom Hendrick  wrote:

> Hello Matt,
> The ffmpeg encoder is set to 45 kbps bitrate and the transmitter/receiver
> is set to about 45 kbps as well.
> The ffmpeg encoder doesn't converge at 45 kbps exactly, but it comes
> close.  The signals are sampled at a pretty high rate of 500 kHz and the
> GRC scripts resample at 1 MHz so the USRP is run at 1MS/s rates.
> Thank you, Tom
>
>
>   ------
> *From:* Matt Ettus 
> *To:* Tom Hendrick 
> *Cc:* "j...@ettus.com" ; "discuss-gnuradio@gnu.org" <
> discuss-gnuradio@gnu.org>
> *Sent:* Wednesday, January 23, 2013 10:34 AM
>
> *Subject:* Re: [Discuss-gnuradio] Unknown cause of Latency with USRP
>
>
> What is the bit rate of the source and what is the bit rate of the data
> transmission?
>
> Matt
>
>
> On Wed, Jan 23, 2013 at 10:32 AM, Tom Hendrick  wrote:
>
> Hello Josh,
> The transmitter sends data when there is enough to fill a packet.  The
> packets are flushed about every 200msec consistently.  The ffmpeg encoder
> seems to have a continuous output that is pretty steady since it is
> encoding webcam images at a pretty reasonably constant bitrate with the
> settings I applied.
>
> When I look on the oscilloscope output of the USRP tx board, the stream
> shows no gaps or pauses at all and the packets look spaced properly in time
> as if I had written the transmitter output directly to a file.
>
> Are the solutions you recommended something I can try implementing with
> GRC (for instance throttle or the gr_block api)?  Making the external
> modulator/demodulator work in a burst type mode is something I probably
> don't know how to do.  I know how to run the modulator/demodulator code but
> I didn't develop it.  The only thing I can think of adjusting is the amount
> of data blocks inside a packet.  I can increase or reduce that number and
> that would increase/decrease the time duration between flushing of packets.
>
> Thanks very much for your help, Tom
>
>
>   --
> *From:* Josh Blum 
> *To:* discuss-gnuradio@gnu.org
> *Sent:* Tuesday, January 22, 2013 10:54 PM
> *Subject:* Re: [Discuss-gnuradio] Unknown cause of Latency with USRP
>
>
> >
> > I appreciate any advice.  I'm out of ideas and have searched a lot on
> > latency related to GNURadio and most of the latency I've read up on
> > seems to be in the microsecond to millisecond ranges.
> >
> > Thanks very much, Tom
> >
> >
>
> Does the application that produces transmit samples send bursts of
> samples only when there is data to send, or is the transmitter always
> being fed?
>
> I ask because gnuradio can potentially have a lot of buffering, and if
> your transmit app is producing continuous samples or producing samples
> faster than the rate consumed, the buffering will just become full, and
> it will take buffer_size/sample_rate seconds to see a change occur
> through the pipeline.
>
> If this is the issue, I recommend some kind of bursty transmission.
> Some neat examples of this in precog
> https://github.com/jmalsbury/pre-cog/wiki
>
> If you need to continuously transmit, you might want to maintain a
> window of buffering where the application throttles back production of
> samples. One way to do this would be to simply use the consumption of rx
> samples to throttle the production of tx samples.
>
> Another alternative would be to use the gr_block api to shrink the
> buffer size of each block in the transmit chain -- to minimize the
> capability of gnuradio buffering data -- if the app must rely on
> backpressure from gnuradio
>
> -josh
>
> >
> > ___ Discuss-gnuradio
> > mailing list Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Unknown cause of Latency with USRP

[Matt Ettus]

What is the bit rate of the source and what is the bit rate of the data
transmission?

Matt


On Wed, Jan 23, 2013 at 10:32 AM, Tom Hendrick  wrote:

> Hello Josh,
> The transmitter sends data when there is enough to fill a packet.  The
> packets are flushed about every 200msec consistently.  The ffmpeg encoder
> seems to have a continuous output that is pretty steady since it is
> encoding webcam images at a pretty reasonably constant bitrate with the
> settings I applied.
>
> When I look on the oscilloscope output of the USRP tx board, the stream
> shows no gaps or pauses at all and the packets look spaced properly in time
> as if I had written the transmitter output directly to a file.
>
> Are the solutions you recommended something I can try implementing with
> GRC (for instance throttle or the gr_block api)?  Making the external
> modulator/demodulator work in a burst type mode is something I probably
> don't know how to do.  I know how to run the modulator/demodulator code but
> I didn't develop it.  The only thing I can think of adjusting is the amount
> of data blocks inside a packet.  I can increase or reduce that number and
> that would increase/decrease the time duration between flushing of packets.
>
> Thanks very much for your help, Tom
>
>
>   --
> *From:* Josh Blum 
> *To:* discuss-gnuradio@gnu.org
> *Sent:* Tuesday, January 22, 2013 10:54 PM
> *Subject:* Re: [Discuss-gnuradio] Unknown cause of Latency with USRP
>
>
> >
> > I appreciate any advice.  I'm out of ideas and have searched a lot on
> > latency related to GNURadio and most of the latency I've read up on
> > seems to be in the microsecond to millisecond ranges.
> >
> > Thanks very much, Tom
> >
> >
>
> Does the application that produces transmit samples send bursts of
> samples only when there is data to send, or is the transmitter always
> being fed?
>
> I ask because gnuradio can potentially have a lot of buffering, and if
> your transmit app is producing continuous samples or producing samples
> faster than the rate consumed, the buffering will just become full, and
> it will take buffer_size/sample_rate seconds to see a change occur
> through the pipeline.
>
> If this is the issue, I recommend some kind of bursty transmission.
> Some neat examples of this in precog
> https://github.com/jmalsbury/pre-cog/wiki
>
> If you need to continuously transmit, you might want to maintain a
> window of buffering where the application throttles back production of
> samples. One way to do this would be to simply use the consumption of rx
> samples to throttle the production of tx samples.
>
> Another alternative would be to use the gr_block api to shrink the
> buffer size of each block in the transmit chain -- to minimize the
> capability of gnuradio buffering data -- if the app must rely on
> backpressure from gnuradio
>
> -josh
>
> >
> > ___ Discuss-gnuradio
> > mailing list Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] DARPA Spectrum Challenge

[Matt Ettus]

By now many of you have heard about the DARPA Spectrum Challenge.  Everyone
should know that the deadline to register is January 31st, so please don't
forget to register your teams.  To register, you just fill out a web form.
 The hard work comes later :)

   http://www.darpa.mil/spectrumchallenge/

The DARPA Spectrum Challenge is a competition to demonstrate a radio
protocol that can best use a given communication channel in the presence of
other dynamic users and interfering systems.  You can win up to $150,000.

We are very proud that the challenge will use USRP radios in the ORBIT
radio testbed at Winlab of Rutgers University:

http://www.winlab.rutgers.edu/docs/focus/ORBIT.html

A number of people have commented on the mistaken belief that the contest
is only open to people in the US.  From the Spectrum Challenge Web Site:

The person identified as the team leader must be a U.S. citizen or
permanent resident (green card holder) at time of registration and
throughout the competition. Other team members need not be U.S. citizens or
permanent residents.

I would really like to see teams from all around the world participate, so
if anyone outside the US would like to participate but cannot find an
American to be team leader, please let me know and I will try to help you
find someone.

Some other thoughts on this --

 - You are not required to use GNU Radio.  You can code directly to the UHD
library, but I anticipate most people will use GNU Radio.

- I think the optimal size for a team is 2-3 people, maybe 4 at the most.
 You can have up to 10 members, but that seems likely to add very little,
so don't worry if you can't find a big group.

- Qualifying teams can get USRPs for development purposes, so don't let a
lack of hardware dissuade you from entering.

I truly believe this contest is one of the most exciting recent
developments in SDR, and I hope there will be a lot of participation from
members of the list.

Matt Ettus
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DARPA Spectrum Challege

[Matt Ettus]

Sorry, I meant "find", not "fund"

Matt


On Sun, Jan 13, 2013 at 3:32 PM, Matt Ettus  wrote:

>
>
>
> On Sun, Jan 13, 2013 at 2:10 PM, Martin Braun (CEL) 
> wrote:
>
>> On Sun, Jan 13, 2013 at 01:50:34PM -0500, Tom Rondeau wrote:
>> > I really hope a lot of you on this mailing list look into participating
>> in the
>> > competition! But note that you have to enter by the end of January.
>>
>> ...those of you based in the US, that is :(
>>
>
>
> No.  If you check the rules they state that every team _leader_ must be
> based in the US.  There is no requirement that the rest of the team be in
> the US.  I'm sure we can fund an American willing to be the lead for teams
> based elsewhere.
>
> Matt
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DARPA Spectrum Challege

[Matt Ettus]

On Sun, Jan 13, 2013 at 2:10 PM, Martin Braun (CEL) wrote:

> On Sun, Jan 13, 2013 at 01:50:34PM -0500, Tom Rondeau wrote:
> > I really hope a lot of you on this mailing list look into participating
> in the
> > competition! But note that you have to enter by the end of January.
>
> ...those of you based in the US, that is :(
>


No.  If you check the rules they state that every team _leader_ must be
based in the US.  There is no requirement that the rest of the team be in
the US.  I'm sure we can fund an American willing to be the lead for teams
based elsewhere.

Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio and Ettus Research at Wireless Innovation Forum

[Matt Ettus]

If you're in Washington DC this week and you have the time, we'd love to
see you at the Wireless Innovation Forum conference (aka SDR Forum).
 Registration for exhibits is free, and you can see our booth there.  At
the booth we have 2 major demos -- an all-software LTE basestation running
on a USRP N210, and a direction-finding demo.

On Wednesday from 5:30 to 6:30 is the Technology Showcase.  Afterwards, a
large group of GNU Radio and USRP users will be meeting up at the
conference hotel at 6:30 and will walk to a nearby restaurant for a get
together to discuss software radio over dinner and drinks. We'll post the
location of the restaurant as well.

Hope to see you there!

Matt Ettus
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Hardware requirement

[Matt Ettus]

Ghulam,

USRP systems are available directly from Ettus Research and we can ship to
India without issues.

   http://ettus.com

Thanks,
Matt Ettus


On Thu, Dec 27, 2012 at 8:58 AM, Ghulam Rasool Begh wrote:

> Hi all,
> I want to build a complete gnuradio platform. Being very new to gnuradio,
> can anybody let me availability of required hardware in india
>
> Regards
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] self-interference with wbx

[Matt Ettus]

One possible reason is that your transmitted signal may have a wider
spectrum than you think due to the intermittent nature and or intermod.
 You should look at the spectrum of the output signal and make sure you are
not transmitting wider than you think.  Rapid on-off keying of the
transmitted signal without ramping up and down at the beginning and end
will create spectral noise.  This is why most standards like bluetooth and
802.11 specify amplitude ramp functions.

Matt


On Thu, Dec 20, 2012 at 5:00 PM, Francois Quitin  wrote:

>  Hi Marcus, 
>
> ** **
>
> Thanks for your answer. I do expect some of the Tx power to leak into my
> Rx chain, and my application can live with that. What I don’t understand,
> is why this power is much higher when transmitting packets than when
> transmitting a continuous tone. 
>
> ** **
>
> Francois
>
> ** **
>
> *De :* discuss-gnuradio-bounces+fquitin=ulb.ac...@gnu.org [mailto:discus
> s-gnuradio-bounces+fquitin=ulb.ac...@gnu.org] *De la part de* Marcus D.
> Leech
> *Envoyé :* jeudi 20 décembre 2012 16:52
> *À :* discuss-gnuradio@gnu.org
> *Objet :* Re: [Discuss-gnuradio] self-interference with wbx
>
> ** **
>
> Dear List, 
>
>  
>
> I am using a USRP-2 with a WBX daughterboard that is operating in full
> duplex mode. Both the Tx and Rx gain are cranked up to their maximum values
> (tx gain 25 dB, rx gain 30 dB). The Tx and Rx frequencies are about 70 MHz
> apart (Tx->964 MHz and Rx->892MHz).  I’m having a little trouble with the
> self-interference: 
>
> when the Tx chain is sending periodic packets (with 0s in between), this
> creates very high noise in my Rx chain (up to 0.01 on gnuradio companion
> scope)
>
> when the Tx chain is sending a continuous pilot tone, there is no noise in
> my Rx chain (noise is lower than 0.0005 on gnuradio companion scope)
>
>  
>
> I would like that, when transmitting periodic packets, the noise would be
> as low as when transmitting a continuous pilot tone. I understand that
> periodic packets would create noise in a wider band than the periodic tone,
> but still, my Tx and Rx frequencies are very far apart. Is there some
> automatic gain in the USRP that is playing tricks here? If so, is there a
> way to solve this? 
>
>  
>
> Any input is appreciated, 
>
> Thanks a lot, 
>
>  
>
> Francois
>
>  
>
> PS: for our application, we had to turn the DUC cordic off. But even with
> the DUC cordic enabled, I still observe similar trends, so I don’ suppose
> that would matter. We also had to put the Clock source to “external” to
> avoid the automatic clock correction (but again, putting it to “Default”
> didn’t change a thing). 
>
> ** **
>
> ** **
>
> ___
>
> Discuss-gnuradio mailing list
>
> Discuss-gnuradio@gnu.org
>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> I a fully-engineered full-duplex system, there'll be a duplexor to provide
> better isolation (70-80dB) for the RX gain an mixer.  Your RX front-end is
>   "seeing" all of the TX energy you're transmitting, and very likely being
> drive into non-linear operating territory -- just because your mixer is
> tuned
>   70Mhz away from the TX, *does not mean* that your RX LNA is "tuned" only
> to your tuned frequency.  You might able to get away with just using
>   a notch for your TX frequency in front of your RX, but without some
> actual RF plumbing/systems-engineering, you'll run into "desense" issues
> like
>   this.
>
> Any such duplexing arrangements are clearly, *necessarily* application
> specific.  Which is why there's no duplexor or other filters on the
> daughtercards.
>   Since they're used for a *huge* variety of applications, there's no way
> to engineer them to always "do the right thing" regardless of application.
>
>
>
>
> 
>
> -- 
>
> Marcus Leech
>
> Principal Investigator
>
> Shirleys Bay Radio Astronomy Consortium
>
> http://www.sbrac.org
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FSK performance as a function of Fd?

[Matt Ettus]

On Sun, Dec 16, 2012 at 2:27 PM, Joanna Rutkowska <
joa...@invisiblethingslab.com> wrote:

>
> This is an FSK receiver from Atmel. Even though it apparently supports
> only data rates between 1-20 kbps, its supported Fd is within a range of
> 18kHz-50kHz. This seems to contradict "your" theory above -- why would
> Atmel use such a wide bandwith if they could just use no more than 20kHz
> for 20kbps?
>


Joanna,


Increasing deviation beyond the deviation of MSK (i.e. the minimum) does
not help performance, but it can help ease receiver design.

The reason to use a very high deviation at a low data rate is to make it
easier to deal with frequency error with low cost crystals.  If you have
low cost 50ppm crystals on both ends, you could have 100 ppm total error.
 100 ppm at 450 MHz is 45kHz.  Spreading the 2 tones further apart allows
you to guarantee that one will always have positive deviation and the other
will have negative deviation.

The FSK demodulation method with 2 filters is almost never used.  This chip
likely uses either direct frequency measurement (derivative of phase) or a
PLL.

Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to switch off the Automatic Digital-Gain-Control?

[Matt Ettus]

Which daughterboard are you using?

Matt


On Mon, Nov 26, 2012 at 3:48 AM, Andis Dembovskis <
andis.dembovs...@gmail.com> wrote:

> Hello, dear Developer-Team,
> I recently came across to situation, when I have to model 2 overlapping
> signals within the same frequency but different power levels. I wanted to
> use variable IQ-envelope size for that - one signal with level of 0.2 and
> another with 0.6. The max sum of 0.8 would be still fitting the allowed DAC
> amplitude of my USRP_N210.
> BUT there seems to be some Automatic Gain Control for the digital signal.
> Independent if I set amplitude of my digital signal to 0.2 or 0.6, the
> measured output in DB is the same.
> How is it possible to switch that function off?
> With the "self.uhd_usrp_sink_0.set_gain(5, 0)" I can do only the analog
> output gain control.
>
> Hope somebody have the solution,
> With best regards,
> Andis
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Hackfest and Twitter

[Matt Ettus]

We're also posting videos of some of our talks on the Ettus Research
Youtube Channel.  The first one is Tom Rondeau's talk about Control Port,
which is a very exciting new development.

  http://www.youtube.com/user/ettusresearch

Matt


On Tue, Nov 27, 2012 at 10:59 PM, Matt Ettus  wrote:

>
> I just wanted to let everyone know that we're in the middle of the largest
> GNU Radio Hackfest we've ever had.  We've pretty much got the whole GNU
> Radio core team here at Ettus Research in CA for the week.  The 15 of us
> have already made a lot of great progress, and we'll be posting more about
> all the great work happening.
>
> If you want to follow along, I'll be tweeting about it all week, so follow
> @MattEttus.  We're all using the #grhack hashtag so you can get updates
> from the other folks as well.  As always, you can join us on the #gnuradio
> channel on IRC  if you want to transmit and not just receive :)
>
> Matt
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Hackfest and Twitter

[Matt Ettus]

I just wanted to let everyone know that we're in the middle of the largest
GNU Radio Hackfest we've ever had.  We've pretty much got the whole GNU
Radio core team here at Ettus Research in CA for the week.  The 15 of us
have already made a lot of great progress, and we'll be posting more about
all the great work happening.

If you want to follow along, I'll be tweeting about it all week, so follow
@MattEttus.  We're all using the #grhack hashtag so you can get updates
from the other folks as well.  As always, you can join us on the #gnuradio
channel on IRC  if you want to transmit and not just receive :)

Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Community Manager

[Matt Ettus]

Martin,

I would really like to thank you for taking on this role.  I look
forward to working with you to expand and strengthen our community!

Matt

On Sun, Nov 4, 2012 at 8:12 AM, Tom Rondeau  wrote:
> Hi everyone,
>
> I just wanted to announce that we have created a new position in the
> GNU Radio project. Martin Braun will be taking up the role of
> Community Manager. I have posted more about this at my blog here:
>
> http://www.trondeau.com/home/2012/10/31/community-manager.html
>
> As noted in the post, Martin has been a huge help to us over the past
> number of years in this way, so we are largely formalizing his
> participation/
>
> Thanks again, Martin!
>
> Tom
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help on choice of daughter board for 40-50MHz experiments

[Matt Ettus]

On Mon, Oct 8, 2012 at 11:54 AM, Baidoo-Williams, Henry E
 wrote:
> We are looking for a daughterboard to run experiments within the range of
> 40-50MHz. We have used the basic Tx and basic Rx before but just for routing
> signals to an oscilloscope probe. Has anyone got any experience with actual
> transmission and receiving with the basic TX/RX boards? We have not tested
> yet because we are yet to purchase LF antennae. Any experience with these
> will be of much help.


You can use the Basic RX and TX for those frequencies.  You will
probably want to put filters between the antenna and the boards for
your specific frequencies of interest.

Matt

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Does USRP ADC have internal noise (out-of-band) dither?

[Matt Ettus]

The ADS62P4x does not have internal dither.  In many RF systems there
is enough gain that natural noise is strong enough to give enough
dither.

Matt

On Mon, Oct 1, 2012 at 10:14 PM, LD Zhang  wrote:
> Dear Group,
>
> I need to clarify a very basic feature of the USRP ADC. The question is:
> Does the ADC have internal noise dither when sampling? I looked at the TI
> ADS62P45 data sheet but did not find explicit mention of the noise dither.
> On the other hand, if you read those app notes from Analog Device Walt
> Kester, the noise dither is such a prominent feature that it is almost
> essential to have it in the A-to-D process. From the spectrum I gathered so
> far, I cannot tell. I would think TI should be good on this basic point.
> Could someone clarify?
>
> Many Thanks,
>
> LD Zhang
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 8-channel receiver

[Matt Ettus]

You can use a gigabit ethernet switch and put all the USRPs on there.
You should be able to make USRPs send data to each other.  You will of
course need to do work to get your algorithms into the FPGA.

Matt

On Wed, Sep 26, 2012 at 12:38 PM, Anisha Gorur  wrote:
> I have a quick theoretical question. Is there any way to construct an
> 8-channel receiver using 4 USRPS without data going through the host
> computer? Basically some kind of way to daisy chain mimo cables (though I
> know this is not possible), or at least get the same benefits you would
> receive from daisy chaining mimo cables, without using a switch or network
> connections.
>
> Thank you,
> Anisha
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] XCVR2450 Gain Calculations: AD8132 Low Cost High Speed Differential Amplifier

[Matt Ettus]

The AD8132 is configured for G=1

On Tue, Aug 21, 2012 at 4:57 AM, Michael Hill  wrote:

> Hi All,
>
> I'm looking at the parts of the XCVR2450 trying to do theoretical gain /
> noise calcs.
> My first question is... has anyone else done these? Do my numbers seem
> reasonable?
>
> Secondly.. I don't know what gain the AD8132 has.. it seems to offer G
> =1,2,5,10 according to page 15...
> Should I be assuming the Gain is maxed out to 10?
>
>
> http://www.analog.com/en/specialty-amplifiers/differential-amplifiers/ad8132/products/product.html
>
> Thanks,
>
>
> -Michael
>
>
> http://en.wikipedia.org/wiki/Friis_formulas_for_noise
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>  2.45 GHz   Gain (dB) Gain Noise Figure (dB) Noise Factor
>  Wire   -1 0.794328235 1 1.258925412   F1
> 1.258925412c Switch   -0.75 0.841395142 0.75 1.188502227   (F2-1)/G1
>   0.237310244b Diplexer   -0.7 0.851138038 0.7 1.174897555
> (F3-1)/(G1*G2) 0.261687958a Band Pass Filter -2.2 0.602559586 2.2
> 1.659586907   (F4-1)/(G1*G2*G3)   1.1595034i Maxim2829 30 1000 0 1
> (F5-1)/(G1*G2*G3*G4)   0j AD8132 10   1001   (F5-1)/(G1*G2*G3*G4)
>   2.917427014   Total   F
> 5.834854028  7.660299957 dB
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>  5.4 GHz   Gain (dB) Gain Noise Figure (dB) Noise Factor
>  Wire   -1 0.794328235 1 1.258925412   F1
> 1.258925412c Switch   -0.9 0.812830516 0.9 1.230268771   (F2-1)/G1
> 0.289891207b Diplexer   -1.6 0.691830971 1.6 1.445439771
> (F3-1)/(G1*G2) 0.68990452i Maxim2829 30 1000 0 1
> (F4-1)/(G1*G2*G3)   0j AD8132 10   1001   (F5-1)/(G1*G2*G3*G4)
> 2.238721139  Total
>   F 4.477442277  6.510299957 dB
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] WBX upper range limit

[Matt Ettus]

The daughterboard code does some limit checking, so you would want to
disable that in uhd/host/lib/usrp/dboard/db_wbx_versionX.cpp (where X
is the version of the board you have).

Some boards will tune further than 2.2 GHz, but it will vary.  80 MHz
might be a bit far for it, but you can try.  Remember also that you
get another 20 MHz from the baseband tuning, so you only need to tune
the LO to about 20 MHz lower than your highest frequency.  You might
only need to get to 2267.5 MHz.

Matt

On Sat, Aug 25, 2012 at 1:17 PM, Ed Criscuolo
 wrote:
> I have an application that requires transmitting at 2287.5 MHz.
>
> Can the GR3.6.1/UHD/USRP2/WBX combination tune to that freq?
> I know it's above the published range for the WBX (2200 Mhz)
> but these ranges are often rounded.
>
> Assuming the WBX will/can get there (Matt?),  is there any
> limit checking in the daughtercard driver sw that hard limits
> the WBX to 2200 MHz?
>
> TIA.
>
> @(^.^)@  Ed
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-announce] Announcing the LiveUSB SDR Environment

[Matt Ettus]

Yes, the link is on the order page.

Matt

On Tue, Jun 19, 2012 at 8:55 PM, S'dir  wrote:
> Hi Matt,
>
> Would like to know if there is an iso image file which we can write to
> CD/USB.
>
> Thanks & Regds,
> Sudhir.
>
> On Tue, Jun 19, 2012 at 2:27 AM, Matt Ettus  wrote:
>>
>> Ettus Research has released the LiveUSB SDR Environment - a 16 GB
>> bootable USB 3.0 drive, which comes pre-installed with Ubuntu 11.10,
>> UHD (USRP Hardware Driver), GNU Radio, OpenBTS, and associated
>> documentation. The SDR Environment enables users to get up and running
>> with the USRP product family quickly and easily, and lets users
>> familiarize themselves with the included software before installing it
>> on their own.   Additionally, the portability of the LiveUSB file
>> system can be used to deploy standard configurations in classrooms,
>> R&D labs, or other USRP installations.
>>
>>      https://www.ettus.com/product/details/LiveUSB
>>
>> Features:
>> * Ubuntu 11.10, 64-bit
>> * Pre-installed Software: USRP Hardware Driver (UHD), GNU Radio, OpenBTS
>> * Documentation Included on Drive
>> * 16 GB
>> * USB 3.0 Read/Write Speeds - fast boot times and RF record/playback
>> capability
>> * USB 2.0 Fallback
>> * Persistent File system - save files, configurations, and other
>> customizations
>> * Portability - take your projects with you and boot on any PC
>>
>> The LiveUSB includes the most recent release of UHD, GNU Radio, and
>> OpenBTS.  UHD is compatible with all USRP devices, and allows
>> applications to be easily ported across different USRP models.  The
>> UHD installation includes documentation and examples.  GNU Radio is an
>> easy-to-use, open-source, DSP toolbox that comes with GNU Radio
>> Companion, a graphical development tool.  OpenBTS is an open-source
>> GSM air-interface implementation, which can be used with the USRP
>> product family to assemble a fully functional cellular base station.
>>
>> The LiveUSB Ubuntu OS is pre-configured to install UHD and GNU Radio
>> from the Ettus Research 'apt' repositories.  This allows users to
>> update the software without manually downloading, building, and
>> installing the source code.
>>
>> This drive is compatible with USB 2.0 ports, but the system will take
>> longer to boot, load programs, and respond to user interaction.
>>
>> Now, developing with the USRP product family is as easy as plugging in
>> the LiveUSB SDR Environment and booting up!
>>
>> You can buy a USB 3 Flash Drive with the environment on it here:
>>
>>    https://www.ettus.com/product/details/LiveUSB
>>
>> Matt Ettus
>>
>> ___
>> USRP-announce mailing list
>> usrp-annou...@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-announce_lists.ettus.com
>
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Announcing the LiveUSB SDR Environment

[Matt Ettus]

Ettus Research has released the LiveUSB SDR Environment - a 16 GB
bootable USB 3.0 drive, which comes pre-installed with Ubuntu 11.10,
UHD (USRP Hardware Driver), GNU Radio, OpenBTS, and associated
documentation. The SDR Environment enables users to get up and running
with the USRP product family quickly and easily, and lets users
familiarize themselves with the included software before installing it
on their own.   Additionally, the portability of the LiveUSB file
system can be used to deploy standard configurations in classrooms,
R&D labs, or other USRP installations.

Features:
* Ubuntu 11.10, 64-bit
* Pre-installed Software: USRP Hardware Driver (UHD), GNU Radio, OpenBTS
* Documentation Included on Drive
* 16 GB
* USB 3.0 Read/Write Speeds - fast boot times and RF record/playback capability
* USB 2.0 Fallback
* Persistent File system - save files, configurations, and other customizations
* Portability - take your projects with you and boot on any PC

The LiveUSB includes the most recent release of UHD, GNU Radio, and
OpenBTS.  UHD is compatible with all USRP devices, and allows
applications to be easily ported across different USRP models.  The
UHD installation includes documentation and examples.  GNU Radio is an
easy-to-use, open-source, DSP toolbox that comes with GNU Radio
Companion, a graphical development tool.  OpenBTS is an open-source
GSM air-interface implementation, which can be used with the USRP
product family to assemble a fully functional cellular base station.

The LiveUSB Ubuntu OS is pre-configured to install UHD and GNU Radio
from the Ettus Research 'apt' repositories.  This allows users to
update the software without manually downloading, building, and
installing the source code.

This drive is compatible with USB 2.0 ports, but the system will take
longer to boot, load programs, and respond to user interaction.

Now, developing with the USRP product family is as easy as plugging in
the LiveUSB SDR Environment and booting up!


Matt Ettus

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP1 XCV2450 LO - can it be bypassed with the motherboard's LO

[Matt Ettus]

Each XCVR2450 is already locked to the motherboard crystal.  But "bypass it
with the motherboard's
X-TAL source" does not make sense.  The LO is generated by locking to the
motherboard crystal source.  No bypassing is necessary.

Matt

On Fri, Jun 8, 2012 at 2:12 PM, Nick Iliev  wrote:

> Hello,
>
>  we have a USRP1 with 2 XCVR2450 daughtercards. Each XCVR2450 has its
> own LO however , we would like to bypass it with the motherboard's
> X-TAL source.
> Both XCVR2450 daughtercards will then be driven synchronously by the
> motherboard.
>
> Is this possible ?   If so, is there a schematic of the XCVR2450 and
> motherboard which will show the required jumpers and/or SMTs ?
>
> If not, which USRP (2 ? ) and daughtercards do we  need ?
>
> Thank you,
> Nick and Han
> UIC wireless lab
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Programming FPGA

[Matt Ettus]

The Verilog code is all available and it is in the UHD git repository.  I
would suggest you start there.

Matt

On Fri, Jun 1, 2012 at 10:34 AM, sibar002  wrote:

>
> Hello
>
> I am currently working on the USRP N210. I am trying to modify the VHDL
> code
> for the FPGA in order to gain acccess to some of the unused pins. I am
> unsure of how to do this, and I was wondering if anyone had any advice on
> how to do this. I would greatly appreciate any help. Thank you.
>
> Sam
> --
> View this message in context:
> http://old.nabble.com/Programming-FPGA-tp33946275p33946275.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] SSDT question

[Matt Ettus]

On Fri, May 4, 2012 at 5:52 PM, frankist wrote:

>
> Hi,
>
> This question isn't necessarily about GNU Radio but about SDR in general.
>
> I am studying spectrum sensing algorithms and I was reading about
> simultaneous sensing and data transmission or SSDT for out-band sensing. It
> means that a radio is capable of transmitting data in one channel and
> sensing at another different channel.
>
> However, using a USRP2, I can only select one center frequency at a time.
> Considering I am applying sensing to signals which have a bandwidth of
> 6MHz,
> in order to transmit/receive data in one channel and sense other
> (different)
> channels at the same time I need crazy sampling rates that GNU Radio can't
> support. A 25 MS/s isn't enough to make a scan for all the ISM Band as I
> wanted.
>


You can tune the RX to one frequency and the TX to a different frequency.
 This is supported with all motherboards and all daughterboards except the
XCVR2450.


>
> So there are several answers for my problem:
> 1. SSDT implies additional hardware making a single USRP2 simply not enough
> 2. There is a way to tune different channel frequencies at the same time
> without any need to increase the sampling rate or use more than one USRP2
>

Yes.  Just tune your TX and RX frequencies separately.

Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Full Duplex with RFX2200

[Matt Ettus]

You are probably ok, but you might also want to use bandpass filters to
keep the excess TX power out of the RX.

Matt

On Wed, Jan 4, 2012 at 2:59 PM, Ed Criscuolo wrote:

> I'm working on an application that will do full-duplex using an RFX2200
> daughterboard in a USRP1.
>
> The transmit frequency will be about 2.055 GHz, and the receive freq
> will be about 2.255 GHz.
>
> Up until now, we've been working with only the transmit or the receive
> flowgraph separately.  Now we're about to integrate the two and I have
> concerns.
>
> In the lab, the transmit and receive sides will be hooked to separate
> antennas.  I am aware that the input to the receiver should not exceed
> -10dBm in order to avoid damaging it.  I'm concerned that the transmit
> antenna will be a short distance away, blasting out 100mW (+20dBm).
>
> Am I right to be concerned?  By my rough back-of-the-napkin
> calculations,  with 3dB antennas, and about 1 1/2 meters separation,
> I should be between -20 dBm and -10 dBm at the receiver.
>
>
> @(^.^)@  Ed
>
> __**_
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Sampling with TVRX daughterboard and Nyquist frequency

[Matt Ettus]

On Tue, Dec 13, 2011 at 8:44 AM, Cyril Cavel  wrote:

> Hi all,
>
> I use a TVRX daughterboard to acquire VHF signals. I believe (but I may be
> mistaken) that the TVRX daughterboard downconverts RF signals to a baseband
> of 6MHz bandwidth before going to the ADC. The function usrp_rx_cfile
> (which I use to acquire signals) has a minimum decimation factor of 8 for a
> sampling rate of 64Ms/s. So it gives a maximum sampling rate of 8MHz.
>

> Nyquist theorem tells us that to acquire properly a signal occupying a
> band between 0 and 6MHz, the sampling rate shall be at least 12MHz, which
> is then unreachable by the TVRX daughterboard.
>
> So, are my figures wrong, or am I missing something ?
>

Nyquist says that you need 2 samples per second for every 1 Hz of bandwidth
you want to sample.  However, we use complex (I and Q) samples, which count
double.  So if you want to sample 6 MHz of BW, you would need 6 MS/s
complex or 12 MS/s real.  You are best off oversampling by about 25%, so
the 8 MS/s complex of a USRP1 or B100 device can give you the full
bandwidth.

Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Interference-alignment and Coordinated multi-point on USRP

[Matt Ettus]

Per,

This is great work!  Interference alignment is a very hot topic these days.
 Thank you for pointing it out to us, and even more so for releasing your
code.

Matt


On Wed, Nov 16, 2011 at 4:19 AM, Per Zetterberg  wrote:

> Hi List,
>
> I have implemented Interference-alignment and coordinated multi-point on
> USRP2/N210. See http://arxiv.org/abs/.3616v1 if you are interested.
>
> I am planning to release my code on CGRAN ones I get it some time to
> tidy it up a bit.
>
> BR/
> Per
>
> How do I edit:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/AcademicPapers
> these days ?
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Re : Re : spurious sidelobes with WBX

[Matt Ettus]

Everything except for the USRP1 has dual halfbands for both TX and RX,
including the B100.  One of the big advantages of the B100 over the USRP1 is
that it uses nearly all the same FPGA code as the USRP2, N2x0, and E1x0, so
they all support the same DSP features.

USRP1 has a smaller FPGA from a different manufacturer which uses a separate
code base.  It only has 1 RX halfband and no TX halfband.

Matt

On Tue, Oct 25, 2011 at 1:52 AM, Mathias Coinchon wrote:

> Dear Matt,
>
> I come back on your answer about halfband filter for TX.
> Which USRP models do have now halfband filters for TX ? Does the new B100
> has it ?
>
> Thank you
>
> Best regards
>
> Mathias
>
> ------
> *De :* Matt Ettus 
> *À :* Mathias Coinchon 
> *Envoyé le :* Mercredi 4 Août 2010 15h55
> *Objet :* Re: Re : [Discuss-gnuradio] spurious sidelobes with WBX
>
>
> On the USRP1, the TX only has CIC filters, not halfband.  CIC filters
> have some rolloff (which you see), and they do not perfectly remove the
> aliases.  You can significantly reduce this effect by interpolating the
> signal more in the host and correspondingly less in the USRP.  This will
> move the passbands further out and reduce the amplitude of those sidelobes.
>
> The USRP2 does not have this problem, since it has halfband filters.  As
> long as you use an interpolation rate that is a multiple of 2 you will
> get their benefit.
>
> Matt
>
>
>
> On 08/04/2010 05:51 AM, Mathias Coinchon wrote:
> > Hi,
> >
> > Thank you for your answer. However I am not sure to understand how you
> > changed your ant-alias filter because this is something that is
> > implemented in the USRP FPGA isn't it ?
> >
> > As I said when monitoring the baseband IQ signal produced by the
> > modulator beofre going to USRP, I don't see these sidelobes, they only
> > appear after USRP.
> > Is it some rounding problem ? and where does this aliasing come from as
> > the signal is centered on 0Hz with no further energy after +/- 750Hz. A
> > sampling frequency of 3.2MHz (complex) should be enough. I can try use a
> > lower interpolation and so use 4MHz instead of 3.2MHz.
> >
> >
> > Best regards
> >
> > Mathias
> >
> >
> > 
> > *De :* Charles Brain 
> > *À :* Mathias Coinchon 
> > *Cc :* gnuradio 
> > *Envoyé le :* Mer 4 août 2010, 8h 32min 40s
> > *Objet :* Re: [Discuss-gnuradio] spurious sidelobes with WBX
> >
> > On 03/08/2010 21:50, Mathias Coinchon wrote:
> >> Hello,
> >>
> >> I am using the USRP1 + WBX to create a DAB OFDM signal (1.5MHz
> bandwidth) in VHF
> >> band.
> >> The sampling rate used is 3.2MHz (interpolation 40)
> >>
> >> However, there's something I don't understand. On the picture attached,
> you can
> >> see 2 spurious sidelobs that appear at about 2.5MHz from the center (red
> arrow).
> >>
> >> They are not present when monitoring the spectrum of the baseband IQ
> signal
> >> before going to USRP.
> >>
> >> They also don't appear when sending a tone signal.
> >>
> >> Is there any explanation for this ? and any hint to avoid or reduce it ?
> >>
> >> Thank you for your help.
> >>
> >> Mathias Coinchon
> >> opendigitalradio.org
> >>
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> > It looks a bit like this doesn't it.
> > http://tinyurl.com/2vhge7j
> > These ears on my DVB-T signal were caused by aliasing.
> > when I changed my anti-alias filter they went away
> >
> > - Charles
> > *
> > *
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DAC I/Q swap and bit inversion

[Matt Ettus]

On Wed, Oct 12, 2011 at 4:12 PM, Ian Buckley  wrote:

> (Matt, this just occurred to me, you should be 2's comping the bus here,
> not simply inverting it, you've introduced an LSB DC offset).


An optimization -- the 1 LSB offset is swamped by real offset in the
hardware, so we just take it out as part of normal DC offset calibration.

Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] New webpage look

[Matt Ettus]

Thanks for doing this.  The new site looks great!

Matt

On Mon, Oct 10, 2011 at 12:58 AM, Martin Braun  wrote:

> On Sun, Oct 09, 2011 at 12:38:44PM -0400, Tom Rondeau wrote:
> > [Website]
> >
> > As always, feedback and constructive criticism are welcome!
>
> Also, it would be great if you, dear reader of this list, could have
> a look if you have any content which could be linked to from the
> website. In particular, do you have
> * any kind of tutorials, or
> * any code which is not on CGRAN, or
> * pre-recorded sample data?
>
> The start page of the gnuradio.org was re-structured in a manner that
> all important stuff can be found straight away, with more specialised
> info available through another layer of clicking (e.g. details of the
> USRP1).
> It would be cool if your stuff could be reachable through the web site
> as well. So, if you're hosting anything interesting on your website,
> please add a link in the appropriate section of our wiki.
> Thanks for contributing!
>
> Martin
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Martin Braun
> Research Associate
>
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe
>
> Phone: +49 721 608-43790
> Fax: +49 721 608-46071
> www.cel.kit.edu
>
> KIT -- University of the State of Baden-Württemberg and
> National Laboratory of the Helmholtz Association
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] New Product Announcements from Ettus Research

[Matt Ettus]

On Tue, Oct 4, 2011 at 6:25 PM, Jeffrey Gregory  wrote:

> The B100 looks appealing for an upgrade from my USRP1, but I have some
> questions.  Since the B100 can accept 10MHz and PPS reference, is it
> compatible with the GPSDO module?



It can accept 10 MHz and PPS from a GPSDO, but it doesn't have a serial port
for position and time info.  You will also need to mount it externally.  So
yes, you can use them together, but with some limitations.



>  Also, the Spartan 3A-1400 looks to
> be roughly twice as big as the cyclone FPGA on the USRP1, is that
> correct?  The two main limitations of the USRP1 for me are the clock
> stability (minor) and the the FPGA size (more significant).
>

The S3A-1400 has twice as many logic cells.  An even bigger difference is
that it has 32 hard multiply units, while the cyclone had to use a lot of
general logic resources in order to do multiplies.  So the capability is
more like 3x.

The B100 will have much better clock stability (~2.5ppm over temperature)
even without the GPSDO.

Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] N210 non-uhd?

[Matt Ettus]

No, it won't work.  I would strongly suggest you switch to UHD.  If that
isn't possible, we have some USRP2s which we can sell you.

Matt


On Fri, Oct 7, 2011 at 10:50 AM, Brett L. Trotter wrote:

> Can I burn the USRP2 non-UHD firmware on an N210?
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] New Product Announcements from Ettus Research

[Matt Ettus]

On Mon, Oct 3, 2011 at 2:34 PM, Richard Clarke  wrote:

> Hi Matt,
>
> just wondering what the PPM spec is of the onboard TCXO? Will the datasheet
> be available soon?
>
>
2.5 ppm.  Datasheet may not be ready for a week or two.

Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] New Product Announcements from Ettus Research

[Matt Ettus]

=

New Product Announcements from Ettus Research

=

We are very excited to announce the immediate availability of the
latest low cost Software Radio product from Ettus Research, the
USRP(tm) B100.  The B100 has the following features:

- USB 2.0 interface
- Xilinx Spartan 3A-1400 FPGA
- Compatibility with our entire daughterboard family
- Fully supported by UHD drivers
- Dual 64 MS/s 12-bit ADCs
- Dual 128 MS/s 14-bit DACs
- Onboard TCXO for precise frequency control
- 10 MHz and 1 PPS inputs for external references
- Flexible clocking from 10 MHz to 64 MHz
- 8 MHz of RF bandwidth with 16 bit samples
- 16 MHz of RF bandwidth with 8 bit samples


The price is $650 each, and the B100 is in stock and ready to ship.

=

The USRP E110 has a larger FPGA (Spartan 3A-DSP 3400) than
the E100, but is otherwise the same.  This is perfect for those who
wish to offload DSP operations from the main ARM processor.

Both the E100 and E110 are now fully compatible with the GPSDO.

The price of the USRP E110 is $1500 and the E100 is $1300.
Both the E100 and E110 are in stock and ready to ship.

=

As always, you can purchase all of our products through:

http://www.ettus.com/order

and you can contact sa...@ettus.com if you have any further
questions.

Thanks,
Matt Ettus
President, Ettus Research LLC
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Bandwidth of XCVR 2450 Daugtherboard

[Matt Ettus]

On Wed, Sep 28, 2011 at 5:18 AM, Konstantinos wrote:

> Hi again,
>
> I recently found out that the Bandwidths of the XCVR 2450 Daugtherboard are
> as
> follows for the RX and TX side respectively:
>
> Bandwidths (Hz):
>
>RX: 15M, 19M, 28M, 36M; (each +-0, 5, or 10%)
>TX: 24M, 36M, 48M
>
> Can someone elaborate on these values please and how to decide upon which
> one to
> use? As I can understand, this is dependent on the specific application,
> however, I am puzzled as to why they are different since these values
> correspond
> to the bandwidth allowed in the bandpass filter prior to
> transmission/reception.
>


These filters are programmable low-pass filters which operate at baseband.
 In general, you just need to set them wide enough for the signals you wish
to deal with.

Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU radio

[Matt Ettus]

USRP N210 and SBX transceiver will give you coverage of all those bands.

Matt

On Wed, Sep 21, 2011 at 9:17 AM, Andrew Rich wrote:

> Maybe I can list my aims and you can tell me if GNU and N200 can do this ?
>
> 1. Receive on 1030 MHz - BW not sure yet
> 2. Receive on 1090 MHz - BW not sure yet
> 3. Receive on 2700 - 2900 MHz - BW not sure yet
> 4. Classify signals on these bands.
> 5. Perform PPM decode - Pulse Position Decode on the 1090 MHz band
>
> Using a hardware device and GNU radio
>
> The computer would be a MAC MINI running openSUSE LINUX
>
> or
>
> MacBook PRO Laptop running LINUX
>
> with either USB or Gigabit ethernet.
>
> What would be the suggested software and hardware combinations ?
>
> Can I use the N200 as a very basic spectrum analyser and a capture device (
> I guess the capture device would be just continuous)
>
> I undestand what I want to do and I have started decoding singals on 1090
> MHz already
>
> I just want to turbo charge the process and make it as fast as my Mode S
> 1090 MHz receiver I have now, which is a 1090 MHz front end and FPGA
>
>
> - Andrew -
>
> - Original Message - From: "Marcus D. Leech" 
> To: "Andrew Rich" 
> Cc: 
> Sent: Thursday, September 22, 2011 1:47 AM
> Subject: Re: GNU radio
>
>
>  On 21/09/2011 11:34 AM, Andrew Rich wrote:
>>
>>> I was just looking at the N200
>>>
>>> Do these hardware components have sensitivity figures ?
>>>
>> That depends entirely on the daughterboard you chose.  Although most of
>> them have noise figures in the 4-5dB range at maximum gain.
>>  If you're just interested in RX in the 1090MHz range, I'd suggest the
>> DBS_RX2.  Sensitivity is dominated by noise figure.  If you need
>>  lower noise figures you'll have to put a band-specific LNA in front,
>> which is what I do for radio astronomy.
>>
>>
>>> I am interested in passive RADAR
>>>
>>> I have been using a 1090 MHz receiver and a cheap digital OSCilloscope
>>> commaned under LINUX as a capture device.
>>>
>>> I guess that is sort of what the hardware and software of an SDR does ?
>>>
>>> My system is very slow
>>>
>>>  In an SDR, nearly-all the processing is done on the host computer, so
>> you need a fastish computer.  Overall compute requirements
>>  are roughly proportional to sample_rate * complexity-per-sample.
>>
>>
>>

>>>
>>>
>>
>>
>
> __**_
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Sample fast and upload after

[Matt Ettus]

You would need to modify the FPGA to do this.  However, some other people
have done that and may have code available.  Check the email archive on the
usrp-users list.

Matt

On Tue, Sep 20, 2011 at 11:21 AM,  wrote:

> Hi all,
> Is it possible with GNURadio to sample at high speed, store the samples in
> FPGA memory, and have the PC retrieve the sample after? We need to sample at
> higher speed than the Ethernet can handle. I'm wondering if this can be done
> without a USRP FPGA code change.
>
> Ben
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dsp_rx_old.vhdl

[Matt Ettus]

That file is pretty straightforward and reads just like a block diagram.  If
you just trace it out it should be pretty obvious.  If you have specific
questions we can answer them.

Matt

On Mon, Sep 19, 2011 at 10:55 AM, Gabriel Morel
wrote:

> **
> Ok, but do you know where i can find the explanation of the dsp_core_rx?
>
> - Original Message -
>
> *From:* Matt Ettus 
> *To:* Gabriel Morel 
> *Cc:* Discuss-gnuradio@gnu.org
> *Sent:* Monday, September 19, 2011 1:29 PM
> *Subject:* Re: [Discuss-gnuradio] dsp_rx_old.vhdl
>
>
> Well, you shouldn't be using dsp_core_rx_old.v, because it is old and
> unused.  Look at dsp_core_rx.v which contains all of the dsp operations.  It
> has a CORDIC mixer, CIC filter, and dual halfband filters.
>
> Matt
>
> On Mon, Sep 19, 2011 at 9:06 AM, Gabriel Morel 
> wrote:
>
>> **
>> Where I could find the explanation of the various modules of the FPGA,
>> especially the module dsp_rx_old?
>>
>> Thx
>> Gabriel
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dsp_rx_old.vhdl

[Matt Ettus]

Well, you shouldn't be using dsp_core_rx_old.v, because it is old and
unused.  Look at dsp_core_rx.v which contains all of the dsp operations.  It
has a CORDIC mixer, CIC filter, and dual halfband filters.

Matt

On Mon, Sep 19, 2011 at 9:06 AM, Gabriel Morel wrote:

> **
> Where I could find the explanation of the various modules of the FPGA,
> especially the module dsp_rx_old?
>
> Thx
> Gabriel
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FW: LFRX Board as Audio analyzer

[Matt Ettus]

You need to turn off DC offset correction.  DC offset correction results in
a narrow spectral hole around DC.

Matt

On Tue, Sep 13, 2011 at 4:13 AM, Kanbier, J.W. <
j.w.kanb...@issc.leidenuniv.nl> wrote:

> **
>
> Hi,
>
> I am trying to do some audio analyzing with the usrp and lfrx board which
> claims to be dc-to 30mhz.
> However it seems that the frequency response form  dc to let say 100hz is
> not flat (lacks)
>
> I have set the USRP source on 0Hz..
>
> Is this just a fact or am I doing something wrong.
>
> *Jasper Kanbier
> *Unix Beheer
> BVS
>
> *ICT Shared Service Centre*
> Universiteit Leiden
> +31 71 527 6894
> ***j.w.kanb...@issc.leidenuniv.nl*** **
>
>  << OLE Object: Picture (Metafile) >>*** *
>
> *ISSC Universiteit Leiden
> *Niels Bohrweg 1
> 2333 CA Leiden
> *www.issc.leidenuniv.nl*
>
> *Helpdesk*
> +31 71 527 
> *helpd...@issc.leidenuniv.nl* 
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Question about IF frequency to send

[Matt Ettus]

The CORDIC is only used for fine frequency correction when the LO can't tune
to the exact frequency you want.  The IF is zero.

Matt

On Wed, Aug 31, 2011 at 7:03 AM, Delgado, Christopher <
christopher.delg...@g3ti.net> wrote:

> **
>
> Hello,
>
> We’re implementing a CDMA base station wholly within the FPGA on the N210.
> I have a question regarding IF frequency.  In the dsp_core_tx module the IQ
> data is going through some interpolation and then a cordic. Is the cordic
> used to upconvert to some IF before being sent to the DAC? If so, what is
> the IF frequency into the DAC?
>
> Thank you.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Extending UHD Device Support

[Matt Ettus]

Jeffery,

The first thing to keep in mind is that everything is GPL'ed (and
specifically, *not* LGPL).  This means that if you use any UHD host code,
you must obey the GPL for EVERYTHING that links in.  This goes all the way
up to your customer's application.  This restriction already applies for GNU
Radio itself since it is also GPL'ed.

The firmware is GPL'ed.  This means that if you use any of the firmware,
your ENTIRE firmware image must obey the terms of the GPL.

The FPGA design is GPL'ed.  This means that if you use any of our Verilog,
*everything* compiled into that FPGA image must comply with the GPL.  This
would include all of your custom signal processing code, if it is in the
same FPGA.

The implementation of UHD host code is heavily oriented towards the state
machines in the firmware and FPGA, so modifying it to work with other
devices is easier if they use the same firmware and FPGA designs.  This is
fine as long as you are ok with invoking the GPL requirements on those
portions of your design.

Users of Ettus Research hardware are able to use all of this under less
restrictive terms in our alternative license.

Matt Ettus
President, Ettus Research LLC


On Wed, Aug 24, 2011 at 8:23 AM, Wilson, Jeffery (DS-1)  wrote:

> Designation: Non-SSA/Finmeccanica
>
> Hello,
>
> ** **
>
> We make several RF front-ends that we’d like to see supported in GNU Radio.
> Our initial idea is was to extend the Ettus UHD to include support for our
> devices, so that a waveform/flow graph using a UHD block could run using
> either a USRP or one of our devices with only minor modifications. Does it
> “make sense” to extend UHD for this purpose?
>
> ** **
>
> Our radios are embedded Linux systems that can communicate over USB as well
> as Ethernet. Initially I would like to use Ethernet as communication (using
> sockets). As far as I can figure a good place to start would be to follow
> the USRP2 UHD implementation and re-implement it for our system.
>
> ** **
>
> Any tips, examples or general guidance would be very much appreciated.
>
> ** **
>
> Thank you!
>
> ** **
>
> --
>
> Jeff Wilson
>
> DRS Signal Solutions, Inc.
>
> Direct: 301.944.8772
>
> ** **
>
> 3.1.1001
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] SBX Noise

[Matt Ettus]

On 08/09/2011 02:32 PM, Farrukh Aziz wrote:
> Hi,
> 
> I have been working with SBX and WBX dboards for a while now. I have
> also experienced more noise with SBX.

A number of people have reported this.  We are investigating and will
get back to you soon.  What motherboard are you seeing this with?

Matt

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Receive Sensitivity and Transmit Leakage?

[Matt Ettus]

On 08/02/2011 08:10 AM, Delgado, Christopher wrote:
> Have some questions regarding received signal levels and what seems
> like LO leakage on transmit side. We are using N210 with WBX (UHD
> driver). This issue seems to be pretty independent of carrier
> frequency.
> 
> 1) Receive sensitivity - We're cabling in a CDMA2000 carrier (1.2288
> MHz bandwidth) from a femtocell base station we have. The transmit
> power is about -80 dBm. We've done a simple test with GRC to receive
> this signal, write to a file and do PN correlations in Matlab to 
> verify the integrity of the data. With the signal level of -80 dBm
> and the rx_gain in the GRC gui set to maximum (38 dBm) the I/Q data
> seems to be about 3 bit values (about +/- 4 or 5). These values seem
> a bit low for this signal level. On other SDR receivers we use (not
> usrp) with max gain, signals over the air from base stations are
> about -90-95 dBm and toggle about 6 bits on ADC. In short, I'm
> wondering if this is expected behavior or if there is another analog
> gain setting to change on receive side.

You didn't state what frequency you are using or what decimation, but
the noise figure should be under 6 dB, and that is the only true measure
of sensitivity.

You can always add more digital gain in the fpga, but I don't think you
need that.

Are you sure you are using the correct antenna input?  Also, the
grand-daughterboard is static sensitive.  In order to check to see if
yours is working, please put a known level sine wave in from a signal
generator, and send us a screenshot of the uhd_fft display along with
the settings you used.


> 2) Transmit leakage We've set up a simple program in GRC to take the
> received IQ from the same base station and retransmit them on a
> different frequency. The receive is in the 800MHz band, and we've
> tried transmit on both 500MHz and 1GHz. Looking at the output on a
> spectrum analyzer as well as just plotting IQ in Matlab, there is
> some strong carrier leakage, in fact the carrier is dominant over
> the signal for all practical ranges of signal level at the input.
> With the input at -30 dBm and the rx_gain set to max 38 dBm the
> signal begins to finally overtake the carrier however this signal 
> level is obviously not practical. Furthermore, the gain parameter in 
> GRC's UHD: USRP Sink block seems to do nothing based on observing
> live spectrum of the transmit signal. The DC offset of the receive
> data seems to be negligible - we're writing it to a file before it
> goes out. Wondering what could be causing such strong LO leakage.


I am confused here.  Is this carrier leakage out of the transmit port,
or leakage of TX into the RX?

Matt

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] replica outband

[Matt Ettus]

On 07/28/2011 02:58 AM, Gaetano Mendola wrote:
> Hi all,
> I'm transmitting my signal with 5Mhz bandwidth with a carrier of 70Mhz,
> analyzing output spectrum I see some "replicas" outside the bandwidth
> (see attached image).
> I'm using a WBX, will the uhd::usrp::multi_usrp::set_tx_bandwidth remove those
> replicas? I don't see any filter after the I/Q modulator (ADL5386).
> 
> Is this intended ?


Those are odd harmonics, which are expected.  In any application where
you are transmitting over the air with significant power, you will need
to filter out the odd-order harmonics.

The WBX has such wide frequency coverage that it is impractical to have
enough filters to do this for the whole range.  This is why we have the
grand-daughterboard -- you can either modify the filter on there
(minicircuits has a whole range of filters to cover the band), or make a
custom filter board for your specific needs.

Matt


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Phase correction

[Matt Ettus]

On 07/27/2011 07:58 AM, Marcus D. Leech wrote:
> I'm looking into updating some of my interferometer code to work with
> newer hardware, like DBS_RX2, which will have unpredictable
>   phase offsets between LOs.
> 
> I played with the fractional interpolator a little while ago, to use for
> phase-correcting one half of the interferometer.  Is there a better
>   method to use?
> 


You don't need to do fractional interpolation.  Just phase rotation
(complex multiply).

Matt

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Removal of USRP2 support

[Matt Ettus]

On 07/19/2011 08:11 PM, Josh Blum wrote:
> 
> 
> On 07/19/2011 07:50 PM, Brenden Smith wrote:
>> Quick question: why is the removal of support for the USRP2 (et. al.) being
>> contemplated? I know its a bit older, but is there another reason?
>>
> 
> Nothing to do with age. It has a lot of problems and isnt feature
> complete. http://code.ettus.com/redmine/ettus/projects/uhd/wiki
> 
> -josh


Josh was not clear in his answer.  Support for the USRP2 is NOT going
away.  What is going away is the OLD way of supporting it.  It is being
replaced by the UHD, which supports ALL of the hardware Ettus Research
makes or has ever made.

Matt


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Max temperature for usrp2

[Matt Ettus]

If you can stand the temperature, your usrp should be fine.

Matt


Steve Mcmahon  wrote:

I have the same problem -- I'm going to be using a USRP2 outdoors in the shade 
(not direct sunlight) for around six hours in Yuma, Arizona, where the daytime 
temperatures are 100-110 degrees F now in July. Will the USRP2 be able to 
operate under these high temperatures?

Check it out:
http://www.wund.com/US/AZ/Yuma.html



--- On Thu, 6/30/11, Feng Andrew Ge  wrote:

> From: Feng Andrew Ge 
> Subject: Re: [Discuss-gnuradio] Max temperature for usrp2
> To: emat...@nd.edu, discuss-gnuradio@gnu.org
> Date: Thursday, June 30, 2011, 4:52 PM
>
> Eric,  in your 2009 experiment
> indicated below, did the USRP2 sustain the high temperature
> of 150 F?
>
> Is there anybody else who has tried to use USRP2
> continuously at a temperature above 105 F?  Your
> feedback is highly appreciated.
>
>
> Andrew
> 
>
> On Mon, Jul 13, 2009 at 1:13 PM, Eric Matlis
> wrote:
>
> >  Hi all-
> >
> >  I'm about to conduct some measurements on a
> running GE aircraft jet engine
> >  with the USRP2.  The test cell temps could
> reach 150 F.  Is that going to
> >  fry my USRP?
> >
> >  Thanks,
> >  eric
> >
>
>
>_

> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

_

Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] WBX CW transmit problem

[Matt Ettus]

On 06/30/2011 07:13 AM, Aleš Povalač wrote:
> Dear all,
> 
> I have been testing USRP2 with WBX board (#957). Using GNU Radio, I
> have created a simple CW TX system. The problem: output signal is
> oscillating when I set the TX frequencies to 900MHz band. Signal
> output (in time domain) at TX/RX connector from the FSL analyzer is in
> the attachment.
> 
> Settings:
> 868 MHz, 200 kSps, gain 15 dB
> 
> Same results with:
> ./tx_waveforms --rate 25 --freq 86800 --gain 15
> 
> The oscillation with ca. 1dB amplitude is present for almost all gain
> settings except the lowest values. I have observed the problem at
> several frequencies from 700M to 1G, sometimes with amplitude over
> 2dB.
> 
> Any ideas about the cause of this problem? Some PA instability or AGC
> loop issue?


There is DC offset in the signal.  Since you are using a 10 MHz RBW, you
are seeing both the DC offset and the desired signal beating with each
other.  If you take your spectrum analyzer out of zero-span mode and
zoom in on the signal you will see that the amplitude is constant.

Matt

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Multiplexing modulators

[Matt Ettus]

On 06/21/2011 06:28 AM, John Ackermann N8UR wrote:
> In GRC I would like to combine the outputs of several NBFM modulator
> blocks to drive a USRP sink.  The idea is to output several discrete
> channels within the USRP transmit bandwidth, e.g., three signal
> channels at -30 kHz, 0 kHz, and +30 kHz offset from the USRP tune
> frequency.
> 
> I'd appreciate suggestions on how best to accomplish this.
> 


If you are going to be doing more than 5 or so channels and the sample
rate is a multiple of the channel spacing it may be more computationally
efficient to use the synthesis filterbank.

Matt

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP1 FPGA modification problem.

[Matt Ettus]

Tiago,

It is very hard to help you.  You are basically saying "we did something
different and it doesn't work."  You haven't posted code, you're using
an old version of GNU Radio, and not using the latest drivers (UHD).
This all makes it hard to help you.

If the FPGA is asserting have_pkt_rdy, the FX2 is not setting RD and OE,
and you haven't changed the code running in theFX2, then it is likely
that your app on the host has died or closed.

Matt



On 06/14/2011 11:52 AM, Tiago Rogério Mück wrote:
> Hi,
> 
> Have anyone taken a look at this ?
> 
> We are still struggling to find a solution to this problem. Any tip
> would help a lot.
> 
> Thanks,
> Tiago
> 
> 
> Em 27 de maio de 2011 16:51, Tiago Rogério Mück  > escreveu:
> 
> Hi,
> 
> We have been working with an (old) USRP1 and doing some
> modifications in the FPGA code. After our modifications (we added an
> extra layer of DDCs to perform channel separation in the FPGA), the
> things didn't work as expected.
> 
> In some Gnuradio applications the USRP stops sending samples after
> some time. For example, usrp_fft.py runs just fine all the time, but
> usrp_rx_cfile.py and usrp_wfm_rcv.py work for some secs and then the
> USRP stops sending samples.
> 
> I added some pics of our preliminary debugging. In the figures, the
> yellow, blue and red signals refer to the have_pkt_rdy, RD and OE
> signals, respectively. After some time, the Cypress stops setting RD
> and OE signals in response to the assertion of have_pkt_rdy (first
> figure). Latter, the USB FIFO in the FPGA overflows and then
> have_pkt_rdy goes down (figure 2). So it seems the problem is not
> with our modifications in the FPGA code but with something related
> to the Cypress.
> 
> Have someone ever had a similar problem ? Any clue in how to solve
> this would help a lot. We are using Gnuradio 3.2.2.
> 
> The funny thing is that usrp_fft.py works perfectly (we double
> checked all *.py to make sure our new bitstream is always being
> loadded and our new DDCs are being properly configured).
> 
> Thanks.
> 
> Regards,
> Tiago.
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Maximum Frequency Hopping speed of the Ettus Transceiver RF frontends

[Matt Ettus]

On 06/10/2011 06:15 AM, Sergio Benco wrote:
> 
> Dear all, 
> 
>   I've read on the Ettus transceiver daughterboards datasheet that the
> PLL lock time is around 200us, which makes it suitable for some FH
> systems (eg. Bluetooth). 


Having worked on Bluetooth systems in the past, I can tell you that
200us would be marginal at best for hopping time.

I've tried to measure this time (plus any other
> possible latency between the Host and the USRP2) by timestamping a
> sequence of "set_center_freq()" calls that swaps between two different
> frequencies (2.412 GHz and 2.413 GHz) many times in a top_block run
> (using only C++, not Python).
> 
> The resulting measured time values are around 400us using a USRP2 +
> XCVR2450 and a quadcore host. 
> 
> 1) How was the 200us time value measured? 

This is the time between when the PLL starts the frequency change to
when it is finished.  It is highly variable, and affected by numerous
settings in the chip.

> 2) Is it possible to obtain a sustained hopping rate of 1/200us?  

Probably not when the hopping is initiated from the host.

> 3) If yes, how can we get that value?
> 


Initiate the hopping on the device.  This will take some FPGA work on
your part.

Matt

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Mainlining FPGA modifications

[Matt Ettus]

On 06/07/2011 04:09 PM, Alexander Chemeris wrote:
> Hi all,
> 
> On Sat, May 28, 2011 at 21:30, Alexander Chemeris
>  wrote:
>> On Sat, May 28, 2011 at 21:04, Marcus D. Leech  wrote:
 Hi all,

 I'm not sure whether to post this to GnuRadio or to USRP-users, so I
 post it here.

 We've started a project to implement a custom SDR hardware (which we
 plan to open-source later) and we want to reuse as much of USRP FPGA
 code as possible. But it will require a good deal of customization as
 well.

 So, we're looking for an advice on how to structure our relations with
 the upstream (i.e. GnuRadio/USRP) the best way. I.e. where should we
 place our code and how to ensure our code will be accepted to the
 mainline, etc?

>>> I can't answer the questions about where to best place the code in the tree,
>>> but maintaining compatibility with the
>>>  UHD wire protocol and API would really help make it easy to integrate into
>>> Gnu Radio.  Matt can comment on
>>>  UHD licensing for projects like this, I'm sure.
>>
>> To make it more clear - we intend to keep all VRT/UHD related FPGA
>> code in place and just replace/change interaction with RF part. May be
>> we'll have to slightly extend VRT/UHD code for our specific purposes,
>> but it will be minor changes.
>>
>> In other words - all our changes will be to support a new platform
>> seamlessly with existing UHD code.
> 
> Could anyone comment on this topic after all?
> Tom, Josh, Philip - I'm not sure who should I bug about this?


We are always looking for contributions to the FPGA code and will
consider including any interesting new functionality.

Matt

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio