Re: Python 3.12 - No module named 'gnuradio' or 'pmt'

[Brian Padalino]

On Tue, Feb 13, 2024 at 3:27 PM Elmore Family  wrote:

> I just installed Python 3.12 and I got the subject error when running a
> script that has been successful under 3.9.2.
>
> What is happening?
>

Check your PYTHONPATH versus where gnuradio is installed.

Brian

>

Re: RFNOC tutorial

[Brian Padalino]

On Sat, Feb 10, 2024 at 2:14 PM Chris  wrote:

> All, I am trying to offload some of my processing power onto my X310's
> FPGA. I have the environment set up but still find myself confused on how
> to build the out of tree block. I was able to add a block and I'm not sure
> what to do next?
>
>
> My design process is as follows: Matlab, get HDL code for DSP algorithms,
> and deploy it on the RFNOC?
>
> My goal is to start out with implementing an adaptive filter on the FPGA.
> When I looked in the FIR filter .v example I wasn't able to match how this
> code works with the rfnoc environment. When I add my new oot block I have
> the verilog code similar to the gain block example but not sure what else
> needs to be changed besides dropping in the verilog code into the
> newly_added_oot_block.v
>
> Is there any more documentation I can follow to make sure I am following
> the right path?
> Any pointers would be appreciated!
>

This is better asked over at the USRP users mailing list since it's USRP
and RFNoC specific:

  https://lists.ettus.com/list/usrp-users.lists.ettus.com

I've got some pointers once you're signed up and ask over there.

Brian

>

Re: status of RFNoC Fosphor and build recommendations

[Brian Padalino]

On Thu, Jul 27, 2023 at 8:40 PM Clint Scarborough <
clinton.scarboro...@gmail.com> wrote:

> I'm trying to run GNURadio with the RFNoC Fosphor block.  I first tried
> building UHD 4.4 and GNURadio 3.10 or 3.11.  I had read the Readme for
> gr-ettus that said for GR3.10 to just use gr-uhd directly.  In GNURadio
> Companion, I see most of the UHD blocks, including RFNoC blocks like
> Fosphor, but searching the available blocks for fosphor doesn't give any
> other results - though I believe I need an RFNoC Fosphor display block.
> Am I missing something?
>

This came up just the other day on the chat channel.  It's currently in
main but not in any release since it isn't well vetted.  You can see the
controller here:


https://github.com/gnuradio/gnuradio/blob/main/gr-qtgui/lib/fosphor_display_impl.cc

So it's currently in the qtgui components - so build the latest UHD (tagged
is fine) and the latest main GNU Radio to get what you need.  I've had
issues getting the GUI to be responsive when the fosphor display is going,
but I haven't spent a lot of time debugging it.

I am attaching the yml for the rfnoc_image_builder X310 build I did that
goes with the flowgraph.

Brian


fosphor.grc
Description: application/gnuradio-grc


x310_fosphor.yml
Description: application/yaml

Re: How can I split a periodic signal?

[Brian Padalino]

On Thu, Aug 25, 2022 at 1:55 PM James Wanga  wrote:

> I'm receiving a phase modulated signal representing a periodic pulsed byte
> that looks something like this:
>
>
> -|-|||--||-|||---|---|-
>
> I'm trying to understand how I might split this signal roughly halfway
> between each pulse of activity so I can save each pulse as a separate IQ
> fil, bit like this:
>
> --|-|||--||--
>
> ---|||-----
>
> --|---|--
>
> The split does not have to be precise, it only needs to avoid bisecting
> any of the pulses. Here are some things I've tried.- Creating a custom
> block on the receiver that uses a timing interval. Unfortunately, the
> pulses aren't perfectly periodic so eventually this causes the split to
> drift.
>
> - Since I also control the transmitter, I tried sending an async pmt
> message from the transmitter to the receiver, but again, since the message
> is async the timing is too unpredictable to make an accurate enough cut.
>
> - I was also wondering if there is any way to propagate a tag from a
> transmitter to a receiver if both are in the same flow graph, but I
> couldn't find any info on how to do this.
>
> Any Ideas? Thanks!
>

I was looking at a bursty signal in the ISM band that I wanted to save and
came up with the attached flowgraph.  The key is the "Burst Tagger" block
and the creation of the trigger utilizing the magnitude of the incoming
signal.  I utilize two "Threshold" blocks - one on the magnitude itself
which should rise pretty quickly, and one based on a filtered version of
the magnitude which falls slower.  Both of those are OR'd together to
create the trigger and saved with the "Tagged File Sink".

GRC and PDF screen capture both attached.

Hope this helps.

Brian


burst_saver.grc
Description: Binary data


burst_saver.pdf
Description: Adobe PDF document

Re: Problem using volk_32fc_s32fc_multiply_32fc function with vector params

[Brian Padalino]

On Mon, May 2, 2022 at 11:26 PM George Edwards 
wrote:

> Hello GNURadio Community,
>
> I am having a problem using the above function with vector parameters. If
> I use an array say:
> gr_complex my_val[240];
> volk_32fc_s32fc_multiply_32fc(my_val, my_val, scale, 240);
>
> It works! But if I change my_val to be a vector like below, it fails:
> std::vector  my_val(240);
>
> The reason I need to use a vector is that with arrays, the size must be
> known at compile time, while with vectors one can build it at runtime.
>

Get the pointer to your data in the array using the data() method:

  https://www.cplusplus.com/reference/vector/vector/data/

Brian

>

Re: Resampling radio data

[Brian Padalino]

On Wed, Feb 17, 2021 at 12:02 PM Marcus Müller  wrote:

> Hi Brian,
>
> On 17.02.21 16:55, Brian Padalino wrote:
> > On Wed, Feb 17, 2021 at 10:05 AM Marcus Müller  muel...@kit.edu>>
> > wrote:
> >
> > Oh, sorry, didn't mean to imply that! FFT interpolation might work
> well (if you can live
> > with the sinc sidelobes).
> >
> >
> > If the bandwidth is already constrained to 20MHz/23MHz, then there would
> be no sidelobes -
> > correct?
>
> What the FFT resampler does is, in the end, interpolation with 23 sincs,
> each at the
> "original" spectral position.
> These sincs' sidelobes of course extent left and right beyond the 23
> original "carriers"
> (thinking of OFDM here)!
>

Just wanted to clarify - 20 carriers are occupied, but sample rate goes out
to 23 carriers. If we assume the extent of the carriers is already at a
stopband and sufficiently bandlimited, the sinc sidelobes would never go
above the already established stopband - no extra spectral growth really -
just extension of the stopband.  Right?


>
> The question here is whether that matters: if the bandwidth of interest is
> -10 to +10 MHz,
> what do I care about what happens beyond that? The answer to that quesiton
> lies in Mark's
> application :)
>

The level of the newly created spectrum should be at the already
established stopband or below it.  Right?


>
> > I do have a question, though: Why do you go for a 4600-FFT? why not
> simply a 23 FFT?
> >
> > Larger n yields greater efficiencies, right?  Doing lots of small calls
> isn't necessarily
> > as efficient as doing less large calls, so long as you can handle the
> latency and the
> > processor can stay fed with data.  I figure ~4000 samples is a good
> compromise, but maybe
> > larger ones work out better, too.
>
> Well, quick calc, and acting as if O-notation was actually meaningful on
> hardware (see
> David's answer, he's got a point about caches: on my CPU, a 32×32 bit
> multiplication
> instruction (non-SIMD) takes about 1/400 of getting memory from random
> positions in RAM
> (cache misses), on average, IIRC.
>
> If we've got M samples to process, and we're doing N_1 or N_2=100·N_1
> length transforms,
> the complexity of the first is
>
> a = O( (M/N_1) · N_·log(N_1) ) = O( M · log(N_1) )
>
> of the second, it'd be
>
> O( (M/100/N_1) · 100·N_1 log(100·N_1) ) = O( M · log(100·N_1) )
> = O( M · log(N_1) + M log(100) )
>
> which is worse, but:
>
> >
> > For reference, here's some performance benchmarks for FFTW (randomly
> chosen processor):
> >
> >   http://www.fftw.org/speed/Pentium4-3.06GHz/ <
> http://www.fftw.org/speed/Pentium4-3.06GHz/>
> >
> > Single precision, non powers of 2, 1d transforms are some good
> benchmarks to look at for
> > something like this.  Obviously some numbers are better than others, but
> the general trend
> > seems to skew towards the mid-thousands as being a decent number to
> target for maximizing
> > throughput.
>
> Real-world data, and I fully agree, always trumps O-notation (which simply
> is a bad model
> for any real-world problem, usually).
>
> Luckily, I've had this same problem before, so... See attachment!
>
> You should be able to call it like
>
> fft_rate -l 46
>
> to set the FFT length to 46, and add a -n 10 to make the FFT do 10 threads
> (which usually
> hurts more than it helps). (Need to multiply the reported rate by the FFT
> length, it
> counts transforms, not samples.)
>
> The single-threaded 2²⁴-FFT I do runs at ca. 34.5 MS/s throughput. If I run
>
> fft_rate -l $(( 23*2*100 ))
>
> I get rougly 87.4 MS/s.
> If I run at
>
> fft_rate -l $(( 23*2 ))
>
> I get ca 92 MS/s.
>
> I'd call this a clear "meh" result!
>

Fair enough regarding the smaller FFT size.  I didn't think it would work
out this way, but it also got me scratching my head.  I wouldn't have
imagined parallelizing a bunch of FFT's would make things worse.  And then
I went to the code, and I see this:


https://github.com/gnuradio/gnuradio/blob/fa3267982aa88e3c8f886d803b57f9b1501f43f6/gr-fft/lib/fft.cc#L231

So this call is initializing fftw as an n-thread operation.  The call to
fftw is still synchronous, so we're asking fftw to parallelize the FFT and
ensure it's all coalesced by the time the call returns.  I can understand
why this would hurt FFT performance.

I then ran the program with 4 or 8 threads as an argument, and looked at
top - but only a single processor was being used.  Maybe my gnuradio wasn't
compiled with multithreading fftw enabled?

For your example program with defaults, I get a rate_avg on a single core
of 91

Re: Resampling radio data

[Brian Padalino]

On Wed, Feb 17, 2021 at 10:05 AM Marcus Müller  wrote:

> Oh, sorry, didn't mean to imply that! FFT interpolation might work well
> (if you can live
> with the sinc sidelobes).
>

If the bandwidth is already constrained to 20MHz/23MHz, then there would be
no sidelobes - correct?


>
> I do have a question, though: Why do you go for a 4600-FFT? why not simply
> a 23 FFT?
>

Larger n yields greater efficiencies, right?  Doing lots of small calls
isn't necessarily as efficient as doing less large calls, so long as you
can handle the latency and the processor can stay fed with data.  I figure
~4000 samples is a good compromise, but maybe larger ones work out better,
too.

For reference, here's some performance benchmarks for FFTW (randomly chosen
processor):

  http://www.fftw.org/speed/Pentium4-3.06GHz/

Single precision, non powers of 2, 1d transforms are some good benchmarks
to look at for something like this.  Obviously some numbers are better than
others, but the general trend seems to skew towards the mid-thousands as
being a decent number to target for maximizing throughput.

Brian

Re: Resampling radio data

[Brian Padalino]

On Wed, Feb 17, 2021 at 8:01 AM Marcus Müller  wrote:

> Rough performance estimate:
>
> for a 1/10 transition width filter (which is sufficient to keep 20 of 25
> MHz Nyquist), you
> need an expertly guesstimated [1] 24-ish taps, so go for 25 taps: that
> happens to be
> exactly the minimum filter length that we can use in an 25-interpolating
> rational
> resampler and still do the full polyphase decomposition trick to run the
> filter at the
> least rate of the system.
>
> For "1 tap per branch", I have a rough 60 MS/s for *my PC* in mind. So, My
> guess is that
> it will work for 46->50 MS/s, not for 92->100 MS/s, on *my PC*.
>
> Problem: this is an inherently badly multi-threadable workload, unless I'm
> overlooking
> something. So, having 48 cores isn't better than having 2.
>

Just curious, why do you think the FFT interpolation won't work?

So long as the block sizes are appropriately picked (how about we stick
with 4600 input size, and 5000 output size), the frequency components
should all line up and be phase aligned from block to block.  There might
be a little scaling factor that the resulting samples will be off due to
the difference in FFT length, but otherwise I think it should work.

Moreover, the FFT work can be done in parallel and utilize all the cores.

I did a quick little test and I think it should work.  Yes?

Brian

Re: Resampling radio data

[Brian Padalino]

On Tue, Feb 16, 2021 at 5:21 PM Mark Koenig <
mark.koe...@iubelttechnologies.com> wrote:

> The BWs are 20mhz, 40mhz and 80Mhz respectively.  The host can range from
> a server with 48 cores(2.6Ghz), 256GB ram to a laptop with 8 cores(3.0Ghz),
> 64GB ram.
>

Have you tried using the blocks you asked about to see what happens with
them?  Jeff Long recommended running top to see if the processing threads
for the resampling fall behind.  You can also check your memory growth to
see if that happens.

You may be able to do a cheap/dirty resampling by taking the FFT at 23MHz,
adding a few 0 bins to get it to 25MHz, then doing the IFFT.  You'll need
to do some strange FFT sizes - maybe 4600 samples at the lower rate, and
pad to 5000 samples for the higher rate.  I don't think you'll need to
filter, but I haven't gone through the exercise.  For cores like that, tho,
it should be very fast to do an FFT followed by an IFFT with some zero's
shoved into a vector, especially with so many cores.

Lastly, have you run fftw wisdom to get the fastest FFT performance?  That
might be useful as well.

Let us know how your experimentation goes.  This sounds interesting.

Brian

>

Re: Resampling radio data

[Brian Padalino]

On Tue, Feb 16, 2021 at 4:14 PM Mark Koenig <
mark.koe...@iubelttechnologies.com> wrote:

> Hello,
>
>
>
> I am receiving data from a radio at 23Msps, and I would like to resample
> to a rate of 25Msps in which my software program can ingest it.  I am aware
> of the Fractional Resampler and the Rational Resampler.  Is one better than
> other, take less CPU cycles, etc.?  Is there a different block which would
> suit my needs more efficiently?  Should I instead look to implement the
> resampling within C++ as opposed to adding another block to my flowgraph?
>
>
>
> I am going to do the above with the following rates:  46Msps -> 50Msps,
> 92Msps -> 100Msps.
>

How much of your bandwidth are you actually looking to keep intact?  How
fast is your host CPU?

Brian

>

Re: aliasing with X310 BasicRX (higher order Nyquist zone) ?

[Brian Padalino]

On Mon, Jul 20, 2020 at 11:32 AM jean-michel.fri...@femto-st.fr <
jean-michel.fri...@femto-st.fr> wrote:

> Indeed second Nyquist zone before decimation.
> My thought was
> 143.05 MHz -> transpose by 100 MHz using the DDC (NCO at 100 MHz
> considering the
> 200 MHz sampling rate) to reach 43.05, and after transposition, decimating
> to reach
> 8 MS/s (I do have Epcos B3607 SAW filters 140+/-3 MHz frontend to select
> only the
> signal I am interested in).
> It is in the decimation process that I was thinking of being in the third
> Nyquist zone after decimation, which is incorrect because 8 MS/s is -4 to
> +4, so that
> 43.05 is in the 6th Nyquist zone after decimation (\in[36:44] MHz).
>

This seems weird.

Sampling 143.05MHz at 200MHz real will produce the desired signal at
56.95MHz and conjugated, won't it?  Since it's real, it'll appear at both
positive and negative frequencies, with the negative component being
conjugated.

So if you mix with 56.95MHz, it will take the conjugated negative signal of
the conjugated desired signal and mix it to 0Hz.  Then you can go through
the decimation filtering however you want and everything is centered at 0Hz.

Right?

Brian

Re: Large baseband spikes from gr-digital OFDM transmitter

[Brian Padalino]

On Tue, Jun 23, 2020 at 10:38 AM Manav Kohli  wrote:

> Hello,
>
> This problem is visualized here:
> https://www.dropbox.com/s/w7kdmf9dewwdomx/20M_2974_20_15_nocal_packet_time_tx.png?dl=0
>
> This is an OFDM packet consisting of 6 symbols: the default sync word 1&2,
> SIG field and three data symbols. The data symbols are QPSK modulated and
> the sync words are BPSK.
>
> Is there any way that I could reduce or eliminate these large spikes that
> even with a moderate baseband scaling still go considerably above a
> magnitude of 1? I have tried to use different data, and a different number
> of packet data symbols, but to no avail. I am definitely able to reduce the
> overall baseband scaling and get those spikes within range, but this is not
> desirable as I am trying to maximize transmit power.
>
> The usage of the USRP-2974 and sampling rate is immaterial; this happens
> using a variety of different radios (should not matter as this is a GNU
> radio "issue") and sampling rates.
>
> If anyone has seen this before or may have any advice, please let me know.
>

It's the nature of OFDM to have a high Peak-to-Average-Power Radio (PAPR).
You can look at PAPR reduction techniques, but otherwise you're in for
around 10dB PAPR.

Good luck.

Brian

>

Re: GNU Radio 3.7 on Ubuntu 20.04

[Brian Padalino]

On Thu, May 14, 2020 at 4:56 PM Alex Humberstone <
alex.m.humberst...@gmail.com> wrote:

> Brian, yeah good questions. So, the computers in my lab are going to all
> be running Ubuntu 20.04 like next week, so we're forced to use that. Not
> that I mind. I like Ubuntu a lot. And I'm planning to use both GNU Radio
> 3.7 and 3.8, because I will be porting some custom blocks we wrote in GNU
> Radio 3.7 to 3.8, but I also need to keep running them in GNU Radio 3.7,
> while also porting them to GNU Radio 3.8. Maybe like after the next
> academic year we can drop GNU Radio 3.7. But not for this year. It depends
> on how well things go for porting all the blocks in our internal library
> here.
>

I've had success using LXC containers to setup different OS environments
without sacrificing performance.  Maybe check out how to get an older
Ubuntu 18.04 LXC container setup to run GNU Radio 3.7 while you port things
to 3.8.

Good luck.

Brian

>

Re: GNU Radio 3.7 on Ubuntu 20.04

[Brian Padalino]

On Thu, May 14, 2020 at 11:30 AM Alex Humberstone <
alex.m.humberst...@gmail.com> wrote:

