Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Guanbo]

Thanks Tom. I tried to see how much the carrier frequency offset would be. 
As you suggested above, I output the coarse freq offset bins, which was
similar as Srinivas's result. It is constant "-2". 

Does it means the carrier offset can be computed as: ADC rate /( Decim_rate
* FFT_len) * 2  ?
If so, in my case, it is around 4KHz. From my knowledge, it seems too good
to be true. 

>From your reference, I put on the channel filter code:
--
bw = (float(occupied_tones) / float(fft_length)) / 2.0
tb = bw*0.08
chan_coeffs = gr.firdes.low_pass (1.0, # gain
  1.0, #
sampling rate
  bw+tb,   #
midpoint of trans. band
  tb,  # width
of trans. band
  gr.firdes.WIN_HAMMING)   # filter
type
self.chan_filt = gr.fft_filter_ccc(1, chan_coeffs)

win = [1 for i in range(fft_length)]

--
Also, my hardware is USRP2+ XCVR2450.
$ sudo python benchmark_ofdm_tx_new.py --mac-addr=  -f 2.462G -m qpsk -i
100 --tx-gain=30 -M 8 -s 1000
FFT_len = 512 (default)
occupie_tones=200






Tom Rondeau wrote:
> 
> On Wed, Jan 12, 2011 at 7:36 PM, Guanbo  wrote:
>>
>> Hi, Tom
>>
>> I am not quite understand the ofdm_sync_xx.cc in
>> python/gnuradio/blks2impl/.
>>
>> What is the difference between frequency synchronization and carrier
>> frequency offset.
>> Why we have to do the timing and frequency synchronization before it?
>>
>> Thanks,
>> Guanbo
> 
> There is the difference between the fine frequency tuning (centering
> the signal inside of a subcarrier) and coarse frequency tunning
> (making sure that subcarrier 0 is at the correct location). The
> ofdm_sync_xx blocks perform the timing and fine frequency calculations
> (the self.nco in ofdm_receiver.py is generated from the fine frequency
> offset from the sync block). This is required before being able to
> perform the FFT demo, or else you'll get inter-carrier interference.
> 
> We can then go into the frequency domain (after the FFT) and work on
> the subcarrier bins to handle the coarse frequency offset, since it is
> easier to do in this domain.
> 
> Tom
> 
> 
> 
>> Tom Rondeau wrote:
>>>
>>> On Tue, Feb 16, 2010 at 5:45 PM, Srinivas  wrote:
 Matt,

 Thanks for verifying the data rate calculation!

 I tried the other solutions that you suggested, namely,

 - increasing the data rate by a factor of 2 or 4
 It works.

 - modifying the OFDM code to widen the search range - How do I widen
 the
 search range ?
 Should I be looking in the "ofdm_sync_" blocks in "blks2impl" folder ?
 If
 yes, which synchronizer is currently used with ofdm_examples ?
>>>
>>> You need to add an argument to gr.ofdm_frame_acquisition in
>>> ofdm_receiver.py (in python/gnuradio/blks2impl).
>>>
>>> In the current Git master, this is located on line 109 of
>>> ofdm_receiver.py. After the "ks[0]" argument, you can put in an
>>> integer. This is the maximum number of bins the receiver will search
>>> over for correlation. It defaults to 10.
>>>
>>>
 - locking the usrps to a common reference
 My usrp2s are located wide apart so I guess this solution is not
 practical.

 Besides, this confirms that the problem is somewhere in the USRP2
 board,
 right ? (as I tried swapping the daughter cards & firmware with the
 working
 pair)

 Thanks,
 Srinivas
>>>
>>> Nope, this is typical of radio hardware. They are always off
>>> frequency. If two oscillators are off frequency and then multiplied up
>>> to another frequency, the difference will also be magnified. So a 2.4
>>> GHz board will have a larger frequency offset than if you ran it just
>>> through the BasicTx/Rx boards (even though the ratios should be the
>>> same).
>>>
>>> Tom
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/OFDM-receiver-on-USRP2-tp27557644p30658514.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/OFDM-receiver-on-USRP2-tp27557644p30669471.html
Sent from the GnuRadio mailing list archive at Nabble.com.

[Discuss-gnuradio] uhd.tune_request_t & DBRSX[2]

[john]

I wonder if someone can help me?

I have been trying to understand 'tuning' and I note that UHD has a
couple of options for setting the centre frequency. The two methods:

tune_request_t( target_freq ) method1

 and tune_request_t( target freq, lo_off)

when I try the former in GNURadio Companion for a source of UHD things
work as I expect but when I decide to put in a lo_off I get strange
results.

