[Discuss-gnuradio] EUSIPCO 2011

2011-01-03 Thread Per Zetterberg 
Dear Lists,

I would like to encourage everybody to send good papers to EUSIPCO 2011
(http://www.eusipco2011.org/), where I will be acting as area chair of 
"Design and Implementation for Communications applications".

BR/
Per Zetterberg


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

[Discuss-gnuradio] Installing the latest gnuradio and gnuradio-companion (grc) in Fedora 14

2011-01-03 Thread Brad Hein 
Hello all -
I wanted to share my notes for installing gnuradio in Fedora 14. There
were a few snags at first but with help from the friendly folks on
discuss-gnuradio, I was able to push through and compile gnuradio and
gnuradio-companion in Fedora 14! Note that Installing gnuradio/grc
with yum didn't work for me so I had to compile from source. At a
future date there may be some updated binaries added to the Fedora
repository, but until then, we can install it by compiling the source!


Getting latest GNURadio from GIT and building it on Fedora 14!
==
* Uninstall any existing gnuradio and grc rpm packages using yum.
* Obtain the source code to gnuradio via git.
  # git clone git://gnuradio.org/gnuradio
* A Link to the build instructions.
  http://gnuradio.org/redmine/wiki/1/BuildGuide
  http://gnuradio.org/redmine/repositories/entry/gnuradio/README
* Per the instructions, for a required package foo, we will install
foo and foo-devel
* The following single YUM command sets up the environment necessary
to build gnuradio!
  # yum install SDL* PyQt4 PyQt4-devel alsa-lib-devel gcc gpp gcc-c++
autoconf automake libtool pkgconfig fftw fftw-devel python numpy boost
boost-* cppunit cppunit-devel swig sdcc sdcc-libc-sources guile
guile-devel guile-* gsl gsl-devel pygsl pygsl-devel wxPython
wxPython-devel xmlto python-cheetah python-turbocheetah python-lxml
doxygen pygtk2 qwt-devel
* Now go into the gnuradio direcotry and run ./bootstrap to build the
configure script.
* Now run configure
  # ./configure --enable-grc --enable-gr-qtgui   --enable-gr-audio-alsa
* Then run
  # make check install


Troubleshooting
-
Problem: Python path set incorrectly and prevents gnuradio-companion
(grc) from starting.
    $ echo $PYTHONPATH
    /usr/lib/python2.7/site-packages/mpich2
Solution:
--> Change the python path before running gnuradio-companion.
--> $ export PYTHONPATH=/usr/local/lib/python2.7/site-packages
--> A more permanent fix can be applied by adding the export command
to a new file in /etc/profiles.d, or ~/.bash_profile.

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

Re: [Discuss-gnuradio] gr_qtgui, SWIG. QT Signals and such

2011-01-03 Thread Tom Rondeau 
On Mon, Jan 3, 2011 at 2:53 AM, Mike Cornelius  wrote:
> Hi All,
>
> I've been playing around with gr_qtgui and adding a few 'enhancements' to
> suit my application, in doing so I've come to a bit of sticking point and
> I'm looking for some advice on how to proceed, my QT and SWIG experience are
> limited so I'm wary of doing things 'the hard way' unnecessarily.

Mike,
Great work so far! I'll try to work with you to handle these things.

> One of the things I'd like to add is support for QT Signals from my derived
> 'gr_qtgui2' back to Python, in particular I'd like to be able to double
> click in the gr_qtgui plot area and receive a QT signal in my Python app.

I use sip to return a QtGui object from the C++ world. I haven't
experimented with what you are asking for, but I hope it's not
unreasonable. We'd have to play with what the object returned by
sip.wrapinstance is actually capable of doing. That is, can we connect
a signal to it? This is something I've been wanting to have, too, so
that you could have a wideband spectrum view and click on a signal to
isolate and start processing it.

> Questions:-
>
> 1 - It appears to me that SWIG does not support QT signals/slots, can anyone
> confirm if that's correct?

Yes, I don't think we'll be doing the signal/slots interfacing through SWIG.

> 2 - If so then I suppose I need to convert my 'gr_qtgui2' over to use SIP ?
> or is there an easier way?

As I said above, because I return a Python QWidget object and that do
the sip.wrapinstance on it to get a PyQt QWidget object, we might have
luck working through this interface.

It'd be best if we can handle everything in the C++ world and connect
it to Python either through SWIG or, more likely, the SIP interface
object. That way, anything we develop for "talking" to the QT window
can be done in either a full C++ app or a Python app.

>
> In case anyone's interested I've made the following 'enhancements' so far:-
>
> - Created a copy of gr_gtgui imaginatively called gr_qtgui2 which 'builds
> out of tree' as a custom block.
> - Removed the QT UI form so that the widget consists of just the plot area
> and labels without the tabs and controls, this allows the widget to resize
> nicely within the parent form and makes it more practical to have more than
> 1 gr_qtgui2 plot displayed simultaneously.

That's perfect. I agree with how you've done that. I think all of the
supporting interfaces (like turning on averaging, max/min hold, etc.)
be made function calls so that they can be built up and used by the
user in whatever context you might want.

I would want to keep the current UI stuff available, though, since it
provides a nice out-of-the-box control for looking at the signals. I'd
have to see how you split out the code, but hopefully we could have
two interfaces: the raw interface you've created and the full one
that's in there currently.

> - Added interfaces to set the BG and FG colour

Cool.

> - Added a 'use_rf_frequencies' interface

Good. This is one of those interfaces that I was just talking about.
Any of the controls in the UI should be made available through
function calls to the interface.

> - Added a center frequency marker and interface
> - Changed zoomer to use drag select rather than click select

I'm not sure what you mean by this. Probably GUI lingo that I'm not
familiar with. Could you explain?

> - Added y axis (amplitude) magnification on mouse wheel

That's cool.

> - Added support in the plot area for catching double clicks and emitting a
> signal (which I can't work out how to receive in Python)

I'll try to help you look into this.

> See http://yfrog.com/f/h8a0xp for an idea of where I'm heading with this.
>
> Any advice would be greatly appreciated.
>
> Mike VK2XMC

Could you let me know if you have this code hosted anywhere? Is there
a public github (or similar) repo that I could pull from?

Thanks!
Tom

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

Re: [Discuss-gnuradio] TETRA phase adjustment bits

2011-01-03 Thread Tom Rondeau 
On Sun, Jan 2, 2011 at 3:02 PM, Harald Welte  wrote:
> Hi!
>
> I know this is slightly off-topic, as it is not really related to gnuradio
> (despite the USRP and gnuradio being used in my current experiments regarding
> TETRA):


I think this list is a fine place to ask these kinds of questions.


> Does anyone know how the phase alignment bits in TETRA exactly work?
>
> I'm reading ETSI EN 300 392-2 V3.2.1 and can find the definition at
> Section 9.4.4.3.6.
>
> So the phase adjustment bits need to be set to the negated sum of the
> phase shift of two other bits in the burst.
>
> Let's assume I'm using hc1, hc2 and thus look at the symbols 8 (bit 15+16) and
> 108 (bit 215+216).
>
> If all of those four bits are 1 (like in the case of the synchronization
> continuous down-link burst), there is a total phase shift of -6pi/4 (two times
> -3pi/4).
>
> But how do you correct such a phase shift in only a single adjustment symbol?
> Using the two bits in the adjustment symbol, I can only apply +1pi/4, -1pi/4,
> +3pi/4 or -3pi/4 ?!?
>
> Any help is appreciated.
>
> Regards,
>        Harald

Harald,
Have you looked at this paper?
http://wsl.stanford.edu/~ee359/doppler2.pdf

It provides a very nice description of pi/4 DQPSK and a receiver
architecture for it. It might provide the answers you're looking for.

Tom

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

Re: [Discuss-gnuradio] DDC and Polyphase Channelizer

2011-01-03 Thread Tom Rondeau 
On Sun, Jan 2, 2011 at 11:57 PM, Jimmy Richardson  wrote:
> Hi, Tom:
>
> Please see my comments below.
>
> Thanks
>
>
> On 12/30/2010 11:47 PM, Tom Rondeau wrote:
>>
>> On Wed, Dec 29, 2010 at 4:32 AM, Jimmy Richardson
>>  wrote:

 Also, keep in mind that fred always develops he own filters straight
 from the remez algorithm. If you are using gr.firdes.low_pass, you're
 not going to get the same output filters. Closer would be to use the
 blcks2.optfir.low_pass, which uses the PM algorithm (which in turn
 uses Remez), but I couldn't give you the specs you need to build the
 same _exact_ filter as in fred's paper. But you'll get close enough
 that the basic shapes of the signals will be the same, if not every
 point.
>>>
>>> Thanks for the suggestion, I modified filter statement to:
>>>
>>>        self._filter_taps = blks2.optfir.low_pass(1, self._input_rate,
>>>                                                  self._cutoff_freq -
>>> self._trans_width/2, self._cutoff_freq + self._trans_width/2,
>>>                                                  0.9, 60, 400)
>>>
>>> Note I have to use 400 as extra taps otherwise remez won't work (too many
>>> extremals -- cannot continue)
>>
>> Hm, that looks wrong. You shouldn't need to use the extra taps input
>> just to get the algorithm to converge. It's really meant to be able to
>> give you minor control over the number of taps you use, specifically
>> if you need a filter with an even or odd number of taps. Using 400 is
>> way too many.
>>
>> The real problem I think comes from your in-band ripple or 0.9. That's
>> a value in dB and specifies the magnitude of the peak-to-peak
>> fluctuations in the passband. I was able to use your settings above
>> but specified a ripple of 0.1, which produces a filter of 764 taps.
>
> You're right, the problem is with the ripple parameter, I changed the line
> to:
>        self._filter_taps = blks2.optfir.low_pass(1, self._input_rate,
>                                                  self._cutoff_freq -
> self._trans_width/2, self._cutoff_freq + self._trans_width/2,
>                                                  0.1, 60)
> and no extra taps are needed, although the new filter has 1524 taps.
>
> But I'm a bit confused why this works, I thought smaller ripple is better,
> and thus harder to get, right? And the ripple parameter is the maximum
> ripple allowed for the filter? If so, 0.9 should be more relaxed than 0.1?

It's not quite that straight-forward. I've found issues when designing
filters with an out-of-band attenuation of 80 that work fine but an
attenuation of 60 fail to converge. The PM algorithm is essentially an
optimization procedure that tries to fit a curve under the provided
conditions. It's been a while since I've looked at the specifics of
it, but because it's doing a curve fit, thinking about it in terms of
one filter being more "relaxed" than another doesn't quite work. Sorry
I can't give you more details or math about why this is true. Maybe
someone else here has gone through this before and has more to offer?


>>> I got the result, but still not the same as the one from Matlab:
>>> 1. The channels seem to be shifted by 20 then wrapped around, i.e.
>>> assuming
>>> channel # starts with 1, the pfb result's channel 1 seems to be matlab's
>>> channel 21, and channel 20 in pfb result seems to be matlab's channel 40,
>>> channel 21 in pfb result seems to be matlab's channel 1.
>>> 2. Assuming the channel shift/wrap is done, the time-domain plot still
>>> are
>>> not the same, pfb channel 1 (matlab's channel 21)'s plot seems to be the
>>> same, and no signal channels do fit, but other channels' plot are not the
>>> same (i.e. the situation is similar to my result of DDC).
>>
>> This strikes me as a simple naming issue; which channel you decide is
>> 0 versus N. The way that I have the output of the channelizer working,
>> channel 0 is the DC channel, channel 1 is the next one to the "right"
>> (the next one in moving in the positive frequency direction). Channel
>> floor(N/2) will either span the last part of the positive spectrum and
>> the first part of the negative spectrum (if N is even) or be the last
>> channel in the positive spectrum (if N is odd). Channel N-1 is
>> directly "left" of channel 0.
>
> Ok, thanks for the explanation, this cleared things up, I added a shift to
> the matlab code to put the two results in line.
>
>> It's hard to know what you mean by the signals being "the same." Are
>> they completely different?
>
> Please check attachment for the results I get:
> appendix_III_receiver_40z.result_time.shifted.jpg: This is the result from
> harris' matlab code, channels are shifted to align with pfb_channelizer_ccf.
> appendix_III_pfb.grfilter.result_time.jpg: This is the result from
> pfb_channelizer_ccf, using filter generated from blks2.optfir.low_pass
> appendix_III_pfb.matlabfilter.result_time.jpg: This is the result from
> pfb_channelizer_ccf, using

Re: [Discuss-gnuradio] TETRA phase adjustment bits

2011-01-03 Thread Harald Welte 
Dear Tom (and others),

On Mon, Jan 03, 2011 at 11:22:11AM -0500, Tom Rondeau wrote:
> >
> > So the phase adjustment bits need to be set to the negated sum of the
> > phase shift of two other bits in the burst.
> >
> > Let's assume I'm using hc1, hc2 and thus look at the symbols 8 (bit 15+16) 
> > and
> > 108 (bit 215+216).

A friend has meanwhile (privately) solved the problem: It is not the sum of the
phase shift of two symbols, but the sum of the phase shift of all symbols in
the range n1...n2.  And as that range is always an odd number, we can always
compensate the cumulative phase shift in a single additional symbol.

> Have you looked at this paper?
> http://wsl.stanford.edu/~ee359/doppler2.pdf

I had seen this before, but thanks anyway.

I'll follow-up to this group once I'm getting anywhere with my code.

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

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

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

2011-01-03 Thread Marten Christophe 
Hello ALL,

Does you have an answer to my request , is there something for charity
there is possibility for like me to use USRP1.

Kind Regards,

On Sun, Dec 12, 2010 at 10:14 PM, Marten Christophe
wrote:

> Hello Matt, and All,
>
> Is there possible,  you can sell only USRP1 board with all components, only
> board no enclosure no power supply only board. with all component soldered
> to it , i will arrange specified ratting power supply here locally,
>
> why i'm requesting it due to i'm a student and dont have that much money to
> buy full USRP1+shipping charges
>
> if you can send only USRP board without enclosures and power supply it will
> reduce shipping cost
> i have arrange so far $ 300  only  , so if it is possible , i will
> be thankful to all of you, USRP1 is very much needed for my practicals and
> study
> you ought to run a program to sell your product to poor students at
> discounted rate as Ettus Research being a big organisation now , but USRP1
> was developed as a open source  hardware with the help of community  and
> very use full for us.
>
> Thanks and Kind regards,
>
>
> On Thu, Nov 4, 2010 at 7:44 PM, Marten Christophe 
> wrote:
>
>> Hello Mr. Ettus,
>>
>> Thanks a lot, at least  for you reply.
>> Now  I will have to search some other cheap SDR, or will have to wait
>> another one year when i will get my scholarship
>> then buy your marvelous product the USRP1..
>>
>>
>> Thanks and Kind regards,
>>
>>
>>
>> On Fri, Nov 5, 2010 at 1:08 AM, Matt Ettus  wrote:
>>
>>>
>>> No.  We do not have or sell blank PCBs.
>>>
>>> Matt
>>>
>>> On 11/04/2010 12:30 PM, Marten Christophe wrote:
>>>
 O, Mr. Ettus,

 at least give me a blank PCB, coz by very hard work i have collected IC
 , FPGA , and all other things, by requesting sample part, if i were
 moneyed
 i must have buy USRP1,

 if i will have a blank PCB at least i will sold all parts , and i wont
 have to copy any others work, and design , and i will kept away my self
 from theft, you know,
 even i will PAY  the blank PCB material cost. and postal charges, from
 US to india, but i buy USRP1 , that i need to shiped, and again high
 amount.

 after all i'm student...from India.

 Kind Regards,


 On Fri, Nov 5, 2010 at 12:51 AM, Matt Ettus >>> > wrote:


No

On 11/04/2010 12:20 PM, Marten Christophe wrote:

Hello Mr. Ettus ,

If you are unable to provide that , know problem , but least
reply my
mail with negation so i wont wait and for you, and start trying
 to
design PCB
with the help of you .SCH file of USRP 1 and will collect money
 to
fabricate it, but for only one PCB it take around $500 start
cost. :(
and more over before doing so, i want you permission b'coze it
 was
designed by you so if it is my moral responsibility to seek your
permission on first place.

Kind Regards,
Devendra Purohit

On Thu, Nov 4, 2010 at 12:02 AM, Marten Christophe
mailto:technosa...@gmail.com>
>>
wrote:



On Mon, Nov 1, 2010 at 11:04 PM, Marten Christophe
mailto:technosa...@gmail.com>
>>
wrote:


Hello Mr. Ettus,


Kindly provide me USRP motherboard Blank PCB board. i
will pay
for postage and material cost.
I'm a poor student and USRP is needed for my research
work and
study, i have almost all components collected by sampling
so i can assemble and sold all of them
if i will have PCB .
$1400+400+ UPS courier charges(oversease shipping) it is
beyond
my ability to spend.
I'm a private Student and keen to learn,but I'm poor too
, hence
don't have capability to buy USRP,
so I'm also trying to make USRP my self. but dont' have
resources to fabricate PCB.
though i have collected all component some of those were
costly
i arranged samples,
only thing left is PCB. can you kindly help me to give
me blank
PCB for USRP ( whether usrp1 or usrp2) mother and
 daughter
board . I will pay the cost what ever it would be for
postage and
your material in advance.
also i need you generous help also , at least guidance.
I'm Doing

Re: [Discuss-gnuradio] Fw: Need Advice for SDR choice

2011-01-03 Thread Mark J. Blair 

On Jan 2, 2011, at 1:31 PM, Andrew Rich wrote:
> I have a MacBook PRO I7 it can run OS X or windows

I have been successfully using the Ettus Research USRP with LFRX, LFTX and WBX 
boards on my 17" MacBook Pro under OS X (Snow Leopard). Installing the software 
portion is pretty easy: Install the MacPorts package, then run "sudo port 
install gnuradio" in a terminal window. You can play with the gnuradio software 
to see if it's right for you before committing to buying any hardware, since it 
can use the audio device and/or data files as a source/sink, or even run 
entirely simulated flowgraphs.

I haven't used any gnuradio-based canned ham radio USB/LSB/whatever 
applications (if any exist). I have successfully received 2m FM transmissions 
with one of the examples that comes with the gnuradio distribution. I've mostly 
used my hardware to generate fairly simple test signals for other radio 
hardware (i.e., a number of simultaneous CW tones within a fairly narrow 
bandwidth) and simple spectrum analysis. At the moment, I'm playing around with 
writing blocks and flowgraphs for sending and receiving high-speed Morse code, 
due to my current interest in devices such as the AN/GRA-71 code burst keyer 
(*). This is all pretty simple stuff that the USRP hardware is overkill for, 
but I'm just beginning to learn about gnuradio and SDR design in general.

Based on what you've stated so far, I think that a USB-based USRP with a WBX 
board and the gnuradio software should work nicely for you, and you can work 
with it directly under OS X. You may also want to get an RFX2400 board to hit 
the 2.4GHz band (I have one, but haven't done much with it yet). This board 
combination will leave a hole between 2.2GHz and 2.3GHz.

If I recall correctly, I've generally set my hardware decimation to limit 
sampled bandwidth to about 2 MHz in order to avoid USB over-runs and/or 
under-runs. I've been able to look at a 4 MHz bandwidth with occasional 
over/under-runs. The occasional over/under-run doesn't seem to cause problems 
when just visually watching an FFT plot (i.e., to look for activity within a 
band).

I don't know if the Ethernet-based USRP platforms work on Macs yet.




(*) More info here if you're curious:

http://www.militaryradio.com/spyradio/gra71.html

These are available (though rare) on the surplus market, but I'm unaware of any 
of the original receiving equipment that has made it out to the hands of 
collectors. A SDR setup seems like a natural way to handle receiving the code 
burst and then either playing it back at low speed for manual decoding, or 
automatically decoding the transmission at normal speed.

-- 
Mark J. Blair, NF6X 
Web page: http://www.nf6x.net/
GnuPG public key available from my web page.





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

Re: [Discuss-gnuradio] Fw: Need Advice for SDR choice

2011-01-03 Thread Marcus D. Leech 
>
> On Jan 2, 2011, at 1:31 PM, Andrew Rich wrote:
>   
>> I have a MacBook PRO I7 it can run OS X or windows
>> 
> I have been successfully using the Ettus Research USRP with LFRX, LFTX and 
> WBX boards on my 17" MacBook Pro under OS X (Snow Leopard). Installing the 
> software portion is pretty easy: Install the MacPorts package, then run "sudo 
> port install gnuradio" in a terminal window. You can play with the gnuradio 
> software to see if it's right for you before committing to buying any 
> hardware, since it can use the audio device and/or data files as a 
> source/sink, or even run entirely simulated flowgraphs.
>
>   
The only caution I have is that the pre-packaged binary packages for
various OS distributions are often
  moderately to severely out-of-date with respect to the current GIT
codebase.

For Ubuntu and Fedora users, I usually recommend a build of Gnu Radio
and UHD from the current
  GIT sources--which I have to admit is partially selfish on my part.
 Fewer people in my support
  queue that way :-) [Wearing my supp...@ettus.com hat].



-- 
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] Synchronized packet transmission

2011-01-03 Thread Sangho Oh 
If I synchronize two USRPs using pps clock

uhd::time_spec_t time_spec = uhd::time_spec_t(0.0);
sdev->set_time_next_pps(time_spec);
boost::this_thread::sleep(boost::posix_time::seconds(1));

and give the metadata for the frame as following

md.time_spec = uhd::time_spec_t(seconds_in_future);

When is the packet is being transmitted?
I believe md.time_spec specify the delay of transmission, which is not an
absolute time of the transmission.



On Sun, Jan 2, 2011 at 4:08 PM, Josh Blum  wrote:

>
>
> On 01/02/2011 12:59 PM, Sangho Oh wrote:
> > Hello Josh,
> >
> > I have used this command
> >
> > dev->send(&buff.front(), samps_to_send,
> > md, uhd::io_type_t::COMPLEX_FLOAT32,
> > uhd::device::SEND_MODE_FULL_BUFF,  seconds_in_future + 0.1);
> >
> > The reference time for seconds_in_future is not clear to me. When does
> the
> > timer starts?
>
> that last parameter is a timeout. In the example, the samples are sent
> several seconds in the future, so the timeout should wait at least that
> long. See the docs for that call:
>
>
> http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1device.html#a11cea7a2131f2764e9afa4eab34bd8d5
>
> The metadata specifies the timestamp of the packet:
>
>
> http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tx__metadata__t.html
>
> > I guess there are large imprecise delay between gnuradio to USRP2 FPGA
> > (gnuradio -> ethernet -> FPGA).
> >
>
> on the order of 10s of microseconds if the CPU is keeping up.
>
> > If I synchronize two USRPs using sync_to_pps(), just wondering how to
> > control the transmit timing from the reference timing stamp, which is
> reset
> > every second?
> >
>
> The time will be set at the next pps to the desired value, and increment
> forever after (its a 64 bit timer). So nothing is reset or rolls over
> every second.
>
>
> http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1single__usrp.html#a7fdb91ce9c7dd16a2c4cf210ebc8105f
>
> -josh
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
*From: Sangho Oh
*
*Voice mail: (609) 759-1552*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fw: Need Advice for SDR choice

2011-01-03 Thread Andrew Rich 
Very helpful thank you 


Sent from my iPhone
Andrew Rich

On 04/01/2011, at 5:22, "Mark J. Blair"  wrote:

> 
> On Jan 2, 2011, at 1:31 PM, Andrew Rich wrote:
>> I have a MacBook PRO I7 it can run OS X or windows
> 
> I have been successfully using the Ettus Research USRP with LFRX, LFTX and 
> WBX boards on my 17" MacBook Pro under OS X (Snow Leopard). Installing the 
> software portion is pretty easy: Install the MacPorts package, then run "sudo 
> port install gnuradio" in a terminal window. You can play with the gnuradio 
> software to see if it's right for you before committing to buying any 
> hardware, since it can use the audio device and/or data files as a 
> source/sink, or even run entirely simulated flowgraphs.
> 
> I haven't used any gnuradio-based canned ham radio USB/LSB/whatever 
> applications (if any exist). I have successfully received 2m FM transmissions 
> with one of the examples that comes with the gnuradio distribution. I've 
> mostly used my hardware to generate fairly simple test signals for other 
> radio hardware (i.e., a number of simultaneous CW tones within a fairly 
> narrow bandwidth) and simple spectrum analysis. At the moment, I'm playing 
> around with writing blocks and flowgraphs for sending and receiving 
> high-speed Morse code, due to my current interest in devices such as the 
> AN/GRA-71 code burst keyer (*). This is all pretty simple stuff that the USRP 
> hardware is overkill for, but I'm just beginning to learn about gnuradio and 
> SDR design in general.
> 
> Based on what you've stated so far, I think that a USB-based USRP with a WBX 
> board and the gnuradio software should work nicely for you, and you can work 
> with it directly under OS X. You may also want to get an RFX2400 board to hit 
> the 2.4GHz band (I have one, but haven't done much with it yet). This board 
> combination will leave a hole between 2.2GHz and 2.3GHz.
> 
> If I recall correctly, I've generally set my hardware decimation to limit 
> sampled bandwidth to about 2 MHz in order to avoid USB over-runs and/or 
> under-runs. I've been able to look at a 4 MHz bandwidth with occasional 
> over/under-runs. The occasional over/under-run doesn't seem to cause problems 
> when just visually watching an FFT plot (i.e., to look for activity within a 
> band).
> 
> I don't know if the Ethernet-based USRP platforms work on Macs yet.
> 
> 
> 
> 
> (*) More info here if you're curious:
> 
>http://www.militaryradio.com/spyradio/gra71.html
> 
> These are available (though rare) on the surplus market, but I'm unaware of 
> any of the original receiving equipment that has made it out to the hands of 
> collectors. A SDR setup seems like a natural way to handle receiving the code 
> burst and then either playing it back at low speed for manual decoding, or 
> automatically decoding the transmission at normal speed.
> 
> -- 
> Mark J. Blair, NF6X 
> Web page: http://www.nf6x.net/
> GnuPG public key available from my web page.
> 
> 
> 
> 
> 
> ___
> 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] DDC and Polyphase Channelizer

2011-01-03 Thread Jimmy Richardson 

Hi, Tom:

Please see my comments below.

Thanks


On 1/4/2011 12:36 AM, Tom Rondeau wrote:

On Sun, Jan 2, 2011 at 11:57 PM, Jimmy Richardson  wrote:

Hi, Tom:

Please see my comments below.

Thanks


On 12/30/2010 11:47 PM, Tom Rondeau wrote:

On Wed, Dec 29, 2010 at 4:32 AM, Jimmy Richardson
  wrote:

Also, keep in mind that fred always develops he own filters straight
from the remez algorithm. If you are using gr.firdes.low_pass, you're
not going to get the same output filters. Closer would be to use the
blcks2.optfir.low_pass, which uses the PM algorithm (which in turn
uses Remez), but I couldn't give you the specs you need to build the
same _exact_ filter as in fred's paper. But you'll get close enough
that the basic shapes of the signals will be the same, if not every
point.

Thanks for the suggestion, I modified filter statement to:

self._filter_taps = blks2.optfir.low_pass(1, self._input_rate,
  self._cutoff_freq -
self._trans_width/2, self._cutoff_freq + self._trans_width/2,
  0.9, 60, 400)

Note I have to use 400 as extra taps otherwise remez won't work (too many
extremals -- cannot continue)

Hm, that looks wrong. You shouldn't need to use the extra taps input
just to get the algorithm to converge. It's really meant to be able to
give you minor control over the number of taps you use, specifically
if you need a filter with an even or odd number of taps. Using 400 is
way too many.

The real problem I think comes from your in-band ripple or 0.9. That's
a value in dB and specifies the magnitude of the peak-to-peak
fluctuations in the passband. I was able to use your settings above
but specified a ripple of 0.1, which produces a filter of 764 taps.

You're right, the problem is with the ripple parameter, I changed the line
to:
self._filter_taps = blks2.optfir.low_pass(1, self._input_rate,
  self._cutoff_freq -
self._trans_width/2, self._cutoff_freq + self._trans_width/2,
  0.1, 60)
and no extra taps are needed, although the new filter has 1524 taps.

But I'm a bit confused why this works, I thought smaller ripple is better,
and thus harder to get, right? And the ripple parameter is the maximum
ripple allowed for the filter? If so, 0.9 should be more relaxed than 0.1?

It's not quite that straight-forward. I've found issues when designing
filters with an out-of-band attenuation of 80 that work fine but an
attenuation of 60 fail to converge. The PM algorithm is essentially an
optimization procedure that tries to fit a curve under the provided
conditions. It's been a while since I've looked at the specifics of
it, but because it's doing a curve fit, thinking about it in terms of
one filter being more "relaxed" than another doesn't quite work. Sorry
I can't give you more details or math about why this is true. Maybe
That is alright, I think I can take it as a quirk of the algorithm, it's 
nice to know :)