> The new Ubuntu 20.04 does not include Python 2 anymore. But GNU Radio 3.7
> requires Python 2. So then can you run GNU Radio 3.7 on Ubuntu 20.04? I
> think there's still a package that you can instal to add Python 2 support
> in Ubuntu 20.04. I found a bunch of websites that make it sound like this
> should be possible. So I'm thinking it should still actually be possible to
> run GNU Radio 3.7 on Ubuntu 20.04. Has anyone actually tried this before?
> Does this work? Is there anything special that you have to do? Any help
> here would be super appreciated. Thanks in advance for your help everyone!
>

Just a couple clarifying questions:

  - Why do you feel you need Ubuntu 20.04 if you want to run GNU Radio 3.7?
  - Why do you need GNU Radio 3.7 instead of 3.8?

Brian

>

Re: GMSK bandwidth

[Brian Padalino]

On Wed, May 6, 2020 at 7:48 PM Artur Nogueira  wrote:

> Hello guys,
>
> I'm trying to generate a GMSK signal in accordance to the GSM
> specifications. To do so, I've been trying with both "GMSK Mod" and "GMSK
> Modulator" blocks, the last one with the following parameters:
>
> [image: image.png]
>
> To set these parameters, I considered (i) a sufficiently high base-band
> sampling rate (samples/symbol) in order to avoid aliasing; (ii) the
> well-known 0.3 BT product and (iii) a 156 bits GSM pulse, i.e. 1 time slot
> (I considered that GMSK provides 1 bit/symbol).
>
> Nevertheless, my signals have a bandwidth which is much larger than the
> 200 kHz requirement.
> What am I doing wrong?
>

I think you want something more like 3 symbols for your pulse duration.
Not 156.

Brian

>

Re: Stucked on a trivial interpolation issue

[Brian Padalino]

On Mon, Mar 23, 2020 at 1:57 PM Christophe Seguinot <
christophe.segui...@orange.fr> wrote:

> Great I was searching for this feature.
>
> Nevertheless, they are some things I don't understand in the interpolation
> bloc!!
>

Mathematically, zero stuffing is the correct interpolation mode when
dealing with spectrum.  What the repeat block does is a zero-order hold,
and distorts the spectrum.

Brian

>

Re: Stucked on a trivial interpolation issue

[Brian Padalino]

On Mon, Mar 23, 2020 at 1:26 PM Christophe Seguinot <
christophe.segui...@orange.fr> wrote:

> First answer to myself :
>
>- I should have used an empty value for parameter taps. This only
>works for Rational resampler, not for interpolation.
>
> Question:
>
>- How can I interpolate without filtering to obtain a linear
>interpolation giving
>- 1 1 1 / 1 1 1 / 1 1 1 / 1 1 1 / -1 -1 -1/ -1 -1 -1/ -1 -1 -1/
>
> Try the repeat block:

  https://wiki.gnuradio.org/index.php/Repeat

Brian

Re: SDR transceiver having independent mixer and ADC sampling clocks

[Brian Padalino]

On Wed, Feb 26, 2020 at 4:23 PM Heikki Laamanen 
wrote:

> > So you want to produce something like a stable 10MHz reference and a
> 1PPS which is synchronous to UTC using broadcast/terrestrial signals such
> as DVB-T, ATSC, LTE, etc?  And your edges can be within +/-50ns of actual
> UTC?
>
>
>
> Yes. All those signals (not sure about ATSC) are synchronized to UTC
> directly (via GPS) or indirectly (via PTP over fiber). Thus, the signals
> carry inherent timing information. There are naturally lots of issues
> related with radio wave propagation in each case like multipath propagation
> caused by reflections, groundwave/skywave phenomena concerning LF radio
> wave propagation, e.g. DCF-77 and the ancient C-Loran. The most ideal cases
> are line-of-sight wave paths like GPS satellite – GPS receiver.
>
>
>
> I have one more question. I have not found any GNU Radio object utilizing
> the possibility of controlling the ADC sampling frequency via controllable
> PLLs on the RF HW. All sync-related objects seem to use – e.g., polyphase
> filters, for adjusting sampling phase. Am I right?
>

Some radios use a DAC to control a VCTCXO with a pullability of
maybe +/-10ppm.  Others use an analog PLL to lock to an externally supplied
reference (like 10MHz or so).

Most would probably want to keep jitter to a minimum and track the sampling
offset digitally.  You may want to look into what it might take to do that
instead of expecting a clock to be perfect.

Brian

Re: SDR transceiver having independent mixer and ADC sampling clocks

[Brian Padalino]

On Tue, Feb 25, 2020 at 2:00 PM Heikki Laamanen 
wrote:

> Thanks Brian. You are right, there exists three VCOs and PLLs in the
> AD9361 which can be controlled independently.
>
>
>
> AD9361 Reference Manual UG-570 shows a more detailed diagram in Figure 7.
> on page 20. The baseband PLL comprises an N/N+1 divider controlled by a
> high-precision sigma-delta modulator. AD9361 Register Map Reference Manual
> UG-671 describes that the control word of the sigma-delta modulator
> consists of 29 bits giving a relative frequency resolution of 1.9 ppb
> (parts per billion).
>
>
>
> A brief description of the timing system.  The objective is a system for
> protecting or replacing GPS-based timing. In addition to navigation, the
> GPS system is used for generating an accurate clock which is in synchronism
> with the Coordinated Universal Time (UTC). A clock synchronized with the
> UTC, can be for example a 1 Hz physical clock signal whose rising edge goes
> up exactly at the start of an UTC second. The accuracy of an GPS-based
> timing system is about +-50 ns. Thus, we can say that the phase accuracy of
> GPS-based timing is about 50 ns.  The objective is to generate such clock
> by receiving a broadcast radio signal which is known to be in synchronism
> with the UTC.
>
>
>
> You mentioned that time is completely relative. If we think of the UTC, we
> could say that it gives an absolute time which is defined by several atomic
> clocks around the globe. A copy of the UTC can be generated, with a certain
> accuracy, by receiving the GPS or other similar satellite signal (Galileo,
> Glonass, Beidou) and synchronizing to it.
>

So you want to produce something like a stable 10MHz reference and  a 1PPS
which is synchronous to UTC using broadcast/terrestrial signals such as
DVB-T, ATSC, LTE, etc?  And your edges can be within +/-50ns of actual UTC?

I guess I'm still unsure if you do or do not believe the radios out there
allow for this to happen?  I'm not sure where you believe you have a
limitation.

Brian

Re: SDR transceiver having independent mixer and ADC sampling clocks

[Brian Padalino]

On Mon, Feb 24, 2020 at 10:39 AM Heikki Laamanen 
wrote:

> Hi experts in SDR RF transceivers,
>
>
>
> I am working on a timing and synchronization system which generates a
> high-precision timing signal from a terrestrial broadcast signal.  I am
> looking for a suitable SDR HW-board providing independent clocks for the RF
> mixers and the ADC.
>
>
>
> It seems that many SDR boards use transceiver chips having mixer and ADC
> clocks which are derived from a single clock. Thus, it is not feasible to
> control the ADC sampling clock frequency without affecting the mixer
> frequency. For example, some USRP products have Analog Devices AD9361
> transceiver chips providing no option to have fully independent mixer and
> ADC clocks.
>

Is this assertion true?  According to this document:


https://ez.analog.com/wide-band-rf-transceivers/design-support/w/documents/10064/ad936x-local-oscillator-lo

There exists 3 VCO's in the AD9361.  One for TX, one for RX, and one for
the baseband.  Why do you believe the clocks are not independent?  I agree
the sampling clock might not be able to achieve the resolution you want,
but I don't see why they are not fully independent already.


>
>
> Why would I like to have independent mixer and ADC sampling clock?
>
>
>
> The target is to generate a physical clock signal having small jitter and
> accurate phase. Hence, I need to control the frequency of some VCO based on
> the information the receiver signal processing gives. The most
> straightforward way to do this is to control the frequency of a VCO
> wherefrom the ADC sampling clock is derived.
>

You need to be more specific regarding your jitter and phase requirements.

Also remember that time is all completely relative.  Lastly, what does
accurate phase mean to you?

Brian

Re: Help : UHD

[Brian Padalino]

On Tue, Feb 11, 2020 at 11:15 AM "Till Hülder"  wrote:

>
> Hello,
>
> i want to implement a FMCW-Radar  in a frequency-chirp. First i tested the
> frequency-chirp . I send the chirp from TX to RX of my USRP.
> I get this warning :
>
> UHD Warning:
> For this connection, UHD recommends a receive frame size of at least
> 8000 for best
> performance, but your system's MTU will only allow 1472.
> This will negatively impact your maximum achievable sample rate.
>

Check how to change the MTU size on your interface to be 8000.  Google can
help with that.


>
> UU
> >>> Done
>
> My constellation- and time gui looks unlikely (see attachment) on the top
> ist TX and the bottom ist RX.
>
> Does anybody has a solution for this?
>

Add more attenuation between TX and RX and/or change the gain of your RX to
be lower.

Brian

>

Re: FBMC

[Brian Padalino]

On Sun, Feb 2, 2020 at 10:40 AM Madhan TJ 
wrote:

> CAN WE IMPLEMENT FBMC (filter bank multi carrier ) IN GNU RADIO ,
> IF YES,
> ANYONE PLEASE HELP ME
>

I believe the MarmotE team from the DARPA SC2 used FBMC in their modem that
they open sourced:

  https://marmote.io/
  https://gitlab.com/marmote/gr-marmote3

Brian

Re: Recommendation for high sample rate receiver?

[Brian Padalino]

On Sun, Jan 26, 2020 at 6:42 PM Mike  wrote:

> The device in question is to replace an existing RF-to-baseband
> component of a geographically distributed signal collection system.
> Each receiving station samples the 6 MHz passband, detects a signal and
> estimates a time-of-arrival, then sends it on to a central facility that
> performs the multilateration calculations.  The existing TOA codebase
> (and other decoders) expects 2 ns samples.
>

If there is only a 6MHz passband, then you should be able to interpolate to
500MSPS from the 6MSPS sample rate and be fine with your existing code base.

Right?

Brian

Re: Recommendation for high sample rate receiver?

[Brian Padalino]

On Sun, Jan 26, 2020 at 1:20 PM Mike  wrote:

> Hello,
>
> I am hoping someone on the list could suggest a device that receives in
> lower L-band (1.0 to 1.6 GHz) and can cover 6 MHz (+/- 3 MHz around
> center) at (and here's the trick) 500 MS/second with at least 8 bits of
> resolution.  I'm looking for 2 ns baseband samples from multiple
> receivers to perform trilateration.
>

Interesting conflicting requirements with the baseband bandwidth of 6MHz
but 500MSPS ADC.

Are you sure you don't need a much wider baseband bandwidth as well?

Brian

Re: [Discuss-gnuradio] need example Costas loop code

[Brian Padalino]

On Mon, Mar 11, 2019 at 11:35 AM Chesir, Aaron M.  wrote:

> Folks,
>
>
>
> I am going through a series of on-boarding projects using GNUradio, and
> one of the projects requires access to a copy of Python source code for an
> example of a Costas loop. Specifically, the project refers to a file “
> gr-digital/examples/examples_costas.py
> ”,
> which was developed for the GNUradio project by Rondeau Research.
> Unfortunately the link in the web page (
> http://www.trondeau.com/gr-tutorial/) that should have pointed to the
> location of the source code is a broken link.
>
>
>
> If any of you have come across the referenced source code, could you
> please email me a copy?
>

Up in the current repository at master but with an absolute link:


https://github.com/gnuradio/gnuradio/blob/a664001c80d93b15ff819cda95ce1bc1ceb70078/gr-digital/examples/example_costas.py

Clone the repo and use 'find' to get the .cc file.

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

Re: [Discuss-gnuradio] [USRP-users] continous Tx voice transmission

[Brian Padalino]

On Wed, Mar 6, 2019 at 3:12 PM Marcus Müller 
wrote:

> I've had rather longish discussions on how to solve this; essentially:
> for something that actually *solves* the issue (instead of postponing
> it), as Ian said, you'd need to have clock domain crossing ability.
>

Could message passing from the real-time blocks solve this issue in a
flexible way?

Imagine the following: blocks connected to actual hardware use the computer
wall clock to try to determine an average sample clock as it relates to the
CPU clock.  The USRP source block would be able to determine how many
samples/(sec of CPU clock) were coming in and Audio sink blocks would be
able to determine how many samples/(sec of CPU clock) were being consumed.
The same idea for Audio sources and USRP sinks.  Since the blocking calls
for USRP or Audio blocks could be wrapped in a high precision timer, once
any initial buffering had been filled up, the rate should settle out.

The modified blocks could then send a message of actual sample rate to
whoever needed to listen, and the appropriate sample rate could be figured
out in the "resampling FIFO".

What am I missing?  Why won't this work?

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

Re: [Discuss-gnuradio] BladeRF + osmosdr + gnuradio

[Brian Padalino]

On Wed, Mar 9, 2016 at 1:56 PM, M. Ranganathan  wrote:
> Hello,
>
> I am trying to get bladeRF to work as a receiver in order to decode LTE
> signals from within a gnuradio block. Here is my configuration :
>
>
> self.u =  osmosdr.source( args="numchan=" + str(1) + " " +
> "bladerf=0" )
> self.u.set_sample_rate(int(self.samp_rate))
> self.u.set_freq_corr(0, 0)
> self.u.set_dc_offset_mode(1, 0)
> self.u.set_iq_balance_mode(2, 0)
> self.u.set_gain_mode(True, 0)
> self.u.set_gain(3, 0)
> self.u.set_if_gain(15, 0)
> self.u.set_bb_gain(15, 0)
>
> It connects to the bladerf and reads values from it but there's something
> wrong with my gain settings I believe because the values I read don't make
> sense. Does somebody have experience with this configuration? Please share
> your settings.

Don't use the numchan argument.  That might be confusing things, but I
am not 100% sure.

Have you tried using the osmocom_fft GUI for getting an understanding
of the gain levels you need?

Brian

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

Re: [Discuss-gnuradio] VOLK: fast way to log10()?

[Brian Padalino]

On a side note, this is extremely impressive and I wish I knew about it sooner:

  https://software.intel.com/sites/landingpage/IntrinsicsGuide/

There's a few different log10_ps (packed single) functions in there.

Brian

On Wed, Sep 16, 2015 at 12:24 AM, Dennis Glatting  wrote:
> On Tue, 2015-09-15 at 23:35 -0400, Marcus D. Leech wrote:
>> On 09/15/2015 11:15 PM, Dennis Glatting wrote:
>> > With the VOLK library, is there a way to compute the log10() of
>> > each
>> > 32f in a buffer?
>> >
>> > That is:
>> >
>> >   for( int i = 0; i < num; ++i )
>> > buf[i] = std::log10( buf[i]);
>> >
>> > I only see log2() in the library but don't know if there is an easy
>> > way
>> > to compute log10().
>> >
>> >
>> > Thanks.
>> Define "fast".
>>
>
> Faster than the code fragment above.
>
> I see log2(), pow(), sin(), and other kernels in the library and
> /assumed/ there must be some way of log10() if only through a
> combination of kernel calls.
>
>
>> Ordinarily, one does a log10 to convert into engineering units at the
>> back of, for example, a power-measurement chain.
>>
>> There's usually no reason to do that in the middle of a flow-graph,
>> where things can stay in linear units.
>>
>
> 1) Working with VOLK to learn VOLK.
> 2) Having fun with vectors.
> 3) Generating power data points for plotting across a selected
>set of samples.
>
>
>>
>>
>> ___
>> 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] VOLK: fast way to log10()?

[Brian Padalino]

On Wed, Sep 16, 2015 at 12:24 AM, Dennis Glatting  wrote:
>
> 1) Working with VOLK to learn VOLK.
> 2) Having fun with vectors.
> 3) Generating power data points for plotting across a selected
>set of samples.

Lastly, another alternative, if you wanted to utilize what is already
there in VOLK, if you wanted to do something like 10*log10(x), you can
also think of it as 10*log2(x)/log2(10) - rewritten to put the
constants together - 10*log2(10)*log2(x), where 10*log2(10) is
3.01029995664.

So convert a vector of floats into log2 then multiply a vector by a
const that is equal to 10*log2(10) to get them to their final value.
Not as efficient, potentially, but still an option if you want to
learn VOLK.

Brian

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

Re: [Discuss-gnuradio] VOLK: fast way to log10()?

[Brian Padalino]

It sounded like a fun and interesting question, so apparently there is
a little post from 2007 about a new implementation in C licensed under
GPLv2:

  https://sourceware.org/ml/libc-alpha/2007-06/msg00124.html

It would be interesting to compare and see if the results are
beneficial even if no VOLK is involved.

Brian

On Tue, Sep 15, 2015 at 11:15 PM, Dennis Glatting  wrote:
> With the VOLK library, is there a way to compute the log10() of each
> 32f in a buffer?
>
> That is:
>
>  for( int i = 0; i < num; ++i )
>buf[i] = std::log10( buf[i]);
>
> I only see log2() in the library but don't know if there is an easy way
> to compute log10().
>
>
> Thanks.
>
>
>
>
> ___
> 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] DC-block block

[Brian Padalino]

On Fri, Mar 20, 2015 at 9:45 AM, Marcus D. Leech mle...@ripnet.com wrote:
 I'm wanting to use the DC-block block, and I have questions about its use.

 My scenario is to use it as a cheap high-pass, with a corner frequency of a
 few milli-hertz, with samples arriving at 50Hz.

 It's not clear how the length parameter relates to the desired corner
 frequency and sample rate.

I believe this is implemented as described as a linear phase DC
blocker in this paper:

  http://www.digitalsignallabs.com/dcblock.pdf

I believe the length parameter is the D parameter in the moving
average calculations.

Hopefully this helps.

Brian

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

Re: [Discuss-gnuradio] Simple Frame Detection

[Brian Padalino]

On Sun, Feb 8, 2015 at 11:01 AM, Aditya Dhananjay adi...@cs.nyu.edu wrote:
 Hello Daniel,

 Are you using OFDM? If so, read on, otherwise disregard the rest of the
 email.

This sounds much less like a problem with regards on how to figure out
the synchronization but more about how to do it inside the confines of
GNU Radio.

The original post wants to discard everything before a preamble they
detect.  Once preamble is detected, I assume a state machine down
stream will decode some information in the samples coming down which
says The length of this transmission is 12345 symbols.  At this
time, the downstream block will send a message to the upstream block -
holding off the samples until it knows how many more to send down -
and finish up.