uhd.tune_request_t(804.75*e6, 40*e6) and I have enabled the dbsrx2_debug
flag to true to see how things are being driven and can see the
following when I execute the GRC, it says: 
  
Target 844.75 and 
actual 844.75  which seems correct (i.e. what I think I asked
 for) but then I get:
   
setting of regs x00 through x07 and then   
Warning: 
 The hardware does not support the requested RX frequency   
 Target 804.75 
 Actual: 868.75   

but it receives the 804.75 signal (or thereabouts - tv audio so wideish
bandwidth)!   

The s/w is calculating the correct integer and fractional values in N
(ext_div of 4 (HMC426), scaler 4 (since freq < 1125Mhz ) etc.



Some questions:

1) why is 844.75 not valid ? 

From the MAX2112 spec there are VASA/VASE signals which 
allow the chip to search/select VCOs but cannot see
where these are set and assume that is the reason that


2) why is the utility talking about 868.75?

3) why, when it says actual is 868.75, is the system receiving
 signals on 804.75? 


4) if you can direct the tuner to a specific frequency with method1 ,
why would you consider having the option to specify an lo_offset? would
it allow an IF to be generated (e.g. 10.7 MHz)?

Kind Regards, 

 John


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

Re: [Discuss-gnuradio] LPDA orientation when receiving GPS signals on USRP2

[Matt Ettus]

On 01/13/2011 07:08 PM, Nick Othieno wrote:

Hi everyone,

Does anyone know what the orientation of an LPDA (log periodic dipole
antenna) should be when receiving GPS signals?

Should the up-most element be the longest one, or should it be the
shortest one? In other words



Point the short side (with the connector) towards the source you are 
trying to receive from.


A log periodic antenna is not ideal for receiving GPS since GPS is 
circularly polarized and the LPDA is linear.


Matt

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

Re: [Discuss-gnuradio] LPDA orientation when receiving GPS signals on USRP2

[john]

On Thu, 2011-01-13 at 22:08 -0500, Nick Othieno wrote:
> Hi everyone,
> 
> Does anyone know what the orientation of an LPDA (log periodic dipole
> antenna) should be when receiving GPS signals?
> 
> Should the up-most element be the longest one, or should it be the
> shortest one? In other words
> 
> 
> 
> ___
>  ___-
> __
>   
> OR ___
>__
> 
> 
> 
> 
> 
> Nick
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

>From ARRL Antenna Handbook (1988) the 'forward' direction is towards the
smaller elements on an LPDA. Don't think that JCM equations have changed
since '88.

 Kind Regards,

 John


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

[Discuss-gnuradio] LPDA orientation when receiving GPS signals on USRP2

[Nick Othieno]

Hi everyone,

Does anyone know what the orientation of an LPDA (log periodic dipole
antenna) should be when receiving GPS signals?

Should the up-most element be the longest one, or should it be the shortest
one? In other words



   ___

___-
   __
     OR
___

__
   





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

[Discuss-gnuradio] re: Low cost hardware option

[B . A . f . H]

FYI

Have a look at the article[1,2] from James Ahlstrom N2ADR [3]. I think it could 
be an interessting approach/ point of start.

[1] 
http://www.arrl.org/files/file/QEX_Next_Issue/Nov-Dec_2010/Ahlstrom%20NOV-DEC.pdf
[2] http://james.ahlstrom.name/transceiver/index.html
[3] http://james.ahlstrom.name/
-- 
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit 
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

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

Re: [Discuss-gnuradio] volk: duplicate symbol _volk_cpu

[Tom Rondeau]

On Mon, Jan 10, 2011 at 11:04 PM, update lee  wrote:
>> when I try to build volk from next branch of git, I got error during make
>>
>> libtool: link: gcc -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o
> .libs/libvolk_runtime.0.dylib  .libs/volk_cpu_x86.o .libs/cpuid_x86_64.o
> .libs/volk_runtime.o .libs/volk_init.o .libs/volk_rank_archs.o
> -L/opt/local/lib
> -O2   -install_name  /usr/local/lib/libvolk_runtime.0.dylib
> -compatibility_version
> 1 -current_version 1.0 -Wl,-single_module
>> ld: duplicate symbol _volk_cpu in .libs/volk_runtime.o and 
>> .libs/volk_cpu_x86.o
>> collect2: ld returned 1 exit status
>> make[2]: *** [libvolk_runtime.la] Error 1
>>
>> BTW, I did it on OSX 10.6.5
>>
>
> Im no expert by any means but this is usually caused when something is
> defined twice in two different .c files. So looking into it it appears
> that way, so I added the static keyword so that each file can use the
> definition but they wont interfear with each other.
>
> proper #ifdef should prob be used but this was quick and dirty and got
> me compiled and up and running on OSX
>
> Chris Lee
> VE6UDL