someone else here has gone through this before and has more to offer?



I got the result, but still not the same as the one from Matlab:
1. The channels seem to be shifted by 20 then wrapped around, i.e.
assuming
channel # starts with 1, the pfb result's channel 1 seems to be matlab's
channel 21, and channel 20 in pfb result seems to be matlab's channel 40,
channel 21 in pfb result seems to be matlab's channel 1.
2. Assuming the channel shift/wrap is done, the time-domain plot still
are
not the same, pfb channel 1 (matlab's channel 21)'s plot seems to be the
same, and no signal channels do fit, but other channels' plot are not the
same (i.e. the situation is similar to my result of DDC).

This strikes me as a simple naming issue; which channel you decide is
0 versus N. The way that I have the output of the channelizer working,
channel 0 is the DC channel, channel 1 is the next one to the "right"
(the next one in moving in the positive frequency direction). Channel
floor(N/2) will either span the last part of the positive spectrum and
the first part of the negative spectrum (if N is even) or be the last
channel in the positive spectrum (if N is odd). Channel N-1 is
directly "left" of channel 0.

Ok, thanks for the explanation, this cleared things up, I added a shift to
the matlab code to put the two results in line.


It's hard to know what you mean by the signals being "the same." Are
they completely different?

Please check attachment for the results I get:
appendix_III_receiver_40z.result_time.shifted.jpg: This is the result from
harris' matlab code, channels are shifted to align with pfb_channelizer_ccf.
appendix_III_pfb.grfilter.result_time.jpg: This is the result from
pfb_channelizer_ccf, using filter generated from blks2.optfir.low_pass
appendix_III_pfb.matlabfilter.result_time.jpg: This is the result from
pfb_channelizer_ccf, using filter generated from matlab code


Thanks, that helps.

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

2011-01-03 Thread Songsong Gee 
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?

-- 
Seokseong Jeon (aka Songsong Gee)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] MIMO-OFDM 2x1 Alamouti code.

2011-01-03 Thread mmena 
Hi all,

Maybe this question has already been done, but I didn't found any relevant
information about it. I want to implement a MIMO OFDM system (2X1) with
the Alamouti's code in the URSP one, but so far I've only been able to run
an OFDM system using the benchmark_ofdm_tx.py and benchmark_ofdm_rx.py
codes.

The system that I'll implement consist in two RFX2200 cards in the same
USRP working as the transmitter and one RFX2200 in another USRP working as
a receiver.

I really don´t know how I can connect the two RFX2200 cards in the first
USRP one to sincronize them, because I tried to implement the alamouti
code and I need both of them transmitting at the same time, then in the
receiver use the Alamouti decoding to obtain the information sent. I once
read that it had to connect both RFX2200 card with a wired link in order
to sincronize them, is this correct or how I can sincronize them, or if
need a cable how I can make the connection with the RFX2200 cards ?

I want to ask too if there are any MIMO-OFDM implementation in GNURadio, I
was checking and I didn't found any related to this.

I hope someone can help or guide me with my doubts, any link, information
or answer will be helpful.

Thks in advance.


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

2011-01-03 Thread Brian Padalino 
On Tue, Jan 4, 2011 at 12:27 AM, Songsong Gee  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