The feedback loop cannot be realized inside the flowgraph since
everything needs to be feed forward.

This is a great example of how someone may want to do RF burst
processing which may not necessarily be real-time but due to
dead-air or guard bands might be able to catch up on the processing if
you didn't have to keep processing every last incoming sample -
especially at a higher sample rate.  Moreover, it shows how blocks
could be used to message each other to create feedback loops and
convey downstream information to upstream processing elements which
may care - things like SNR estimation, timing information, etc.

I'm very interested to see how this all ends up.

Brian

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

Re: [Discuss-gnuradio] Distorted QPSK Constellation

[Brian Padalino]

On Thu, Jan 15, 2015 at 1:41 PM, Salman Dinani salmandin...@gmail.com wrote:
 Hi to all,

 Thanks very much to all of you for your valuable suggestions.In accordance
 with your suggestions, I experimented with my designed DQPSK system and got
 few problems which I am listing down.All the referenced figures are
 attached.

 I reduced the symbol per sample to 4 (previously it was 8) and added a RRC
 filter before constellation plot (figure RRC_const) but constellation
 remains the same L

You gave 0 taps to your RRC filter?  Why would you do that?  I'm not
sure what that would do.

At one exact phase you'll get the points when your system is setup
correctly.  The other phases will get ISI.

Brian

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

Re: [Discuss-gnuradio] Distorted QPSK Constellation

[Brian Padalino]

It's a constellation plot for sure - says it right on the block in the
PNG, but it's all internally generated anyway.  There should be 1
perfect phase, then 3 out of phase points.  No noise - no
phase/frequency offset.  Timing shouldn't be an issue here even if it
were a normal plot.

I think the issue is no matched filter on the other side.  RRC
filtering won't look very appealing to the eye, but RC filtering
should match what you expect.

Try adding a matched RRC filter before you do the constellation.  You
should see the 4 samples/symbol and their trajectories as they
converge onto the 4 nice points.

Brian

On Wed, Jan 14, 2015 at 2:51 AM, Martin Braun martin.br...@ettus.com wrote:
 On 01/14/2015 04:56 AM, Salman Dinani wrote:
 Hi to all,

 I am a beginner in using GNU radio(GRC). I have made a DQPSK transmitter
 using the blocks of GNU radio (attached Figure QPSK_1). when I connected
 the constellation plot with it, It gave me the a very scattered
 Constellation Plot Instead of four Clean Constellation Dots (attached
 Figure QPSK_2). I have checked with all forms of signals but the
 constellation remains distorted.(i.e. vector source, signal source etc.)

 Is it normal plot or am I missing some thing? Kindly help.

 My guess is yes, it's a normal plot, and you have no time sync in there.

 M


 ___
 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] Odd Behavior

[Brian Padalino]

Unless your CPFSK is defined such that each bit is +/-90 degrees, then
you're right.

If you are setup to have +/-90 degree phase shifts per bit, then each
bit transition time should fall on 0, 90, 180 or 270 exactly.  No
slight phase shifts one way or the other in the transmitter.

My guess is that there is just some precision rounding happening and
after a few minutes with hundreds of thousands of phase increments,
you've just accumulated a decent amount of error.  But this is just a
guess.

Any actual system will need to track any sampling rate differences and
frequency offsets, so it's probably negligible - though it is also
worth while to try to investigate and see where the offset is coming
from.

Brian

On Mon, Dec 15, 2014 at 6:22 PM, Richard Bell richard.be...@gmail.com wrote:
 I think I want to back off this claim of odd behavior. The more I think
 about general CPFSK, the more I'm convincing myself that total accumulated
 phase will be changing, depending on the ratio of -1's to 1's. So seeing the
 real part slowly change phase should not be a worry, I think?

 Rich

 On Mon, Dec 15, 2014 at 2:21 PM, Richard Bell richard.be...@gmail.com
 wrote:

  I have an update to this behavior. It is still not fixed.

 I was using a separate multiply block after the CPFSK block to control the
 amplitude. There was no good reason for this, it's just how I set it up the
 first time.

 I decided to remove that multiply block and use the built in amplitude
 parameter to control the output gain. This has reduced the accumulating
 phase offset that creeps into the CPFSK output, but not completely.
 Overtime, the real part of the output will still begin to change phase.

 This leads me to believe there is some kind of thread timing issue that is
 allowing a phase offset to creep into the CPFSK output on the transmitter
 side. I'm including a screenshot of my transmitter. Not much going on here.
 I am also including a screenshot of the real and imaginary time series when
 the program first starts and after a few minutes of run time.

 Rich

 On Mon, Dec 15, 2014 at 10:28 AM, Richard Bell richard.be...@gmail.com
 wrote:

 Problem: Real and Imaginary outputs of CPFSK sometimes seem flipped in
 the transmitter.

 I'm using the CPFSK block to modulate for a binary FSK radio. All that I
 reference here is in the transmitter. There are 3 input paramaters for the
 block: k (modulation index), A (Amplitude) and N (Samples/Symbol). The
 relationship between input and output of the CPFSK block is shown below and
 found in the source code:

 out[n] = A*exp( j * k * pi * 1/N * n * input[n] )

 where input[n] = +1 or -1 is the input data to the block.

 Now with that all setup, here is the odd behavior. Since input[n] is only
 +1 and -1, I expect the real part of the output to remain unchanged and the
 input changes, because cos(-x) = cos(x) and I expect the imaginary part to
 flip signs as the input changes because sin(-x) = -sin(x). What I see is
 sometimes the cos will be flipping signs with the sin remaining constant. It
 is as though the inphase and quadrature arms were reversed.

 I am looking at the real and imaginary output of the CPFSK block in the
 transmitter. Because we are in the transmitter, there are no channel effects
 or synchronization effects that come into play to cause this.

 Does anyone know what could cause this?

 v/r,
 Rich


 ___
 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] gr-fcdproplus for non-Linux?

[Brian Padalino]

We ran into the clock_gettime issue for the bladerf library
implementation.  We fixed it like this:

  
https://github.com/Nuand/bladeRF/blob/master/host/utilities/common/src/osx/clock_gettime.c

According to stackoverflow, the pthread_barrier_t is discussed here:

  
http://stackoverflow.com/questions/8920803/pthread-and-gcc-compiling-issue-on-os-x

Hope this helps.

Brian

On Fri, Jan 17, 2014 at 10:33 AM, Michael Dickens m...@alum.mit.edu wrote:
 I was playing around with gr-fcdproplus  
 https://github.com/dl1ksv/gr-fcdproplus  in MacPorts just now, and it 
 requires Linux (e.g., uses pthread_barrier_t and clock_gettime) ... 
 anyone know if there is another version which is more OS compatible? - MLD


 ___
 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] Again gr/bladeRF/gr-osmosdr/libusbx/gqrx do not fit together

[Brian Padalino]

Hi Ralph,

libusb_get_version() was added I believe around 1.0.10?

It's wrapped in a logging enabled flag so if you disable logging then
maybe it will get past it:

  
https://github.com/Nuand/bladeRF/blob/009d8181e0799f3b8e282e22f6ac793ac9b85f85/host/libraries/libbladeRF/src/backend/libusb.c#L525

I'll take a look at how we can help fix that on our end.

Try updating libusb(x) in the meantime?

Brian