We're working on trying to fix this. The patch that was submitted does
not actually work. When I run it with the patch, the resulting
architectures that VOLK will build for is only the 'generic' one, not
all of what should be built (on my Core2Duo: generic 64 mmx sse sse2
sse3 ssse3).

I only think that I might know why at this point. It shouldn't be hard
to fix once I get my head wrapped around it properly.

Tom

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

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Tom Rondeau]

On Wed, Jan 12, 2011 at 7:36 PM, Guanbo  wrote:
>
> Hi, Tom
>
> I am not quite understand the ofdm_sync_xx.cc in python/gnuradio/blks2impl/.
>
> What is the difference between frequency synchronization and carrier
> frequency offset.
> Why we have to do the timing and frequency synchronization before it?
>
> Thanks,
> Guanbo

There is the difference between the fine frequency tuning (centering
the signal inside of a subcarrier) and coarse frequency tunning
(making sure that subcarrier 0 is at the correct location). The
ofdm_sync_xx blocks perform the timing and fine frequency calculations
(the self.nco in ofdm_receiver.py is generated from the fine frequency
offset from the sync block). This is required before being able to
perform the FFT demo, or else you'll get inter-carrier interference.

We can then go into the frequency domain (after the FFT) and work on
the subcarrier bins to handle the coarse frequency offset, since it is
easier to do in this domain.

Tom



> Tom Rondeau wrote:
>>
>> On Tue, Feb 16, 2010 at 5:45 PM, Srinivas  wrote:
>>> Matt,
>>>
>>> Thanks for verifying the data rate calculation!
>>>
>>> I tried the other solutions that you suggested, namely,
>>>
>>> - increasing the data rate by a factor of 2 or 4
>>> It works.
>>>
>>> - modifying the OFDM code to widen the search range - How do I widen the
>>> search range ?
>>> Should I be looking in the "ofdm_sync_" blocks in "blks2impl" folder ? If
>>> yes, which synchronizer is currently used with ofdm_examples ?
>>
>> You need to add an argument to gr.ofdm_frame_acquisition in
>> ofdm_receiver.py (in python/gnuradio/blks2impl).
>>
>> In the current Git master, this is located on line 109 of
>> ofdm_receiver.py. After the "ks[0]" argument, you can put in an
>> integer. This is the maximum number of bins the receiver will search
>> over for correlation. It defaults to 10.
>>
>>
>>> - locking the usrps to a common reference
>>> My usrp2s are located wide apart so I guess this solution is not
>>> practical.
>>>
>>> Besides, this confirms that the problem is somewhere in the USRP2 board,
>>> right ? (as I tried swapping the daughter cards & firmware with the
>>> working
>>> pair)
>>>
>>> Thanks,
>>> Srinivas
>>
>> Nope, this is typical of radio hardware. They are always off
>> frequency. If two oscillators are off frequency and then multiplied up
>> to another frequency, the difference will also be magnified. So a 2.4
>> GHz board will have a larger frequency offset than if you ran it just
>> through the BasicTx/Rx boards (even though the ratios should be the
>> same).
>>
>> Tom
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> --
> View this message in context: 
> http://old.nabble.com/OFDM-receiver-on-USRP2-tp27557644p30658514.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

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

Re: [Discuss-gnuradio] Passing a message from one block to other

[Tom Rondeau]

On Wed, Jan 12, 2011 at 2:43 PM, John Andrews  wrote:
> Hi,
> Suppose I have two gnuradio blocks called gr_ACQUISITION and gr_TRACKING
> where, gr_TRACKING is dependent upon some result derived from gr_ACQ block.
> Is it possible to pass certain messages to gr_TRACK in order to change its
> state while the flowgraph is running? One way to do is to have an output
> line in gr_ACQUISITION that carries this info to the block gr_TRACKING but
> this doesn't seem like an attractive option to me.
>
> Thanks,
> John.

We have recently introduced the concept of stream tags into GNU Radio
that might be what you want. They are not currently well-documented,
but you can find some information in my presentations from this years
SDR conference (specifically Tues and Weds):
http://gnuradio.org/redmine/wiki/gnuradio/SDR2010

You can also see a simple example in the code source (you'll have to
be on the next branch in git right now):
gnuradio-examples/python/tags

I will hopefully soon find time to write more examples and document it
better. But hopefully, the examples will be enough to show you how to
add a tag to an output stream from one block and receive it in another
block.

If you manage to get it working, I'd be very interested to hear about
your experiences. What you are looking to do sounds like it could be a
perfect case study for the use of the tags that others could well
benefit from.

Tom

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

Re: [Discuss-gnuradio] DDC and Polyphase Channelizer

[Tom Rondeau]

On Wed, Jan 5, 2011 at 4:14 AM, Jimmy Richardson  wrote:
> Hi, Tom:
>
> Please see my comments below.
>
> Thanks
>
> On 1/4/2011 11:44 PM, Tom Rondeau wrote:
>>
>> On Mon, Jan 3, 2011 at 11:25 PM, Jimmy Richardson
>>  wrote:

 Indeed. Very strange. My guess is that there is a misconception
 somewhere in the code about sample rate. I can't quite see it in my
 head, but I'm guessing that the channel spacing isn't exactly the
 channel spacing you think it is.
>>>
>>> You mean the oversample rate O = N/i is wrong? As far as I can see,
>>> that's
>>> the only number that could go wrong, since pfb_channelizer_ccf only takes
>>> 3
>>> parameters, # of channels, taps and oversample rate, and it doesn't look
>>> like the other two can be wrong.
>>>
>>> I checked the calculation of O again, but couldn't find the problem. In
>>> the
>>> Matlab code, harris uses loops "for nn=1:28:5600-28" to do the
>>> processing,
>>> so it does seems a 28-to-1 downsampling in 40 channels.
>>
>> No, not the oversample rate, just the sample rate. I'm thinking that
>> there is some misunderstanding somewhere about the actual sample rate
>> and the therefore the channel bandwidths such that the channels you
>> are pulling out are not covering the same frequencies that you think
>> they are.
>
> Sorry, maybe I didn't get how the algorithm works, but it looks to me the
> actual sample rate does not enter into the equation, except in the filter
> generation part? If we use the same filter on both methods, then the actual
> sample rate should not cause the difference?

No, the sample rate as a real number doesn't enter into the code, but
it does abstractly in where the signals exist, what the channel
bandwidths mean, etc. I'm not sure what else to say here, really, just
to think closely about the signals and the channelizer. Again, it
could be that there is a bug in the code that only worked for my
cases.

>> On the other hand, it could be a miscalculation in the
>> pfb_channelizer, although all of my tests with it came out fine.
>
> Is the test cases included in the GNURadio source code? Also if I want to
> understand the logic inside pfb_channelizer implementation, are there any
> book or paper I should review besides harris' paper and book?

No, they aren't. It shouldn't be difficult to modify the example codes
that are there, though, to see what happens and make sure it makes
sense.

Tom

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

Re: [Discuss-gnuradio] OFDM Benchmark Change Modulation

[Tom Rondeau]

On Tue, Jan 4, 2011 at 8:49 AM, You Lizhao  wrote:
> Hi all,
>
> Recently I want to implement a OFDM based multi-rate system, and I am using
> benchmark_ofdm_tx/benchmark_ofdm_rx programs in ofdm directory. I know I can
> use unlock/lock mechnism to disconenct/connect the exising blocks to change
> modulation block, and it indeed works. However, I also notice that the
> difference between all modulation, i.e. BPSK, QPSK, QAM16, QAM64, is
> rotated_const paramter in gr.ofdm_mapper_bcv block. So I write a new block
> howto.ofdm_mapper_bcv which can change rotated_const  (d_constellation in
> gr_ofdm_mapper_bcv.h/.cc) with a defined function call. But it does not
> work. When I change BPSK to QPSK by altering rotated_const, I can receive
> nothing but TIMEOUT in QPSK demodulator. If I still use BPSK demodulator, it
> works in compromised performance with some packets failed to pass CRC check.
> Why does it happen, since I already change rotated_const? Is there any
> misunderstanding on this ofdm benchmark program?

You shouldn't have to stop and start the flow graph to change
modulations. Instead, add a function to gr_ofdm_mapper_bcv and
gr_ofdm_frame_sink that allows you to change the modulation
constellation.

As to why you may not be receiving anything, it's because the OFDM
code is not very robust for different channel conditions, so you're
physical setup and channel may not work well. At this point in the
code, you just have to do a lot of hand tunning to get various levels
of modulation to work. To do better, you'll need to get into the guts
of the algorithms and try to improve them.

> Furthermore, I also find that if I use QAM16, it seems that the packet
> reception simuation is very bad, about 50% PRR or even lower. When
> using QAM64, PRR~0%, almost all packets failed CRC check. I think if I use
> channel coding, the situation will be better. I am wondering how to add
> channel coding block to existing architecture. Is there any possible
> examples?
>
> Any comments are welcomed! Thank you very much!
>
> Regards,
> -Lizhao