On Fri, Dec 13, 2013 at 12:25 PM, Ralph A. Schmid, dk5ras
ra...@schmid.xxx wrote:
 Hi out there,

 Again the bundle of gr, bladerf, gr-osmosdr/iqbal, libusbx and gqrx do not 
 fit together.

 After updating bladerf gqrx does not start any more, giving this error:

 gr-osmosdr v0.1.0-46-g05d51b53 (0.1.1git) gnuradio v3.7.2.1-86-g324cdab6
 built-in source types: file bladerf
 Using Volk machine: avx_32_mmx_orc
 gr-osmosdr v0.1.0-46-g05d51b53 (0.1.1git) gnuradio v3.7.2.1-86-g324cdab6
 built-in source types: file bladerf
 gqrx/gqrx: symbol lookup error: /usr/local/lib/libbladeRF.so.0: undefined 
 symbol: libusb_get_version
 ras@ubuntu:~$

  So I removed everything but gnuradio and built/installed it all from scratch 
 again. libusbx, bladerf, gr-osmosdr/Iqbal, gqrx - when building gqrx, it 
 fails with this one:

 g++ -Wl,-O1 -o gqrx main.o mainwindow.o receiver.o remote_control.o 
 remote_control_settings.o cafsk12.o costabf.o agc_impl.o correct_iq_cc.o 
 lpf.o resampler_xx.o rx_demod_am.o rx_demod_fm.o rx_fft.o rx_filter.o 
 rx_meter.o rx_agc_xx.o rx_noise_blanker_cc.o sniffer_f.o stereo_demod.o 
 udp_sink_f.o afsk1200win.o agc_options.o audio_options.o demod_options.o 
 dockinputctl.o dockaudio.o dockfft.o dockiqplayer.o dockrxopt.o freqctrl.o 
 ioconfig.o meter.o nb_options.o plotter.o qtcolorpicker.o nbrx.o 
 receiver_base.o wfmrx.o pa_device_list.o pa_sink.o pa_source.o 
 moc_mainwindow.o moc_remote_control.o moc_remote_control_settings.o 
 moc_cafsk12.o moc_afsk1200win.o moc_agc_options.o moc_audio_options.o 
 moc_demod_options.o moc_dockaudio.o moc_dockfft.o moc_dockinputctl.o 
 moc_dockiqplayer.o moc_dockrxopt.o moc_freqctrl.o moc_ioconfig.o moc_meter.o 
 moc_nb_options.o moc_plotter.o moc_qtcolorpicker.o qrc_icons.o
 -L/usr/lib/i386-linux-gnu -lboost_system -lboost_program_options -lrt 
 -lpulse-simple
 -lpulse -L/usr/local/lib -lgnuradio-analog -lgnuradio-filter -lgnuradio-fft 
 -lgnuradio-osmosdr -lgnuradio-blocks -lgnuradio-runtime -lgnuradio-pmt 
 -lQtSvg -lQtGui -lQtNetwork -lQtCore -lpthread
 /usr/local/lib/libbladeRF.so.0: undefined reference to `libusb_get_version'
 collect2: ld returned 1 exit status
 make: *** [gqrx] Error 1
 ras@ubuntu:~/gqrx$

 Any ideas?

 Thanks a lot for your ideas, and with best regards

 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

Re: [Discuss-gnuradio] QAM Modulation-Demodulation in Loopback

[Brian Padalino]

On Tue, Dec 3, 2013 at 1:44 PM, Kartik Seth kartikset...@gmail.com wrote:
 I am transmitting and receiving from the same bladeRF board using a cable
 and a 20 dB attenuator.

 If you see in the flowgraph I multiply by 0.3, that is specifically to
 prevent clipping and non-linearity.
 I have tried using AGC or gain of low pass filter but no success.

 The problem is that same flowgraph is working perfectly for BPSK and
 QPSK(most of the times), so I think issues with
 amplitude/clipping/non-linearity are ruled out.

 However, when I move to 8PSK and QAM, I don't get demodulated output.

 Any suggestions whether there are issues with flowgraph or is it some issue
 with hardware?

It very well could be an issue with hardware.  Also I wouldn't be so
quick to rule out amplitude or clipping if BPSK or QPSK works.  They
are pretty resilient modulations.

Try removing hardware from the equation and just using GNURadio as
simulation?  You may want a throttle block in there.

Take a look at the time domain and see if you are seeing things nicely
between (-1,1) or if you see a big square and are pegged most of the
time?

Brian

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

Re: [Discuss-gnuradio] Gauging interest for an SDR PA

[Brian Padalino]

On Tue, Nov 26, 2013 at 9:37 PM, Louis Brown rfe...@everestkc.net wrote:
 Given the availability of SDR hardware (USRPs, BladeRF, HackRF, etc) covering 
 VHF through S/C bands, is there any interest in a wide band power amp to 
 complement this hardware?  GaN seems to be ubiquitous now, and there are 
 medium power, 48 VDC parts available in low cost SMT packages.  So I think 
 it's feasible for something like:

 50 MHz - 3 GHz bandwidth
 Class AB
 5 - 30 VDC supply (high efficiency, high frequency boost supply)
 10 dBm drive
 37 dBm Psat
 Robust to full mismatch (open/short)
 Logic level enable
 ALC with VSWR monitoring (serial, I2C, etc)
 Small (cigarette pack or smaller)
 Low cost
 Open source

This sounds neat to me.  Would you plan on having harmonic filter
banks on the input and/or output of the amplifier? How do you think
you would tackle the ALC with the different arbitrary bandwidths of
the SDR signals?  Also, curiously, do you have an efficiency in mind
that you want to design for?

Brian

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

Re: [Discuss-gnuradio] Again bladerf / gqrx / gr-osmosdr

[Brian Padalino]

On Thu, Oct 10, 2013 at 1:52 AM, Ralph A. Schmid, dk5ras
ra...@schmid.xxx wrote:
 Hi,

 Looks like there is something missing from your libbladeRF.so.  The
 repository shows they were added on October 2nd.  Are you sure you're
 building the latest stuff?

 Should be the latest, when doing a git pull right before building it. I did
 not yet delete the whole BladeRF folder and clone into a totally new folder,
 maybe this helps?

I always recommend blowing away the build directory and rerunning
cmake .., make, sudo make install.

That is the best way I've found to make sure things are fresh.

I just rebuilt against everything last night and things seemed fine to
me.  Others have also reported success.

Let me know how it goes.

Brian

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

Re: [Discuss-gnuradio] Again bladerf / gqrx / gr-osmosdr

[Brian Padalino]

On Wed, Oct 9, 2013 at 2:23 PM, Ralph A. Schmid, dk5ras
ra...@schmid.xxx wrote:
 Hi,

 After cleaning everything still the message:

 /usr/local/lib/libgnuradio-osmosdr.so: undefined reference to
 `bladerf_fpga_version'
 /usr/local/lib/libgnuradio-osmosdr.so: undefined reference to
 `bladerf_fw_version'
 collect2: ld returned 1 exit status
 make: *** [gqrx] Error 1
 ras@ubuntu:~/gqrx$

 I have no idea what I should do to resolve this...

Looks like there is something missing from your libbladeRF.so.  The
repository shows they were added on October 2nd.  Are you sure you're
building the latest stuff?

  
https://github.com/Nuand/bladeRF/blame/master/host/libraries/libbladeRF/include/libbladeRF.h#L851

Brian


 Ralph.

 -Original Message-
 From: discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-
 gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Ralph A. Schmid,
 dk5ras
 Sent: Tuesday, 8 October, 2013 19:57
 To: 'Alexandru Csete'; discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] Again bladerf / gqrx / gr-osmosdr

 I did make uninstall and make clean in bladerf, gr-osmosdr and gqrx, then
 rebuild
 it all, still this error:

 /usr/local/lib/libgnuradio-osmosdr.so: undefined reference to
 `bladerf_fpga_version'
 /usr/local/lib/libgnuradio-osmosdr.so: undefined reference to
 `bladerf_fw_version'
 collect2: ld returned 1 exit status
 make: *** [gqrx] Error 1
 ras@ubuntu:~/gqrx$

 Time to restore the backup :)

 With best regards

 Ralph.



 ___
 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] gqrx / gnuradio / BladeRF

[Brian Padalino]

Hi Ralph,

I've noticed that as well, and we need to fix it.  I believe it's a
bug.  Not sure if it's in libbladeRF or gr-osmosdr, but we're on it.

Sorry for the inconvenience.

Brian

On Tue, Oct 1, 2013 at 3:14 AM, Ralph A. Schmid, dk5ras
ra...@schmid.xxx wrote:
 Hi,

 Not exactly the perfect list for it, but as the specialists are all here in
 this list, it somehow should fit :)

 When using gqrx with the BladeRF I observe that tuning takes ages. Every
 entered or changed frequency digit takes almost one second to be accepted,
 and I mean to remember that directly out of gnuradio this is much faster,
 although usually I do there no live tuning, but sending the frequency to the
 unit just once, out of a block. When using the USRP1 with WBX or a
 RTL2832/E4000 receiver, tuning occurs without noticeable delay.

 Bug or feature? :-)

 With best regards

 Ralph.



 ___
 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] gqrx / gnuradio / BladeRF

[Brian Padalino]

On Tue, Oct 1, 2013 at 10:41 AM, Ralph A. Schmid, dk5ras
ra...@schmid.xxx wrote:

 Hi,

 Hi Ralph,

 I've noticed that as well, and we need to fix it.  I believe it's a
 bug.  Not sure if it's in libbladeRF or gr-osmosdr, but we're on it.

 OK, great to hear.

 Sorry for the inconvenience.

 Huh?! Early adopters we are, guess this is normal :-)

 Is there are dedicated mailing list for BladeRF? The forum is so
 inconvenient... Or should we keep it here?

There is an IRC channel on freenode, #bladerf, which has decent
activity.  No mailing list yet.  I agree the forum is not ideal.

Best bet is through IRC and/or using the issue tracker on github.

Brian

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

Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?

[Brian Padalino]

On Fri, Sep 13, 2013 at 2:19 AM, Ralph A. Schmid, dk5ras
ra...@schmid.xxx wrote:
 Hi,

 I am using bladeRF with gr-osmosdr, gnuradio 3.7 and gqrx, so far a fine
 radio. One thing, when using gqrx...I am limited to USB2.0 at the moment, so
 I use a sampling rate of 8 Ms/s, and in this mode I have big problems with
 images from the neighbour frequencies that are still within the 26 MHz
 bandwidth, or whatever the maximum BW is.

 Is there some command to set this bandwidth to a smaller value? I assume
 that this would improve my RX experience a lot :) A quick look at osmocom
 showed me nothing, but maybe I missed smth.

The gr-osmosdr interface allows for a bandwidth setting to be changed here:

  http://cgit.osmocom.org/gr-osmosdr/tree/lib/bladerf/bladerf_source_c.cc#n581

The driver will figure out which bandwidth is closest to what you want
with a minimum of 1.5MHz and a maximum of 28MHz for the low-pass
filters.

It will definitely make a world of difference by actually applying the
LPF and removing the aliasing.

As for official support for gqrx, it's next on our list.  We need to
get on the gqrx mailing list and figure out what code we need to
write.

Brian

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

Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?

[Brian Padalino]

On Fri, Sep 13, 2013 at 3:58 PM, Alexandru Csete oz9...@gmail.com wrote:
 On Fri, Sep 13, 2013 at 3:53 PM, Brian Padalino bpadal...@gmail.com wrote:
 On Fri, Sep 13, 2013 at 2:19 AM, Ralph A. Schmid, dk5ras
 ra...@schmid.xxx wrote:
 Hi,

 I am using bladeRF with gr-osmosdr, gnuradio 3.7 and gqrx, so far a fine
 radio. One thing, when using gqrx...I am limited to USB2.0 at the moment, so
 I use a sampling rate of 8 Ms/s, and in this mode I have big problems with
 images from the neighbour frequencies that are still within the 26 MHz
 bandwidth, or whatever the maximum BW is.

 Is there some command to set this bandwidth to a smaller value? I assume
 that this would improve my RX experience a lot :) A quick look at osmocom
 showed me nothing, but maybe I missed smth.

 The gr-osmosdr interface allows for a bandwidth setting to be changed here:

   
 http://cgit.osmocom.org/gr-osmosdr/tree/lib/bladerf/bladerf_source_c.cc#n581

 The driver will figure out which bandwidth is closest to what you want
 with a minimum of 1.5MHz and a maximum of 28MHz for the low-pass
 filters.

 It will definitely make a world of difference by actually applying the
 LPF and removing the aliasing.

 As for official support for gqrx, it's next on our list.  We need to
 get on the gqrx mailing list and figure out what code we need to
 write.


 Actually, it was a deliberate choice not to have explicit support for
 that API call since it seemed unnecessary. Wouldn't one always want to
 use the narrowest analog bandwidth corresponding to a given sample
 rate? If yes, the setting may as well happen as part of the sample
 rate configuration and best handled at a layer that knows about the
 specific device. Am I wrong?

One may want to listen to an LTE signal that is 5MHz wide, but sample
at the standard 30.72MHz sample rate.  In this case, I would think the
LPF might want to be set smaller than 28MHz (maybe 8MHz?) but still
sample at 30.72MHz?

Maybe another case is wanting to see 5MHz worth of bandwidth, seeing a
weak signal, move the weak signal into the LPF region, and tighten the
filter such that you could increase the gain without clipping the ADC
in case there is a near-by blocker?

I agree you can shoot yourself in the foot very easily by separating
the two of them and have lots of noise alias in, but keeping them
separate, in my mind, is still a very reasonable thing to do.

Maybe, for the case of gqrx, an option for gr-osmosdr at device
opening (and passed to the constructor) is to have a bandwidth setting
(auto or manual) that when put into auto mode will do as you suggest,
and set the appropriate low pass filter bandwidth as well as warn if
the sample rate is too low, and there will be aliasing due to the LPF
not being tight enough?

What are your thoughts?

Brian

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

Re: [Discuss-gnuradio] bladeRF and gnuradio?

[Brian Padalino]

On Mon, Sep 9, 2013 at 6:43 AM, Ralph A. Schmid, dk5ras
ra...@schmid.xxx wrote:
 Hi,

 Are there any out here with experience in getting bladeRF being usable with
 gnuradio/grc? So far I followed the usual steps, bladerf and gr-osmosdr
 compiled, but as documentation is  being far from getting finished, I only
 reach the point of loading manually the FPGA image, nothing more :(
 Furthermore, with the latest changes in code bladeRF even does not compile
 any more...

There was a recent change which added a call to libusb_get_version()
which doesn't exist in 1.0.9 of libusbx.  So if you're running that,
you should consider updating to a newer version.  I know it exists in
1.0.12 and later.  What version of libusbx are you using?  Is it a
possibility to update?  version 1.0.17 was recently released.

https://github.com/libusbx/libusbx

 I know the forum, but I prefer mailing lists like this - maybe there even is
 some active bladeRF list?

We've gone through some restructuring of the library and where it's
installed to so if you've potentially got a stale version somewhere
you're not expecting it to be, that might cause issues.

After moving to libusb instead of a straight kernel driver, the
current work to go on the driver right now is to interface with the
asynchronous stream instead of using the synchronous transmit and
receive interface.  The kernel driver did a bit of pseudo asynchronous
shenanigans on the synchronous interface whereas the libusb
synchronous interface does not.  This will limit the effective
samplerate, but we're working on getting it resolved.

As for any other issues - anything specifically you're seeing that is
an error and stopping the flowgraph?

Brian

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

Re: [Discuss-gnuradio] Low cost SDR hardware

[Brian Padalino]

Hi Manu,

What is your output power requirement?  Frequency coverage?  Do you have a
target price?  Do you have LO phase coherency requirements?

Support for nuand's bladeRF was just recently pushed to gr-osmosdr for both
GNU Radio 3.6 and 3.7.  The output power is 6dBm CW, so with some backoff
for linearity and PAPR on your transmission signal, you're probably at
-6dBm or so for transmission.  Harmonic filtering is required if you plan
to hook it up to an antenna.  The frequency coverage is from 300MHz -
3.8GHz and costs $420/board.

More information can be found here:

  http://nuand.com

Feel free to e-mail me directly off list if you'd like to discuss more.

Brian

Full disclosure: I'm involved with nuand and bladeRF.



On Tue, Jul 30, 2013 at 12:25 AM, Manu T S manu.t.s...@gmail.com wrote:

 Hello everyone,

 A professor in my university wants to revive lab course on communication.
 He wants to introduce some experiments involving SDR. For that we need
 about 100 pieces of hardware( both receiver and transmitter). Buying 100
 USRP is not a viable solution for us. We can go for RTL SDR but it has only
 transmitter. Does anyone know of a good solution for low cost hardware,
 (transmitter + receiver or just transmitter) preferably GNU Radio
 compatible, that we could opt for?

 --
 Manu T S

 ___
 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] ATSC Magic coupling constant

[Brian Padalino]

On Tue, Jul 30, 2013 at 5:55 PM, Andrew Davis glneolistm...@gmail.comwrote:

 Hello all,

 I'm working on fixing up gr-atsc and I have been working on a little
 problem for a while now, there is a constant ( FPLL_BTLOOP_COUPLING_CONST )
 that sets the reference for an AGC, the value is ( 2.5 * 3.125 ) and is
 literally defined as Magic, so it seems to be a value that just works.
 With that value the AGC filters the real input and then this is multiplied
 by a NCO part of a PLL. This puts the value of the +/- 5 timing sync levels
 at about +/- 5. The problem is when I pass samples though the AGC and then
 do 'complex' multiplication on them the +/- 5 values end up at about +/- 7.
 I'm not sure why but it seems like the values coming out of the complex
 multiply are not the same as the real multiply. The original code is:

 nco.sincos (a_sin, a_cos);  // compute cos and sin
 float I = input * a_sin;
 float Q = input * a_cos;

 My code is:

 nco.sincos (a_sin, a_cos); // compute cos and sin
 gr_complex result = (gr_complex(input_real, input_imag) *
 gr_complex(a_cos, a_sin));
 float I = result.real();
 float Q = result.imag();

 I is larger in my version and so the equalizer and slicer fail downstream.
 I built a coherent AGC into the sync timing loop but it still fails with
 large gain differences.

 My question is whether there is anyone around who worked on gr-atsc who
 could give me a hint as to how the Magic coupling constant was derived in
 the first place so I can build a new one so I don't have to rebuild the
 equilizer.


I can't help you with your MAGIC, but if you say the real signal is mixed
then filtered in the original code that works, whereas it is just mixed
with your code - maybe it's just off by a sqrt(2) since you're filtering
off your image after the NCO happens and losing 1/2 power?

I did notice that sqrt(2)*5 = 7 - so maybe making your NCO a little less
powerful might bring you to the correct power levels since I am assuming
you aren't filtering in your chain since there is no image to filter out?

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

Re: [Discuss-gnuradio] VITA49 - VRT Output from spectrum analyser

[Brian Padalino]

On Wed, May 15, 2013 at 10:20 AM, Charlie Starling fool2c...@gmail.comwrote:

 Hi all, I have a spectrum analyser that outputs its I and Q data over TCP
 or UDP in the VITA49 format, I've been searching around looking for a way
 to interface this into gnuradio but all the information I can seem to find
 regarding VITA49 seems to be with reference to USRP. Can anyone offer any
 advice or pointers for where to start? I have some programming experience
 if that's what's needed.


For curious minds - what is the make and model of the analyzer you are
using?

Thanks,
Brian


 Thanks
 Charles

 ___
 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] Computer controllable antenna tuner

[Brian Padalino]

On Mon, May 13, 2013 at 10:52 AM, Marcus Müller 
master.of.knowle...@gmail.com wrote:

 Hi Juha,

 there's a lot of devices that do your job.
 From the classic commercial-grade devices of the USRP line,
 to cheaply available rx modules like the (in)famous dvb-t dongles. You can
 use the tuners on old PCI tv cards and a ton of other stuff.
 It all depends on what you need to do: What frequencies do you need to
 tune to? What bandwidth do you need afterwards? Do you want I/Q or are you
 basically doing AM? Want to have ADC afterwards or do you really need the
 analog baseband?
 For your commercially available tunable magnetic loop antenna: I don't
 know. Not my kind of technology. Try a random used car radio that can
 receive MW broadcasts and does the tuning digitally. Most probably you'll
 find a tuner module that works well but has no available documentation
 whatsoever. Use your favourite digital analyzer to find out how the
 microcontroller interfaces with that. Or ask your RF IC manufacturer of
 choice. They build hardware. GNU Radio has nothing to do with that.
 However, this question is awefully unspecific and has little to do with
 GNU Radio, as it is a software radio system (and less concerned with the
 hardware; anyway, 1-20MHz sounds a lot like baseband to me).


I believe he is looking for something more like an antenna coupler/tuner
used in HF applications to tune and impedance match for maximum power
transfer:

  http://en.wikipedia.org/wiki/Antenna_tuner

As for not talking about hardware on the GNU Radio mailing list - I find
that a little silly.  While GNU Radio is more about a framework for
processing baseband signals, there's also the real need to interface to the
outside world.  Dynamic range, gain, and all the little hardware bits in
the radio front end are all valid discussion points and completely on
topic, in my opinion.

Brian


 Greetings
 Marcus

 Am 11.05.2013 14:37, schrieb Juha Vierinen:

 Hi,

 Does anyone know a good antenna tuner with a serial port, usb or
 ethernet connection that allows you to tell the tuner what frequency to
 tune to? I could really use something like this.

 Also, does anyone know of a good commercially available magnetic loop
 antenna for the HF band (1-20 MHz)? Again, I'd want to use a computer to
 tune the antenna for a certain frequency range.

 juha


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



 __**_
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/**listinfo/discuss-gnuradiohttps://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] i have a question about channel model block

[Brian Padalino]

Hi Irfan,

You should check out the propagation models from the 3GPP, specifically
in 3GPP TS 45.005 Annex C has some channel models you can take a gander at
trying to model different types of terrain.

Good luck!

Brian


On Mon, May 6, 2013 at 6:29 AM, Irfan Ullah irfancoms...@yahoo.com wrote:

 hi all,
  i am working on channel model block but i have a confusion about
 the value of taps parameter
 in block how many taps i should include to simulate a real life channel
 like GSM wireless channel.
 and what are the values of these taps should i set?
 regards
 Irfan Ullah
 COMSTAS university islamabad campuse EE department final semester student
 working on cooperative communication using GNU radio and implementation on
 usrp kits.

 ___
 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 demodulation

[Brian Padalino]

On Wed, Apr 17, 2013 at 6:30 AM, Karan Talasila karan@gmail.com wrote:

 Hi,


 I am trying to understand ofdm demodulation using schmidl and cox paper.
 Can anybody explain how a pn sequence on even frequencies and 0 on odd
 frequencies help in the estimation of timing and frequency offset.


Hi Karan,

I haven't read the paper, but here is what I know from the description of
the scenario.  Someone who has more OFDM experience can probably speak with
a little more authority.

If you skip every other bin in the frequency domain, the time domain signal
is actually repeated during the whole OFDM symbol. Since the time domain
information is repeated, you can perform a correlation with a delayed
version of the symbol coming in for some rough synchronization of the
preamble.  Also, the phase difference of that result will be the average
frequency offset over that number of samples, giving you a decent frequency
offset estimate as well.

At least, that's what I think would be useful.

Does that make sense to you?

Brian


 --
 Regards
 Karan Talasila

 ___
 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] Redmine, GNU Radio Wiki and LaTeX

[Brian Padalino]

I tried looking but I couldn't find a way to inline LaTeX equations on the
GNU Radio wiki or if there was some plugin required that wasn't installed?

Something like mathjax support would be great if we could have it, but I am
completely out of my element here.  Suggestions?  Ideas?  Am I just being
silly and there's already a way to do it?

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

Re: [Discuss-gnuradio] Error in Interpolating FIR filter

[Brian Padalino]

On Fri, Apr 5, 2013 at 8:29 AM, Tom Rondeau t...@trondeau.com wrote:

 On Fri, Apr 5, 2013 at 1:31 AM, Manu T S manu.t.s...@gmail.com wrote:
  Executing the attached flow graph I get the following error.
 
 
 #
  gr_fir_ccc: using SSE
  Traceback (most recent call last):
File /home/manu/coding/top_block.py, line 72, in module
  tb.Run(True)
File
 
 /usr/local/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py,
  line 76, in Run
  self.start()
File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py,
  line 97, in start
  self._tb.start(max_noutput_items)
File
 
 /usr/local/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_runtime.py,
  line 3077, in start
  return _gnuradio_core_runtime.gr_top_block_sptr_start(self,
  max_noutput_items)
  RuntimeError: gr_buffer_add_reader: nzero_preload must be = 0
 
 ###
 
  What could be the possible reason?
 
  I have installed using build-gnuradio script on day before yesterday.
 
 
 
  --
  Manu T S

 Manu,

 You have to give the interpolator taps. It can't run without a filter
 defined.


The error message could definitely be much better.

  RuntimeError: gr_buffer_add_reader: nzero_preload must be = 0

Even to an experienced person, without seeing the flow graph, that error
doesn't mean anything.  Debugging a large flow graph might be like looking
for a needle in a haystack.

As a side note, what error gets thrown when this is in a straight C++
application?  Is it more informative or equally as ambiguous?

Is it possible to get the filter to throw the assertion/error versus the
runtime?

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

Re: [Discuss-gnuradio] Need help

[Brian Padalino]

On Wed, Apr 3, 2013 at 10:56 PM, vamshi krishna dodla 
vamshikrishna.do...@gmail.com wrote:

 can some one send me a flow graph of QPSK transmitter and receiver, this
 flow graph should include a root raised cosine filter, qpsk generator,
 multipath channel, additive gaussian noise source, snr estimator and feed
 back, interpolator, carrier recovery using bandedge filters, timing
 recovery using poly phs clock sync, lms equalizer, coastas detector.

 I tried doing the same but having hard time executing the flow graph.


That's a pretty large ask.

Can you be more specific in the hard time you're having executing your flow
graph?  Can you post your flow graph to the internet and link to it?  Is
this for simulation or is there hardware in the loop?

You'll probably have a much higher degree of success if you ask specific
questions about your (shared) graph instead of asking someone to re-create
a graph you're trying to make.

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

Re: [Discuss-gnuradio] Talking about DSP and SDR [Was: On tunnel.py]

[Brian Padalino]

On Sat, Mar 30, 2013 at 3:09 PM, Tom Rondeau t...@trondeau.com wrote:


 I'd suggest that Brian start formatting the page based on the list he
 put above, but I think we might be better served by having someone
 come up with a full page for something, like the OFDM model you
 mentioned, so we can get a feel for how this will go and how the pages
 will eventually look.


I setup a little outline of what I thought might be some of the big hitter
topics here:

  http://gnuradio.org/redmine/projects/gnuradio/wiki/SignalProcessing

They are replicated here for comments and suggestions:

  Modulations
  Specific types of modulations - analog, digital and diversity in space,
time and frequency are all welcome!

  Filtering
  IIR, FIR, adaptive, and even analog - all the techniques.

  Synchronization
  Carrier, symbol and timing recovery.

  Forward Error Correction
  Including data integrity! Quite an expansive topic.

  Hardware and Physics
  The impacts of the physical world on software defined radio. Cascade
analysis, near-far problem, and channel models.

  Signal Identification and Classification
  Figuring out what is out there, and what it means to you. One mans noise
is another mans signal. So which is it?

  Standards
  Dissecting and understanding specific industry standards such as 802.11,
GSM, 802.15.4, etc.

Comments?  Thoughts?

I like the idea of starting with OFDM since it has gotten a major rewrite
and is used extensively.  Is the majority of the OFDM rewrite in the next
branch?

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

Re: [Discuss-gnuradio] Talking about DSP and SDR [Was: On tunnel.py]

[Brian Padalino]

On Sat, Mar 30, 2013 at 9:54 AM, Tom Rondeau t...@trondeau.com wrote:

 To move on in this topic, Alex brings up an interesting point. One of
 the reasons for this mailing list is to discuss signal processing,
 SDR, algorithms, etc. Hopefully in a way that helps us improve either
 GNU Radio itself of our use of GNU Radio tools and blocks. I would
 really like to see more of this.

 The problem is that in the past, every now and then, someone tries to
 do this. But it never seems to work or end very satisfactorily. The
 mailing list structure seems like it doesn't lend itself to properly
 discuss signal processing in a useful way.

 To start with, we need to start passing around flowgraphs (preferably
 GRC) so that we can all see what's being discussed. There is also the
 gnuradio.org wiki that people could use to build pages that better
 describe the problem, idea, or suggestion. That format can handle
 images, better embedding of formulas, and file attachments (include
 data sets that are too big to mail out).

 I would love to see someone take this on as a challenge to try to spur
 on more discussion about communications. Over the past few years,
 we've also gotten much better about using Git and tools like github to
 submit patches and fixes. So I would encourage everyone to use the
 available tools to help us all better communicate with each other.


As I am here mainly for the algorithm talk, this sounds like a great idea.
 Are you envisioning a new Signal Processing and SDR section to the main
page?  Some of the topics I think that would be a good start are:

  0. Understanding the (insert commercial standard here) MAC and PHY
  1. Frequency calibration using your local GSM station
  2. The near-far problem and how hardware still matters with software
defined radios
  3. Synchronization and frequency offset
  4. Modulations and channel filtering
  5. Forward Error Correction
  6. Simulation within GNU Radio
  7. OFDM Demystified
  8. Diversity in Space, Time, and Frequency
  9. Wireless Channels and how to mitigate their effects

I am pretty sure most, if not all, of the topics are covered somewhere in
the GNU Radio code base or can be easily explained by some people on the
mailing list.

Also, I am sure most everyone has seen it, but Charan Langton's website:

  http://complextoreal.com/tutorials/

has some excellent, freely available tutorials that explain the theory and
math of a slew of communication related topics.  It would be great to link
those tutorials with a real implementation in GNU Radio.

I think some good candidates for the first topics might be all the new OFDM
work as well as the simulation aspect of GNU Radio so more of the user base
feels empowered by the software without feeling like they need hardware to
be able to use GNU Radio.

So what do you think should be first?  What would you like to see?  I know
you've blogged about GNU Radio updates.  Should those be topics discussing
algorithms and pragmatic GNU Radio?

I think you said it best:

  It's not easy, but communications is not easy. In fact, it's very, very
hard.

Seems to apply to every aspect of communication and is not limited to
wireless.

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

Re: [Discuss-gnuradio] bit error rate

[Brian Padalino]

On Fri, Mar 8, 2013 at 8:47 PM, manjusha yandamuri.ma...@gmail.com wrote:

 ber_before_tx.png
 http://gnuradio.4.n7.nabble.com/file/n40088/ber_before_tx.png
 ber_tx.png http://gnuradio.4.n7.nabble.com/file/n40088/ber_tx.png


It doesn't look like you're doing any carrier recovery?

Before putting USRP blocks in there, maybe you should try a straight
simulation that adds noise and some frequency offset artificially.  Get
that working, and then connect up the USRP source/sink?


 I am trying to find the Bit error rate for a vector signal.I get a error
 rate of 0.528(i am assuming it to be 52%) when i don't transmit  and an
 error rate of 0.625000 when i transmit.

 Am i right on this??i dont understand the logic behind it..

 Also,is 52% not too high??!!!


Around 50% BER is what you would expect from a random signal.  100% BER is
very good since you just need to flip all the bits and you get the right
answer!  That is also given the input signal statistics are sufficiently
whitened/random.



 thank you



You might want to take a step away from putting blocks in GRC and just take
a look at some of the resources on the GNU Radio wiki about suggested
reading:

  http://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading
  http://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReadingOrder

Sanity is hard to come by if you're dealing with magic.

Good Luck!

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

Re: [Discuss-gnuradio] How to get the carrier's frequency offset in PM demodulator?

[Brian Padalino]

On Wed, Jan 30, 2013 at 9:30 AM, adream adream...@gmail.com wrote:

 I am feel sorry for no reply


It's just been a day - sometimes if the answer doesn't come quickly, people
are confused by what you're asking.




 2013/1/30 adream adream...@gmail.com

 Does gnuradio provide this function?
 thank you


Natively I don't think it does, but there are properties to the demodulated
signal you may be able to exploit and calculate it.



 2013/1/29 adream adream...@gmail.com

 Hello,
 I am learning PM Demodulation, and someones tell me that the FM
 Demodulator in gnuradio can demodulate the PM signals.
 I want to get the carrier's frequency offset in PM demodulating, does
 gnuradio provide this function?
 For example, in my project, I set the frequency of IF signal is 70MHz,
 but the real input IF signal is 70.01MHz.
 In this case, I hope my program can print the carrier's frequency
 offset, 10KHz
 Thank you.


FM has the property that frequency offset results in a DC offset at the
demodulated signal that is proportional to the amount of frequency offset
(given the input signal has no DC component).

For PM, since you are not taking the first derivative of the phase as you
are with FM, the DC component will be shifted up to your frequency offset.
 Doing a long term average of a demodulated FM signal should (hopefully!)
come out to be 0 for no frequency offset.

You could FM demodulate, put a DC filter then reintegrate at the output to
get your PM signal back - but I am not sure how well that works.  Give it a
shot and let us know!

Hope that helped.

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

Re: [Discuss-gnuradio] USB-3 40MHz BW 300MHz -3.8GHz SDR Transceiver 400 USD

[Brian Padalino]

On Wed, Jan 30, 2013 at 12:49 PM, Martin O'Shield
mar...@windycitysdr.comwrote:


 William,


 Thanks for making me aware of this:

 100Khz - 20Ghz for their SDR boards, but their Front ends are:

 RFE0108 100 kHz to 10 GHz Radio Front End
High performance radio receiver front end with frequency tuning range
 of 100 kHz to 10 GHz and capable of processing up to 450 MHz of
 instantaneous RF bandwidth.

 All Impressive INDEED!

 I wonder what the pricing for ThinkRF products are and what will the
 BladRF USB
 be priced at?


The bladeRF is definitely nowhere close to what the thinkRF folks are doing
- but the market segments are different as well.  The thinkRF guys are much
more into high performance/SIGINT whereas bladeRF is good performance and
highly integrated yielding a lower cost at the sacrifice of bandwidth.

The bladeRF is based on the LMS6002D RF transceiver with documentation here:

  https://github.com/chemeris/lms6002-documentation

The $400 price tag along with the 300MHz - 3.8GHz tuning range, 28MHz of
instantaneous bandwidth and bus powered over USB 3.0 superspeed to get
5Gbps full duplex are the biggest selling points.  Full schematics can be
found on the support page or directly:

  http://nuand.com/bladerf.pdf

It's a good SDR for a very palatable price.

Brian
___
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?

[Brian Padalino]

On Sun, Dec 16, 2012 at 9:39 PM, Michael Ossmann m...@ossmann.com wrote:

 On Sun, Dec 16, 2012 at 11:27:47PM +0100, Joanna Rutkowska wrote:
 
  Thanks for the detailed answer! I did some more study and my
  understating is that what you wrote above applies to (theoretical)
  coherent demodulation. AFAIU nearly all practical receivers use
  non-coherent demodulation (because it's cheaper, and apparently, has
  about 1dB penalty only on sensitivity?). This non-coherent detection
  is apparently realized using two bandpass filters centered around the
  two frequencies.

 I believe you are correct that sensitivity vs. deviation is strongly
 dependent on the receiver implementation.  You may not be correct
 assuming anything about the particular receiver implementation in the
 Atmel part.

  So, my understanding goes, in any practical realization, it should be
  better (not worse at least) to use as large Fd as one can, because it
  makes the job of the two filters easier...
 
  But, it's apparently not like this. Here's the link to the Atmel paper
  I mentioned before (again, please take a look at Figure 9-2):
 
  www.atmel.com/Images/doc9174.pdf

 Making a guess about the receiver implementation, I'd say you correctly
 describe why the sensitivity improves as Fd increases toward 50 kHz.
 I'd further guess that the reason sensitivity gets worse above 50 kHz
 deviation is that the bandwidth of the signal exceeds the fixed IF
 filter in the receiver.


The IF filter says it's around 400kHz wide at the 3dB points, so I doubt a
50kHz deviation is hitting those limits.  They also have frequency offset
numbers which suggest they can handle significant frequency offset and
still get their data through.

Looking at the graph and reading through the datasheet it seems there is a
noise figure of around 10dB and 8.5dB SNR required to work well.  At the
120kHz deviation, we can get the input level at room temperature as such:

  -174 dBm/Hz + 10*log10(120e3*2) + 10dB + 8.5dB = -101.7dBm

Very close to the -102dBm they show in their graph.  Even at 30kHz
deviation which is shown as -107dBm on the graph comes up with a very close
-107.7dBm from the calculation.

What's actually interesting is for a value of 100kHz deviation shows on the
graph a sensitivity of -105dBm whereas the calculation comes up with
-102.5dBm.

If the receiver were actually implemented as a pair of bandpass filters as
in Figure 9-1, then the above calculation wouldn't hold since the noise
between the filters would be filtered out and not contribute to the SNR
calculation.  If the two bandpass filters actually covered -f_dev to just
below carrier and just above carrier to +f_dev they would effectively cover
the entire -f_dev to f_dev bandwidth.  If the lower cutoff of each bandpass
filter was actually pushed out (like in Figure 9-1), filtering out the
noise and limiting the bandwidth of the system to be less than the occupied
bandwidth of the transmission, that might explain what is happening.

It's really just an SNR in a given bandwidth problem.  Your two frequencies
could be hundreds of MHz apart.  If the two bandpass filters are the same
width, the effective bandwidth of the system is the same - is it not?

After writing all this, I am not sure I've convinced myself I am right or
wrong but it's fun to think about.  Thanks!

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

Re: [Discuss-gnuradio] SRRC pulse shaping question

[Brian Padalino]

Have you taken into account the group delay of the filter?  How long is
your filter?  Try sending zeroes at the end to flush your filter state?

Brian


On Tue, Dec 4, 2012 at 11:35 PM, George Sklivanitis 
george.sklivani...@gmail.com wrote:

 Hello all,

 I have a question applying to everybody that have tried transmitting
 symbols in different kinds of modulation (BPSK, QPSK, GMSK etc).
 I am using the following configuration in GNU Radio ( random source block
 - bytes to symbols - SRRC block - file sink)

 The attached figure plots the generated symbols (+1,-1)  with red color
 along with the upsampled SRRC waveform (blue)
 For some reason that I am not able to understand the last 8-bits do not
 have a correspondence with the waveform created. In other words
 the waveform is cut at the last byte.
 Can anyone help me with the above.

 Thanks,
 -George

 --
 Sklivanitis Georgios
 PhD Student

 ___
 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] SRRC pulse shaping question

[Brian Padalino]

You'll need to figure out how to flush the filter state and send actual
0+0j samples through.  Maybe you can set a flag and multiply the samples
coming out by 1 or 0 depending if you are flushing or not?

Brian


On Wed, Dec 5, 2012 at 12:11 AM, George Sklivanitis 
george.sklivani...@gmail.com wrote:

  The filter is consisted of 55 taps.
 I tried by sending zeros. Though zeros are interpreted in -1's from the
 modulation mapping block.
 Moreover, the zeros will be taken into account as symbols to be shaped,
 therefore, the same thing will happen.

 -George


 On 12/5/12 12:07 AM, Brian Padalino wrote:

 Have you taken into account the group delay of the filter?  How long is
 your filter?  Try sending zeroes at the end to flush your filter state?

  Brian


  On Tue, Dec 4, 2012 at 11:35 PM, George Sklivanitis 
 george.sklivani...@gmail.com wrote:

 Hello all,

 I have a question applying to everybody that have tried transmitting
 symbols in different kinds of modulation (BPSK, QPSK, GMSK etc).
 I am using the following configuration in GNU Radio ( random source block
 - bytes to symbols - SRRC block - file sink)

 The attached figure plots the generated symbols (+1,-1)  with red color
 along with the upsampled SRRC waveform (blue)
 For some reason that I am not able to understand the last 8-bits do not
 have a correspondence with the waveform created. In other words
 the waveform is cut at the last byte.
 Can anyone help me with the above.

 Thanks,
 -George

 --
 Sklivanitis Georgios
 PhD Student

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




 --
 Sklivanitis Georgios
 Ph.D Student
 Communications Division,
 Department of Electronics and Electrical Engineering
 University at Buffalo, The State University of New York
 North Campus, Office 205, Furnas Hall
 Buffalo, NY 14260www.acsu.buffalo.edu/~gsklivan


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

Re: [Discuss-gnuradio] Questions about OOK mod and demod

[Brian Padalino]

On Wed, Jul 18, 2012 at 2:49 PM, lliao003 lliao...@ucr.edu wrote:

 Hi all!

 I am a rookie and I am working about OOK mod and demod. I have few questions
 following:

 I modify the digital_constellation.cc file as

 d_constellation[0]=gr_complex(0,0)
 d_constellation[0]=gr_complex(1,0)

 like this, I think after re-make, I already achieve OOK mod. However, in
 order to build ook demod, I modify as following:

 return (real(*sample)0.5)

You really want that to be the magnitude of the sample, not just the
real portion.  If you wanted to avoid the sqrt, magnitude squared can
probably work as well.

 I also embed OOK mod and demod into GRC and try to simulation in GRC whose
 flow graph is
 File Source-packet Encoder-OOk mod-Channel Model-Throttle-OOk
 demod-Packet decoder-File sink.
 If there is no noise in channel model, ook mod and demod work perfect, but
 if there is any noise, I can not receive any file.

 Anyone can tell me if I did wrong in modifying the code or there are still
 something I need to modify. Thank you for time and help very much!

Are you filtering your demodulated OOK signal afterwards?  Beforehand?
 How many samples/symbol are you running?

So many questions!  Good luck!

Brian

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

Re: [Discuss-gnuradio] Real-time fading simulation?

[Brian Padalino]

On Wed, May 30, 2012 at 4:23 AM, J Mc columbo_the_leg...@hotmail.com wrote:


 Date: Tue, 29 May 2012 22:15:43 -0400
 Subject: Re: [Discuss-gnuradio] Real-time fading simulation?
 From: bpadal...@gmail.com
 To: columbo_the_leg...@hotmail.com
 CC: discuss-gnuradio@gnu.org


 On Tue, May 29, 2012 at 9:47 PM, J Mc columbo_the_leg...@hotmail.com
 wrote:
  I have been considering using GnuRadio with the USRPN210 as a realtime
  fading simulator for radio hardware testing, however any approaches I've
  considered in doing this seem to fall down fundamentally if I limit to
  using
  a single USRP. I'm still relatively sure it could be done, was wondering
  if
  anyone had any advice/input.
 
  The main issue I've had is trying to understand how to do this with
  single
  antennas systems, if I take something like 2 cheap WiFi nodes both
  attached
  to a common Tx and Rx port is there any way to prevent the transmitting
  node's signal feedback when it hits the receiving node's antenna. If
  anyone
  has looked at this question, opinions would be appreciated...

 I think you can do it with an one USRP1, or two USRPN210s using some
 circulators and a special FPGA load.

 Circulators move in a clockwise motion:

 [WiFi] - [ Circulator ] - [USRP Rx/Tx]
 ^
 |
 v
 [ Circulator ] - [WiFi]
 ^
 |
 v
 [USRP Rx/Tx]

 I think that diagram shows the WiFi card transmitting to the USRP
 Rx/Tx port, the Tx from the USRP goes to the other circulator, and
 into WiFi card.

 The second WiFi card transmits into the circulator then into the USRP
 Rx/Tx port, and the Tx from the USRP goes to the original circulator,
 and into the original WiFi card.

 FPGA load would essentially be programmable with your noise/fading
 profile, and with little host intervention create noise on the
 baseband then retransmit.

 Does that work?

 Brian

 I may be missing something however anyway I try construct this design on
 paper (which is variations on what I've been considering) the following
 issues seem to occur;

 -Many Daughterboards only have 1 Tx channel, which both the nodes must
 connect to, how at transmissions addressed i.e. the circulator won't be
 able to avoid this
 -Because WiFi and other standards that use TDD share a single antenna, they
 must near-simultaneously transmit and receiver. If a USRP Transmission is
 heard by the original node, it will create a feedback loop

That is why you need either 2 USRPN210's or 1 USRP1.  The USRP1 can
have 2 daughterboards which allows you to have 2 independent RX/TX
ports.  The circulators handle the rest for you.

You're correct that using a single TX on a single daughterboard isn't
good enough.

 For the fading I was thinking of just using gnuradio without any FPGA
 alterations, (theres a fading model/noise sources/notch filters), my only
 uncertainty is the ability to receiver and transmit to the same USRP on
 different antenna ports.

I believe there are latency requirements in 802.11 that may be
difficult/impossible to achieve if you're shipping samples back and
forth.  If latency isn't a concern, I think that the above setup
should be valid.

Do you agree?

Brian

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

Re: [Discuss-gnuradio] Real-time fading simulation?

[Brian Padalino]

On Tue, May 29, 2012 at 9:47 PM, J Mc columbo_the_leg...@hotmail.com wrote:
 I have been considering using GnuRadio with the USRPN210 as a realtime
 fading simulator for radio hardware testing, however any approaches I've
 considered in doing this seem to fall down fundamentally if I limit to using
 a single USRP. I'm still relatively sure it could be done, was wondering if
 anyone had any advice/input.

 The main issue I've had is trying to understand how to do this with single
 antennas systems, if I take something like 2 cheap WiFi nodes both attached
 to a common Tx and Rx port is there any way to prevent the transmitting
 node's signal feedback when it hits the receiving node's antenna. If anyone
 has looked at this question, opinions would be appreciated...

I think you can do it with an one USRP1, or two USRPN210s using some
circulators and a special FPGA load.

Circulators move in a clockwise motion:

[WiFi] - [ Circulator ] - [USRP Rx/Tx]
 ^
 |
 v
   [ Circulator ] - [WiFi]
 ^
 |
 v
[USRP Rx/Tx]

I think that diagram shows the WiFi card transmitting to the USRP
Rx/Tx port, the Tx from the USRP goes to the other circulator, and
into WiFi card.

The second WiFi card transmits into the circulator then into the USRP
Rx/Tx port, and the Tx from the USRP goes to the original circulator,
and into the original WiFi card.

FPGA load would essentially be programmable with your noise/fading
profile, and with little host intervention create noise on the
baseband then retransmit.

Does that work?

Brian

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

Re: [Discuss-gnuradio] RTT time of ping based on OFDM tunnel

[Brian Padalino]

On Thu, May 17, 2012 at 7:06 PM, Alex Zhang cingular.a...@gmail.com wrote:
 It seems that the GMSK modulation is doing well in supporting higher
 datarate over GNURadio, than OFDM modulation.

 Today I did test using the GMSK between two USRP N210 nodes, the maximum
 data rate with acceptable packet loss rate of ping (2%) is 3Mbps. It can
 support video transmission.
 This result is much better than the existing OFDM implementation in
 GNURadio. I beleive that OFDM signal processing is much more complex than
 GMSK and cost much more resource than GMSK, but I did not expect that
 GNURadio OFDM link can only support less than 200kbps data rate.

What's the EVM of your OFDM signal coming out of the RF daughterboard?
 Are you backing off enough to allow for OFDM's high PAPR to remain in
the linear region?

GMSK has the nice advantage of being constant envelope, so compression
doesn't matter.  OFDM, on the other hand, doesn't get that luxury and,
in fact, requires a significant backoff.

Have you tried running the code without a USRP and just simulating
AWGN and possibly a slight frequency offset to see if the OFDM code is
adequately robust?  What are your subcarrier modulations?  Are you
running with any FEC?

Sorry for all the questions.

Brian

 Can any guru give your testing result?

 On Wed, May 16, 2012 at 10:41 PM, Alex Zhang cingular.a...@gmail.com
 wrote:

 Hi all,

 I did some experiments of Ping, between two USRP N210 nodes, over the OFDM
 link. I need to know if any other has the same performance as I did.

 This OFDM link is using two frequencies,  900MHz and 1800MHz, as the SBX
 daughter board is used. The antenna is VERT900 which is working in  824 to
 960 MHz, 1710 to 1990 MHz Quad-band .
 Two computers of intel i7 (4 cores @3.4GHz) are used to run gnuradio.

 My performance is that as below:

 Static ARP entries are used for both the computer. Tunnel devices are
 setup receptively to run ping on it.

 Bandwidth = 500K, occ=400/512, average RTT time is 14ms, and packet loss
 of ping is 17%
 Bandwidth = 1M, occ = 400/512, average RTT time is 8ms, and packet loss of
 ping 33%
 Bandwidth = 1.2M, occ = 400/512, average RTT time is 7ms, but packte loss
 of ping is degraded to 90%, means the PC can not support such kind
 bandwidth.

 If I use two intel core 2 PC, the supported bandwidth with acceptable
 paccket loss rate (35%) is a little higher than 500K (RTT = 20ms). With more
 bandwidth, the computer would be slow down significantly and the link
 quality is near crash.

 So I need to know if any other friend have tested such experiment and what
 the corresponding performance is.

 --

 Alex,
 Dreams can come true – just believe.




 --

 Alex,
 Dreams can come true – just believe.


 ___
 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] RDS reception

[Brian Padalino]

On Fri, Feb 24, 2012 at 2:58 PM, Philip Balister phi...@balister.org wrote:
 On 02/24/2012 02:45 PM, Rafael Diniz wrote:
 It would be nice, but it could be fixed up and converted to cmake in the
 current svn repo also...

 But most of us have forgotten how to use subversion :)

For those who want to have their cake and eat it too:

http://subgit.com/

Brian

 Philip




 The CGRAN RDS code seems abandoned, I'm thinking about cloning it to
 github so it can be converted to UHD and Cmake and fixed up.

 On Fri, Feb 24, 2012 at 1:31 PM,  mle...@ripnet.com wrote:
 I don't know about having it inside the main codebase, but converting it
 to
 use the CMake build system would be good, since it didn't really
 understand
 how to place its python files into a filesystem that uses
 /usr/local/lib64--so I had to move them manually.

 -Marcus



 On Fri, 24 Feb 2012 10:23:48 -0800, Rafael Diniz wrote:

 It would be great to have the rds code inside the gnuradio tree instead
 of
 in a separate cgran project!
 ; )

 I don't know why, but when I tried the cgran rds code, the grc example
 worked much better then the python one.

 Best regards,
 Rafael Diniz



 Actually, I'm using the blks2 WBFM block, which I believe is a PLL
 demodulator.

 Both of my test stations are actually roughly 100km
 away from me, broadcasting from a high point in the Ottawa Valley.

 One
 station comes in about 10dB stronger than the other, although both have
 an ERP of about 100kW, and both are located on the same transmit tower.


 I'll send you my 'stuff' once I'm more comfortable with it. The audio
 quality is actually reasonably good, so I think the FM demodulator
 portion is just fine.

 -Marcus

 On Fri, 24 Feb 2012 11:12:28 -0500,
 Andrew Davis wrote:

 I think the problems with SNR is with the FM

 Demod, my car stereo can

 get RDS as the station fades 40 miles away,

 but with my USRP has

 trouble picking up the stereo pilot from a 50kw

 station one mile away

 ( -10dBm ). FM demod is hard for software ( I

 think GNUradio just uses

 a zero-crossing detector ).

 Do you have

 the code, I would love to test it.

 On Thu, Feb 23, 2012 at 11:33

 PM, Marcus D. Leech wrote:

 I managed to get gr-rds built tonight, and

 was able to test it planted inside my FM receiver. Even for a local
 station, there are *lots* of errors, and more distant stations get even
 more. I'm going to play around a bit with filter bandwidths, etc, to see
 if I can improve it. Looking at the modulation technique, it's no big
 surprise--they use a bi-phase baseband coding (basically like
 differential Manchester), that drives a DSB-SC modulator with a carrier
 at 57kHz. But that signal is generally about 20dB below the other audio
 sub-channels on the FM demodulator output. So the SNR is generally
 *terrible*. I'm rather surprised, after looking at it, that anyone
 bother deploying RDS. It seems utterly crappy. It's generally broadcast
 with fairly-low SNR, and there's no FEC built in, only CRC. I re-jigged
 the XML for the demodulator part so you can reset the demodulator state
 machine from within a GRC flow-graph (there was a reset() method on the
 demod, but it wasn't exposed within the XML framework for GRC). Also, I
 may re-jig the decoder portion--it currently injects decoded frames into
 a message queue and to stdout. Might be useful to do other things with
 those messages. Like is there a simple way to have a message dequeuer
 within a GRC flow-graph so that one could stuff messages into a
 variable? -- Principal Investigator Shirleys Bay Radio Astronomy
 Consortium http://www.sbrac.org [1]
 ___ Discuss-gnuradio mailing
 list Discuss-gnuradio@gnu.org [2]
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [3]




 Links:
 --
 [1] http://www.sbrac.org
 [2]
 mailto:Discuss-gnuradio@gnu.org
 [3]
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 [4]
 mailto:mle...@ripnet.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


 ___
 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] discussion on USRP--Wall Socket for Power Line Comms

[Brian Padalino]

On Tue, Feb 21, 2012 at 3:00 PM, George Nychis gnyc...@gmail.com wrote:
 Okay!  So apparently there is some interest in power line communication for
 GSoC.  But, what we would want to do is already have a safe way of
 connecting the USRP in to the wall socket for the student(s), and for the
 future of GNU Radio and USRP power line communications development.

 So, as a goal of this thread I'd like to get some feedback on how we can
 make this possible.  Ideally, something off-the-shelf would be great,
 providing the highest amount of safety for those experimenting with it.

 Please keep in mind my background is not EE, but I am more than happy to try
 and lead this and test/try/sacrifice what needs to be done.

 Jonathan mentioned that for a project he was working on before, generic
 50-ohm wall socket power couplers were made.  I don't know how difficult it
 would be to replicate something like this.

 Evan Merewether suggested picking up some power line telephone extenders
 from Radio Shack and dissecting them.

 Ideally, I think we could connect whatever it is to a basic TX/RX.

 Any thoughts here?

Not sure how much they are or where you can even buy them, but they're
pretty much perfect for this:

http://www.onfilter.com/products.html?s=MSN01

Brian

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

Re: [Discuss-gnuradio] discussion on USRP--Wall Socket for Power Line Comms

[Brian Padalino]

On Tue, Feb 21, 2012 at 5:03 PM, Johnathan Corgan
jcor...@corganenterprises.com wrote:
 On Tue, Feb 21, 2012 at 13:20, Nick Foster n...@ettus.com wrote:

 Before anyone goes out there and barbecues themselves with a USRP, two
 things:

 1) Use Ettus Research products for power-line or hazardous voltage
 applications at your own risk and after careful evaluation by competent
 engineer.

 Yep.  While of course individuals may choose to go whatever route for
 their own experimentation, if we (GNU Radio project) do anything with
 GSoC related to power line communications, the student would need to
 use a commercially manufactured product that has been engineered for
 the purpose and have UL and/or CE certification.

Maybe something a little more accessible from MAXIM:

  http://www.maxim-ic.com/products/powerline/

They have an evaluation kit which might have some testpoints to
connect up to a USRP, or try to ship off samples through their 10/100
ethernet interface.

Brian

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

Re: [Discuss-gnuradio] A function named usb_control_msg

[Brian Padalino]

2011/11/29 signalswdm signals...@yeah.net:
 Dear everyone:
   You see in usrp_basic.h there is a function named _write_9862() and
 it uses function usrp_9862_write(),defined in usrp_prims_common.h. And
 usrp_9862_write() uses function usrp_spi_write(), also defined in
 usrp_prims_common.h.
 usrp_spi_write() uses function write_cmd(), defined in usrp_prims_libusb0.c
 and usrp_prims_libusb1.c.
  In usrp_prims_libusb0.c write_cmd() uses a function named
 usb_control_msg(). But I can not find where usb_control_msg() is. Can anyone
 tell me where it is???

libusb:

http://libusb.sourceforge.net/doc/function.usbcontrolmsg.html

Brian

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

Re: [Discuss-gnuradio] Anyone do you know good GPS receiver Method?

[Brian Padalino]

2011/11/18 山本弘貴 k.yamamoto.0...@gmail.com:
 Hi, All
 I have  very trouble
 My experiment enviroment isUBUNTU 11.04 , USRP N200, DBSRX2 ,active
 antenna and gnuradio
 I am worrying about good software GPS receiver is not　exist .
 I want to receive L1 signal , and want to demodulate that signal
 However GPS signal is used  Spread spectrum modulation scheme.
 I try to creating gnuradio-companion's blocks.(use to Spread spectrum
 demodulation blocks)
 but that is very difficult so Now I think method is

 　GPS L1　signal → USRP N200 →　gnuradio-companion(UHD_source→File_sink)
 →　software decode soft →　output(Location data)


 Eventually　I want to Calculate location data,
 Please let me know if you're a good　this way

I recently came across this product listing at Spark Fun:

http://www.sparkfun.com/products/10981

Which has a link to a book all about GPS receiving and even comes with
MATLAB source code:


http://www.amazon.com/Software-Defined-GPS-Galileo-Receiver-Single-Frequency/dp/0817643907

I am sure, with the source, you could adapt it to use the USRP
recorded signal, and then possibly port the MATLAB over to either
Python (using Josh's signal processing in Python blocks) or straight
C++.

 I am sorry that My English is not good

 Kouki

Good luck - it's definitely not a trivial task, but it sounds extremely fun.

Brian

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

Re: [Discuss-gnuradio] Designing a good receiver

[Brian Padalino]

On Thu, Jun 2, 2011 at 7:10 AM, Mike Clark undefinedsp...@gmail.com wrote:
 This comes from a discussion over on the USRP-users mailing list, but
 I felt it would be more appropriate to post here. Over on that list,
 someone was asking about problems they were having consistently
 receiving data on their USRP. My background is in CS, not RF comms, so
 please forgive me as I'm sure the answer will be fairly standard :)

 Anyways, the question I have is, is there a general procedure one can
 follow to design a decent receiver in gnuradio? For example, I have a
 project that I'm using for experimentation where my receiver looks
 like this: USRP Source - GMSK Demod - Packet Decoder - File Sink.
 This works well when I have the USRPs cabled together and even when I
 have antennas with line of sight (I haven't checked max distance).
 When I don't have line of sight, however, I stop receiving packets.
 Are there any other gnuradio blocks I can add in to my setup which
 will help get better performance when there is no line of sight? I
 haven't tested it, but my guess is that when there is no line of
 sight, there must be a frequency shift or something of that nature
 happening which ruins the connection.

Transmitting is the easy part, it's the receiving that is difficult.

Recently, there were some articles printed by EE Times about propagation:

http://www.eetimes.com/ContentEETimes/Documents/McClaning_3_pt1.pdf
http://www.eetimes.com/ContentEETimes/Documents/McClaning_3_pt2.pdf

They are from the book Wireless Receiver Design for Digital
Communications, 2nd Edition, by Kevin McClaning.  This is probably
good reading in general.

Good luck.

Brian

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

Re: [Discuss-gnuradio] How can we measure the frequency offsets between two USRPs?

[Brian Padalino]

On Sun, May 15, 2011 at 3:30 PM, John Andrews gnu.f...@gmail.com wrote:
 How can we correctly measure what is the frequency offset between the two
 USRPs?

Set one USRP to send CW.  Tune the other USRP to receive CW.

The resultant frequency on the receiver side is the frequency offset.

 Thanks

Make sense?

Brian

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

Re: [Discuss-gnuradio] Questions about E100

[Brian Padalino]

On Thu, May 5, 2011 at 5:42 PM, Scott Johnston
scott.johns...@ll.mit.edu wrote:
 Hi,

 Has anybody out there done any development on the DSP? What tools are
 available to program it? I have used TI's code composer in the past to
 program DSPs, is there something comparable to that included with E100, or
 is it easy to get it?  What I would like to be able to do is obtain common C
 libraries and compile C code to run on the DSP.

With a TI account, you can grab the free tools here:


https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.htm

Brian

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

Re: [Discuss-gnuradio] Questions about E100

[Brian Padalino]

On Thu, May 5, 2011 at 6:07 PM, Brian Padalino bpadal...@gmail.com wrote:
 With a TI account, you can grab the free tools here:

    
 https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.htm

Also, another good resource for all TI processors seems to be:

http://processors.wiki.ti.com/index.php/Main_Page

Brian

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

[Discuss-gnuradio] Dual Gigabit Ethernet PCIe FPGA Card

[Brian Padalino]

I recently saw that Lattice Semiconductor is having a promotion for a
development kit that has PCIe x1, dual gigabit ethernet and 1Gb DDR3
for $99:


http://www.latticesemi.com/products/developmenthardware/developmentkits/ecp3versadevelopmentkit.cfm

This might be interesting for people who are looking for an
intermediary with low-latency between a USRP N-device (or two of
them?).

Just raising awareness on, what I think, is a pretty decent deal.

Brian

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

Re: [Discuss-gnuradio] TI vs Freescale DSP for open-source development

[Brian Padalino]

Hi Alexander,

On Fri, Jan 28, 2011 at 10:14 AM, Alexander Chemeris
alexander.cheme...@gmail.com wrote:

 2) Development tools price
 Both Freescale CodeWarrior and TI Code Composer seem to be at the same
 line with about $2K per single license (correct me if I'm wrong - I
 may have missed something easily).

 Big minus here is that neither Freescale nor TI offer open/free
 compilers for their DSPs, which is a big roadblock for open-source
 development.

TI has a free download of their DSP compiler.  Information can be found here:

http://processors.wiki.ti.com/index.php/Compiler_Releases

I don't know what the licensing is like, but I thought I'd let you
know you can at least generate code without paying $2k.

Brian

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

Re: [Discuss-gnuradio] GNURadio is disappointing [was: Greeting and a question]

[Brian Padalino]

I changed the subject to better match the tone of the email.

On Thu, Jan 20, 2011 at 11:12 AM, Sanjay Singh
sanjaysinghshyam...@gmail.com wrote:
 Hi all,

 Am disappointed with the way GNURadio is getting into.

 I see all the discussion around is to promote the products of Ettus
 Research.

 Agreed!. Great work from Ettus Research.

 But there are many boards available which are far better in capability vs
 price. I don't want to mention them here to deviate the concern.

 During the market for USRP1, no one in the forum focused discussion on
 embedded platform. When queries regarding any such embedded platform was
 posted, there were lot of quotes saying GNURadio is focused on developing
 SDR framework based on Desktop based solution. With Ettus Research coming
 out with USRP E100, everyone on is bouncing on embedded platform.

 I wonder; Is GNURadio biased with Ettus Reserch ?. My obvious understanding
 is NO!.

 Its the community of people driving Ettus products into market. The
 potential of doing so is to make money. Either way, Ettus Research is now
 part of National Instruments and may be now GNURadio be delinked with Ettus
 Research for being open source. There are many people who can contribute low
 cost open source solutions.

 Initially, all the Hardware and software was part of GNURadio. All the files
 was part of free source available to download and use. In around a year or
 so all the files from GNURadio were moved out separating hardware and
 software. All the hardware related files were not available after this. Why
 so, no one knows.

 The boards when purchased from Ettus Research it was under terms and
 conditions as free open source schematics for motherboard and free open
 source schematics and pcb files.

 Its time now for the community of people interested in building free open
 source platform including both software and Hardware to come out with an
 complete open source low cost solution.

 S---

I need to borrow your soapbox.

This e-mail infuriates me.  If you thought you bought a motherboard
from Ettus under the terms that you were getting schematics and PCB
files and blah blah blah, fine.  If you didn't get them, point to the
line item on the receipt or the clause in the contract and take it up
with Ettus.

Next - the general tone of GNU Radio seems to be biased towards Ettus
only due to the fact that he, Josh and a whole slew of other people
worked damned hard to not only develop their hardware, but make sure
it was compatible with GNU Radio.

Let me repeat that.

Matt, Josh, and the rest of the people at Ettus Research did damn near
ALL the legwork - software and hardware - to make it compatible with
GNU Radio so you can buy something, plug it in and make it work.
Moreover, they field support questions on an open forum for free.  To
dismiss this fact is grossly inappropriate.

On that note, I have put together a simple list of things for people
to do if they feel they want to get out of this Ettus Research
totalitarian dictatorship that is GNU Radio:

1) Create your own RF front end boards
2) Create your own digital/baseband board
3) Write all the software for board in step (2) to control all the
boards you create in step (1)
4) Write all the host side software to interface software written
in step (3) with GNU Radio
5) Contribute all previous work to GNU Radio
6) Stop complaining*

*NOTE: Steps 1-5 are optional.

I am a massive proponent of making some 100% fully open SDR hardware
that serves the low cost/cheap and
easily-modifiable-for-my-specific-purpose market.

Like I said in my original e-mail, stop asking and stop the rhetoric.
If you want to dethrone Ettus from the monopoly he has on the GNU
Radio hardware scene, you just need to do something.  GNU Radio is
open source.  Make your board and contribute your patches.

In other words, do some work if you don't like the current state of
things.  This community is driven by the people on this list.  If you
don't like something about it, you need to have the drive to change
it.  Demonizing Ettus Research is childish.  If anything, look at
their past and draw inspiration from it.

I look forward to seeing your patches in GNU Radio.

Thanks for the soapbox.

Brian

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

Re: [Discuss-gnuradio] How to run gnuradio application with a file input and no physical receiver?

[Brian Padalino]

Hi Lee,

On Sun, Jan 16, 2011 at 3:25 PM, Lee McKusick lee...@gmail.com wrote:
 Hello and thanks for your guidance:

 I would like to run the gnuradio software package with an input file and
 other input data.

 So far, when I run examples in gnuradio-examples the application stops
 because no USRP is found.

Try using the audio examples, or bypass the examples all together and
use gnuradio-companion to setup your signal flow.  Feel free to change
the audio sources from those examples and replace them with generated
signal sources.

 A short term goal is to learn about the process of digital signal
 recovery. The long term goal is to use input data from a breadboarded
 digital radio gadget.

 Thanks again, Lee McKusick

Brian

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

Re: [Discuss-gnuradio] Low-cost hardware options

[Brian Padalino]

On Sat, Jan 15, 2011 at 9:56 PM, John Gilmore g...@toad.com wrote:
 Also upgraded to the next speed-grade of the ADC, to give 40Msps...

 You spec'd only a 12-bit ADC.  In my naive view, resolution seems like
 it's more important to SDR than samples per second.  Resolution is how
 you avoid losing weak signals when you are of necessity sampling a
 wide band.  Can we improve on this to get a 14- or 16-bit ADC, perhaps
 with a lower sampling rate, at a reasonable price?

It's all about power, right?  So you may sacrifice sample rate for
accuracy, but you can gain those bits back in the digital domain via
filtering.  Only if you really want to see more than the 72dB of
dynamic range the ADC supplies do you somewhat get screwed, I think.
I've heard of people recovering very narrowband signals with
narrowband blockers where the desired signal is below the dynamic
range at their fastest sample rate, but through digital filtering were
able to bring the signal out of that noise floor.  I haven't done it
myself.

In my opinion, being able to play with emerging wireless standards in
the 1MHz to 20MHz or even 40MHz bandwidth area is more appealing than
being able to pull them from the muck.  I was reading about the WHDI
wireless HD technology and thought it would be very interesting to
read about and sample.  Link here:

http://www.whdi.org/Technology/

I know plenty of people will disagree with me so it's just an opinion.

 As I recall from early USRP days, clock jitter makes a real mess of
 doing anything important with an SDR.  If you can't trust your clock,
 you don't know when your samples happened, which makes all the
 computation a lot fuzzier.  That's why the USRP didn't synthesize its
 sampling clock -- nobody back then built a synthesized clock that had
 low enough jitter.  Does this ADF4351 qualify?  And what kinds of
 interactions are there between that clock and the clock on the ADC?
 Shouldn't the downsampler and the digitizer both be using the same
 clock, or a clock that's derived from the same clock?

Clock jitter is pretty detrimental with a high IF, but with baseband
sampling, I can't imagine even the clock an FPGA synthesizes to be too
terrible.  You may not be able to do 1024-QAM, but for modest
modulations I am sure it should be fine.  On the other hand, Silicon
Labs seems to make some pretty spectacular clock synthesis chips with
single-digit picosecond RMS or even sub picosecond RMS jitter numbers.

 Is there a way to use i2c programmable width filters instead of the 20
 MHz lowpass filters, to narrow the bandwidth of the signal being
 digitized down to just the range of interest?  This would help
 ameliorate the low-res ADC by filtering out nearby
 loud-yet-uninteresting signals.

By that time, there's a good chance the damage has been done with the
RF mixing.  The real way, on the RX side of things, would be to use
preselector filters so mixing products and other bad things don't get
in the way.  This is especially true for direct conversion receivers
where you have DC, gain and phase imbalances coming into the ADC.
When you have large blockers or jammers, they replicate themselves
through those imbalances and it just becomes a huge mess to try to
deal with.

But, back to your point about I2C programmable width filters, Skyworks
makes some that are SPI.  The SKY73202-364LF is one for direct
conversion receivers or for reconstruction filters for DACs.  Link
here:

http://www.skyworksinc.com/Product.aspx?ProductID=400

Relatively inexpensive as well.

 Finally, don't assume that a USB3 chip will easily support downgrading
 to a USB2 connection.  It ought to be that way, but might not be.  The
 EZ-FX2 chip does support both USB1 and USB2, but in the last ten
 years, nobody ever got around to programming the USRP firmware to
 actually make it work with USB1.  That became somewhat moot as USB2
 became standard in everything.

Superspeed USB explicitly states that there are two connections - the
superspeed wires and the USB2 wires.  When superspeed is present, both
methods of communication must be supported.  In fact, it even states
that they can be used in tandem.

 Similarly, the GigE interface on the USRP2 has never supported
 downgrading to 100 Mbit Ethernet, even though that's part of the GigE
 spec.  However, now that they've switched to using a UDP-based
 protocol rather than an Ethernet-frame-based protocol (finally -
 hooray!), you can plug the USRP2 into a switch.  Switches all allow
 10, 100, and 1000 Mbit/sec Ethernet to communicate.  If you're going
 to put 1GE on this device rather than USB2 or USB3, I suggest
 including a switch chip too, so it will transparently talk to any
 speed of Ethernet.  GigE is still too uncommon on laptops these days.

        John

Brian

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

Re: [Discuss-gnuradio] re: Low cost hardware option

[Brian Padalino]

On Wed, Jan 12, 2011 at 8:36 PM, Jamie Morken jmor...@shaw.ca wrote:

 Hi,

 I am interested in helping out with making some new gnuradio hardware that is 
 compatible with the USRP daughterboards.  I worked with Matt doing CAD on the 
 original gnuradio project hardware and have since then made lots more boards 
 including a cyclone 3 board.

 Here is a possible hardware configuration:
 USB 3.0 transceiver IC or USB 3.0 microcontroller
 Altera Cyclone3 FPGA
 highspeed DAC/ADC

 If we use just a single channel ADC and DAC (ie half a USRP v1) then we can 
 get away with a smaller/cheaper FPGA and have a cheaper/simpler board that 
 can be paralleled if needed (ie. two boards hooked up to USB 3.0)

The idea of USB3 is nice for the future, but I don't think there are
enough peripherals out there yet to make a good board.  I can't really
find anything that's not completely preliminary and somewhat cheap.
I'd like to propose what I think may be a good compromise.

Altera Cyclone IV EP4CGX15 FPGA, Analog Devices AD9861 MxFE, USB2
microcontroller (for reprogramming the FPGA) in an ExpressCard/34
format.  The FPGA has a hard PCIe 1.1 x1 lane with a hard IP core for
PCIe connectivity.  The PCIe interface has an extremely low latency
and pretty high throughput - ~200MB/sec full duplex (after overhead
and whatnot).  The FPGA would be mostly empty since the PCIe core is
hard.  If the F169 package is used, it should be compatible with up to
a EP4CGX30 which would give 80 18x18 multipliers and over 1Mbit of
embedded memory.  The ExpressCard format can fit into desktop PC's
with simple and cheap adapters, or into laptops which have ExpressCard
slots.

ExpressCard has both an x1 PCIe connection as well as a USB 2.0
connection.  I imagine a small USB 2.0 micro used for FPGA
configuration and, possibly, a secondary way for samples to enter/exit
the FPGA for different use cases (similar to the original USRP).  But
the main purpose would be for reconfiguration of the FPGA.

Frequency synthesis can be an optional part of the assembly.  I
imagine a relatively inexpensive VCTCXO (2ppm accuracy?) along with an
Si5338 clock synthesis chip.  The idea, though, is to be completely
optional for those who really want it.  Otherwise, the FPGA PLL's can
probably be good enough for most people.

For connectors, 2 HDMI (commodity and cheap, twisted pair, shielded
and rated to relatively high frequencies) - one for analog/baseband
signals, one for digital I2C/SPI comms.  Goes to a daughterboard
carrier which can hold the daughterboard and a digital IO port
expander for controlling the RX/TX IO [0:15] pins for the db
connectors.

I think the high bandwidth, low latency, and low CPU utilization of
PCIe is very attractive.  The main downside to the parts are the BGA
components which can be daunting for hobbyists, but toaster ovens with
PID controllers can really do a pretty amazing job.  I'm not sure if
this is a dealbreaker or not.

I'm very interested to hear other people's opinions as to proposed
interfaces, platforms, architectures, and connectivity.

Jamie, I hope you don't see this as a hijacking of your original
e-mail.  I am particularly interested in your response.

Brian

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

Re: [Discuss-gnuradio] re: Low cost hardware option

[Brian Padalino]

On Wed, Jan 12, 2011 at 10:26 PM, Marcus D. Leech mle...@ripnet.com wrote:
 On 01/12/2011 10:01 PM, Brian Padalino wrote:

 Altera Cyclone IV EP4CGX15 FPGA, Analog Devices AD9861 MxFE, USB2
 microcontroller (for reprogramming the FPGA) in an ExpressCard/34
 format.  The FPGA has a hard PCIe 1.1 x1 lane with a hard IP core for
 PCIe connectivity.  The PCIe interface has an extremely low latency
 and pretty high throughput - ~200MB/sec full duplex (after overhead
 and whatnot).  The FPGA would be mostly empty since the PCIe core is
 hard.  If the F169 package is used, it should be compatible with up to
 a EP4CGX30 which would give 80 18x18 multipliers and over 1Mbit of
 embedded memory.  The ExpressCard format can fit into desktop PC's
 with simple and cheap adapters, or into laptops which have ExpressCard
 slots.

 ExpressCard has both an x1 PCIe connection as well as a USB 2.0
 connection.  I imagine a small USB 2.0 micro used for FPGA
 configuration and, possibly, a secondary way for samples to enter/exit
 the FPGA for different use cases (similar to the original USRP).  But
 the main purpose would be for reconfiguration of the FPGA.

 Frequency synthesis can be an optional part of the assembly.  I
 imagine a relatively inexpensive VCTCXO (2ppm accuracy?) along with an
 Si5338 clock synthesis chip.  The idea, though, is to be completely
 optional for those who really want it.  Otherwise, the FPGA PLL's can
 probably be good enough for most people.



 There are a couple of downsides to a PCIe implementation that I can
 think of:

  o not all host platforms are going to have PCIe slots
  o it's noisy in there!

Agreed on PCIe, though I think less platforms have USB3.

When speaking of noise at baseband (2V driving 50Ohms), assuming you
have a little can over the analog bits, is the noise that high?

Brian

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

Re: [Discuss-gnuradio] Re: A Humble Request....for allowing to copy Circuit into PCB

[Brian Padalino]

Hi Marten,

On Sat, Jan 8, 2011 at 6:39 PM, Marten Christophe technosa...@gmail.com wrote:
 Hello Mr. Ettus,
 Do you have any plan to reduce price for USRP1 or release PCB layout for
 poor students?

So I have a feeling your requests are going to go unanswered, and I
don't blame the deaf ears one bit.

Here starts some guidance, maybe a little ranting, but try to take
from it some good direction as to where students should go and take
their want and desire for hardware.

The metaphor of a dog chasing a car really stands firm in this case.
Once the dog catches the car, or the student acquires a USRP, what are
they going to do with it?  In both cases, I predict - nothing!

So lets figure out something that is worth while for you to do -
simulate something.  Simulate anything!  There is a channel simulator
built into GNU Radio.  Use it.  Get familiar with it.  Familiarize
yourself with channels of varying types.  If you can't get that
channel simulator to work, make your own!  Prove it accurately
simulates different channels.  Understand frequency offset,
synchronization problems, non-coherent and coherent reception, dynamic
range, multipath, equalization, forward error correction, etc.

What you seem to not realize or understand is that the GNU Radio
software that you can compile and putz around with is worth
significantly more to you than any piece of hardware that will capture
or create EM radiation.

I implore you, as a student, to write papers using GNU Radio, create
and simulate systems using GNU Radio, and get your BER curves where
you think they should be using GNU Radio.  When you accomplish that,
then maybe you could ask someone for some hardware to perform
experiments and see how your system works in the real world versus
your simulation.  Do the models match?  Where do they differ?  Are you
on your way to becoming a communications expert?

I believe, wholeheartedly, that if you showed this level of drive,
understanding and expertise, you could probably find someone to either
front the money to buy you a system for you to continue your work or
gladly donate something to you.  But until you can figure out what
you're going to do with the car after you catch it and show you are
competent, I doubt this line of questioning will be any better than
interrogating a brick wall.

My sincerest apologies if this comes off as crass or rude, but I
honestly tried to be motivating and give direction.

Good luck with your endeavors.

Brian

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

Re: [Discuss-gnuradio] RX waveform is not what I expected...

[Brian Padalino]

On Tue, Jan 4, 2011 at 12:27 AM, Songsong Gee gee.songs...@gmail.com wrote:
 I have RFX400 daughter boards on both TX and RX side and set them on 450MHz.
 TX details are below:
 grc file / image / scope plot
 RX details are below:
 grc file / image / scope plot
 As you can see, the scope plot on RX side is not what I expected, I wanted
 rectangular waveform like TX side
 and this weird waveform is a part of LONG sinusoidal wave
 how can I fix it to get a fine waveform?

Looks like you suffer from a frequency offset problem.  Try finding
the magnitude or power of the signal, and you'll get something more
similar to the transmitted waveform.

 --
 Seokseong Jeon (aka Songsong Gee)

Brian

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

Re: [Discuss-gnuradio] WBX image rejection

[Brian Padalino]

On Tue, Dec 21, 2010 at 11:48 PM, USRP9 tie...@gmail.com wrote:

 Hi,

 I have few questions about WBX daughter card:

 1. Is it possible to receive signal from both TX/RX or RX 2 ports
 simultaneously?

 2. How WBX mixer reject image? Is it complex mixer? If true, the mixer will
 have two inputs and the inputs will be feed I assume an RF signal from
 either TX/RX or RX2 port will be fed with a same RF signal from either TX/RX
 or RX2 port. Is my thought correct?

 3. Please let me know the frequency range of the WBX board local oscillator.

 Thanks in advance for your answers

While I don't own a WBX or even have any experience with USRPs in
general, I am still aware and grateful that Matt publishes the
schematics for his circuits.  For the WBX, check here:

http://code.ettus.com/redmine/ettus/documents/17

It's only 5 pages long and pretty well documented with part numbers
and even a power budget.

If you need other documents, try here:

http://code.ettus.com/redmine/ettus/projects/public/documents

And if you need to know where I found those links, it was from here:

http://www.ettus.com/faq#pcb

This is probably not the answer you want to hear, but it's the one
that pushes you to look at the parts, understand the circuit and
experiment more.  It also makes you rely less on the mailing list and,
hopefully, more on yourself.

Good luck.

Brian

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

[Discuss-gnuradio] Intel Stellarton Configurable Processor (for SDR?)

[Brian Padalino]

I don't know where I've been, but this is the first time I've seen
anything about the announcement:


http://www.slashgear.com/intel-stellarton-atom-e600fpga-promises-flexible-embedded-devices-14102251/

While the Atom processor is not very powerful, pairing it with a full
fledged FPGA sounds promising for SDR that can work using fixed-point
algorithms.

Has anyone else heard about this processor?  Is anyone else interested in it?

I saw Altera is going to release Qsys which will support the
processor/FPGA design flow:


http://www.altera.com/b/embedded-fpga-design-flow.html?GSA_pos=1WT.oss_r=1WT.oss=qsys

What are other people's thoughts?

Brian

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

Re: [Discuss-gnuradio] USRP spike

[Brian Padalino]

Hi Naveen,

On Mon, Aug 16, 2010 at 2:05 PM, naveen nischal
naveen_crys...@yahoo.co.in wrote:

 Brain,
 Thanks for the reply. We have tried terminating the antenna input, the spike
 still shows up. We also tried tuning a bit away from the signal of interest
 and mixing the signal of interest to baseband but it doesn't seem to help,
 the spike just follows the signal all over.

I expected the DC offset to still show up after terminating the
antenna input, but I don't understand how the spike always follows the
signal unless something is actually there.

From your example, you have 435.300MHz as your center frequency which
appears to have a large signal present.

If you tune to 437.300MHz, do you see a strong signal at 435.300MHz
still - or does it follow your center tuning to 437.300MHz and
435.300MHz is in the noise floor?

 Thanks,
 Naveen

Brian

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

Re: [Discuss-gnuradio] USRP spike

[Brian Padalino]

Hi Naveen,

On Mon, Aug 16, 2010 at 6:01 PM, naveen nischal
naveen_crys...@yahoo.co.in wrote:

 Brain,
 Sorry my bad...your earlier technique worked.  Thanks much
 Regards,
 Naveen

Glad you were able to get it figured out.

Brian

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

Re: [Discuss-gnuradio] Combining filters

[Brian Padalino]

On Sat, Aug 14, 2010 at 7:59 PM, Marcus D. Leech mle...@ripnet.com wrote:
 I have an application that's running on some fairly spartan hardware,
 so I'm trying to find ways to make the
  flow-graph more computationally efficient, so that I have more
 headroom for inevitable feature creep.

 Part of my flow-graph has a FIR bandpass filter, which is followed
 immediately by an FFT filter.  The FIR bandpass is simply
  to define my passband of interest (I bring in 1MHz, but only need/want
 700KHz in the middle), and the FFT filter is designed
  to allow me to dynamically notch-out narrowband interferers.   Is
 there an efficient way to combine these two into a single
  filter, that will be more computationally efficient than two filters
 in series?

You should be able to convolve the time domain taps of both filters to
achieve the cascaded performance of the two filters in series.

I am not sure this would really yield any better computational
results, but it's the easiest thing that comes to mind.  Switching to
fixed point for your filtering may be the best bang-for-your-buck as
long as you don't need a massive amount of dynamic range.

I'd be interested to hear what solution you come up with.

 --
 Marcus Leech
 Principal Investigator
 Shirleys Bay Radio Astronomy Consortium
 http://www.sbrac.org

Good luck.

Brian

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

Re: [Discuss-gnuradio] Combining filters

[Brian Padalino]

On Sat, Aug 14, 2010 at 8:18 PM, Marcus D. Leech mle...@ripnet.com wrote:
 On 08/14/2010 08:08 PM, Brian Padalino wrote:
 On Sat, Aug 14, 2010 at 7:59 PM, Marcus D. Leech mle...@ripnet.com wrote:

 I have an application that's running on some fairly spartan hardware,
 so I'm trying to find ways to make the
  flow-graph more computationally efficient, so that I have more
 headroom for inevitable feature creep.

 Part of my flow-graph has a FIR bandpass filter, which is followed
 immediately by an FFT filter.  The FIR bandpass is simply
  to define my passband of interest (I bring in 1MHz, but only need/want
 700KHz in the middle), and the FFT filter is designed
  to allow me to dynamically notch-out narrowband interferers.   Is
 there an efficient way to combine these two into a single
  filter, that will be more computationally efficient than two filters
 in series?

 You should be able to convolve the time domain taps of both filters to
 achieve the cascaded performance of the two filters in series.

 Oh, I knew somebody would say just convolve 'em, but that yields a
 filter that's
  computationally the some order as the two in series, give or take.  Sigh.

Glad I could be that somebody.

 I am not sure this would really yield any better computational
 results, but it's the easiest thing that comes to mind.  Switching to
 fixed point for your filtering may be the best bang-for-your-buck as
 long as you don't need a massive amount of dynamic range.


 My impression is that floating-point performance these days, on *86
 hardware,
  is generally better than integer, particular with the SIMD floating-point
  instructions.  The particular platform is Atom based, a D510, which is
  a dual-core CPU running at about 1.7GHz.  The current app is taking up
  about 65% of the combined CPU, and I just want to get a little more
 headroom.

If you take that approach, you'd get better performance for the longer
SIMD instructions since you wouldn't be fetching as many instructions
using the convolved filters, right?  The number of operations ends up
being the same, but how quickly and how concise you can tell the
processor to do the operation is what you're fighting now it seems.

It's a shame it's a D510 and doesn't support DPPS or DPPD dot product
instruction as described here:

http://en.wikipedia.org/wiki/SSE4#SSE4.1

Either way, you may be able to pack twice as many samples if you use
16-bit samples instead of 32-bit floats:

http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions

But that ends up as a reduction in dynamic range, which I'm not sure
you can deal with.

 I'd be interested to hear what solution you come up with.


 Me too :-)

 Actually, something I'd thought of would be to treat the edges as
 multiple contiguous
  notches, and run that in the FFT filter only, and eliminate the FIR
 bandpass filter.  But I'm not sure
  I'll get really good stop-band attenuation that way.

Not knowing your bandpass FIR filter, but guessing equiripple - you
could complex mix your center to baseband and do a real low-pass
filter which should be a lower order than an equivalent bandpass
equiripple - but I am making a lot of assumptions about your filters,
your data/dynamic range requirements and all sorts of other crucial
bits.


 --
 Marcus Leech
 Principal Investigator
 Shirleys Bay Radio Astronomy Consortium
 http://www.sbrac.org




In the end, I'm no microarchitecture expert - especially when it comes to x86.

Good luck.

Brian

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

Re: [Discuss-gnuradio] ADC calibration

[Brian Padalino]

On Fri, Aug 13, 2010 at 3:17 PM, Daniel Halperin
dhalp...@cs.washington.edu wrote:
 On Tue, 10 Aug 2010, Matt Ettus wrote:

 When using a BasicRX or LFRX with the PGA set at 0dB gain (USRP1 only),
 +10dBm is full scale on the ADC.  On the USRP2 full scale on the ADC is full
 scale when it gets back into gnu radio.  On the USRP1 full scale on the ADC
 is (1.67/2) times full scale due to the gain of the CORDIC.

 +10dBm = 2Vpp = 1 Vpeak = 0.7 Vrms

 With other daughterboards you will need to calibrate at the frequency of
 interest.

 Thanks, that's helpful.  However, I can't quite make the math work:

 P = V^2/R ; 0.01 W = (1 V)^2/R ; R = 100 Ohms.

 But we're using SMA connectors which are 50 Ohms right?  Or should I be
 putting 1 Vpeak I *and* 1 Vpeak Q and getting the 100 Ohms from the
 combination of the two 50 Ohm connectors?

This may be helpful:

http://en.wikipedia.org/wiki/Alternating_current#Mathematics_of_AC_voltages

Note the usage of Vrms for power calculations and not Vpeak.

 Thanks,
 Dan

 (forgot to reply all first, sorry for the double-msg Matt)

Good luck.

Brian

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

Re: [Discuss-gnuradio] USRP1 Inband firmware questions

[Brian Padalino]

On Thu, Aug 12, 2010 at 8:27 AM, Sylvain Munaut t...@246tnt.com wrote:
 Hi,

 I'm trying to adapt openbts to the inband firmware for which the source
 are available. (it seems the sources for the std_inband.rbf that openbts
 uses has been 'lost')

 Two things I'm faced with

  - How can I know the 'current' TX timestamp ? I want to send a ping
 command, but I don't see a way to know what timestamp I should use.

I think there is a NOW timestamp of all F's.

  - The timestamp seems imprecise: I often get a timestamp difference
 between two packets of 24191 or 24193  while I should in fact get 24192
 (I'm at 192 decimation). With such a high decimator, I can fix it up
 myself, but still, that looks weird.

From what I remember, there were some issues with that count.  I am
not sure if anyone fixed them.

 Cheers,

   Sylvain

Good luck.

Brian

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

Re: [Discuss-gnuradio] USRP spike

[Brian Padalino]

On Thu, Aug 12, 2010 at 1:56 PM, naveen nischal
naveen_crys...@yahoo.co.in wrote:

  Hi All,
 
  We have been using the USRP1 with the WBX card on it to communicate with
  the AO-51 satellite. We are expecting to hear from the satellite using
  an Fm Receiver GRC at 435.300 MHz but don't receive anything as yet, we
  are pretty sure about our antenna setup and the GRC are right. The
  problem though is a spurious spike of about 17db which appears at
  whatever center frequency we tune to in the spectrum. we think that this
  might be the problem as that might be jamming the signal which was
  supposed be about the same db level. The point of notice for us is that
  this spike is always there even without the antenna connected. the fft
  is directly the output of the usrp source in the grc so, we are
  presuming that the problem might be in the usrp motherboard .
  Attached is the screenshots FM receiver spectrum. Did anyone have this
  problem? How can we fix it?.

Terminate your antenna input.  Does it still show up?

Chances are you have a DC offset at the ADC that needs to be removed.
This will happen if the DDC in the FPGA isn't required to resolve any
frequency offset due to the limitations of the LO in the RF chain.

One way to mitigate this is to tune a little bit away from your signal
of interest, then mix your signal of interest to baseband, and filter
off the DC component.

 Thanks,
 Naveen

Hope this helps, and good luck.

Brian

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

Re: [Discuss-gnuradio] Report configure - Packages skipped

[Brian Padalino]

On Thu, Jul 29, 2010 at 9:46 AM, Federico Battaglia
federico.battag...@hotmail.it wrote:
 Hello everyone,
 I ran into a problem during installation of GNU Radio and I hope someone can
 help me.
 I have a Ubuntu 9.04, GNU Radio 3.2.2 and a USRP2.
 I want to emphasize that I still has the best guide on the wiki,
 particularly that relating to dependencies. To this I can not explain why
 some skip.
 During the execution of the command ./configure I get the following reports:

 *
 The following components were skipped either because you asked not
 to build them or they didn't pass configuration checks:
 usrp2-firmware
 These components will not be built.

 The following GNU Radio components have been successfully configured:
 config
 gruel
 omnithread
 gnuradio-core
 pmt
 mblock
 usrp2
 gr-usrp2
 gr-audio-alsa
 gr-audio-oss
 gr-cvsd-vocoder
 gr-gsm-fr-vocoder
 gr-pager
 gr-radio-astronomy
 gr-trellis
 gr-video-sdl
 gr-wxgui
 gr-qtgui
 gnuradio-examples
 grc
 docs
 You my now run the make command to build these components.

 The following components were skipped either because you asked not
 to build them or they didn't pass configuration checks:
 gcell
 usrp
 gr-usrp
 gr-gcell
 gr-audio-jack
 gr-audio-osx
 gr-audio-portaudio
 gr-audio-windows
 gr-gpio
 gr-radar-mono
 gr-sounder
 gr-utils
 These components will not be built.
 *

 In this respect I do not understand why follow packages are skipped:
 usrp2-firmware, usrp and gr-utils. Moreover, with regard to others is
 normal that I should be skipped?
 I hope that I answer so many, so thanks in advance.

 To be precise I have installed:
 SWIG 1.3.36, G++ 4.3.3, AUTOMAKE1.9 1.9.6, LIBTOOL 2.2.6, PYTHON-DEV 2.6.2,
 LIBCPPUNIT-DEV 1.12.1, SDCC 2.8.0, LIBASOUND2-DEV 1.0.18, LIBSDL1.2-DEV
 1.2.13, PYTHON-WGXTK2.8 2.8.9,
 SUBERVISION 1.5.4, GUILE-1.8-DEV 1.8.5, LIBQT4-DEV 4.5.0, CCACHE 2.4.16,
 PYTHON-OPENGL 3.0.0, LIBGSL0-DEV 1.12.1, PYTHON-CHEETAH 2.0.1, PYTHON-LXML
 2.1.5, LIBQWT5-QT4-DEV 5.1.1,
 LIBQWTPLOT3D-QT4-DEV 0.2.7, QT4-DEV-TOOLS 4.5.0, LIBFFTW3-DEV 3.1.2, DOXYGEN
 1.5.8, PYTHON-NUMPY-EXT 1.2.1
 --
 Federico Battaglia

You don't really need to post twice.

You can grep through the output of configure for skipping or
something similar and see what failed.  It's usually pretty
descriptive what it can't find.

Brian

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

Re: [Discuss-gnuradio] DDC design

[Brian Padalino]

On Thu, Jul 22, 2010 at 7:28 PM, zero cool smzeroc...@gmail.com wrote:
 hi all,
 I am trying to design my own DDC for the purpose of better reception of gsm
 signals, but stuck with its design, currently I am using vertex 5 FPGA from
 Xilinx, so please if there is any link or design guide from where we can
 start, Any help is very much appreciated.

Are you getting stuck with the FPGA/Verilog portion, or the signal
processing what do I do? portion?

For the FPGA/Verilog stuff, it isn't too bad - just ask the right
question and there should be an answer somewhat quickly.

For the signal processing what do I do? stuff, you should try that
book Bob McGwier posted about earlier:


http://www.lulu.com/product/paperback/signal-processing-techniques-for-software-radios/11905533

Looked like it has some good SDR material in it.  I am sure they go
over mixers and DUC/DDC and plenty of filtering.

Good luck!

Brian

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

Re: [Discuss-gnuradio] Transmit signal power - How to find from the amplitude set in transmit_path?

[Brian Padalino]

On Thu, Jul 15, 2010 at 6:11 PM, John Andrews gnu.f...@gmail.com wrote:
 you are right but I don't neither do i have an scope nor a power meter. Any
 other suggestion?

Buy a scope and/or an RF power meter.

Brian

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

Re: [Discuss-gnuradio] usrp_fft.py axis values and units

[Brian Padalino]

On Wed, Jul 14, 2010 at 9:30 AM,  bjoe...@ee.ethz.ch wrote:
 Hi,

 I'm currently using USRP, GNU Radio and the file usrp_fft.py to find the
 Signal-to-noise ratio, Noise- and Signal-power.
 I use the ZigBee PHY from Thomas Schmid to generate the signals at 2.412GHz.

 My questions are the following:
 1. In usrp_fft.py are the axis denoted as amplitude [db] and of course
 frequency. Now in order to deduce the signal strength or the noise
 strength respectively, I need the reference amplitude used to compute the db
 value. In the code there is the setting --ref-scale and it's default value
 is 13490.0. Now is this reference Amplitude 13490.0 mV? (look at units -
 milli-volts)

It sounds like you're trying to figure out SNR based on an FFT.  If
that's the case, I don't recommend that.  There are plenty of in-band
noise sources that would be counted as signal when, in fact, they are
noise.  There are other methods for estimating SNR if you indeed want
to get that calculation.

I don't think the amplitude maps directly to milli-volts.  The units
are literally the integer values after filtering.  You need to take
into account any gains in the system before and after the digital
converter.

As a rudimentary example, if you had a converter which gave signed
14-bit numbers (+/- 8191), you may want to set the reference to be
84.28dB (6.02dB/bit * 14bits) and figure out how far down from full
scale input you are (this will be a negative number as 84.28dB should
be your top end).  You can then add and subtract the overall system
gain from that point to figure out what power levels are at different
locations in the system.  NOTE: This is something that requires you to
understand all the gains in the entire system.

Does that make sense to you?

 2. How can I get from here to the signal-power and noise-power? Or maybe the
 signal-strength isn't bad either... (I need those values to find the
 transmitting power of the USRP, I guess it could be 1mW, but don't know how
 to check that)

If you just want to find the transmitting power of the USRP, just
connect the antenna spigot to a 50Ohm terminated load, set your USRP
to output a vector of (1+0i) and measure the voltage.  You now know V
and R as well as the fact it's a single carrier tone - calculating
power should be easy.  You can then compare that in ratio to 1mW to
calculate dBm.

Calculating the exact noise power, on the other hand, ends up being a
much more difficult problem.

 Thanks a lot for your help!
 best,
 Björn

Good luck.

Brian

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

Re: [Discuss-gnuradio] installation error

[Brian Padalino]

On Tue, Jul 13, 2010 at 9:26 AM, Asad Mahmood asadmeh...@gmail.com wrote:
 Hi,

 Am new to the community. Have installed all the dependencies on Fedora Core
 7 but when i do ./configure in the gnuradio directory i get the error -
 following components will not be installed including gnuradio-core...i
 wonder what might be the prob.

I didn't really see an error show up here.  In fact, you're the only
one who mentions an error.

Now, lets grep through the list.  The first one seems to be:

Not building component gnuradio-core.

Well that seems a little strange.  I wonder what the reason may be.
Oh - the line above!

gnuradio-core requires package gsl = 1.10, not found.

Then one must ask themselves:

Do I have gsl installed?

Repeat for the other dependencies you find that you wish to have
installed but can't satisfy.

One may also try checking out the Build Guide on the wiki:

http://gnuradio.org/redmine/wiki/gnuradio/BuildGuide

Locating their favorite distro and seeing if those instructions work.

Consider contributing back to the wiki if the instructions are out of
date and/or require updating.

 here's the screen shot

 for cblas_sgemm in -lscs... no
 checking for cblas_sgemm in -lcomplib.sgimath... no
 checking for cblas_sgemm in -lcblas... (cached) no
 checking for cblas_sgemm in -lcblas... (cached) no
 checking for cblas_sgemm in -lblas... no
 checking for cblas_sgemm in -lgslcblas... yes
 checking for GSL... no
 gnuradio-core requires package gsl = 1.10, not found.
 Not building component gnuradio-core.
 Component pmt passed configuration checks; building.
 Component mblock passed configuration checks; building.
 checking whether stat file-mode macros are broken... no
 checking for fcntl.h... (cached) yes
 checking for sys/time.h... (cached) yes
 checking for unistd.h... (cached) yes
 checking whether getenv is declared... yes
 checking linux/usbdevice_fs.h usability... yes
 checking linux/usbdevice_fs.h presence... yes
 checking for linux/usbdevice_fs.h... yes
 checking for fast usb technique to use... linux
 checking for mkstemp... yes
 checking for mkstemp limitations... no
 checking whether byte ordering is bigendian... (cached) no
 checking for byteswap.h... (cached) yes
 checking linux/compiler.h usability... no
 checking linux/compiler.h presence... no
 checking for linux/compiler.h... no
 checking for getrusage... yes
 checking for sched_setscheduler... (cached) yes
 checking for pthread_setschedparam... yes
 checking for sigaction... (cached) yes
 checking for snprintf... (cached) yes
 checking for USB... yes
 checking for sdcc... sdcc -mmcs51 --no-xinit-opt
 checking for asx8051... asx8051 -plosgff
 checking sdcc_version 2.6.0... 2.6.0
 Component usrp passed configuration checks; building.
 checking whether host_os is linux*... yes
 checking for arpa/inet.h... (cached) yes
 checking for byteswap.h... (cached) yes
 checking linux/if_packet.h usability... yes
 checking linux/if_packet.h presence... yes
 checking for linux/if_packet.h... yes
 checking sys/socket.h usability... yes
 checking sys/socket.h presence... yes
 checking for sys/socket.h... yes
 checking sys/un.h usability... yes
 checking sys/un.h presence... yes
 checking for sys/un.h... yes
 checking for struct msghdr.msg_control... yes
 checking for struct msghdr.msg_accrights... no
 checking for struct cmsgcred.cmcred_uid... no
 checking for struct ucred.uid... yes
 Component usrp2 passed configuration checks; building.
 Component gr-usrp requires gnuradio-core, which is not being built or
 specified via pre-installed files.
 Not building component gr-usrp.
 Component gr-usrp2 requires gnuradio-core, which is not being built or
 specified via pre-installed files.
 Not building component gr-usrp2.
 Component gr-gcell requires gcell, which is not being built or specified via
 pre-installed files.
 Not building component gr-gcell.
 Component gr-audio-alsa requires gnuradio-core, which is not being built or
 specified via pre-installed files.
 Not building component gr-audio-alsa.
 Component gr-audio-jack requires gnuradio-core, which is not being built or
 specified via pre-installed files.
 Not building component gr-audio-jack.
 Component gr-audio-oss requires gnuradio-core, which is not being built or
 specified via pre-installed files.
 Not building component gr-audio-oss.
 Component gr-audio-osx requires gnuradio-core, which is not being built or
 specified via pre-installed files.
 Not building component gr-audio-osx.
 Component gr-audio-portaudio requires gnuradio-core, which is not being
 built or specified via pre-installed files.
 Not building component gr-audio-portaudio.
 Component gr-audio-windows requires gnuradio-core, which is not being built
 or specified via pre-installed files.
 Not building component gr-audio-windows.
 Component gr-cvsd-vocoder requires gnuradio-core, which is not being built
 or specified via pre-installed files.
 Not building component gr-cvsd-vocoder.
 Component gr-gpio passed 

Re: [Discuss-gnuradio] Programmable band-pass filters

[Brian Padalino]

On Fri, Jul 9, 2010 at 11:30 AM, Elvis Dowson elvis.dow...@mac.com wrote:
 Hi,
       Are there any components that can be used to implement a programmable 
 band-pass filter between the antenna and the LNA, of the RF front-end for an 
 SDR application.

 I was wondering if there are an discrete components available that can be 
 programmed by I2C or SPI, that can be controlled by an FPGA, to tune the 
 band-pass filter in between the antenna and the LNA.

You could try something like a switched filter bank as a preselector:

http://www.spectrummicrowave.com/sfb.asp

That was something a quick google search found.  Unfortunately, your
band-pass requirements are lacking.  What types of channel bandwidths
do you want?  How many channels?  How much rejection are you looking
for?

I am guessing said filters are pretty expensive.

 Best regards,

 Elvis

Good luck.

Brian

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