There are a few codes available in GNU Radio right now, including
reed-solomon, convolutional, and trellis coding. It will take some
work to add any of them to the OFDM code, though.

Tom

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

Re: [Discuss-gnuradio] Building an RF Front end for DSP FPGA Kits with ADCs

[Marcus D. Leech]

Thanks Marcus.

The reason why I do not want to attenuate is because I want to receive a
high-powered signal and low-powered signal at the same frequency.

If I attenuate then the low-powered signal will be reduced and if I go
beyond the noise floor, I might see it.  The goal was to stretch the
difference in power between the high-powered signal and the low-power.  But
now if I think about it no matter what I will be limited to my Dynamic
Range.


Yes, given that perfectly-acceptable signals can arrive at the front-end 
at -90dBm or lower, and you want to be able
  to "see" +30dBm at the same time, you'll need roughly 120dB of 
dynamic range.  But +30dBm is about 7.07VRMS, or
  about 10VP.  There's no way on gods little green earth that you're 
going to find an ADC that can sample at 100Msps or
  more, and have a peak input voltage of +10VP (+7VRMS), and have a 
120dB dynamic range.  Let alone a receiver
  front-end RF chain that can tolerate anything more than about +15dBm 
or so.


For 120dB dynamic range, you'd need a 20-bit ADC, *and* it would need to 
run at a fast sample rate, *and* it would need to be

  able to handle +10VP input.  Not gonna happen.

I'm curious about why you need to inject +30dBm into a receiver.  You're 
getting no more information out of that signal than if

  it arrived at -30dBm.


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



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

Re: [Discuss-gnuradio] grc amplitude demodulation questions

[Marcus D. Leech]

Hello-

I am using GRC 3.3 to create a flow graph using the USRP2 and a LFRX to do 
amplitude demodulation.  I have a few questions.

1) What are good values for "Audio Pass" and "Audio Stop" within the "AM Demod" 
block?

2) I observe a DC offset at the output of the demodulation.  Is this expected, 
and what is the best way to remove it?  I am currently using a high-pass 
filter.  My incoming signal is a 27 kHz sine modulated at 1 kHz.
There will always be a certain amount of DC offset in an AM demodulator, 
since it's just a power detector, and since the RF chain always
  produces at least *some* noise, the detected version of that noise 
results in a small residual DC offset. You can null it out with an

  an "ADD" block.


3) I am sending the result to an FFT sink. I instituted a variable slider to 
control the decimation within the AM Demod block, but when I change that 
decimation, the displayed fft trace does not adjust correctly to the new sample 
rate.  In fact, the fft trace remains in a fixed position; the only thing that 
changes in the plot is the x-axis, ie frequency.  I have a second slider for 
the usrp2 decimation which does change the displayed spectrum correctly, so 
that the peaks move to the correct position.  Any thoughts?
The FFT sink isn't psychic.  It needs to be told what the current sample 
rate is, so if you change decimation on the fly, you'll need to

  arrange for the FFT sink to know about the new sample rate.


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



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

Re: [Discuss-gnuradio] Building an RF Front end for DSP FPGA Kits with ADCs

[sirjanselot]

Thanks Marcus.

The reason why I do not want to attenuate is because I want to receive a
high-powered signal and low-powered signal at the same frequency.  

If I attenuate then the low-powered signal will be reduced and if I go
beyond the noise floor, I might see it.  The goal was to stretch the
difference in power between the high-powered signal and the low-power.  But
now if I think about it no matter what I will be limited to my Dynamic
Range.



Marcus D. Leech wrote:
> 
> On 01/13/2011 10:33 AM, Euripedes Rocha Filho wrote:
>> Why not just buy a USRP + WBX?
>>
>> 2011/1/13 sirjanselot > >
>>
>>
>> Hello,
>>
>> I am looking to buy an Altera DSP FPGA Kit (DSP Development Kit,
>> Stratix III
>> Edition) for school research but I'm not sure how i am going to
>> build an
>> RF-Front End for it.  I am looking to receive signals up to +30
>> dBm from 30
>> MHz - 2 GHz with bandwidths up to 50 MHz.  This the kit I am
>> looking to
>> purchase:
>> http://www.altera.com/products/devkits/altera/kit-st3-dsp.html
>>
>> This kit comes with two 150 MSPS 14-bit ADCs and 250 MSPS 14-bit
>> DACs.  My
>> question is it possible to buy a Commercial off the Shelf
>> Front-End that
>> provides the necessary inputs?
>>
>> Is there something special that I have to do in order to receive
>> signal
>> levels up to +30 dBm so that my ADCs do not saturate?
>>
> Attenuators.  At +30dBm, the concern isn't saturation, but *device
> destruction*--it would be a shame
>   to destroy your $2800.00 Altera development board.
> 
> 
> 
> -- 
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Building-an-RF-Front-end-for-DSP-FPGA-Kits-with-ADCs-tp30662773p30666803.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

[Discuss-gnuradio] grc amplitude demodulation questions

[ematlis]

Hello-

I am using GRC 3.3 to create a flow graph using the USRP2 and a LFRX to do 
amplitude demodulation.  I have a few questions.  

1) What are good values for "Audio Pass" and "Audio Stop" within the "AM Demod" 
block?  

2) I observe a DC offset at the output of the demodulation.  Is this expected, 
and what is the best way to remove it?  I am currently using a high-pass 
filter.  My incoming signal is a 27 kHz sine modulated at 1 kHz.

3) I am sending the result to an FFT sink. I instituted a variable slider to 
control the decimation within the AM Demod block, but when I change that 
decimation, the displayed fft trace does not adjust correctly to the new sample 
rate.  In fact, the fft trace remains in a fixed position; the only thing that 
changes in the plot is the x-axis, ie frequency.  I have a second slider for 
the usrp2 decimation which does change the displayed spectrum correctly, so 
that the peaks move to the correct position.  Any thoughts?

4) Related to the above- I thought I'd mention that if I move the usrp2 
decimation slider bar too quickly, the fft plot then fails to adjust the fft 
trace correctly - I have to move the bar slowly.

5) Occasionally I am seeing a random error which causes the flowgraph to freeze:

Executing: "/home/matlis/Downloads/top_block.py"

Error: failed to enable realtime scheduling.
>>> gr_fir_fff: using SSE
Traceback (most recent call last):
  File 
"/usr/local/lib64/python2.6/site-packages/gnuradio/wxgui/plotter/plotter_base.py",
 line 187, in _on_paint
for fcn in self._draw_fcns: fcn[1]()
  File 
"/usr/local/lib64/python2.6/site-packages/gnuradio/wxgui/plotter/plotter_base.py",
 line 59, in draw
self._draw()
  File 
"/usr/local/lib64/python2.6/site-packages/gnuradio/wxgui/plotter/grid_plotter_base.py",
 line 395, in _draw_p
oint_label
label_str = self._populate_point_label(x_val, y_val)
  File 
"/usr/local/lib64/python2.6/site-packages/gnuradio/wxgui/plotter/channel_plotter.py",
 line 149, in _populate
_point_label
y_value = (samples[x_index_high] - samples[x_index_low])*scale + 
samples[x_index_low]
IndexError: index out of bounds

>>> Done


Thanks for any suggestions!

eric


  

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

[Discuss-gnuradio] transient when changing valve state

[David L]

I have a grc file that has a UHD source with output going to two places.

1) A scope graphical sink
2) A valve

When I change the state of the valve, I see a glitch on the scope output.
I would think that since the valve is not between the source and the scope
that it would not affect the samples going to the scope.  But it does.  Why?

Thanks,

David

PS -
video of glitch: http://www.youtube.com/watch?v=Zr9PKVx5WiI
grc window: 
https://docs.google.com/leaf?id=0B5MNiGB_nlGJNDAyNzViNGYtZGJmYy00M2ZkLTlhNTktZWQyOGNmYmZlMGIw&hl=en&authkey=CP266Z0N
grc file - 
https://docs.google.com/leaf?id=0B5MNiGB_nlGJYWM0NDkwN2MtOTUwYy00NThkLWI0MDQtZWNjMTBhYjk2MWY2&hl=en&authkey=CJa60JME

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

Re: [Discuss-gnuradio] About clock rate of USRP E100

[Matt Ettus]

On 01/11/2011 10:18 PM, Alexander Chemeris wrote:

Hi Matt,

Thank you for your clarification.

What are the limits and steps/accuracy of ADC/DAC clock speed regulation?
E.g. is it possible to sample at 56MHz or 26 MHz and set sampling
clock with 1Hz precision?


You cannot get 1 Hz steps.

See http://www.ruby-forum.com/topic/555255 for a fuller explanation.

Matt

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

Re: [Discuss-gnuradio] Finally compiled USRP2 code works fine with UDPimage ...but not with compiled Raw Ethernet Image

[Josh Blum]

> I tried it with cygwin but it didn't find ise_helper.tcl.  I don't know
> why, the file is at the good place.  Do you have any idea of the
> problem, I will ask somebody else at school.

That tells me that xilinx ise "xtclsh" did not know what to do with that
cygwin (unix) file path. That means you probably need to run from
windows command prompt.

-Josh

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

Re: [Discuss-gnuradio] Building an RF Front end for DSP FPGA Kits with ADCs

[Marcus D. Leech]

On 01/13/2011 11:23 AM, jan acosta wrote:
> I have one already, but you can't receive anything above - 10 dBm. 
> Plus I'd like to gain FPGA programming experience. 
I'll observe that with a 30dB attenuator in front of your receiver, you
can easily do what you want
  to do.  I suspect that you don't know that much about the RF world,
otherwise the $5.00 attenuator
  solution would immediately occur to you as a more economically-sound
solution than a
  $2800.00 system replacement.

Further, the FPGAs on the USRPs are programmable, and the souce Verilog
is publically available
  for you to modify, etc, etc.

Note that I'm not saying *dont buy* your Altera development board--it's
your $2800.00, do what you
  want with it, but if the reasons are just the attenuator and "I want
to program my own FPGA", then
  you already pretty-much have what you need.


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



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

Re: [Discuss-gnuradio] Building an RF Front end for DSP FPGA Kits with ADCs

[Marcus D. Leech]

On 01/13/2011 10:33 AM, Euripedes Rocha Filho wrote:
> Why not just buy a USRP + WBX?
>
> 2011/1/13 sirjanselot  >
>
>
> Hello,
>
> I am looking to buy an Altera DSP FPGA Kit (DSP Development Kit,
> Stratix III
> Edition) for school research but I'm not sure how i am going to
> build an
> RF-Front End for it.  I am looking to receive signals up to +30
> dBm from 30
> MHz - 2 GHz with bandwidths up to 50 MHz.  This the kit I am
> looking to
> purchase:
> http://www.altera.com/products/devkits/altera/kit-st3-dsp.html
>
> This kit comes with two 150 MSPS 14-bit ADCs and 250 MSPS 14-bit
> DACs.  My
> question is it possible to buy a Commercial off the Shelf
> Front-End that
> provides the necessary inputs?
>
> Is there something special that I have to do in order to receive
> signal
> levels up to +30 dBm so that my ADCs do not saturate?
>
Attenuators.  At +30dBm, the concern isn't saturation, but *device
destruction*--it would be a shame
  to destroy your $2800.00 Altera development board.



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

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

Re: [Discuss-gnuradio] Building an RF Front end for DSP FPGA Kits with ADCs

[jan acosta]

I have one already, but you can't receive anything above - 10 dBm.  Plus I'd
like to gain FPGA programming experience.

- Jan

On Thu, Jan 13, 2011 at 10:33 AM, Euripedes Rocha Filho <
rocha.euripe...@gmail.com> wrote:

> Why not just buy a USRP + WBX?
>
> 2011/1/13 sirjanselot 
>
>>
>> Hello,
>>
>> I am looking to buy an Altera DSP FPGA Kit (DSP Development Kit, Stratix
>> III
>> Edition) for school research but I'm not sure how i am going to build an
>> RF-Front End for it.  I am looking to receive signals up to +30 dBm from
>> 30
>> MHz - 2 GHz with bandwidths up to 50 MHz.  This the kit I am looking to
>> purchase: http://www.altera.com/products/devkits/altera/kit-st3-dsp.html
>>
>> This kit comes with two 150 MSPS 14-bit ADCs and 250 MSPS 14-bit DACs.  My
>> question is it possible to buy a Commercial off the Shelf Front-End that
>> provides the necessary inputs?
>>
>> Is there something special that I have to do in order to receive signal
>> levels up to +30 dBm so that my ADCs do not saturate?
>>
>> My goal would be to build it myself, but if I am pressed with deadlines I
>> will have to get COTS product.
>> --
>> View this message in context:
>> http://old.nabble.com/Building-an-RF-Front-end-for-DSP-FPGA-Kits-with-ADCs-tp30662773p30662773.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Finally compiled USRP2 code works fine with UDPimage ...but not with compiled Raw Ethernet Image

[Gabriel Morel]

If you don't trust me, try it. Use Xilinx on Windows, create a project
and put in all file of all different makefile in the repo for USRP2 with
u2_rev3.v in top. Implement top module and create the bin file. After,
give me some news plz. It's not loosing time, nobody had answer to my
question and somebody have same problem than me. Thx a lot.


Well, that is where you are going wrong.  Don't create a project file.
Use the makefile as is.  It works fine.  The Xilinx tools are very picky
and we have everything set up just right.  We also use them under linux
which works much better.

Matt



I tried it with cygwin but it didn't find ise_helper.tcl.  I don't know why, 
the file is at the good place.  Do you have any idea of the problem, I will 
ask somebody else at school.


Gab 




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

Re: [Discuss-gnuradio] Building an RF Front end for DSP FPGA Kits with ADCs

[Euripedes Rocha Filho]

Why not just buy a USRP + WBX?

2011/1/13 sirjanselot 

>
> Hello,
>
> I am looking to buy an Altera DSP FPGA Kit (DSP Development Kit, Stratix
> III
> Edition) for school research but I'm not sure how i am going to build an
> RF-Front End for it.  I am looking to receive signals up to +30 dBm from 30
> MHz - 2 GHz with bandwidths up to 50 MHz.  This the kit I am looking to
> purchase: http://www.altera.com/products/devkits/altera/kit-st3-dsp.html
>
> This kit comes with two 150 MSPS 14-bit ADCs and 250 MSPS 14-bit DACs.  My
> question is it possible to buy a Commercial off the Shelf Front-End that
> provides the necessary inputs?
>
> Is there something special that I have to do in order to receive signal
> levels up to +30 dBm so that my ADCs do not saturate?
>
> My goal would be to build it myself, but if I am pressed with deadlines I
> will have to get COTS product.
> --
> View this message in context:
> http://old.nabble.com/Building-an-RF-Front-end-for-DSP-FPGA-Kits-with-ADCs-tp30662773p30662773.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[William Cox]

I like this discussion. Perhaps we could talk to the folks at
http://www.oshwbank.org/ about helping sponsor the project (more details:
http://antipastohw.blogspot.com/2009/03/introducing-open-source-hardware.html
)
Another idea would be to do a Kickstarter campaign to raise some initial
funds.
A platform like this for a hobby-accessible price would be fabulous for
education.
-William


On Thu, Jan 13, 2011 at 8:02 AM, Philip Balister wrote:

> On 01/13/2011 02:00 AM, Jamie Morken wrote:
>
>>
>> All "non-commercial use only" clauses most likely restrict most military
>>  use, and these are quite common, and are far more restrictive than a
>> "non-military use only" clause.  I do follow what you are saying though,
>> but its a choice like "ethical investing", it makes economic sense to some
>> people and seems foolish to some people.
>>
>>
> Non-commercial use, academic only and other clauses restricting use of the
> hardware/software in derived works is not compatible with the OSI definition
> of an open source license. See:
>
> http://www.opensource.org/docs/osd
>
> Specifically, clause 6 states:
>
> 6. No Discrimination Against Fields of Endeavor
>
> The license must not restrict anyone from making use of the program in a
> specific field of endeavor. For example, it may not restrict the program
> from being used in a business, or from being used for genetic research.
>
> Philip
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Building an RF Front end for DSP FPGA Kits with ADCs

[sirjanselot]

Hello,

I am looking to buy an Altera DSP FPGA Kit (DSP Development Kit, Stratix III
Edition) for school research but I'm not sure how i am going to build an
RF-Front End for it.  I am looking to receive signals up to +30 dBm from 30
MHz - 2 GHz with bandwidths up to 50 MHz.  

This kit comes with two 150 MSPS 14-bit ADCs and 250 MSPS 14-bit DACs.  My
question is it possible to buy a Commercial off the Shelf Front-End that
provides the necessary inputs?  

Is there something special that I have to do in order to receive signal
levels up to +30 dBm so that my ADCs do not saturate?  

My goal would be to build it myself, but if I am pressed with deadlines I
will have to get COTS product.  
-- 
View this message in context: 
http://old.nabble.com/Building-an-RF-Front-end-for-DSP-FPGA-Kits-with-ADCs-tp30662773p30662773.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

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

[Philip Balister]

On 01/13/2011 02:00 AM, Jamie Morken wrote:


All "non-commercial use only" clauses most likely restrict most military
  use, and these are quite common, and are far more restrictive than a
"non-military use only" clause.  I do follow what you are saying though, but its a choice 
like "ethical investing", it makes economic sense to some people and seems foolish to 
some people.



Non-commercial use, academic only and other clauses restricting use of 
the hardware/software in derived works is not compatible with the OSI 
definition of an open source license. See:


http://www.opensource.org/docs/osd

Specifically, clause 6 states:

6. No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a 
specific field of endeavor. For example, it may not restrict the program 
from being used in a business, or from being used for genetic research.


Philip

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