Re: [Discuss-gnuradio] DQPSK bug or incorrect settings?

[Bob McGwier]

In a word, NEVER.  No self respecting communication systems designer 
would allow that much excess bandwidth on the air or any realistic 
transmission medium.


Typically 2-3 samples per baud is more than enough.  You then use a 
polyphase filter bank based clock recovery tool to FIND the correct 
upsampled phase (at SAY, 6-10 samples per baud) but you never operate 
the demodulator at that much oversampling.


I think Tom has finished and checked in the PFB based clock recovery 
based on the work by fred harris last summer-ish. Am I right?  If not, 
if I may be off assistance in finishing, I will.


Bob


On 8/8/2010 5:00 PM, Tom Rondeau wrote:

On Sun, Aug 8, 2010 at 1:41 PM, Thunder87  wrote:

Thunder87 wrote:


If so, what is maximal and minimal safe "samples/symbol" to "samp_rate"
rates?



Minimal "samples/symbol" is 2.
Is there a maximal ?


215 is a pretty outrageous number to use; you should never need to
oversample that much.

2 to 4 is typical, 6-10 is about the highest you probably want to go.

Tom

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




--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
“Be yourself, because the people who mind don't
 matter. And the people that matter don't mind."
-Dr. Seuss
Active: Facebook,Twitter,LinkedIn


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

Re: [Discuss-gnuradio] complex multiplication question

[Bob McGwier]

The SECOND ORDER Costas loop produces foptr(n) and poptr(n) which is the 
frequency and phase estimate for the carrier.


sin(poptr(n)) is the estimated carrier.

If S(n)*sin(poptr(n) is the spreading code modulating the estimated 
carrier,  then


S(n)*P(n) * complex_conjugate(S(n)*sin(poptr(n)) should be approximately 
P(n) up to error in



a) your estimate of the carrier

BUT ALSO

b) the clock of the transmit system and its initial phase offset for the 
complex spreading code MUST ALSO be estimated to close this system and 
track.  My little equation above ASSUMES perfect knowledge of S(n) which 
is NEVER the case in a real system.


Bob





On 8/3/2010 9:45 PM, John Andrews wrote:

Hi,
can someone guide me a little here please. I have a complex signal S(n)
that I multiply with a sequence P(n) of length N (the sequence consists
of {-1,1} ). I pass the product into a Costas Loop to track the carrier.
Btw, the complex_input signal a spread signal spread using the sequence
P(n) and BPSK modulated.

S(n)*P(n) ---> Costas Loop

Then I want to remove the carrier from the original signal which can be
done by multiplying the frequency output of the costas loop which is
foptr[i] with S(n). Is that right? I want to do this in GRC. Can someone
guide me a little here and tell me if I am understanding it right.

Will be eagerly waiting for a reply. I am not good at Communications
stuff as this is not my major but I am trying hard. :) A little help
will greatly appreciated.

Thanks
John



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



--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
“Be yourself, because the people who mind don't
 matter. And the people that matter don't mind."
-Dr. Seuss
Active: Facebook,Twitter,LinkedIn


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

Re: [Discuss-gnuradio] improper WBX transmission of tone in center of spectrum

[Bob McGwier]

That is an awesome amount of LO suppression in an SSB mixer based system 
(I mean the power 1/33-th of the LO).  A more interesting number 
given this level of LO suppression would be the introduction of a tone 
(say) above the LO at LO+F and to see what the power is at LO-F (the image).


Bob



On 8/3/2010 4:55 PM, Matt Ettus wrote:


The WBX can put out about 20dBm at 520 MHz. -55dBm would be 75dB below
the desired signal, which is quite a good amount of LO suppression. If
you need more, you'll need to actively calibrate the DC offset to null
it out.

Matt


On 08/03/2010 12:55 PM, George Nychis wrote:

The power of the tone comes in to the spectrum analyzer at -55.6dBm






--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
“Be yourself, because the people who mind don't
 matter. And the people that matter don't mind."
-Dr. Seuss
Active: Facebook,Twitter,LinkedIn


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

[Discuss-gnuradio] 2nd Edition

[Bob McGwier]

The 2nd edition of the REALLY expensive ($29.95) SDR book by friend and 
colleague, Behrouz Farhang-Beroujeny,   has been released from lulu.  It 
contains important additions (OFDM, more filtering, all known errata 
fixed) and I recommend it highly.


http://bit.ly/cTU2cm

Enjoy
Bob McGwier
(ARS N4HY)


--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
“Be yourself, because the people who mind don't
 matter. And the people that matter don't mind."
-Dr. Seuss
Active: Facebook,Twitter,LinkedIn


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

[Discuss-gnuradio] Go New Zealand (Slashdot article through bit.ly)

[Bob McGwier]

http://bit.ly/bpwfa9
--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
“One must be a fox in order to recognize traps,
 and a lion to frighten off wolves"
-Machiavelli
Active: Facebook,Twitter,LinkedIn



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

[Discuss-gnuradio] Rohde and Schwarz ridiculous patent app. Sorry Ulrich

[Bob McGwier]

This patent must be fought tooth and nail.  It is loaded with art which 
has been done MANY times before.  I will be personally taking this on as 
a battle for my employers but we need all guns blazing at the patent 
office.  Lockheed, General Dynamics, and more have done SDR units with 
red side/black side in it for JTRS but we just don't want R&S to be able 
to patent something so basic as this in a communications system.


This should be on the radar for cellular telephone companies and more.


Bob





http://www.faqs.org/patents/app/20100027782

Inventors:  Ingo Voll  Boyd Buchin  Dieter Soergel
Agents:  MARSHALL, GERSTEIN & BORUN LLP
Assignees:  Rohde & Schwarz GmbH & Co. KG
Origin: CHICAGO, IL US
IPC8 Class: AH04L918FI
USPC Class: 380 42
Patent application number: 20100027782

Abstract:
The invention relates to a device for processing datastreams in a 
communications unit with two mutually-separate data-processing regions, 
which provide at least two separate message paths. The message paths are 
connected respectively to a message transmitter and a message receiver, 
wherein, in each message path, an encoding module is provided, which is 
connected both to a first data-processing region and also to a second 
data-processing region. Furthermore, in the second data-processing 
region, a distribution unit is provided, which is connected to the 
message paths of the first data-processing region and to all encoding 
modules of the corresponding message paths in order to distribute given 
messages in a targeted manner.

Claims:
1. Device for processing datastreams in a communications unit with two 
mutually-separate data-processing regions, which provide at least two 
separate message paths, which are connected respectively to a message 
transmitter and respectively to a message receiver,comprising,an 
encoding module in each message path connected both to a first 
data-processing region and to a second data-processing region, anda 
distribution unit connected to the message paths of the second 
data-processing region and to all encoding modules of the corresponding 
message paths for the targeted distribution of given messages.


2. Device according to claim 1, whereinthe first data-processing region 
is provided for processing of sensitive data, and the second 
data-processing region is provided for a processing of non-sensitive data.


3. Device according to claim 1, whereintest rules for data exchange 
between the various message paths of the first data-processing region 
are provided in each encoding module.


4. Device according to claim 1, whereinin a relay operating mode, a 
selective distribution of the datastream to the various message paths is 
provided.


5. Device according to claim 4, whereinthe selective distribution of the 
datastream is provided on the basis of different domains with an 
addressing and/or different classification with regard to confidentiality.


6. Device according to claim 1, whereintest rules for a configurable 
data exchange between the first data-processing region and the second 
data-processing region of a message path are provided in each encoding 
module.


7. Device according to claim 6, whereinthe test rules are address lists 
and/or other confidentiality tables.


8. Device according to claim 1, whereinin the case of an error, a data 
leakage from the first data-processing region is prevented.


9. Device according to claim 1, whereinan automatic testing of the 
incoming and/or outgoing communication between the message paths is 
provided in the encoding modules.


10. Device according to claim 1, whereina differentiation of the 
datastreams on the basis of a degree of confidentiality is provided.


11. Device according to claim 1, whereinthe distribution unit is 
connected to a configuration unit.


12. Device according to claim 6, whereinthe test rules are selectively 
configurable in the encoding modules.


13. Device according to claim 1, whereinat least one key capable of 
being read in from externally is stored in each encoding module.


14. Device according to claim 13, whereinthe key can be read in by a 
memory element.


15. Device according to claim 1, whereinthe various message paths meet 
different and/or the same communications standards.


16. Device according to claim 1, whereinthe communications unit is a 
radio device.


17. Device according to claim 1, whereineach message path is connected 
at a first end to an antenna and at a second end to a user interface.


18. Device according to claim 1, whereina bi-directional operating mode 
is provided at least for a subset of the message paths.


19. Method for processing datastreams in a communications unit, 
comprising processing the datastreams in two separate data-processing 
regions, and transporting the datastreams in at least two separate 
message paths between respectively a message transmitter and 
respectively a message receiver and are encoded or decoded in each case 
by an encoding modul

[Discuss-gnuradio] Ettus Research, Inc purchase by NI

[Bob McGwier]

The endeavors of the those I work with has involved applying serious 
research in SDR with the aid of people at Ettus and other GNURadio 
developers.  We have applied serious funding to Ettus Research, Inc. in 
particular and GNURadio in general.  We have every intention of 
continuing this and expanding it.   We write GPL v3 code and we insist 
on the openness continuing.  We have given code back to the repository 
for years and this will continue.  A recent example is the new polyphase 
filter bank and arbitrary rate resampler code checked in by one of the 
developers for GNURadio.


The amount of money and people time involved is significant to anyone's 
way of thinking and has directly impacted, in my view for the better, 
the quality and the quantity of the code currently in the repository. 
This too will continue.  Companies,  governments, scientists, engineers 
and even those that don't know it yet, NEED open source and open 
hardware and are supporting it and using it because of their need. Many 
in older stodgier communities have been slow to follow but are now 
really getting into the act.  It is as simple as that. This trend will 
continue and you are seeing this trend reported about openly in various 
media.  One needs only to decide to pay attention to see it.


I would say for now, fear not, and congratulation to Matt. In my 
conversations with him,  he feels that NI has left him in charge (he is 
the president of the new Ettus) and that while Ettus is a wholly owned 
subsidiary, it is not a small office inside the megalith of immovable 
bureaucracy.  Ettus is a maker as are many of the rest of the developers 
in GNURadio.  I think NI does not want to foul up what is working.  In 
my mind, knowing something of Matt for years,  he would not compromise 
his idealism for a buck.  I have personal knowledge of at least one 
incident where he turned away enough money to satisfy dream's of avarice 
for most of us in a stand in defense of his idealism.  I am proud to 
know him.   The maker mentality's time has come and while USRP is not 
yet in the ideal "maker format" (no 3d printers are involved YET) it is 
moving that way with the inexpensive plug in cards.  Hopefully you won't 
mind me plugging my favorite ex-EFF employee and favorite current syfy 
author's book on the subject.


http://craphound.com/makers/makers_tor_big.jpg

Bob

(P.S. I was not informed before it the NI deal was a fait d'accompli and 
after I spent some time having contracting officers and project managers 
deal with it all, I am personally feeling this will work for us)



--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
“Our beds are empty two-thirds of the time. Our
 living rooms are empty seven-eighths of the
 time. Our office buildings are empty one-half
 of the time. It’s time we gave this some
 thought.” -- R. Buckminster Fuller
Active: Facebook,Twitter,LinkedIn



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

[Discuss-gnuradio] NO KNOBS, An interesting piece on army web site

[Bob McGwier]

http://www.twitpic.com/105rzu

I wonder why it disappeared?  Maybe coincidence.   This was mentioned at 
the recent SDR Forum technical conference.  SDR Forum has become the 
newest buzz word in town,  Wireless Innovation Forum (you have to stay 
relevant right?  You cannot believe how many times I hear at work that 
RF is dead but Wireless is in!).


Bob



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

Re: [Discuss-gnuradio] gr-pager build issue

[Bob McGwier]

Whenever this comes up,  I need to do

sudo make uninstall

for whatever reason.  Something that is in /usr/local/lib/gnuradio ... 
etc. gets in the way of the build.  It is just too easy to do the 
uninstall for me to take time to figure it out.


Bob


On 1/15/2010 8:54 PM, Johnathan Corgan wrote:

On Fri, Jan 15, 2010 at 17:44, Veljko Pejovic  wrote:


I got the same error:

make[4]: *** No rule to make target `/../lib/libgnuradio-pager.la',
needed by `_pager_swig.la'.  Stop.



Did anyone find out what is the source of this error is?


I just did a from-scratch rebuild of the current git revision on
Ubuntu 9.10, no issues.  I suspect this may have to do with a build
tree left over from a prior compile.  Did you just upgrade from 9.04
to 9.10 perhaps?  In any case, the complete
nuke-it-all-to-pristine-state command in git is:

$ git clean -d -x -f

Then you can bootstrap, configure, make, etc.

Johnathan


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




--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"the only people for me are the mad ones,
 the ones who are mad to live, mad to talk,
 mad to be saved, desirous of everything at
 the same time, the ones who never yawn or
 say a commonplace thing, but burn, burn, burn
 like fabulous yellow roman candles" Kerouac
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn



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

[Discuss-gnuradio] Cygwin major upgrade

[Bob McGwier]

There is now available a major upgrade to cygwin, so much so that it 
issues a warning when you try and upgrade to read the documentation.


One of the most significant changes seems to be the swapover to gcc4 and 
some other significant changes to libcygwin, cygserver, etc.


I am not an expert, but those running gnuradio and other things under 
cygwin,  the move to gcc4 and some of the other stated improvements seem 
to me to be a win.


Bob

--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"the only people for me are the mad ones,
 the ones who are mad to live, mad to talk,
 mad to be saved, desirous of everything at
 the same time, the ones who never yawn or
 say a commonplace thing, but burn, burn, burn
 like fabulous yellow roman candles" Kerouac
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn



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

Re: [Discuss-gnuradio] git

[Bob McGwier]

The web site server serves git.  We are all down.

Andreas Fink wrote:

can someone give me the exact command to check out gnuradio via git?
as the website is down, I'm stuck.




___
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] Linux Journal covers amateur radio

[Bob McGwier]

ARRL Website refers to Linux Journal:  http://bit.ly/4Xce6q

73's
Bob
N4HY


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

[Discuss-gnuradio] OT: WARNING! My trouble maker gene is firing

[Bob McGwier]

I am wondering if anyone in receipt of this note is friends with or 
knows the name of a  good high level contact at the ACLU.   I have a 
first amendment case I would like to discuss with them.


Please contact me OFF LIST.

Bob McGwier

--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"You don't need to see the whole staircase, just
take the first step.", MLK.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn




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

Re: [Discuss-gnuradio] Tracking a Carrier Frequency

[Bob McGwier]

The FFT divides the frequency range into bins.  While you can do some 
computation based on the window function you use and how much power is 
in adjacent bins based on this knowledge and get a refined offset,  from 
your proposal that sounds like it might be a step or two down the road 
for you rather than your first step.  The gist of this is that the FFT 
will not be any more accurate than the bin width allows.


A better plan is to allow the FFT to "get you close" , and then use the 
FFT bin center as the initial condition for a PLL, and then use the 
actual phase locked loop based carrier routines with a noise bandwidth 
smaller than the bin width in the FFT.  This will refine the estimate of 
the frequency nicely by using phase lock. 


Bob




Don Latham wrote:

Hi Thomas: What you propose might work; it's a simple bang-bang servo
frequency control. It's success depends a lot on the frequency
characteristics of the drift you are trying to track. I have absolutely no
idea about the difficulty of implementation in Gnuradio, I'm sure that
depends a lot on the rest of your app.
Don

Thomas
  

Hello everyone,

I have an application in which I need the USRP to track a carrier
frequency being received. What I mean by "tracking the carrier" is I need
the USRP to stay tuned to the carrier frequency even if the carrier
frequency drifts (or if the USRP's frequency reference drifts).

I was thinking that I could peridically (perhaps once per second) take the
FFT, find the frequency of the greatest magnitude, and re-tune the USRP to
this frequency.

Is there any reason why this wouldn't work, and is there a better way? It
seems to me this would be a common problem, and there would already be a
good solution, but I haven't been able to find one.

Thanks,

Thomas



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





  



--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"You don't need to see the whole staircase, just
take the first step.", MLK.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn




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

Re: [Discuss-gnuradio] Why not use matched filter in GMSK demodulator

[Bob McGwier]

This is NOT optimal.  CPM and FM detector is a noncoherent detection of 
MSK/GMSK.  The near optimal receiver for MSK and GMSK does two things:


1) it does a coherent detection of the received symbols and
2) it does something like a trellis/viterbi decode for the correct phase 
path through the symbols using the fact that at each symbol time the 
phase transition is +/- pi/2.


Should you follow this type of construction, the performance of coherent 
detection/with "viterbi error correction" for the paths, the performance 
is approximately the same as QPSK with the same bit rate.


Bob


Shizheng Li wrote:

Thank you for your reply!

I think the generic receiver for CPM you mentioned is the optimal 
receiver for CPM and the projection onto basis functions (correlation 
with basis functions) is equivalent to the matched filters, am I right?


Go back to the GMSK transceiver I mentioned in the file

http://gnuradio.org/trac/browser/gnuradio/branches/releases/3.2/gnuradio-core/src/python/gnuradio/blks2impl/gmsk.py

The modulator structure is NRZ mapping --> Gaussian filter --> FM 
modulator
And the demodulator structure is  FM demodulator --> Timing recovery 
--> detector


I think after the FM demodulator the signal can be viewed as a PAM 
modulated signal and what if I add a matched filter before the timing 
recovery? Can I improve the BER performance? I think the matched 
filter can maximize the output SNR. Will it make the detector work 
better?


Best regards,
Shizheng Li



On Thu, Jul 30, 2009 at 2:07 PM, Achilleas Anastasopoulos 
mailto:anas...@umich.edu>> wrote:



There is no reason why you should not use a matched filter.
However make sure you understand that a symbol-spaced MF
generates sufficient statistics only for detection,
ie, not for (epoch) synchronization.
Also note that in the case of GMSK (CPM in general) a bank of MFs
will generate colored noise.
Another appropriate implementation of a front end projects the
entire oversampled signal to a set of orthonormal basis functions
which has the advantage of generating white noise samples for
(simpler) further processing.

Take a look at how a generic receiver for an arbitrary CPM
is developed in

http://gnuradio.org/svn/gnuradio/trunk/gr-trellis/src/examples/test_cpm.py

There, the signal is first projected to its basis functions (which
is calculated by a helper python application in "fsm_utils.py")
to generate a sufficient statistic which is then used in
conjunction with trellis decoding to do soft-decision sequence
detection.
What is missing though is epoch and phase syncronization (to do at
some point...)

Achilleas


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




--
Best Regards,
Shizheng Li
Ph.D. Student and Research Assistant
Department of Electrical and Computer Engineering
Iowa State University



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



--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"You don't need to see the whole staircase, just
take the first step.", MLK.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn




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

Re: [Discuss-gnuradio] Audio Sample rate problem

[Bob McGwier]

In gnuradio-examples/python/audio there is a completely worked out 
example block to do EXACTLY what was requested, go to and from 32000 and 
 48000.  It is good practice to look in the examples directory because 
with very high probability, the developers who check stuff in have faced 
the kinds of problems you want to tackle.  Ask after you have looked there.


In this case it is test_resampler.py

It does a PERFECT 3/2 polyphase resampling ( and back 2/3) since that is 
a rational fraction, not an approximation.  If you use the low_pass_2 
filters, you gain better control over the number of taps required.  It 
uses the brilliant study by fred harris of finding the minimum number of 
taps that will just exceed the number required to get in band ripple, 
transition bandwidth, and stop band rejection you are targeting.


Bob


davek wrote:

On Tue, Jul 7, 2009 at 11:20 PM, Abdalla Sokar wrote:



thanx very much this way really worx and wonderfully too

--- On Wed, 7/8/09, davek  wrote:

From: davek 
Subject: Re: [Discuss-gnuradio] Audio Sample rate problem
To: "Abdalla Sokar" 
Date: Wednesday, July 8, 2009, 5:14 AM

i dont know much about this so it might be wrong but
if you cant figure it out you could put a fractional interpolation
filter before your audio block set to 2/3


On Tue, Jul 7, 2009 at 8:58 PM, Abdalla Sokar wrote:

my audio sampling rate is 48000 not 32000 so all the the gnu examples that
output an audio dont work and due to this 48000 i cant configure the
decimation and interpolation to be even integers as required

so is there away to change sampling rate of my audio card to 32000

i am using Dell Inspiron 1525 with ubuntu 9.04 with the latest version of
GNU
and my USRP is rev 4.2

Please i need help ASAP
Thanx




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

[Discuss-gnuradio] CQ WW contest has a new category, XTREME

[Bob McGwier]

For those who are amateur radio operators and are interested in software 
radio, cognitive radio,  diversity reception, and other such things,  
the contest committee at CQ Magazine has put together a new category of 
operation to help promote innovation.  The brain child of K3LR and K1DG 
with support from many other members of the committee made the following 
official rules and the announcement follows.  Doug, K1DG, came to the 
SDR forum at Dayton and announced it directly to us (before the contest 
forum heard the official announcement).  The Xtreme class is "anything 
goes within reason" and "within reason" is clearly defined and quite 
generous.  Who knows if the "within reason" will continue to be as 
generous as this but the developer/geeks are clearly having the gauntley 
throw down.  Some fantastic experiments can easily be foreseen.  At the 
contest forum at Dayton, it was revealed that banks for Perseus 
receivers had been deployed around the world to "record the contest" and 
some truly fascinating analysis and use was made of these recordings.


I am personally interested in being on a team to develop and operate in 
this class but please contact me OFF LIST, direct email.  Here is the 
official  announcement.  Please, take this and send it everywhere you 
can think of where we might gather some interest.


Bob McGwier
N4HY

--

This year at Dayton, the new CQWW Xtreme categories were announced.

These new categories (single-operator and multi-operator) have been
established to allow amateurs to participate in the CQ WW Contest
while experimenting creatively with Internet-linked stations and other
new technologies that currently are not permitted in any of the
existing contest categories. The full rules for the new Xtreme
Category, as approved by the CQ WW Contest Committee, appear in June
CQ magazine and also at:

http://cqww.com/CQ_WW_Xtreme_Rules.pdf

This PDF file may be copied and re-posted to other Web sites as long
as this text is included: "Reprinted with permission from the June
2009 issue of CQ magazine; copyright CQ Communications, Inc."

Please forward this email to your local club reflectors and newsletters.

The new categories are effective with the 2009 CQ WW Contest later this year.

In essence, (almost) anything goes! The "almost" part means that you
must obey the rules of your country, including power (up to the CQWW
1500W maximum), licensing, and remote operation (if you use it).

It is permitted to use multiple transmitting sites with one callsign
(if legal in your country), but all transmitting sites must be located
in the same country and CQ zone, and only one signal is permitted on a
band at any time. Single-ops with packet, Skimmer, robot stations,
on-line databases, etc. are OK! Multiops with remote operators and
remote receiving sites around the world...OK!

The initial response at both the Contesting Forum and SDR Forum at
Dayton was very positive, with some of the SDR Forum attendees
actually challenging each other in public! This is a chance for
experimenters to see which technology innovations actually work best
in competitive situations.

If you have questions about the rules, please send them to xtr...@cqww.com

There is an also email reflector (xtreme-t...@contesting.com) set up
for discussions relating to these new categories. You can subscribe by
sending email to xtreme-talk-requ...@contesting.com with the word
SUBSCRIBE in the subject line and message text, or go here:
http://dayton.contesting.com/mailman/listinfo/xtreme-talk
(thanks, K5TR)

K3LR has stepped up and is sponsoring the K3TUP Memorial Trophies for
the winners of the single-op and multi-op Xtreme categories.

73, and let the Xtreme Contesting Games begin!

Doug K1DG


--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"You don't need to see the whole staircase, just
take the first step.", MLK.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn




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

Re: [Discuss-gnuradio] Re: Mulitply PN sequence to real and convert output to complex - Question

[Bob McGwier]

Sir:

Welcome to GnuRadio and happy to have a newcomer.  Let me spend some 
time on netiquette here.  Asking the same question, many times in many 
different ways is a sure fired way to get LESS help and for it to be 
delayed by an irritation factor.


To convert a complex signal to real,  it depends on where you are doing 
it.  You are writing what looks like C/C++.   There are gr_complex types 
for GnuRadio in C++.   Let us assume you have a complex number X.   Then 
X.re() is the real part.


Your x(t) is not "making the signal real", it is modulating the complex 
signal Y at baseband by the complex carrier exp(j 2pi t fc).


This gives

Yc(t)Cos(2*pi*fc*t) - Yi(t)Sin(2*pi*fc*t)



as the REAL PART of that modulation process.  


Yc(t)Sin(2*pi*fc*t) + Yi(t)Cos(2*pi*fc*t)  is the imaginary part of that 
complex modulation process.



This is not taking the real part, or "making it real",  it is making a passband 
signal out of a baseband signal.

Your question is somewhat ill posed.  Assuming that you meant modulating the 
signal away from zero frequency by
the carrier frequency fc, and taking the real part to get a passband signal, 
then the answer to your question is yes, you did it right.

Bob




Peng Huo wrote:

sorry a correction,

To convert this complex signal to a real, one has to do

this according to the following formula, isn't it?

x(t) = Yc(t)Cos(2*pi*fc*t) - Yi(t)Sin(2*pi*fc*t) where 
Yc(t) -> Inphase component,Yi(t)-> Quadrature component, fc -> Carrier frequency, x(t) -> real signal.




I looked at the block "complex_to_real" and it outputs the Inphase component
as the real signal. Is it because, "fc" is 0Hz as the signal being at
baseband? I think this sounds right.



I want to mulitply this real signal with a PN sequence and then pass the 
result
on to a costas loop which takes a complex input. I want to know how can we
get a complex signal from a real one. Is there a block that does that? 




The book "Communication Systems" by Simon Haykin 2nd edition says,
- The complex envelope g_complex(t) equals a frequency shifted version of 
the pre-envelope g+(t) as shown
  g_complex(t) = g+(t)*exp(-j2*pi*fc*t), where fc-> carrier 
frequency.


  and the pre-envelop is defined as, g+(t) = g_real(t) + j*g_hilbert(t).

I suppose this is what I need to do to get what I want. Is there a block 
that does it all?

Thanks,
Peng.


P.S. - I am sorry but I thought to make sure before I go ahead so that I 
don't spend time doing things that may be unnecessary.






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



--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"You don't need to see the whole staircase, just
take the first step.", MLK.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn




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

[Discuss-gnuradio] Frank and Sandy

[Bob McGwier]

Frank Brickle (AB2KT) is married to a well known psychologist, Sandra 
Leiblum.  If you do not follow Frank's facebook, linked in, etc.  social 
networking you may not know some news.  They were vacationing recently 
and Sandy suffered a horrific biking accident.  She has had serious 
surgery but is comatose.   Her doctor's are hopeful (we can only hope 
that means a full recovery).  I know all of you will want to join me in 
sending prayers, good wishes,  good vibes, etc. to Frank and Sandy.


Bob

--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"You don't need to see the whole staircase, just
take the first step.", MLK.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn




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

Re: [Discuss-gnuradio] USRP2 Is Now Available

[Bob McGwier]

Congratulations Matt!


Matt Ettus wrote:



John Ackermann N8UR wrote:
Are there any significant hardware differences between the beta and 
production units?  If so, can the betas be reworked to production 
status?



Most of the small list of changes were in layout and are not user 
visible.  The only change of note is that two of the clocks swapped 
pins on the clock generator, but this is all handled in the standard 
firmware.


The reasons for the longer than expected beta period:

- Software -- We wanted to make sure all the daughterboards were 
properly supported, and there were some ethernet throughput issues in 
the host drivers that we wanted to address.  Everything works now.


- Hardware -- We got uncomfortably low yields on the first 2 batches 
of boards and needed to figure out the cause.  It turned out that the 
problems were with a couple of our vendors, but it took a long time to 
figure out the root cause.  We have corrected it, and neither of those 
vendors will ever be used again.  Note that this did NOT affect any 
boards shipped to customers, which were all very thoroughly tested.


- Long lead times for parts -- Once we were ready to go ahead and 
build more boards, some parts we had a "hold" on had been mistakenly 
released to a different customer, and we had to wait 10 weeks for 
replacements.


Matt





--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"You don't need to see the whole staircase, just
take the first step.", MLK.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn




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

Re: [Discuss-gnuradio] MIMO and USRP

[Bob McGwier]

Great.

Sit in front of your keyboard and during the time you wrote this 
complaint you could have made a start on the code.  If you need to build 
flavors of MIMO and you cannot even make this beginning yourself,  you 
are in the wrong end of this business.


This is a user contributed project.  Matt sells hardware.  Users write 
the code.  If you cannot do that and you simply want a code monkey to do 
your work, I suggest you contact Jonathan Coulton or hire a contractor 
or work on it yourself QUIETLY.



Bob McGwier


john boon wrote:

hi all,
   i haven't had any reply till now on "MIMO with USRP". its very 
unfortunate that big people like eric,jonathan and even matt didn't 
reply to my query. A Board like USRP which started way back in 2005 
(usrp1..which is mimo capable according to ieee spectrum 2006 ), still 
dont have any reference code for MIMO. sorry to say, this is really 
slow pace..work. I Understand I NEED to write and make  a way out  and 
for that one has to go through mails lists archives. But my 
investigation requires me to test different flavours of MIMO, i would 
have been happy if there is some working code on which I NEED TO BUILD 
MANY FLAVOURS of MIMO without really breaking down my head over 
writing hardware related configurations program. Forget about C++, i 
dont think any python reference code exists for MIMO. having so many 
standards like wimax and LTE which have MIMO implementations, i think 
gnuradio forum people should seriously think about MIMO 
implementations. Anyway..no way..out i have started writing code..but 
i still stand on the word.."this is not the way you support for open 
source hardware > this is to hardware manufacturers"


thanks
john



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



--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"You don't need to see the whole staircase, just
take the first step.", MLK.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn




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

[Discuss-gnuradio] GPS SDR

[Bob McGwier]

It appears Heckler has repaired his site and in fact the git repository 
has seen activity since the beginning of the year.  It is good that the 
hacked wiki, etc. has been recovered.


This would be a PERFECT candidate to go into cgran (open source, not 
assigned to FSF).


HINT


Bob

--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"It is human nature to think wisely and act in
an absurd fashion.", Anatole France.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn




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

Re: [Discuss-gnuradio] using gnuradio for GPS

[Bob McGwier]

The person has not been maintainingthe web site for a while.  It had 
been hacked and hacked.  Its wiki was so hacked that it was unusable.  
Every now and again,  I would go and set the wiki pages back to the date 
before the hacking occurred but the hackers would just come and wipe it 
out again.  It is such a shame to see this work go into the dustbin.


Bob



Woody Dickson wrote:

The link is not active.  Does anyone know why?

Thanks,
Woody


On Tue, Apr 14, 2009 at 12:15 PM, davek  wrote:
  

www.gps-sdr.com

On Tue, Apr 14, 2009 at 12:05 AM, Woody Dickson  wrote:


Hi,

Does anyone know if there is any reference implementation on the use
of gnuradio for GPS?

I am interested in DIYing my own GPS system.

Any information will be greatly appreciated.

Thanks,
Woody


___
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

  



--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"It is human nature to think wisely and act in
an absurd fashion.", Anatole France.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn




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

[Discuss-gnuradio] Earth Venus Earth communications at

[Bob McGwier]

I am really happy to tell everyone of a terrific  "SDR" experiment.  HI.

Our colleagues in AMSAT-DL have been working towards demonstrating 
several of the pieces  to allow for interplanetary communications in the 
event the Phase V mission to Mars comes to fruition.


A team consisting of many well known amateurs including Wolfgang Büscher 
(DL4YHF),   Freddy de Guchteneire (ON6UG),  Hermann Hagner (DK8CI), 
Michael Lengrüsser (DD5ER) ,  Karl Meinzer (DJ4ZC), James Miller 
(G3RUH), Max Münich (DJ1CR), Hartmut Paesler (DL1YDD), Achim Vollhardt 
(DH2VA).


The AMSAT-DL web page is here:

http://www.amsat-dl.org//index.php?option=com_content&task=view&id=166&Itemid=97

and the English press release is here:

http://www.amsat-dl.org/pic/gallery2/main.php?g2_view=core.DownloadItem&g2_itemId=7561

In the photographs attached to these pages and press releases, one can 
see the SDR-IQ and Spectrum Lab. Congrats to  RFSPACE 
(http://rfspace.com/Home.html)  and  Wolfgang DL4YHF 
(http://freenet-homepage.de/dl4yhf/spectra1.html).


I hope everyone joins in congratulating this team on their multiple year 
effort and outstanding achievement.


Bob McGwier
N4HY

--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"It is human nature to think wisely and act in
an absurd fashion.", Anatole France.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn




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

Re: [Discuss-gnuradio] usrp_wxapt_rcv.py

[Bob McGwier]

I am the author.   The bandwidth of the signal transmitted from the APT 
satellites (NOAA) is 30 kHz but this does not allow for doppler.


The basic RX is almost wholly inappropriate for NOAA APT and for 
anything band pass sampling application without appropriate filtering.  
Operating a 60-ism MHz sample rate A/D means the Nyquist frequency is 
30-ish Mhz.  So all of the signals you are talking about are done with 
undersampling, using aliasing.  But,  FM transmitter are extremely 
strong.  APT are NOT.  All of the noise that is in every 30-ish MHz 
segment up and beyond are folded down on top of the signal of interest.  
This is less important in FM than in weak signal satellite work.


I never considered that anyone would do this or I would have tested for 
the presence of an appropriate tuner or an override be asserted.


Bob




Patrik Tast wrote:

Hi All,
 
My name is Patrik Tast from Vasa, Finland.
 
I this week received the Ettus USRP with daughterboards BasicRX and 
800-2400 MHz RX from CA, US.
I fired it up today to test the BasicRX side using the usrp_wfm_*.py 
and nbfm and everything works as expected. I am able to hear what 
ever FM channels with great quality.
 
Since I am a wxapt guy, http://www.poes-weather.com/, the 
usrp_wxapt_rcv.py was my next test in the examples directory.
 
NOAA 17 @ 137.62 MHz was here just (usrp_wxapt_rcv.py -f 137.62e6 -V 
0) and all I could hear was German radio comming through. Extremly 
faintly, I could hear the TICK-TOCK sound in the background (I also 
could have been imagining, it was so unclear) and (just) some change 
in the graph while the satellite was over me (45 degrees).
 
When I changed to the R2FX-receiver (dedicated APT-receiver) the 
signal is there http://www.df2fq.de/english_version/r2fx_eng.html
 
I could not find an author to the usrp_wxapt_rcv.py nor could I find a 
GRC block diagram for it.
I can see that the author is aiming for 32 kHz bandwith but I suspect 
there is something missing?

APT spec is at http://www2.ncdc.noaa.gov/docs/klm/html/c4/sec4-2.htm
 
I'm using Fedora 9 and GnuRadio 3.1.3 (latest stable release, not from 
svn)
 
Any help appreciated,

Thanks,
Patrik
 
 
 



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



--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"It is human nature to think wisely and act in
an absurd fashion.", Anatole France.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn




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

[Discuss-gnuradio] Call for talks

[Bob Mcgwier]

My last official act as chair of ARRL SDR committee was to agree to chair the 
SDR FORUM at the Dayton Hamvention.

I solicit talks from individuals, groups, or a business.  The talk must be 
about SOFTWARE radio.  I encourage Elecraft, Flex, TAPR/AMSAT, Quicksilver and 
others to participate.  I think this is likely to be the last year as through 
the efforts of individuals, groups, and companies, we are entering mainstream 
territory.  

Let me hear from you if you are interested.  I will pursue invited talks 
separately.

Bob McGwier
ARS N4hy___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pls help me out

[Bob McGwier]

gnu client wrote:

Hi all,

I want to make a GNU radio by using USRP , pls help me out.


Regards,
Basha.


So many new options, so little time. Windows Live Messenger. 






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


http://gnuradio.org/trac



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

Re: [Discuss-gnuradio] GNU Radio 1.3.1 and SMP

[Bob McGwier]

Hew How Chee wrote:

Hi,

Quite some time ago, there are multi core scheduler testing branch for GNU 
Radio.

http://lists.gnu.org/archive/html/discuss-gnuradio/2008-07/msg00159.html

Can I do the same with GNU Radio release 3.1.3 and follow the same instructions 
mentioned in that mail ? I have actually done that but it does not seem to 
distribute the processing among the core on the Intel Atom 330 motherboard.

Regards,
Hew




  



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



Can you actually see the four threads (two hyperthread cores) in the 
linux listing (/proc/cpuinfo).  Do you have SMP and HT enabled in the BIOS?


Bob



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

Re: [Discuss-gnuradio] Correct method for "compressing" a power spectrum

[Bob McGwier]

Franks comments are right on median and ROM in this case.I stayed up 
to 4 AM and went to work at  after having breakfast and a cup of coffee 
and arrived by 9.  It is showing.


The entire gist of my comments amount to nothing more than don't allow 
"aliasing" of the spectral changes as your traverse the compressed power 
spectrum to cause you to miss a peak that is ABOVE the detection threshold.



So,  pardon me but,  is this a pretty picture exercise or a real 
detection problem?  If it is a detection problem,  then you might as 
well just compress to the largest value in the bins to be pushed 
together so you assure that your threshold is exceeded when it should 
be.  If it is a pretty picture problem,  just prevent scalloping by any 
old heuristic, just make it as fleet of calculation feet as possible and 
throw in some pretty grassy stuff to make it look nice.


Bob



Marcus D. Leech wrote:

Bob McGwier wrote:
  

I suggest that the best algorithm for this would be the rank order
mean alternated with the max so long as you are going to insert
"heuristic grass".  So it would be max, ROM, max, ROM, .


Let [B1, B2, B3, B4, ... BN]  be powers of five adjacent bins.

Put them in rank order

[R1, R2, R3, R4,  ... RN]

If N is even,  the rank order mean is (R_(N/2) + R_/(N/2 +1)*0.5.
If N is odd,  the rank order mean is R_(N/2 +0.5)

But I still see a problem:

I suggest that in order to prevent "scalloping" of a swept tone across
this algorithm or any other like it,  that some "bin"  in the lossy
compression set of bins must ALWAYS be forced to take on the large of
the power spectrum otherwise your alternative min/max/min/max might
jump up and down as you sweep a tone through it.  Or did I miss
something?

Bob


I love that phrase, Bob.   "Heuristic grass".

I think that the real answer is to "play with it, and see what best
suits the application".   Ranking the bin might end up being
  expensive.  I'd probably use qsort(),  but I can't remember what its
computational complexity is. Just looked it up.  Worst case
  is O(N**2), and best-case is O(NlogN).   For worst-case, that's rather
brutal at 4M bins (and even worse at my maximum of
  16M bins).

This discussion has ended up being much more fascinating than I had
predicted.   Keep it up everybody!

  



--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"It is human nature to think wisely and act in
an absurd fashion.", Anatole France.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn




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

Re: [Discuss-gnuradio] Correct method for "compressing" a power spectrum

[Bob McGwier]

I suggest that the best algorithm for this would be the rank order mean 
alternated with the max so long as you are going to insert "heuristic 
grass".  So it would be max, ROM, max, ROM, .



Let [B1, B2, B3, B4, ... BN]  be powers of five adjacent bins.

Put them in rank order

[R1, R2, R3, R4,  ... RN]

If N is even,  the rank order mean is (R_(N/2) + R_/(N/2 +1)*0.5.
If N is odd,  the rank order mean is R_(N/2 +0.5)

But I still see a problem:

I suggest that in order to prevent "scalloping" of a swept tone across 
this algorithm or any other like it,  that some "bin"  in the lossy 
compression set of bins must ALWAYS be forced to take on the large of 
the power spectrum otherwise your alternative min/max/min/max might jump 
up and down as you sweep a tone through it.  Or did I miss something?


Bob

John Ackermann N8UR wrote:
One thing you might look at is the "Rosenfell" algorithm used in some 
HP spectrum analyzers (like the 8566).  As I recall, they alternately 
take the maximum and minimum values in the bins -- ie, if you're 
collapsing three bins into one and the original values are


010 050 010|010 050 010|120 130 120|120 130 120|010 050 010|010 050 010

You'd end up with

050 010 130 120 050 010

The idea is that this looks more like the "grass" that you would see 
on a non-digital analyzer and accentuates the difference between noise 
and stable signal, where averaging the bins would lose that 
distinction -- it has the effect of removing indicators that you're 
looking at noise.


Not sure if this might be applicable to the application, and not sure 
I got the details just right from memory, but I think searching 
"Rosenfell" would find more details.


John


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




--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"It is human nature to think wisely and act in
an absurd fashion.", Anatole France.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn




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

[Discuss-gnuradio] Now wait just a minute

[Bob McGwier]

Competition is a great thing. Intel starts down the road towards 
attacking the mobile market and TI/ARM fire back.


https://www.alwaysinnovating.com/touchbook/


This has an OMAP processor in it.  $299 for tablet,  $399 for notebook.

Bob




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

Re: [Discuss-gnuradio] audio_alsa_sink problem

[Bob McGwier]

What is needed IMHO is not extra documentation about GRC but to NOT USE 
plughw or require it when it is not needed.  For those of us with sound 
cards like Delta or other many channeled things,  this causes 
unnecessary burden on the complexity.


Bob


Josh Blum wrote:

I will add a note to the documentation in grc audio blocks about plughw.

Can you edit the generated code and test the following 2 combinations:

self.audio_sink_0 = audio.sink(44100, "plughw:0,0", False)
self.audio_sink_0 = audio.sink(44100, "plughw:0,0")

Let me know. -Josh

Arto Oksanen wrote:

this is from the working dial_tone.py

dst = audio.sink (sample_rate, options.audio_output)

and this is from GRC generated code:

self.audio_sink_0 = audio.sink(44100, "plughw:0,0", True)

For me it looks like the generated code has an extra parameter..

arto





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

[Discuss-gnuradio] Intel ATOM WHOOAAAAA Nellie

[Bob McGwier]

Many of us have and love the Intel ATOM 330 boards we have.  I have 3 of 
them!  I want to ask those who do not see an immediate need for them but 
are thinking about getting one for SDR purposes,  I want to tell you 
that "better things are arriving" as always.


The Nvidia ION will address almost 100% of the few gripes with the 
D945GCLF2 and D945GCLF (Intel Mobo) computers.  The intel graphics chip, 
3D/2D acceleration, is okay, but it is not great.  The D945GCLF2 
addressed the desire for 64 bit OS, but we still had pretty slow memory 
supporting slow DDR2.  Unhappy with the PC VGA connector on the Intel?  
The Nvidia ION has HDMI  output and 7.1 audio!


The Nvidia ION address both of these shortcomings.  The Nvidia ION has a 
memory of Nvidia's very impressive GPU's with the GEO Force (9300/9400) 
family.  It is also supports DDR3 memory.  Both of these factors will 
represent MAJOR improvements in the performance.


Please, if you have not already purchased the Intel ATOM motherboards,  
hold up a bit.  There is nothing wrong with the $80-$90 motherboards you 
currently have but these new ones will represent bit steps in the right 
direction. 

HOWEVER, for those folks who want to build an small board computer for 
supporting the Flex family of firewire devices,  the Intel motherboards 
are your only choice.  You need the PCI slot to get the firewire support.


For those of us who want to support USB 2.0 or better yet,  GigE,  the 
Nvidia ION will provide more IO ports than the Intel motherboard and has 
the other advantages already mentioned here.  You will need an external 
drive case to hold the drives as the eSata ports are on the back of the 
motherboard for Nvidia ION.


So,  no firewire needed?  better memory and graphics needed?  HDMI 
needed or desired?  Wait for the Nvidia ION motherboards to become 
available to you in the second quarter of this year in desktops and 
motherboards.  The ASUS N10Jc notebook are, or soon will be available.


Bob

--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"It is human nature to think wisely and act in
an absurd fashion.", Anatole France.
Twitter:rwmcgwier
Active: Facebook,Myspace,LinkedIn




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

Re: [Discuss-gnuradio] Newbie need help with installing gnuradio 3.1.3

[Bob McGwier]

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

When you have followed the instructions for your OS to the letter.  Come 
back.


Bob


Chris Stankevitz wrote:

Pete,

How did you solve this problem:


While running ./bootstrap, I am getting the following error:
[r...@fodora gnuradio-3.1.3]# ./bootstrap
gr-trellis/doc/Makefile.am:51: `%'-style pattern rules are a GNU
make extension



Chris


___
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] Filterbank stuff

[Bob McGwier]

WSJT uses portaudio directly and that can talk to jack through its 
portaudio host if jack has been compiled with that support in it.


Bob


Frank Brickle wrote:
On Thu, Feb 12, 2009 at 7:59 PM, Marcus D. Leech > wrote:
 


I'm looking into this for a friend who wants to use his USRP2 for EME.
I'll see if I can do something JT65-like (or exactly that!)
 in Gnu Radio.


You should be able to just use it via portaudio on top of JACK, 
talking to the USRP through GNU Radio. There may be some sample rate 
issues that need to be solved in GNU Radio -- last time I looked, WSJT 
only pretended to handle variable sample rates.


Frank


--
...we ain't going to hell, we're going to the rebel side of heaven. -- 
Langhorne Slim





--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"It is human nature to think wisely and act in
an absurd fashion.", Anatole France.



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

Re: [Discuss-gnuradio] Filterbank stuff

[Bob McGwier]

Marcus D. Leech wrote:

I'm toying with some insane ideas for EME (Moonbounce) for a friend of mine.

I'm toying with taking a modulated baseband from a QAM16 modulator, and
replicating it across several spectral pickets
  over a wide band, then on reception doing "something" with these
redundant copies to improve SNR/BER.

I'm currently thinking Analysis Filterbank/Synthesis Filterbank to take
the baseband signals, and spread them across
  a wider spectrum, with replication.

Ignoring whether this approach is sane or not is the filterbank the
right block to use to take multiple narrow baseband signals and
  "map" them onto a wider baseband?

  
PLEASE do yourself a favor and look at WSJT by Joe Taylor.  This guy has 
years and years and years of experience doing this.  He has studied the 
problem absolutely to the n-th degree.  His system is really beautifully 
done.  And,  you know he isn't a nut case because he won the Nobel prize 
for physics proving observational evidence for General Relativity by 
discovering and observing certain types of radio emission pulsars.  The 
only thing that has ever caused me to doubt his sanity was his taking 
the job of Dean of Faculty at Princeton for seven years!


http://www.physics.princeton.edu/pulsar/K1JT/

Bob

--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"It is human nature to think wisely and act in
an absurd fashion.", Anatole France.



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

Re: [Discuss-gnuradio] USRP2 missing Quadrature samples

[Bob McGwier]

AHA!!

(sheepish grin on face wondering why signals looked real  because 
they are)



Bob


Leslie Choong wrote:

Huzzah! It works! I did have the older Flex 2400 daughtercard so I
moved the resistors around and re burned  it. It now works great.
Thanks to everyone who helped out, especially Matt and Jonathan!
-Leslie

On Thu, Feb 5, 2009 at 11:31 AM, Matt Ettus  wrote:

Leslie Choong wrote:

Thanks to Johnathan's help it seems my problem is with the USRP2's
recognition of the daughterboard. I used a USRP1 Rev 4.1 to flash my
FLEX 2400 to the rfx2400 EEPROM using this command:
./burn-db-eeprom -A -t rfx2400 --force


Also, are X1 and X101 populated on your RFX2400?  If so, you have a very old
non-MIMO_B version, which is probably why you saw this problem in the first
place.  If so, you will need to follow the directions here:

   http://gnuradio.org/trac/wiki/USRPClockingNotes

Look under Flex2400.

Matt




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




--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"It is human nature to think wisely and act in
an absurd fashion.", Anatole France.


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

Re: [Discuss-gnuradio] checking for boost >= 1.35... no

[Bob McGwier]

Markus:

In the root directory of the trunk, there is a README file that looks 
suspiciously like it will be the answer to your question. (as in 
README.building-boost)


Good luck
Bob


feldmaus wrote:

Hi All,


i tried to compile gnuradio from trunk(2009.Jan.28) and
got Problems with the boost Package.
My System is openSuse 11.1.

The following Message appears:

checking for boost >= 1.35... no   
  
configure: error: we could not detect the boost libraries (version 1.35 or
higher).   
   
If you are sure you have boost installed, then check your version number looking
in .  
error: Bad exit status from /var/tmp/rpm-tmp.92103 (%build)



Wherfore do i need Boost ?
I tried to use the Option <--with-boost=/usr/include/boost> but without
success.
I installed boost and boost-devel !
Do you have further instructions for me?


Here is a List of all Packages i installed:
python-cheetah-2.0.1-3.4
python-lxml-2.0.5-1.7
python-numpy-1.2.1-6.1
LabPlot-debugsource-1.6.0.2-17.7
LabPlot-1.6.0.2-17.7
gsl-1.11-1.38
libusbpp-0_1-4-0.1.12-136.10
libsigc++2-2.2.2-40.25
xmlto-0.0.18-182.24
python-wxGTK-2.8.8.1-1.48
wxGTK-compat-2.8.8.1-1.48
sdcc-2.8.0-2
libboost_filesystem1_36_0-1.36.0-9.5
wxGTK-2.8.8.1-1.48
sdcc-common-2.8.0-2
fftw3-threads-3.1.2-109.30
swig-1.3.36-2.6
libboost_graph1_36_0-1.36.0-9.5
libboost_iostreams1_36_0-1.36.0-9.5
libboost_math1_36_0-1.36.0-9.5
libboost_program_options1_36_0-1.36.0-9.5
libboost_python1_36_0-1.36.0-9.5
libboost_regex1_36_0-1.36.0-9.5
libboost_serialization1_36_0-1.36.0-9.5
libboost_system1_36_0-1.36.0-9.5
libboost_test1_36_0-1.36.0-9.5
libboost_thread1_36_0-1.36.0-9.5
libcppunit-1_12-0-1.12.0-2.93
guile-1.8.5-22.23
python-gtk-2.12.1-63.3
gtk2-2.14.4-8.1
alsa-1.0.18-8.7
udev-128-9.3
python-numeric-24.2-195.8
fftw3-3.1.2-109.30
libboost_signals1_36_0-1.36.0-9.5
python-2.6.0-2.16
python-base-2.6.0-2.12
alsa-oss-1.0.17-1.37
SDL-1.2.13-104.1
libusb-0_1-4-0.1.12-136.10
SDL-devel-1.2.13-104.1
alsa-devel-1.0.18-8.7
gsl-devel-1.11-1.38
libusb-devel-0.1.12-136.10
wxGTK-devel-2.8.8.1-1.48
boost-devel-1.36.0-9.5
fftw3-devel-3.1.2-109.30
libcppunit-devel-1.12.0-2.93
guile-devel-1.8.5-22.23
python-gtk-devel-2.12.1-63.3
python-devel-2.6.0-2.12
automake-1.10.1-4.264
autoconf-2.63-1.97
libtool-2.2.6-1.20

As you can see there should be all what i need.

Regards Markus




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

  



--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"It is human nature to think wisely and act in
an absurd fashion.", Anatole France.



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

RE: [Discuss-gnuradio] Intel Atom is NICE.

[Bob McGwier]

I did do the install.  BEWARE, steps are required.  PAY ATTENTION.

You need to do a BIOS upgrade to the Dec. 2008 version of the BIOS.  

I chose to use the ISO to CD ROM and boot from the CD ROM.  I tried several
times to flash the BIOS and it never succeeded.  If I hit F2 after reboot it
said that I still had the old BIOS.  On reboot each time, it said I had a
checksum error.


IF ANYONE CAN SHOW ME WHERE IN THE INSTRUCTIONS IT SAYS THIS IS A TWO PASS
PROCESS OR WHERE DURING THE COURSE OF DOING THE FLASH IT SAYS THIS IS A TWO
STEP PROCESS, I WOULD BE PLEASED TO BE TOLD I AM BLIND.

After you do the boot to the ISO CD ROM, and you tell it run,  it runs and
then reboots.  YOU ARE NOT DONE.

On the second reboot,  it THEN flashes the BIOS and succeeds.  I was
removing the CD ROM each time after boot  "so it wouldn't do it again" and
the checksum error was its BRILLIANT message that it had failed to read the
image on the CD.  Give me a break!


After that was finally accomplished,  the Ubuntu 8.10 and F10 CD/DVD
respectively started without a kernel panic.  Also, the BIOS setup page
reveals a new banner page saying "Intel 64 Bit processor compatible" and not
"EM64T Processor capable".

I have compiled and done make distcheck on Ubuntu 8.10 AMD64 and it works.
The GigE works.  I just did all of this yesterday and have not had a chance
to plugin in my USRP2 yet.

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom

-Original Message-
From: discuss-gnuradio-bounces+rwmcgwier=gmail@gnu.org
[mailto:discuss-gnuradio-bounces+rwmcgwier=gmail@gnu.org] On Behalf Of
John Gumb
Sent: Sunday, January 11, 2009 9:02 AM
To: discuss-gnuradio@gnu.org
Subject: Fw: [Discuss-gnuradio] Intel Atom is NICE.

I'd also expect better performance if running a 64 bit OS. When I get chance
I'll install Fedora 10 x86_64 on my D945GCLF2.

cheers

John

- Original Message - 
From: "Eric Cottrell" 
To: 
Sent: Monday, January 05, 2009 3:27 AM
Subject: Re: [Discuss-gnuradio] Intel Atom is NICE.


> - Start Original Message -
> Sent: Mon, 29 Dec 2008 22:53:06 -0500
> From: "Eric A. Cottrell" 
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Intel Atom is NICE.
>
> > Hello,
> >
> > I bought the earlier version of the motherboard with just the 10/100
> > ethernet.  I put it in a MI-100 case and it is a nice little system.  I
> > have not gotten a chance to use it with GNURadio much so I have not
> > commented about it on the list.  I am thinking of using it as a car
> > computer.
>
> - End Original Message -
>
> Hello,
>
> I did not realize that the D945GCLF2 has the new Atom 330 dual core
processor. It should work even better than the earlier D945GCLF board or
netbook that I used.
>
> 73 Eric
>
>
> ___
> 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 mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] Thread scheduling for high-sensitivity, high-resolutionFFTs

[Bob McGwier]

Marcus:

What is the time constant on your IIR?  If the time constant is longer than
two FFT's you are probably losing sensitivity doing noncoherent averaging.
All I am suggesting is that a computation is in order to determine the
"noise figure" of the two approaches.

Bob

ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom


-Original Message-
From: Marcus D. Leech [mailto:mle...@ripnet.com] 
Sent: Wednesday, January 07, 2009 12:00 PM
To: Bob McGwier
Cc: 'Eric Blossom'; 'GNURadio Discussion List'
Subject: Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity,
high-resolutionFFTs

Bob McGwier wrote:
> >From what Eric has described (which should work), you have choices.  The
> choices would be to increase sensitivity by adding the results of the
fft's
> which is the same as producing spectra from long term autocorrelation
which
> will increase sensitivity O(n) because it is coherent averaging or if you
> sist on noncoherent averaging sensitivity will be increase O(sqrt(n)) but
> only by decreasing the variance of the noise.  And/or you can build larger
> fft's from the intermediate ones via several techniques to increase
> frequency resolution.  The latter requires more careful organization
because
> you do not wish to window the smaller ones if you wish to combine them
> later.  This would require windowing in the frequency domain and
necessarily
> the expense of convolution rather than multiplication.
>   
In the existing FFT sink, many frames are dropped, and the FFT output
bins are averaged using a single-pole
  IIR.  It takes long integration times for this to be as sensitive as
an FFT in which no input frames are ever dropped.

In my application (SETI), having long integration times hurts, because
of chirp (although one could also de-chirp
  the baseband prior to computing spectra).

I'll conduct some experiments as Eric has suggested, once I get my
quad-core system back in operation.
  [Don't muck with hardware when you're too sick to cope.  That's how
LGA775 sockets get bent
  pins :-( :-( :-( ].
> This is all a fruitful area for experimentation now that we have the new
TPB
> scheduler.
>
> Bob
>   
Indeed


-- 
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] Thread scheduling for high-sensitivity, high-resolutionFFTs

[Bob McGwier]

>From what Eric has described (which should work), you have choices.  The
choices would be to increase sensitivity by adding the results of the fft's
which is the same as producing spectra from long term autocorrelation which
will increase sensitivity O(n) because it is coherent averaging or if you
sist on noncoherent averaging sensitivity will be increase O(sqrt(n)) but
only by decreasing the variance of the noise.  And/or you can build larger
fft's from the intermediate ones via several techniques to increase
frequency resolution.  The latter requires more careful organization because
you do not wish to window the smaller ones if you wish to combine them
later.  This would require windowing in the frequency domain and necessarily
the expense of convolution rather than multiplication.

This is all a fruitful area for experimentation now that we have the new TPB
scheduler.

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom


-Original Message-
From: discuss-gnuradio-bounces+rwmcgwier=gmail@gnu.org
[mailto:discuss-gnuradio-bounces+rwmcgwier=gmail@gnu.org] On Behalf Of
Eric Blossom
Sent: Wednesday, January 07, 2009 12:39 AM
To: Marcus D. Leech
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Thread scheduling for high-sensitivity,
high-resolutionFFTs

On Tue, Jan 06, 2009 at 11:20:48PM -0500, Marcus D. Leech wrote:
> Eric Blossom wrote:
> >
> >
> > Is this an SMP machine, or a cluster?
> >
> > If SMP, it'll "just work".  If it's a cluster, you'll need to figure
> > out how to partition separate instantiations of GR on each node.
> >
> > Eric
>
> SMP.
> 
> Describe how it'll "just work"??
> 
> Maybe I haven't looked at all the blocks carefully enough, but I can't
> immediately see how to do this.
> 
> I basically want a "distributor" block that distributes FFT input frames
> to multiple instances of an FFT computation,
>   across multiple threads, and have the results of the separate FFTs
> synchronized.

Sounds good.  Sorry,  I misunderstood your goal.
(I'm working on the guts of FFTW now and have FFT on the brain...)

I think we have the blocks you need to do the fanout and fanin
already.  They're disguised as

  gr.deinterleave(itemsize)
  gr.interleave(itemsize)

I think you could use them like this:

  fft_size = 512

  usrp = ...

  fanout = gr.deinterleave(fft_size * gr.sizeof_complex)
  fanin = gr.interleave(fft_size * gr.sizeof_complex)

  fft0 = ...
  fft1 = ...
  fft2 = ...
  fft3 = ...

  connect(usrp, fanout)

  connect((fanout, 0), fft0)
  connect((fanout, 1), fft1)
  connect((fanout, 2), fft2)
  connect((fanout, 3), fft3)

  connect(fft0, (fanin, 0))
  connect(fft1, (fanin, 1))
  connect(fft2, (fanin, 2))
  connect(fft3, (fanin, 3))


Each block runs in its own thread, so this should run faster on an SMP
machine.  Please let us know if this works for you!

[FYI, there are also two extra copies happening in the gr.fft_* block that I
now know how to remove...]

Eric


___
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] Fedora 10 and svn head

[Bob McGwier]

I run Fedora 10 on my Quad core and boost 1_37 installed in /opt.  I am
putting it on one of my dual power PC blades and on one of my dual CBE
blades for experimentation with SDK 3.1.  I am attempting to work out all of
the gotchas with F10 for this work.

--with-boost=/opt/boost(directory of your choice)

in the configure, all seems well.  I believe this is the recommended
procedure in the README.boost in the root of the trunk.  Of course, README
is one of those files that is ignored almost always right?

The only problem I am having with F10 anywhere is cross compile on the PS3
and this is some weird ostream  is no longer included by default in some
file used in the qa code (libcppunit is involved in the error message) which
I just have not had time to work out.

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom

-Original Message-
From: discuss-gnuradio-bounces+rwmcgwier=gmail@gnu.org
[mailto:discuss-gnuradio-bounces+rwmcgwier=gmail@gnu.org] On Behalf Of
Eric Blossom
Sent: Wednesday, December 31, 2008 2:33 PM
To: John Gumb
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Fedora 10 and svn head

On Wed, Dec 31, 2008 at 06:08:42PM +, John Gumb wrote:
> Folks
>
> FWIW just installed Fedora 10 and tried building svn head. Configure  
> fails due to boost being rev 1.34. Seems like Fedora folks don't want to  
> keep up to date with boost. 1.35 or later is required.
>
> The following seems to fix it:
> Download boost-devel-1.37.0-2.fc11.i386.rpm from
>
> http://koji.fedoraproject.org/koji/buildinfo?buildID=75604
>
> If this fails (firefox doesn't seem to like this)
>
> # wget  
>
http://kojipkgs.fedoraproject.org/packages/boost/1.37.0/2.fc11/i386/boost-1.
37.0-2.fc11.i386.rpm
>
> should work.
>
> Remove existing boost devel
> # rpm -e boost-devel-1.34.1-17.fc10.i386
> ...various complaints are seen but the remove does succeed
>
> Add new one:
> # rpm -vi boost-devel-1.37.0-2.fc11.i386.rpm
>
> HTH
>
> Happy New Year!
>
> John

I doubt that 1.37 is binary compatible with 1.34.  

I'd recommend leaving 1.34 installed as the default and figure out how
to get a later version installed in parallel with the system default.
Building boost from source is known to work, see
  
 
http://gnuradio.org/trac/browser/gnuradio/trunk/README.building-boost?format
=raw

Eric


___
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] Intel Atom is NICE.

[Bob McGwier]

And GPU's are going to become commodity priced quickly and possibly even move 
into the GPP and replace older ways of doing floating point.  With Nvidia CUDA, 
you can write code for your GPP, call GPU with intrinsics to get pretty quick 
payback while a better longer term strategy is worked on.

The future of really hard to program heterogeneous/not symmetric multiple core 
processors,  irrespective of how great the bandwidth is,  I don't think is 
looking all that rosy.  It simply cannot take months and months to get speed to 
make the processor pay or the cost per flop, when ALL COSTS are amortized 
(expensive people, etc.) begins to look bad.

Bob



ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom


-Original Message-
From: Newman, Timothy [mailto:trnew...@vt.edu] 
Sent: Monday, December 29, 2008 10:05 AM
To: Marcus D. Leech; Bob McGwier
Cc: hp...@lists.hpsdr.org; q...@yahoogroups.com; flexra...@flex-radio.biz; 
discuss-gnuradio@gnu.org; tim.newman...@gmail.com
Subject: RE: [Discuss-gnuradio] Intel Atom is NICE.

There are many more ways than just lumping everything onto a single GPP.  A 
good example is a recent thread on the GNU radio mailing list where the poster 
is using the USRP2 as a standalone radio with no PC.  Pushing key elements to 
other reconfigurable processors, e.g. the USRP2 FPGA, will greatly ease the 
burden of the GPP.  My point is that "big iron" isn't always necessary if 
you're willing to put some work into distributing the work load to other 
processors (a major research issue currently).

Tim


> -Original Message-
> From: discuss-gnuradio-bounces+trnewman=vt@gnu.org 
> [mailto:discuss-gnuradio-
> bounces+trnewman=vt@gnu.org] On Behalf Of Marcus D. Leech
> Sent: Monday, December 29, 2008 8:14 AM
> To: Bob McGwier
> Cc: hp...@lists.hpsdr.org; q...@yahoogroups.com; flexra...@flex-radio.biz; 
> discuss-
> gnura...@gnu.org
> Subject: Re: [Discuss-gnuradio] Intel Atom is NICE.


> While I can heartily agree that for the expansion of SDR into the
> consumer space, you want it to run on low-power processors, etc, I can't
>   agree that "for most operations" you don't need a high-end CPU.
> 
> For example, 802.11 at anywhere approaching 802.11b bitrates needs some
> serious iron, and yet in our world (the world of SDR
>   geeks), wanting to build SDR/GnuRadio-based 802.11b implementations
> seems a fairly common goal.
> 
> In my work in radio astronomy, I've found that despite the relative
> simplicity of the basic functions my software provides--full-bandwidth
>   spectral display, and total power, for one or two channels, big iron
> is necessary.   I recently upgraded to a quad-core Q6600 to replace
>   a dual-core Pentium D 940.  The quad core loses against the dual-core
> because of a difference in maximum clock speed.  I can
>   run the D 940 at 3.2Ghz forever, and it can process a full 8Mhz of
> dual-channel, complex bandwidth.  The Q6600, on the other hand,
>   is unstable above 2.85Ghz or so, and can't sustain more than about
> 5.3Mhz of dual-complex-channel bandwidth without incurring
>   massive USRP overruns.
> 
> Despite the wonderful new multi-threaded Gnu Radio framework, it seems
> that at least one of those threads really needs as many
>   MIPs as the processor can throw at it, because it has to keep up with
> a real-time data source.
> 
> Any time you're dealing with having to suck in (or send out) as much
> bandwidth as the USRP can tolerate, and
>   *actually doing something* with the entire bandwidth, you need
> ManyMIPS(tm).
>   Which means spending $$$ (although, my dual/quad-core system was much
> less than the $1000.00 you quote above).
> 
> --
> 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



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

RE: [Discuss-gnuradio] Intel Atom is NICE.

[Bob McGwier]

The intel graphics chip set and northbridge are power hungry.  I think the idea 
is optimize code for the 330 and not the peripherals with this inexpensive and 
easy to use Mobo.  The disk drive is hungry as well.

The Intel ATOM Z500 family are mobile processors that have the same SIMD 
registers,  support LCD,  good GigE support, and the potential wart (POTENTIAL) 
is the 100 or 133 MHz FSB.

http://www.axiomtek.com.tw/Products/ViewProduct.asp?view=680#3


The Virginia Tech Mobile (SDR/CR) groups are looking at these (largest SDR/CR 
department in the world I think).

I think we want to optimize SIMD code and see what we can get running on these 
prepackaged, easy to get up and running systems as well as the SoC parts such 
as that family of TI OMAP parts carried on the Beagleboard.

One does NOT need to spend thousands of dollars on an SDR computer for most 
operations.   That is a convenient excuse for me to justify my computer budget 
for "development" and get high end things to play with (so I can kill aliens 
from another galaxy or FSU laboratory with impressive graphics in my "spare 
time").  But most people need to really justify the need for the high end 
computer in my mind and they cannot.  That is my point in all of this.

SDR wants to be on consumer/commodity level processors and SoC to be in 
everyone's "coffee budget" and taken for granted in the ideal world in my book. 
 There seems to be little gained by optimizing this for Quad core extreme 
processors with massive GPU's sitting on them,  tons of expensive high speed 
memory, and the world's fastest drives and costing well upwards of $1000 US.  
Lightweight,  easy to distribute, with browser level GUI's and distributed 
everything on inexpensive processors and we rule the world.  You can call me 
Dr. No. and SDR Working group chairman stands for SPECTRE DUMB RESEARCH working 
group. 

Cheers,
Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom


-Original Message-
From: Daniel O'Connor [mailto:dar...@dons.net.au] 
Sent: Sunday, December 28, 2008 6:12 PM
To: discuss-gnuradio@gnu.org
Cc: Bob McGwier; hp...@lists.hpsdr.org; q...@yahoogroups.com; 
flexra...@flex-radio.biz
Subject: Re: [Discuss-gnuradio] Intel Atom is NICE.

On Monday 29 December 2008 06:53:30 Bob McGwier wrote:
> I am running GnuRadio, SDRMAX, and  PowerSDR on my new Intel ATOM 330 
> MiniITX motherboard.  I had to put a firewire card in the single PCI slot.
> The integrated intel graphics are nice and spiffy (glxgears is at 800 
> fps if you turn off the desktop enhancements, no wiggly windows please).
>
>
>
> At 96000 PowerSDR is running under 15% CPU.  The ATOM burns EIGHT 
> watts and has dual hyperthread cores  (shows up as four processors in task 
> manager).

Unfortunately the 945 chipset eats ~20W - god knows why Intel lumbered the Atom 
with it :(

Toms Hardware (and others) did a test of the Atom vs an underclocked Athlon and 
the later won most of the tests

http://www.tomshardware.com/reviews/Atom-Athlon-Efficient,1997-1.html

I think the Atom combo is cheaper and smaller though :)

--
Daniel O'Connor software and network engineer for Genesis Software - 
http://www.gsoft.com.au "The nice thing about standards is that there are so 
many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C



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

RE: [Discuss-gnuradio] Intel Atom is NICE.

[Bob McGwier]

The intel graphics chip set and northbridge are power hungry.  I think the idea 
is optimize code for the 330 and not the peripherals with this ine

ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom


-Original Message-
From: Daniel O'Connor [mailto:dar...@dons.net.au] 
Sent: Sunday, December 28, 2008 6:12 PM
To: discuss-gnuradio@gnu.org
Cc: Bob McGwier; hp...@lists.hpsdr.org; q...@yahoogroups.com; 
flexra...@flex-radio.biz
Subject: Re: [Discuss-gnuradio] Intel Atom is NICE.

On Monday 29 December 2008 06:53:30 Bob McGwier wrote:
> I am running GnuRadio, SDRMAX, and  PowerSDR on my new Intel ATOM 330 
> MiniITX motherboard.  I had to put a firewire card in the single PCI slot.
> The integrated intel graphics are nice and spiffy (glxgears is at 800 
> fps if you turn off the desktop enhancements, no wiggly windows please).
>
>
>
> At 96000 PowerSDR is running under 15% CPU.  The ATOM burns EIGHT 
> watts and has dual hyperthread cores  (shows up as four processors in task 
> manager).

Unfortunately the 945 chipset eats ~20W - god knows why Intel lumbered the Atom 
with it :(

Toms Hardware (and others) did a test of the Atom vs an underclocked Athlon and 
the later won most of the tests

http://www.tomshardware.com/reviews/Atom-Athlon-Efficient,1997-1.html

I think the Atom combo is cheaper and smaller though :)

--
Daniel O'Connor software and network engineer for Genesis Software - 
http://www.gsoft.com.au "The nice thing about standards is that there are so 
many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C



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

[Discuss-gnuradio] Intel Atom is NICE.

[Bob McGwier]

I am running GnuRadio, SDRMAX, and  PowerSDR on my new Intel ATOM 330
MiniITX motherboard.  I had to put a firewire card in the single PCI slot.
The integrated intel graphics are nice and spiffy (glxgears is at 800 fps if
you turn off the desktop enhancements, no wiggly windows please). 

 

At 96000 PowerSDR is running under 15% CPU.  The ATOM burns EIGHT watts and
has dual hyperthread cores  (shows up as four processors in task manager).

 

My intel ATOM computer, case, memory, disk, keyboard/mouse cost me $275.

 

The motherboard is available for $85  (with processor on it, air cooled) at
NewEgg.   I used it for firewire since there is no firewire.  You no longer
need the LCD display stuff so I hope that is dumped.

The ATOM 330 supports SSE,SSE2, SSE3, SSSE3 so it will run SIMD code quite
nicely and does so with GnuRadio, SDRMAX, and PowerSDR.

 

 

Intel atom mobo/processor bundle: $85

http://www.newegg.com/Product/Product.aspx?Item=N82E16813121359

 

case:  $56

http://www.newegg.com/Product/Product.aspx?Item=N82E16811154084

 

memory:  $21

http://www.newegg.com/Product/Product.aspx?Item=N82E16820134192

 

drive:  $79

 

http://www.newegg.com/Product/Product.aspx?Item=N82E16822136320

 

 

The case has a completely overkill 250w power supply.  They must be
expecting you to put a Pentium D MiniITX board in there.  ;-).  It was an
excessive thing anyway and done only because it will sit next to the
television in the den.

 

Already had keyboard and mouse and the firewire card was $12 the last time I
looked.  The (new from Santa) 52" TV is my monitor.  Running Ubuntu 8.10 and
Windows XP Pro.I have used it to do GnuRadio, PowerSDR, SDRMAX II,
streamed video's from Netflix, Hulu, Youtube, and more.

 

This is a cheap enough, high enough performance computer to complete
dedicate it to the task, and never run into a stupid outlook glitch for
PowerSDR.  On Ubuntu, it is spiffy to compile GnuRadio pretty quickly with
make -j4.

 

I will give some GnuRadio and SDRMaxII numbers later.  Phil Covington has
one so maybe he can give us SDRMax II numbers while I concentrate on
GnuRadio/DttSP. 

 

I will be the first to admit it is not as fast as my QX6700 Ubuntu machine
or the new I7 extreme machine (dual Fedora, Vista 64 for Nvidia Tesla
programming which requires a GOOD pciE-x16 slot and SLI support and a $400
Mobo) but it is plenty fast for these dedicated job small CPU tasks (SDR)
and really cheap.  I made no great effort to save money, it is just cheap
anyway.  

 

I am pushing ahead on the Beagleboard because  I think we need to
collectively turn some attention to the embedded low power SoC and I combine
(along with my embedded programming friends) both ARM and SIMD DSP for SDR.

 

Happy New Year,

Bob

   

 

ARRL SDR Working Group Chair

Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.

"And yes I said, yes I will Yes", Molly Bloom

 

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

RE: [Discuss-gnuradio] Customization of FFT display via C or C++

[Bob McGwier]

This is in the trunk now right?

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom


-Original Message-
From: discuss-gnuradio-bounces+rwmcgwier=gmail@gnu.org
[mailto:discuss-gnuradio-bounces+rwmcgwier=gmail@gnu.org] On Behalf Of
Matt Ettus
Sent: Thursday, December 11, 2008 1:49 PM
To: isaacgerg
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Customization of FFT display via C or C++

isaacgerg wrote:
> Is it possible to modify the existing FFT Graphical Sink code to display
time
> domain data on user defined axis.  I would like to create some custom axis
> plots that display the PSD of the signal and optionally allow the user to
> retune, decimate, and subband tune by right mouse clicking and selecting
an
> option from the menu.
>
> Thanks in advanced
>   

Check out the qt gui work that Tom Rondeau has been doing.  It may not 
do everything you are looking for, but I think it is close.


http://gnuradio.org/trac/browser/gnuradio/branches/developers/trondeau/qt

Matt






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

RE: [Discuss-gnuradio] Upgrade (downgrade?) to a Q6600 CPU

[Bob McGwier]

To be completely honest,  I have never understood the gain to us provided by
the COST the single threaded scheduler imposed.  I cannot find the service
the single thread scheduler provides that cannot be done more easily and
with much greater efficiency in the TPB or even before in a simpler worker
thread pool thing but I am sure this is my ignorance.  Of course, it is easy
to criticize when I did not write it and when the author is in the middle of
the Atlantic with a torn sail limping home (take it easy, he was 30 nm from
the end at 7 this morning)!

Well anyway, we are there now with TPB and that is only going to get better.

I would prefer to have enabled and know how to set this in the config file
than to have environment variables alone.

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom


-Original Message-
From: Johnathan Corgan [mailto:jcor...@corganenterprises.com] 
Sent: Friday, December 12, 2008 10:49 AM
To: Marcus D. Leech
Cc: Bob McGwier; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Upgrade (downgrade?) to a Q6600 CPU

On Thu, Dec 11, 2008 at 1:46 PM, Marcus D. Leech  wrote:

> Also, I looked into the process details of the process running
> usrp_ra_receiver.py, and found that it had
>  25 threads.  That must mean that each block runs in its own thread
> now?

Yes.  The "thread-per-block" design by Eric allows, in many cases, for
the flowgraph throughput to rise until an individual block consumes
100% of a single core.  This is a great improvement over the
single-threaded scheduler that would rate-limit when an entire
flowgraph of blocks consumed a single core.

You can switch between the two for comparison:

$ export GR_SCHEDULER=STS   # single-threaded-scheduler (old)
$ export GR_SCHEDULER=TPB   # thread-per-block (new, default)

-Johnathan



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

RE: [Discuss-gnuradio] Upgrade (downgrade?) to a Q6600 CPU

[Bob McGwier]

Are you taking full advantage of the multi threading now available?  Are you
running a 64 bit version of Linux?

Have you tried compiling GnuRadio with the following flags?

-O3 -msse -msse3 -mfpmath=sse



The gain from the multiple cores is that more threads get "two thirds of
processor" making the aggregate faster but NOT necessarily the single
threads.

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Marcus D. Leech
Sent: Wednesday, December 10, 2008 1:22 PM
To: GNURadio Discussion List
Subject: [Discuss-gnuradio] Upgrade (downgrade?) to a Q6600 CPU

I've been running my radio astronomer receiver software for a couple of
years on a Dual-core Pentium P25 CPU, with
  2GB of 533 Ram, with the CPU clocked at 3.2Ghz.   This has allowed me
to do 8Mhz dual-polarization continuum and
  spectrum, with very few overruns (uOuOuO)

I "upgraded" this system to a Quad-core Q6600, with 4Gb of 667Mhz
ram.It's only able to do 4.5Mhz in situations where
  the previous system could handle 8Mhz.  This is, of course, a big
disappointment, since I was hoping that multiple cores
  would increase the ability for me to add more complex signal
processing, but maintain the same bandwidth as the old system.

Apart from the obvious hardware upgrades (move to a MOBO that can
overclock the Q6600 into the 3Ghz region, and use
  dual-channel RAM), are there software tweaks (I'm thinking
particularly of USB buffering or something) that would allow me to get
better
  performance, without overruns?

Note that I'm using the latest trunk code, as of a few days ago.

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



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

RE: [Discuss-gnuradio] Fixing high pass filter design by optfir.py

[Bob McGwier]

I haven't looked at that code in a while.  I will take the assignment.

Maureen Quirk and I are doing a Octave and SciPy replacement for fdatool.
Maureen has spent years writing FIR and IIR design code.  We are updating it
to use C++ as the code was originally Fortran and written for the Cray
supercomputers we used to have.  This is not "make work".  We need to use it
in several more modern things about to be included here (such as the
polyphase filter bank code I am doing from the work harris and I did this
summer).  We have one more teleconference meeting Friday and then code will
fly out the door.  The design code will follow after Maureen is happy with
it.

This is to be used for and will include both FIR and recursive/all pass
versions of the partition filters.

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Johnathan Corgan
Sent: Monday, December 08, 2008 3:00 PM
To: Firas A.
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Fixing high pass filter design by optfir.py

On Mon, 2008-12-08 at 08:38 -0800, Firas A. wrote:

> There is comment in optfir.py saying "# FIXME high_passs is broken...".
> 
> Can anyone send me an example to regenerate this problem? I have some
spare
> time and I think I can help in fixing this problem (If it still exist)

Firas,

Grepping for FIXME in the code is a great way to look for ways to
contribute, and thanks for offering your help.

Unfortunately, that particular FIXME doesn't make clear what is broken,
so perhaps you shouldn't start there. 

(Hmm.  The FIXME has been there for almost four years.  Maybe nobody
uses that part of the API?  Maybe it isn't broken?)

-Johnathan




___
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] FW: [Jack-Devel] JACK 0.116.0 released

[Bob McGwier]

FYI

ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Davis
Sent: Friday, December 05, 2008 12:02 PM
To: [EMAIL PROTECTED]
Subject: [Jack-Devel] JACK 0.116.0 released

I am happy to announce the release of JACK 0.116.0. This is an important
release, because it fixes all the problems reported with 0.115.6 and now
makes 0.109.2 completely obsolete. Nobody should be using 0.109.2 within
a few weeks, and even that is only to allow for distributions to update.

Packagers should note that there really are manpages for most of the
"tools" clients now (unlike the claim in 0.115.6). 

Source tarball:

 http://jackaudio.org/downloads/jack-audio-connection-kit-0.116.0.tar.gz

Changes since 0.115.6:

(in rough order of importance)

 * compile on OS X
 * fixed deadlock in jack when handling multiple vanishing clients
 * netjack now supports CELT codec to allow use over DSL/WAN
 * many fixes and redesign for netjack code 
 * add missing changes for mixed 32/64-bit server/client support
 * make dynamic SIMD work on OS X
 * man pages for most toolkit clients
 * transport control client added to toolkit clients
 * build system notably cleaned up and stabilized


___
Jack-Devel mailing list
[EMAIL PROTECTED]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org



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

[Discuss-gnuradio] Tom Rondeau esquire

[Bob McGwier]

Dr. Tom Rondeau, formerly of Va. Tech.,  Trinity College Dublin,  and now
the Center for Communications Research has been given the "Best U.S.A. Ph.D.
thesis of 2008" by the council of graduate schools in Washington, D.C. at a
dinner in his honor yesterday.   

 

Tom has been a long time extremely valuable contributor to GnuRadio and now
he even gets paid to have the fun.   I jumped for joy when he said yes to
coming to work with me at CCR.  His long term impact on software radio and
cognitive radio will be tremendous. 

 

 

Please join me in congratulating Tom.

Bob

 

 

ARRL SDR Working Group Chair

Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.

"And yes I said, yes I will Yes", Molly Bloom

 

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

[Discuss-gnuradio] FW: [Linrad] Re: Ubuntu 8.10

[Bob McGwier]

Thank you Roger for the solution to the problem!

Set your Visual Effects to none in Ubuntu 8.10 for efficient operation.

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
" Don't despair, not even over the fact that you don't despair. ", Kafka

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Leif Asbrink
Sent: Sunday, November 23, 2008 11:18 AM
To: [EMAIL PROTECTED]
Subject: [Linrad] Re: Ubuntu 8.10


Hi Roger,

You have solved the problem:-) My Ubuntu 8.10 installation had
'Visual Effects' set to 'Normal'. That was the reason for
abnormal behaviour.

I have now set visual effects to 'None' and now the computer
has normal behaviour and seems to run as well as with other
distributions. (I have not analyzed timing issues in detail.)
Thank you Roger:-)

---  0  ---

According to public media here in Sweden it seems like the
leading distributions are:

1)Ubuntu
2)Fedora
3)Opensuse
4)Mandriva 

I am using Debian for my daily work, and I have now tested
Ubuntu 8.10 and Mandriva 2009 (the most recent ones) Both of
them (now) run well although I was not able to change the
numbering of my soundcards under Mandriva. ALSA is different 
there somehow.

I will test Fedora and Opensuse also.

Is there anyone on this list who prefers another distribution
than the five mentioned? Slackware, Gentoo, CentOS or something 
else? If you post a message to this list about why you prefer it
I will install it on my multi-partition hard disk and try to 
install Linrad on it to see if there are any surprises...

73

Leif / SM5BSZ





On Sun, 23 Nov 2008 09:43:03 -0500
w3sz <[EMAIL PROTECTED]> wrote:

> 
> What follows may or may not be germane to the issue you describe.
> 
> I found that an earlier version of Ubuntu [8.04] installed, by  
> default, here with 'Appearance' extras selected that caused no problem  
> on 'modern' Core2Duo machines but which brought to its knees an old  
> Pentium III that I ran remotely via VNC and using the Gnome desktop.
> 
> The atrocious refresh and HID delays disappeared when I changed the  
> 'appearance
> enhancements' to 'none' by clicking on 'System' then 'Preferences'  
> then 'Appearance' then "Visual Effects', and then clicking to select  
> the 'None' radio button.
> 
> I found that neither 'Normal' or 'Extra' settings of the 'Visual  
> Effects' gave satisfactory performance when the VNC server was active  
> on this old, slow machine.  With the setting of 'None', everything  
> works acceptably.
> 
> Check your 8.10 install and see if something other than 'None' is  
> selected.  If so, select 'None', then recheck your CPU utilization.  I  
> would also suggest rebooting and then checking it again after making  
> the change from either 'Normal' or 'Extra' to 'None'.
> 
> Because you report that 8.04 did not exhibit porcine CPU behavior for  
> you, this issue may not be related to your problem.  On the other  
> hand, it is possible that the 'default' settings of 'Visual Effects'  
> have not remained constant throughout the lifetime of 8.04, and that  
> your default install settings for 8.04 were not identical to mine,  
> thus preventing you from seeing the problem
> with 8.04.
> 
> If the above issue is NOT germane to the problem you described, please  
> accept my apologies for the bandwidth.
> 
> 73,
> 
> Roger Rehr
> W3SZ
> http://www.nitehawk.com/w3sz
> 




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

RE: [Discuss-gnuradio] TI open source tools

[Bob McGwier]

It is supportive of open source development and while that is not enough, it
is enough for now. While we would all like for them open source on their
tools, this is a good first step.

They are committed to open source projects as stated in the many pages here:

http://focus-webapps.ti.com/general/docs/sitesearch/searchsite.tsp?selectedT
opic=1653260327&searchTerm=open+source+development+tools&Input=New+Search


This is a trial period for them to show it makes sense.  The people who
support this at TI are committed and have several things happening in the
industry that is helping them win the day.  You will see in the links above
the commitment to Android, and more.

I do not disparage them for taking these first steps but congratulate them.

Bob



ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
" Don't despair, not even over the fact that you don't despair. ", Kafka


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Philip Balister
Sent: Wednesday, November 19, 2008 11:25 AM
To: Gregory Maxwell
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] TI open source tools

On Wed, Nov 19, 2008 at 8:49 AM, Gregory Maxwell <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 19, 2008 at 9:15 AM, Bob McGwier <[EMAIL PROTECTED]> wrote:
>> In the squeaky wheel gets the grease category,  I have two things.  The
>> story about the removal of the open source Linux tools.  It was a mistake
>> and caused by disorganized placement of tools in their directory
structure.
>> The second thing is I have been given personal assurances from the people
in
>> charge that TI is UTTERLY committed to open source tools.   They are
>> providing me with an ftp site for the tools and are reconstituting the
web
>> site as quickly as possible.
>
>
> TI does not have open source tools for their DSPs, it would appear you
> are again mistaken.  They have proprietary tools available at no cost
> for open source developers to build software for their products.
>
> Regardless of their statements to you, the license agreement reads
> otherwise and they could withdraw the tools at any time. If they like
> to demonstrate the kind of "utter" commitment that you're crediting
> them above then they could release their DSP toolchain  software under
> an open source license, or at least enter into a binding legal
> agreement the prevents the withdraw of the tools.
>
> In any case, I'm glad to hear that your initial claim was mistaken and
> that they hadn't done such a foolish thing today.  Now you can
> continue your uncompensated labour helping them sell their products.
> :)




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

[Discuss-gnuradio] TI open source tools

[Bob McGwier]

In the squeaky wheel gets the grease category,  I have two things.  The
story about the removal of the open source Linux tools.  It was a mistake
and caused by disorganized placement of tools in their directory structure.
The second thing is I have been given personal assurances from the people in
charge that TI is UTTERLY committed to open source tools.   They are
providing me with an ftp site for the tools and are reconstituting the web
site as quickly as possible.

 

THANK YOU TI and friends who helped get this resolved.  I would say we can
proceed with our open source SDR work using the TI parts.

 

Bob

N4HY

 

ARRL SDR Working Group Chair

Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.

" Don't despair, not even over the fact that you don't despair. ", Kafka

 

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

RE: [Discuss-gnuradio] Sigh

[Bob McGwier]

I have a my ti login, which is easy to get.  The link is just gone.



ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
" Don't despair, not even over the fact that you don't despair. ", Kafka


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jeff Brower
Sent: Tuesday, November 18, 2008 2:48 PM
To: Bob McGwier
Cc: discuss-gnuradio@gnu.org; [EMAIL PROTECTED]
Subject: Re: [Discuss-gnuradio] Sigh

Bob-

> It appears that TI has withdrawn the free offering of a linux version of
> its compilers that I pointed out earlier (in October)  at this link.
> 
>
https://www-a.ti.com/downloads/sds_support/targetcontent/LinuxDspTools/downl
oad.html
> 
> This is very disappointing.  Without free tools it makes no sense
> whatsoever to use TI parts for our projects (OMAP, etc.).
> 
> They just took a great thing and flushed it down a toilet.

The above page requires a MyTI log-in... which most people on the group
probably
don't have.

Is there another link that everyone can see?

-Jeff


___
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] Sigh

[Bob McGwier]

It appears that TI has withdrawn the free offering of a linux version of 
its compilers that I pointed out earlier (in October)  at this link.




This is very disappointing.  Without free tools it makes no sense whatsoever to 
use TI parts for our projects (OMAP, etc.).

They just took a great thing and flushed it down a toilet.






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

[Discuss-gnuradio] Jack 1.9 official release

[Bob McGwier]

“

Future Jack2 will be based on C++ jackdmp code base. Jack 1.90 is the  
"renaming" of jackdmp and the result of a lot of developments started  
after LAC 2008.
 
What is new:
 
- waf based build system : Nedko Arnaudov, Grame for preliminary OSX  
support
- control API, dbus based server control access : Nedko Arnaudov, Grame
- NetJack2 components (in progress)  : jack_net backend, netmanager,  
audioadapter, netadapter : Romain Moret, Grame
- code restructuring to help port on other architectures : Michael Voigt
- code cleanup/optimization : Tim Blechmann
- improve handling of server internal clients that can now be loaded/ 
unloaded using the new server control API : Grame
- a lot of bug fix and improvements
 
Jack 1.90 (API compatible with Jack 0.109.2) is now distributed in 2  
different versions:
 
Source code only:
 
http://www.grame.fr/~letz/jack-1.9.0.tar.bz2
 
 
Source code with OSX 32/64bits and Windows binaries:
 
http://www.grame.fr/~letz/jack-1.9.0.tgz
 
 
Stéphane 

 

“

 

 

ARRL SDR Working Group Chair

Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.

" Don't despair, not even over the fact that you don't despair. ", Kafka

 

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

[Discuss-gnuradio] OTP 12B-5 released

[Bob McGwier]

http://www.erlang.org/download.html

 

ARRL SDR Working Group Chair

Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.

" Don't despair, not even over the fact that you don't despair. ", Kafka

 

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

[Discuss-gnuradio] AJAX

[Bob McGwier]

I am looking for anything remotely resembling expert advice on AJAX.  I am
looking for recommendations on books, development tools, etc.

 

Please respond directly to me.  I am doing an open source project and I want
to do a lot of the work using AJAX.

 

Such as

 

http://www.n2yo.com

 

AWESOME.

 

73's

Bob

N4HY

 

 

ARRL SDR Working Group Chair

Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.

" Don't despair, not even over the fact that you don't despair. ", Kafka

 

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

RE: [Discuss-gnuradio] USRP working but problem with cygwin

[Bob McGwier]

Sounds like a volunteer to me!  Ask for a login to the trac wiki!

 

Bob

 

 

ARRL SDR Working Group Chair

Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.

" Don't despair, not even over the fact that you don't despair. "

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Umair Nasir
Sent: Monday, November 03, 2008 11:31 PM
To: [EMAIL PROTECTED]
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] USRP working but problem with cygwin

 

Cygwin works fine. But i really think the wiki installation guide should be
organised in a better manner. The right versions must be present with the
cygwin setup.exe. We face problems in libtool versions and many other
packages.



-- 
Umair

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

RE: Re: [Discuss-gnuradio] Ubuntu 8.10

[Bob McGwier]

If you are not on a cell processor,  you don't want gcell or gr-gcell anyway.  
You have to have jack installed or portaudio installed to get gr-audio-jack and 
gr-audio-portaudio respectively.  These are optional for most.  The 
gr-audio-portaudio and gr-audio-osx are really needed for windows and Mac OS/X 
respectively.

For gr-qtdui install the pack qwt-dev, qt4-dev, qwtplot3d-qt4-dev.  These will 
draw in the necessary packages as dependencies are resolved.  BOOM, you are 
done.

73's
Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
" Don't despair, not even over the fact that you don't despair. "

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Robert
Sent: Monday, November 03, 2008 4:36 AM
To: [EMAIL PROTECTED]
Cc: discuss-gnuradio@gnu.org
Subject: Fw: Re: [Discuss-gnuradio] Ubuntu 8.10

Hi Johnathan,

I went through the wiki instructions again, and this time instead of cutting 
and pasting the long apt-get commands I ran one apt-get per package required 
(so I could see if it worked) and it worked ok with the exception of gcell, 
gr-gcell, gr-audio-jack, gr-audio-osx, gr-audio-portaudio, gr-audio-windows, 
gr-comedi and gr-qtgui.

I captured the configure output to a file, but most of the info in there is  
beyond me. I cant send it to you if you want.

Regards,
Matt


--- On Mon, 3/11/08, Matt Robert <[EMAIL PROTECTED]> wrote:

> From: Matt Robert <[EMAIL PROTECTED]>
> Subject: Re: [Discuss-gnuradio] Ubuntu 8.10
> To: "Johnathan Corgan" <[EMAIL PROTECTED]>
> Received: Monday, 3 November, 2008, 11:39 AM
> G'day Johnathan,
> 
> One of the dependancies is failing when I run ./configure
> which causes the build of gnuradio-core to fail. I'll
> sift through the configure output tonight and give some
> specific info.
> 
> Cheers,
> Matt
> 
> 
> --- On Mon, 3/11/08, Johnathan Corgan
> <[EMAIL PROTECTED]> wrote:
> 
> > From: Johnathan Corgan
> <[EMAIL PROTECTED]>
> > Subject: Re: [Discuss-gnuradio] Ubuntu 8.10
> > To: [EMAIL PROTECTED]
> > Cc: "Robert McGwier"
> <[EMAIL PROTECTED]>, discuss-gnuradio@gnu.org
> > Received: Monday, 3 November, 2008, 10:44 AM
> > On Sun, 2008-11-02 at 14:36 -0800, Matt Robert wrote:
> > 
> > > I have been trying to get the current trunk to
> install
> > on 8.04 and 8.10 but couldnt get it working.
> > > 
> > > The instructions in the GNUradio wiki if followed
> to
> > the letter don't seem to work for me.
> > 
> > I've been going through the Ubuntu 8.10
> dependencies,
> > etc., in detail,
> > as part of revising the binary packaging for release
> 3.2. 
> > Once I'm
> > done, I'll go through the Wiki and make any
> updates
> > needed.  What is
> > failing for you?
> > 
> > -Johnathan
> 
> 
>   Search 1000's of available singles in your area
> at the new Yahoo!7 Dating. Get Started
> http://au.dating.yahoo.com/?cid=53151&pid=1011


  Search 1000's of available singles in your area at the new Yahoo!7 
Dating. Get Started http://au.dating.yahoo.com/?cid=53151&pid=1011


___
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] fractional_interpolator_cc?

[Bob McGwier]

Whenever you do an efficient implementation of the rational ratio resampler,
you pick out one of the polyphase arms to do the actually evaluation of the
filter taps and skip all of the implied zeros in the upsampled signal (for
the obvious computational advantage).  BUT, you can pick which "phase" or
step to start evaluating the filter.  This is the genesis of the term
"polyphase".

HOWEVER, the fractional interpolator is NOT the rational resampler which is

http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/filter
/gr_rational_resampler_base_XXX.cc.t

and the fractional interpolator is intended for use with resampling ratios
that would require HUGE filters to be partitioned in order to achieve the
rational resampler.  Since all digital computers are by their nature,
rational number machines,  it would be possible, but onerous.



Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"Trample the slow   Hurdle the dead"


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Brian Padalino
Sent: Tuesday, October 21, 2008 10:34 AM
To: Clark Pope
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] fractional_interpolator_cc?

On Tue, Oct 21, 2008 at 10:15 AM, Clark Pope <[EMAIL PROTECTED]> wrote:
>
> I'm not able to get this function to work correctly. I have it just
connected between a snapshot file and an output file. I set the
interpolation factor to 2.0 and the output file ends up half the size of the
input file. It's like it is a decimation block instead of interpolation?

How does the rational resampler work out - or can you not represent
the ratio as a rational number?

Are you calling it correctly?  It seems as if there is a phase shift
as well as an interpolation ratio being passed in.

 
http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/filter
/gr_fractional_interpolator_cc.cc#L38
 
http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/filter
/gr_fractional_interpolator_cc.cc#L67

There may be an issue here:

 
http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/filter
/gr_fractional_interpolator_cc.cc#L49

Might be upside down?

Brian


___
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] Using gnu-radio for ARM NEON

[Bob McGwier]

It is actually an ARMv7a.

This a LATER chip than the ARM11, much less the ARM9.  The NEON is a
powerful 128 bit wide SIMD processor capable of doing floating point
arithmetic.

Bob


This is definitely going to make a VERY nice low power SDR board.  Another
we should consider is the OMAP-L137 which has 
ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"Trample the slow   Hurdle the dead"


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Philip Balister
Sent: Tuesday, October 14, 2008 9:11 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Using gnu-radio for ARM NEON

On Tue, Sep 30, 2008 at 9:24 PM, John Gilmore <[EMAIL PROTECTED]> wrote:
>> Do you mind adding NEON to this list?  NEON is a SIMD unit on ARM
>> Cortex-A8 processors. Information on NEON instructions is at
>>
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204h/Bcfjicf
>> j.html.
>> Sorry it si the superseded link, I'm too lazy to find the current one
>> :)
>
> This assembler language manual gives pretty good details (except
> actual instruction encodings):
>
>
http://infocenter.arm.com/help/topic/com.arm.doc.dui0204h/DUI0204H_rvct_asse
mbler_guide.pdf
>
> I also tried looking at NEON for the ARM-9, but got:
>
>  http://infocenter.arm.com/help/topic/com.arm.doc.ddi0409a/index.html
>
>  "Cortex-A9 NEON Media Processing Engine Technical Reference Manual
>   Revision: r0p0

The Cortex-A9 is not the same as an arm9. The Beagle uses a Cortex-A8
which is an armv7 architecture processor. Confusing? Yes. An arm9
processor uses an armv5 instruction set. (From memory)

The arm7 technical reference is not public, but if you ask nicely you
can get a copy. Needing it to implement NEON based filters for GNU
Radio was a good reason.

Bottom line: companies are still "funny" about doucmentation for high
end products, but attitudes are changing very slowly.

Philip
>
>   This is a placeholder for a restricted document that is not
>   available from this site. Please contact ARM for more information."
>
>John
>
>
>
> ___
> 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 mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] error in ./configure

[Bob McGwier]

Follow the instructions for your distribution given on the wiki

 

Here:  http://gnuradio.org/trac

 

On this page click on build.  The click on your distribution.  Had you done
this to begin with, you would have installed all of the python development
needs and never would have seen this message.  

 

Bob

 

ARRL SDR Working Group Chair

Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.

"Trample the slow   Hurdle the dead"

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Prasant Misra
Sent: Thursday, October 02, 2008 9:55 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] error in ./configure

 

  
I downloaded the tarball gnuradio-3.1.3.

When I run the ./configure, I get the error message:

configure: error: cannot find usable Python headers

Please suggest as to what I need to do.

Thanks. 

Prasant Kumar Misra.


 
 Black578x38_banner2.gif

 

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

[Discuss-gnuradio] wfm_rcv_pll.py and usrp_wfm_rcv_pll.py

[Bob McGwier]

I made changes to the wfm_rcv_pll.py and usrp_wfm_rcv_pll.py that I believed
were necessary.

 

I modified the bandwidth of the PLL in wfm_rcv_pll.py to comply with
"Carson's rule".  I modified the audio output to be 48 kHz using rational
resamplers.  

 

If there are any problems, please let me know.  This is my first step in a
multistep task  and I want to get this all right first.

 

Bob

 

 

ARRL SDR Working Group Chair

Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.


"Trample the slow   Hurdle the dead"

 

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

RE: [Discuss-gnuradio] FPGA Modeling in MATLAB/Octave

[Bob McGwier]

You mean as in simulink (matlab only)? Or as a standalone (.m file)
matlab/octave program?

Is there a fixed point rough equivalent for Octave?

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"Trample the slow   Hurdle the dead"


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Kyle Pearson
Sent: Wednesday, October 01, 2008 2:54 PM
To: Gnu radio Mailing list
Subject: [Discuss-gnuradio] FPGA Modeling in MATLAB/Octave

I'm looking to model the rx_chain of the USRP using MATLAB's fixed
point toolbox and I'm wondering if anyone has tried this yet in MATLAB
or Octave.

Thanks,
Kyle


___
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] On Off Keying

[Bob McGwier]

U.  I thought the ADC's or an external gain element was on the USRP1.

 

ARRL SDR Working Group Chair

Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.

"Trample the slow   Hurdle the dead"

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Firas Abbas
Sent: Tuesday, September 30, 2008 3:22 PM
To: Brian Padalino; Johnathan Corgan
Cc: sri ram; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] On Off Keying

 


Hi,


> Johnathan Corgan <[EMAIL PROTECTED]> wrote:
>

> None  of the daughterboards have AGC as far as I'm aware (Matt,


> correct me if I'm wrong on this.)


I'm not very sure, but I think TVRX daughter board has an AGC.

Regards,

Firas

 

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

RE: [Discuss-gnuradio] Patch 3/3: db specific patches

[Bob McGwier]

Tom is VERY close to support for almost all of the daughter cards.   He,
Jason, and I have already all currently available daughterboards or on order
for quick delivery with the goal of making all of them work.  Jason needs
all of them at work and with USRP1 support for now, and USRP2 support once
it is in our hands and we have c++/libgnuradio.so support rung out.

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
“Trample the slow   Hurdle the dead"


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Johnathan Corgan
Sent: Tuesday, September 30, 2008 3:06 PM
To: Stefan Brüns
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Patch 3/3: db specific patches

Stefan Brüns wrote:

> What but be the best way to get any changes into trunk or a branch as soon
as 
> possible? First, there are some changes possible in Toms branch to get it 
> more in line with trunk. Clearly there are other parts which are not in 
> trunk, but in Toms branch (eg the usrp_basic::db(...) method and related 
> stuff), which have to be merged into trunk. And there are some changes
which 
> should be applied to Toms branch to make the patch and the codebase as
small 
> as possible.

All the work on the C++ db code has been merged into a feature branch
based on a very recent trunk:

http://gnuradio.org/trac/browser/gnuradio/branches/features/cppdb

Fortunately, very little had to be changed to work with the current
trunk vs. the one the development branch was based on, so you shouldn't
expect any surprises in the actual daughterboard code.  Any future
changes to the code, as well as some wider testing, will happen here.

Right now there are some issues regarding compatibility with the
original Python implementations; we're working through that.



___
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] Using gnu-radio for project

[Bob McGwier]

I agree with this because of the Beagle board and the efficacy of OMAP
processors for embedded SDR apps.  With TI finally giving us free
development tools for noncommercial activities (not exactly GPL v3) the 6000
DSP part on the OMAP and the Neon are both sources of considerable MIPS at
very low power.

We should think about how to officially support libraries based on open
source we develop but for which there are NO free tools for some of the more
interesting parts coming out way including Cell, OMAP, Tilera Tile64, and
more.  We are doing this now for USRP2.  It is time to make a simple policy
statement that open source, but binary support is accepted and encouraged
given these conditions: A), B), 



Bob

ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"Trample the slow   Hurdle the dead"

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Philip Balister
Sent: Tuesday, September 30, 2008 2:03 PM
To: Eric Blossom; Inderaj Bains; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Using gnu-radio for project

On Tue, Sep 30, 2008 at 1:48 PM, Eric Blossom <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 29, 2008 at 03:13:09PM -0700, Inderaj Bains wrote:
>> Thanks Eric,
>> Yes I want to use SIMD. Since I want to spend most time improving
>> performance, it would be nice if I can start off from something
functioning
>> or put together something quickly.
>> How much effort would it be to get a GSM (other?) all software system
>> together (except A/D I guess). Maybe I could use pre-generated streams on
>> both ends in software.
>>
>> Thanks
>> Inderaj
>
> This is great.  What we've been thinking about is building a library
> of SIMD accelerated primitives, along the lines of Intel's Integrated
> Performance Primitives.  The crucial differences would be: free
> software (GPLv3); support for SSE, SSE2, SSE3, Altivec and Cell SPE
> instruction sets.

Do you mind adding NEON to this list?  NEON is a SIMD unit on ARM
Cortex-A8 processors. Information on NEON instructions is at
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204h/Bcfjicf
j.html.
Sorry it si the superseded link, I'm too lazy to find the current one
:)

> Our working title for this is the "Generic Performance Primtives" (GPP).
>
> One unresolved issue is what code to start with.  We need a framework
> that provides for reference implementations, QA, testing all argument
> alignments, correctness, performance, etc; runtime dispatch based on
> the equivalent of cpuid; can be built as both shared and static
> libraries (need static on the SPE).
>
> The basic idea (for the user visible routines) would be to start with
> the well thought out API described in Volume 1 (Signal Processing) of
> the IPP docs, peforming a s/ipp/gpp/g.
>
>
http://softwarecommunity.intel.com/isn/downloads/softwareproducts/pdfs/34649
9.pdf
>
>
http://softwarecommunity.intel.com/isn/downloads/softwareproducts/pdfs/34653
2_userguide_win_ia32.pdf
>
>
> Two possible starting points are:
>
>  liboil  http://liboil.sourceforge.net(currently x86, x86-64 and
PPC)

liboil is used by a number of desktop programs, spending time on this
would be a win for me :)

Philip

>  Framewave   http://framewave.sourceforge.net (x86 and x86-64 only)
>
>  (Framewave is built on top of SSEPlus, a thin wrapper on top of the SSE
>  C/C++ intrinsics.  http://sseplus.sourceforge.net
>  Mostly it appears that they provide emulations for instructions that
>  are missing at a particular level.  E.g., your code could target SSE3,
>  and they'd emulate the missing addsub instruction in terms of SSE.)
>
>
> For starters, it would be great if you could look at these two options
> (and any others that you come across) and let us know how you think
> these would work out as starting points, given the requirements above.
>
> If this seems like more than you want to bite off, I can provide a
> list of high-priority functions and you could start implementing the
> reference version and any of the SSE*, Altivec or SPE versions that
> grab your attention.  We're big on complex arithmetic :-)
>
> Please let me know how this sounds and if you've got any comments or
questions.
>
> Thanks!
> Eric
>
>
> ___
> 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 mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] GNU-Radio GUI applications freeze

[Bob McGwier]

If you have a hardware accelerated graphics card which supports opengl,  you
can get even better speed up:

http://gnuradio.org/trac/browser/gnuradio/trunk/gr-wxgui/README.gl


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"Trample the slow   Hurdle the dead"


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Paul Mathews
Sent: Friday, September 26, 2008 8:53 PM
To: 'Raul Siles'
Cc: discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] GNU-Radio GUI applications freeze

Thanks should go to Jon Jacky, who identified the problem some time ago.
Paul

-Original Message-
From: Raul Siles [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 26, 2008 4:07 PM
To: Paul Mathews
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] GNU-Radio GUI applications freeze


Paul, you rock

Changing the decimation factor (-n) to a bigger value (the default value is
1) works like a charm and solves all my GUI freeze issues, even within
VMware. I started with "-n 100" (as you suggested) for usrp_oscope.py, but
it is too much and the refresh rate is very slow. Then I tried, 10, 5, and
in my case, it even works great with "-n 2".

Thanks a lot!!
--
Raul Siles
www.raulsiles.com





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

RE: [Discuss-gnuradio] USRP vs alternatives

[Bob McGwier]

You will need a soundcard and then you set up an stereo source.  I/Q at
baseband is delivered.

There is no "softrock interface" in gnuradio because there is no hardware to
control.  It delivers a 100 kHz or so and this is centered on the crystal
frequency on the softrock.

In gnuradio-examples/python/apps there are the Swiger hf_*  applications
which could be easily modified to do the required tasks.

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"Trample the slow   Hurdle the dead"


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Chris Albertson
Sent: Thursday, September 25, 2008 12:58 PM
To: Paul Miller
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] USRP vs alternatives

I really does not have it's own software.  It's just that most softrock user
like to use the "rocky" software because it runs on Windows.  You can't
really do much with Rocky because it is closed source, binary only.

Many people are using other software with softrock hardware.  However
I think most of that "other" software is Dttsp based rather then
gnuradio based. The
hardware is designed to be connected to a sound card and outputs
I and Q over a pair of analog outputs.  So what ever software you use
it would not have to "talk" to the softrock, it would talk to your
computer's audio subsystem.  Connections to the SR are all
analog

The kit costs only $8 for the
receiver and even with it's use of SMD is not hard to build.

On Thu, Sep 25, 2008 at 6:55 AM, Paul Miller <[EMAIL PROTECTED]>
wrote:
> Because of the very high cost of the USRP, I'm looking for
> alternatives.  I found this gadget and I wondered if GNUradio is setup
> to use devices like this:
>
> http://www.amqrp.org/kits/softrock40/
>
> It appears to have its own software, but I'd rather get it to work
> with gnuradio if it's possible to do so.  Am I better of adapting the
> software they provide?  Am I better of trying to find the money for a
> USRP?  I don't know enough to even know how to approach these
> questions.  It seems like everything I read in SDR turns into a very
> deep rabbit hole.
>
> --
> If riding in an airplane is flying, then riding in a boat is swimming.
> 107 jumps, 43.5 minutes of freefall, 83.4 freefall miles.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
=
Chris Albertson
Redondo Beach, California


___
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] USRP2 FPGA Notes

[Bob McGwier]

I see an emotional decision being considered and not necessarily a wise
business decision and one that involves more than Ettus, Inc.  Open Source
software, which I live and breathe for, does not mean free.  It is certainly
not free to you, Matt, when you have to support multiple versions of the
hardware.  It is not free to the developers who support GnuRadio, day in and
day out, spending their personal time,  their employers time, etc. to write
code for these devices.  

On the Xilinx software, indeed, you can redo the demo versions repeatedly.
My opinion is, it is what it is,  you made the right design decision to give
all of us sufficient capability to do all of those things that will allow
those of us who are pursuing (with a dogged vengeance) the manufacture of
one stop shopping for radio infrastructure, here in gnuradio.

I would oppose your well intentioned expenditure of time on this.  You just
got the USRP2 out the door, and within a short time,  there is little doubt
in my mind that the part will be supported by the free tools in a fairly
short time as other parts have in the past.


You cannot please everyone all of the time and this hardware and this
software project are doing "the good work" that needs doing for the vast
majority of the users/supporters here.

Bob

ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"Trample the slow   Hurdle the dead"

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Matt Ettus
Sent: Saturday, September 20, 2008 1:59 PM
To: David M. Witten II
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] USRP2 FPGA Notes


David,

--- snip ---

Well here is one alternative.  The S3-1500 is pin compatible with the 
2000.  If enough people wish to purchase a special version with the 
smaller FPGA I can have a number of them built that way.  You would have 
to do some work to save a few block RAMs, but this isn't impossible.  My 
last version that used the 1500 (rev 1) should still be in the repository.


Please let me know what you think.

Matt




___
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] USRP2 Price

[Bob McGwier]

The same daughter boards that work for USRP, work for USRP2.

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"Trample the slow   Hurdle the dead"


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
isaacgerg
Sent: Tuesday, September 09, 2008 4:34 PM
To: Discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] USRP2 Price


I dont see any daugterboards that work for the USRP2.

isaac
-- 
View this message in context:
http://www.nabble.com/USRP2-Price-tp19399125p19400649.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] USRP2 Price

[Bob McGwier]

The accessories are the same,  order awayyy

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"Trample the slow   Hurdle the dead"


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Dan Halperin
Sent: Tuesday, September 09, 2008 3:15 PM
To: Brian Padalino
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] USRP2 Price

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 9, 2008, at 12:11 PM, Brian Padalino wrote:

> On Tue, Sep 9, 2008 at 3:08 PM, isaacgerg <[EMAIL PROTECTED]>  
> wrote:
>>
>> Any ideas in US dollars?
>
> http://www.ettus.com/orderpage.html
>
> List price seems to be $1400, but don't forget the accessories!


Whoa; are these actually purchaseable yet? Last I heard Matt wasn't  
taking preorders and there weren't any announcements to the contrary.

- -Dan





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

RE: [Discuss-gnuradio] USRP2 Price

[Bob McGwier]

Click on the web page.  You will like it.

http://ettus.com

ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"Trample the slow   Hurdle the dead"


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
isaacgerg
Sent: Tuesday, September 09, 2008 3:14 PM
To: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] USRP2 Price


What about the daughter boards? Any rough ideas?
-- 
View this message in context:
http://www.nabble.com/USRP2-Price-tp19399125p19399213.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: gnu radio with a soundcard

[Bob McGwier]

 

Get a softrock 40.  I/Q sampler based on the quadrature sampling detector
(fully balanced. Virtual ground, thus not Tayloe).  High performance, good
sensitivity.  Yields I/Q in stereo audio for baseband processing.  If you
already have a USRP, get the LFRX.

 

http://groups.yahoo.com/group/softrock40/

 

 

http://www.amqrp.org/kits/softrock40/

 

 

Frank Brickle and I wrote the SDR core for the software in the GUI shown in
the second link (PowerSDR).

 

 

Bob McGwier

 

 

 

ARRL SDR Working Group Chair

Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.

"Trample the slow   Hurdle the dead"

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
sriram s
Sent: Tuesday, September 02, 2008 12:33 AM
To: [EMAIL PROTECTED]
Cc: gnu radio
Subject: [Discuss-gnuradio] Re: gnu radio with a soundcard 

 


Hi,
You could try tapping the IF out of an old radio (which uses FETs) . But you
will need  a mixer and band pass filters to bring the signal down to a range
which your soundcard can handle.

Regards,

Ram

On Sat, Aug 30, 2008 at 11:25 PM, Mathew George <[EMAIL PROTECTED]
<http://us.mc592.mail.yahoo.com/mc/[EMAIL PROTECTED]>
>wrote:

>  Hi all,
>
> Can someone explain how we may build a FM/SW receiver using A/D D/A
> converter in a sound card and minimal additional hardware? Somewhere I
have
> read that this is possible, in principle, but could not yet gather info
> suitable for a novice.
>
> Thanks for the help.
>
> Cheers,
> Mathew
>
> --
> Movies, sports & news! Get your daily entertainment fix, only on
<http://live.com> live.com Try
> it now! < <http://www.live.com/?scope=video&form=MICOAL>
http://www.live.com/?scope=video&form=MICOAL>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
<http://us.mc592.mail.yahoo.com/mc/[EMAIL PROTECTED]> 
> 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] NICE, mp schedule and stand alone library

[Bob McGwier]

The new check-ins with the full scheduler support for SMP machines, the
ability to write code that calls libgnuradio.so, and also runs the USRP and
other hardware from C++ is really awesome work.   This is all pretty
breathtaking in its scope and impact.

 

THANKS!!

 

Bob

 

 

 

ARRL SDR Working Group Chair

Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.

"Trample the slow   Hurdle the dead"

 

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

RE: [Discuss-gnuradio] Flipping problem

[Bob McGwier]

I agree with this analysis unless Isaac tells us he has a carrier and baud
synchronizer in his system.  If he is looking at raw output from the USRP,
indeed the two oscillators (as they would in any real system) shift
frequency over time and drift in and out of any phase relationship.

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"Trample the slow   Hurdle the dead"


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Matt Ettus
Sent: Tuesday, July 29, 2008 2:40 AM
To: isaacgerg
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Flipping problem

isaacgerg wrote:
> I am sending a known sequence of samples from one USRP to another using
the
> Basix RX/TX d'boards setting the frequency to 24e6.
>
> When I rx the sequence, the correlation of it keeps flipping, but not in a
> way that suggests residual carrier.  It seems as if I am experiencing an
> instantaneous flip.
>
> My gain on both the RX and TX is set to 500. The signal amplitude I rx is
> ~1200. When I run the GRC model, the Rx says I have no residual carrier,
> invert is set to false, the dxc frequency is set to -24e6 and the baseband
> to zero.  On the TX side, I have these same values with the exception of
the
> dxc freq, it is not set to 24e6. Why the flip??   What do all these things
> mean???
>
> Is 24e6 a bad freq to use with the basic TX/Rx?
>
> Thanks in advance!
>   

I believe what you are seeing here is that the two USRPs are on two 
different frequencies.  This is not a fault of the USRP.  No two 
oscillators will be on exactly the same frequency, and so in any 
practical receiver you must synchronize. 

Matt


___
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] SDR platform other than usrp with gnuradio

[Bob McGwier]

Look at gr-msdd6000 and you will see how an IP based device was interfaced
to gr.  You device will need different controls of course but it should
definitely give you a helping start.  UDP is the chosen transfer mechanism
but TCP is also supported.

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"Trample the slow   Hurdle the dead"

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Anand Prabhu Subramanian
Sent: Friday, July 18, 2008 4:52 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] SDR platform other than usrp with gnuradio

Hello,

I am currently working on a custom made SDR platform and trying to use gnu
radio to program it. I understand that I need to write seperate source and
sink blocks to receive and send I/Q samples from and to the device. I was
wondering if anybody in the list could help me in understanding how to
write these block. I suspect I would need to write something similar to
the usrp code. Can you please let me know a starting point on how to write
these blocks? The device I am currently using interfaces with the host
using ethernet and sends/receives base band I/Q samples.

Are there documentations on interfacing gnuradio to SDR platforms other
than usrp. It would be very helpful if you could give some pointers.

-Anand


Anand Prabhu Subramanian
Wireless Networking and Simulation Lab (WINGS)
State University of New York, Stony Brook
http://www.wings.cs.sunysb.edu/~anandps


___
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] Decimation scheme

[Bob McGwier]

Sebastian:

http://users.snip.net/~donadio/cic.pdf

contains more than you ever wanted to know about CIC filters in great detail
including how to calculate the transfer function.

Bob


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"Trample the slow   Hurdle the dead"


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Brian Padalino
Sent: Wednesday, July 16, 2008 3:12 PM
To: Sebastiaan Heunis
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Decimation scheme

On Wed, Jul 16, 2008 at 2:46 PM, Sebastiaan Heunis <[EMAIL PROTECTED]>
wrote:
> Hi
>
> Can anyone please help me with some information on the CIC filters in
> the USRP?  I need to know how many CIC stages there are, what the
> cutoff frequency and out of band rejection is and how the decimation
> is performed after filtering.  Which .v files should I have a look at?

The decimating CIC filter implementation can be found here:

 
http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/sdr_lib/cic_decim.
v

It's a 4-stage CIC filter.  Decimation is somewhat inherent within the
process, so I don't understand that question.  Sorry.

Good luck.

Brian


___
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] PMT

[Bob McGwier]

Thanks for your quick assistance.  It is amazing to me how often I take
these complex tools (such as libtool) for granted and assume they will
always work perfectly.  

Bob


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Johnathan Corgan
Sent: Thursday, June 26, 2008 1:33 AM
To: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] PMT

On Wed, Jun 25, 2008 at 10:19 PM, Eric Blossom <[EMAIL PROTECTED]> wrote:

>   Unless I missed something it follows --prefix just like the rest of
>   the known universe.

Just to follow up, if you re-run 'configure' with a different prefix,
you need to do a 'make clean' first before you attempt to re-install.
Libtool will have encoded the prior prefix into its linked object
files, and will complain when it tries to re-link for installation
with the new prefix.

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.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] Cell Chip in a laptop

[Bob McGwier]

They got enough stuff wrong in the article to comment.

Spurs is not a powerpc.  It is a four spe coprocessor sitting in a very
Intel-like system as the Toshiba laptop has a Core 2 Duo in it along with
the spe coprocessor running at 1/2 clock for power reasons.

The Sony PS3 does NOT have 7 spes available.   It has six.  They used up one
of those available aid running the silly hypervisor.

And on and on.

Bob


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Matt Ettus
Sent: Monday, June 23, 2008 8:23 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Cell Chip in a laptop



http://arstechnica.com/news.ars/post/20080623-cell-chip-makes-laptop-debut-i
n-toshiba-qosmio-but-why.html


___
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] PMT

[Bob McGwier]

Forcing PMT to be in /usr/local/lib  is a problem.  Why shouldn't I check in
a "fix"?

 

Bob

 

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

Re: [Discuss-gnuradio] GMSK Viterbi Equalization

[Bob McGwier]

isaacgerg wrote:

Is this scheme as simple as doing an LMS decision-directed equalization
scheme where the Viterbi algorithm used to make the symbol decision?


  
No there is no "equalizer" per se. It is a misnomer, but a popular one. 
What you have is a model of the filter the channel applies to the data 
symbols emitted by the source to produce the signal. You do dynamic 
programming forward in time over the putative symbols and the metric is 
the distance between the observed data and the filter applied to the 
paths in reverse. So the channel filter is applied to the "paths" as you 
try new symbols. Just like viterbi decoding, you have coalescence. When 
all paths backwards terminate in the same node, that is when you emit a 
decision in theory. Practically speaking, this is usually done after a 
fixed interval.


The channel sounding symbols are used to update the "channel filter".

This is much better than trying to "invert the channel" which is what an 
equalizer does. Those places where the channel transfer function has a 
zero in its spectrum (or a deep null) you have significant difficulties 
when inverting. You enhance the noise there because you are "nearly 
dividing by zero".


Bob

--
ARRL SDR Working Group Chair. Member: ARRL, AMSAT, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC.
“Trample the slow   Hurdle the dead"



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

Re: [Discuss-gnuradio] OFDM results.

[Bob McGwier]

Matt Ettus wrote:

Jeff Brower wrote:

Bob-

 

In your sixteen QAM and other figures I see two effects.

Notice just the slightest hint that arcs through the top four
constellation points in the 16 QAM is not straight.  This curvature is
caused by nonlinearity.

Your result almost surely can NOT be clock jitter.  If you had a lot of
clock jitter,  the pictures would look much worse.  Notice the
dispersion gets larger as your proceed away from the origin.  This is
almost surely phase noise in some oscillator.



"Phase noise" of an oscillator to me means jitter.  Can you clarify?  
Do you mean a
sinusoid oscillator that has some issue with shape; i.e. 
non-linearity?  Thanks.
  


I have to disagree with Bob here.  I think that you are seeing some 
form of distortion.


To me there is no doubt about the nonlinear distortion as you can see 
curvature in the edges of the "square".  If you have amplitude 
components modulating the signal coming into the DBS-RX mixer,  it will 
not just spread them in angle.  I do take your point about the 
constellation points being symmetric rather than more elongated it might 
just be compression effects.  Back off will answer the question.
In a QAM pattern, gaussian noise will look like uniformly-sized round 
balls.  Phase noise will look like ovals which are longer in the 
"rotation direction" than they are along the line to the center of the 
constellation, proportionally so for the outer points than the inner 
ones.  ISI, frequency-selective fading and ICI will, over time, tend 
to look round as well.  Distortion like nonlinearities in the 
transmitter will mostly affect the outer constellation points.  This 
is a little more complicated in an OFDM system rather than straight 
single-carrier QAM, but that still looks like what you are seeing.  
Also, 31 subcarriers is a very small number for OFDM, so the affect is 
more like on plain old QAM.


I would suggest backing the transmit power off a bit further.

Matt



___
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] OFDM results.

[Bob McGwier]

Jeff:

Good to hear from you again.  I am distinguishing betwen clock recovery 
operations in the receiver and the oscillator feeding the down 
conversion mixers.  Even though there is some commonality in the sources 
for these two DIFFERENT things on the USRP,  implementation factors of 
the clock recovery,  how well the DBS-RX takes the up conversion of the 
oscillator by MANY factors to make the downconversion mixer sources, 
etc. are almost enough different to be independent noise sources.


I believe the clock recovery is working just fine or these pictures 
would look like crap.   The jitter of the constellation increasing with 
increasing distance from the origin is VERY indicative of angular phase 
noise in the downconversion oscillators in (say) the DBS-RX.


Bob



Jeff Brower wrote:

Bob-

  

In your sixteen QAM and other figures I see two effects.

Notice just the slightest hint that arcs through the top four
constellation points in the 16 QAM is not straight.  This curvature is
caused by nonlinearity.

Your result almost surely can NOT be clock jitter.  If you had a lot of
clock jitter,  the pictures would look much worse.  Notice the
dispersion gets larger as your proceed away from the origin.  This is
almost surely phase noise in some oscillator.



"Phase noise" of an oscillator to me means jitter.  Can you clarify?  Do you 
mean a
sinusoid oscillator that has some issue with shape; i.e. non-linearity?  Thanks.

-Jeff
  




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

Re: [Discuss-gnuradio] OFDM results.

[Bob McGwier]

The USRP is not in the same league with the USRP2.  The on board 
oscillator is much better but external oscillators will make it even 
better.  So the answer is a big yes, the USRP2 will be better.


Bob


Per Zetterberg wrote:
 

  

-Original Message-
From: Bob McGwier [mailto:[EMAIL PROTECTED] 
Sent: den 6 juni 2008 09:23

To: Per Zetterberg
Cc: discuss-gnuradio@gnu.org; 'Per Zetterberg'
Subject: Re: [Discuss-gnuradio] OFDM results.

In your sixteen QAM and other figures I see two effects.

Notice just the slightest hint that arcs through the top four 
constellation points in the 16 QAM is not straight.  This 
curvature is caused by nonlinearity.


Your result almost surely can NOT be clock jitter.  If you 
had a lot of clock jitter,  the pictures would look much 
worse.  Notice the dispersion gets larger as your proceed 
away from the origin.  This is almost surely phase noise in 
some oscillator.


Bob




Thanks!

New question:
Would the phase noise get smaller in USRP2 where we can use an external
reference, given that we use a high precision external reference ?




  




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

Re: [Discuss-gnuradio] Losing data during long collects

[Bob McGwier]

There is insufficient dynamic range in any GPS signal on any ordinary 
mortals GPS antenna to use more than 8 bits.


Bob


Chris Stankevitz wrote:

Dan Halperin wrote:
USRP's cfile utility cannot write my data without overruns, so I use 
my own app which I have attached to this email in case anyone is 
interested.  I will try Juha's recorder to see if it performs better.


FWIW (maybe you've fixed the problem already), I would think that if 
this is the case then you're using the cfile script wrong. Are you 
using the '-s' switch (to halve the required disk bandwidth)?


Hi Dan,

Yes, I record the data as 16 bit shorts vs. 32 bit floats.  At 4Msps 
complex data, this provides 16 megabytes per second which is within 
the capabilities of my 4 disk RAID0 array.  Here are the results of 
the bonnie++ benchmark which reports my drive can write at 58 
megabytes per second:


Version  1.03   --Sequential Output--
-Per Chr- --Block--
MachineSize K/sec %CP K/sec %CP
cstankevitz-lapt 4G 34335  44 58313   5


Chris


___
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] gsm gmsk demodulation

[Bob McGwier]

This is not my professional experience.  The sounding data is used to 
find the channel and then the data symbols are soft detected through a 
"viterbi equalizer" in every implementation I am aware of that is any 
good at all with the exception of one I wrote several years ago which 
estimates the data given the channel and then restimates the channel and 
then the data and then the channel and then the data, etc.  MMSE and not 
MLE is the goal and this was a suboptimal implementation of the EM 
algorithm.  It was suboptimal since it did not estimate the data bauds 
using ALL observations but only those between sounding data.  Further,  
assumptions that the conditional distributions of the data given the 
observations could be described in 1st and 2nd product moments (not 
Gaussian but having similar properties).  This has been published by 
many.  The computational complexity is on a par with the viterbi 
equalizer and it outperforms it.


Most of the cell phones I know use the Viterbi equalizer.

Bob


Steven Clark wrote:

On Thu, Jun 5, 2008 at 7:45 AM, isaacgerg <[EMAIL PROTECTED]> wrote:
  

Hi,
 Concerning GSM GMSK demodulation, due to the ISI, I initially thought many
folks were using the Viterbi algorithm on the waveform to demodulate it
properly.  After doing some lit review, I am finding that this is not the
case and that when most folks talk about Viterbi concerning GSM GMSK
demodulation, they are referring to undoing the convolution encoding and not
referring to demodultion in the face of ISI.  Can anyone please confirm
this?

I see many demodulators simply just ignoring the ISI and just demodulating
as if it wasnt present.  It seems they just rely on the convolutional
encoding for error correction and therefore dont need to worry about the
ISI..Is this true?



What you have said is true in my experience as well. More often than
not, Viterbi decoding is just used as part of the forward error
correction scheme.

Please look for my next email to the mailing list for an alternate
GMSK demodulator that reduces ISI...

-Steven


_




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

Re: [Discuss-gnuradio] OFDM results.

[Bob McGwier]

In your sixteen QAM and other figures I see two effects.

Notice just the slightest hint that arcs through the top four 
constellation points in the 16 QAM is not straight.  This curvature is 
caused by nonlinearity.


Your result almost surely can NOT be clock jitter.  If you had a lot of 
clock jitter,  the pictures would look much worse.  Notice the 
dispersion gets larger as your proceed away from the origin.  This is 
almost surely phase noise in some oscillator.


Bob


Per Zetterberg wrote:

Dear all,

I am experimenting with OFDM between two USRPs. Unfortunately, I am not yet
able to master the gnuradio framework so I have made my own implementation.
The results are given in the link below.

http://www.s3.kth.se/~perz/usrp/OFDM_results.pdf


How does this compare with the gnuradio OFDM implementation ?

What is the cause of the problems. Clock jitter ?, non-linearities ?


BR/
Per Zetterberg





___
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] help with tuning RFX2400 MIMO_b, weird RX results

[Bob McGwier]

George:

The flattened ellipsoid is in the eye of the beholder.  ;-).  It isn't 
really.  It is the aspect ratio of your gnuplot.  You are clipped and it 
appears there is a slight DC bias on the I channel to plus DC (pushed 
slightly to the right).


Bob


George Nychis wrote:

I'm getting a little closer...
http://cyprus.cmcl.cs.cmu.edu/tmp/flex_graphs/closer.jpg

it looks like I'm clipping a little bit, and is that "wide circle" 
effect a result of DC offset?


- George


Long, Jeffrey P. wrote:

Kind of looks like it is clipping to me and possibly some DC offset
problems.
-Jeff
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
George Nychis
Sent: Tuesday, April 29, 2008 10:13 AM
To: Eric Blossom
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] help with tuning RFX2400 MIMO_b,weird
RX results



You're not being shunned :)

Stating the obvious, it would be great to have 1 complete
implementation of the C++ daughterboard code, rather than N partial
implementations.



Hopefully once I get passed my May madness I can work with Michael 
on  this.


Does it look like I am clipping? I am not changing the transmitter  
between the two dumps. I figured the rx gain was too high but it seems


to be being set correctly.

- George


___
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 mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] M&M impl, its parameters, and why does itwork for GMSK?

[Bob McGwier]

Long, Jeffrey P. wrote:

While we are on the topic of clock recovery and someone more
knowledgeable than me is reading :) I would like to pose a question to
Bob. How might one do clock recovery on a M-ary CPM signal? It sounds
like a ML sequence technique might be an option but is there a simpler
ad-hoc technique that works as well? My "superiors" tell me to just do
clock recovery on a 2-ary modulated preamble and then hold it for the
rest of the packet when it switches to your M-ary mode. I suppose this
would work but I think it might be a little too much work in GNU right
now until the meta data extra channel thing is ready, right? For
simplicity I would prefer a technique that could run on streaming data
like the M&M.

thanks
Jeff

  


Also, let me be judgmental for a moment.  I consider it extremely poor 
design practice to assume stationary channels, even for short duration 
signals if you can afford  to do the tracking  algorithms.


Bob

--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." - Brian W. Kernighan 




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

Re: [Discuss-gnuradio] M&M impl, its parameters, and why does itwork for GMSK?

[Bob McGwier]

Long, Jeffrey P. wrote:

While we are on the topic of clock recovery and someone more
knowledgeable than me is reading :) I would like to pose a question to
Bob. How might one do clock recovery on a M-ary CPM signal? It sounds
like a ML sequence technique might be an option but is there a simpler
ad-hoc technique that works as well? My "superiors" tell me to just do
clock recovery on a 2-ary modulated preamble and then hold it for the
rest of the packet when it switches to your M-ary mode. I suppose this
would work but I think it might be a little too much work in GNU right
now until the meta data extra channel thing is ready, right? For
simplicity I would prefer a technique that could run on streaming data
like the M&M.

thanks
Jeff

  

Jeff:

The answer is between the two.

;-)

Use the 2-ary modulated symbols for timing acquisition and also for 
initial carrier recovery.  Then since you will be close switch to a 
tracking mode:  Mengali's joint timing and recovery algorithm for CPM 
signals


Search for "Joint Timing and Phase Recovery for CPM signals" by Umberto 
Mengali, et. al.  The joint estimator helps significantly as you can read.


Bob


--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." - Brian W. Kernighan 




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

Re: [Discuss-gnuradio] M&M impl, its parameters, and why does it work for GMSK?

[Bob McGwier]

George Nychis wrote:

Thanks for the response.

You're correct, it can work with complex or real input.  GMSK and the 
MSK implementation are both using the real input, passed on from 
gr_quadrature_demod_cf.  Here is the MSK impl:
https://moo.cmcl.cs.cmu.edu/trac/cmu_sdrg/browser/phys/802.15.4/trunk/src/python/ieee802_15_4.py#L84 



I'm not sure if I and Q are meant to be de-staggered before hand or not.

- George



George, Jeffrey:

You are discovering by inference in the M&M research work what most 
communications professionals know because someone told them  (usually 
Matlab) ;-).


Staggered QAM and MSK minimize envelope variation and as such, the 
nonlinearity in M&M generates a much weaker clock tone. At the risk of 
bringing up sore topics,  Matlab uses M&M where it is appropriate.  For 
MSK and GMSK, they use a fourth order nonlinearity to generate the clock 
tone.


I use them and their large R&D shop as "proof by intimidation" rather 
than going through all of the arguments why this should be so but they 
start from the small envelope variation I mentioned.


google search Matlab MSK-type signal timing recovery.  They have my 
favorite timing author ever (Umberto Mengali) referenced.


Long before M&M wrote,  Umberto Mengali wrote a paper on the asymptotic 
maximum likelihood clock recovery method.  After you approximate the 
hyperbolic tangent with the simplest first order approximation and use 
two tap differentiator, VOILA,  M&M pops out.


--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." - Brian W. Kernighan 




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

Re: [Discuss-gnuradio] new 802.11b receiver

[Bob McGwier]

Gregory Maxwell wrote:

On Mon, Mar 31, 2008 at 7:17 PM, Mohammad Hamed Firooz
<[EMAIL PROTECTED]> wrote:
  

 Yes, new USRP will support Gigabit Ethernet, but most computers don't
 support that. You have to buy an extra card  or buscard for your
 desktop or laptop.



Just about anything bought in the last few years should have gige. ...
Keep in mind that you're not going to be able to keep up with the
100+MByte/sec USRP2 sample firehose on a computer that is five years
old.

All else fails you can usually buy a cheap gig-e nic for just a few
dollars and a good one for perhaps $20 or so.


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

  


I know my four year old ASUS motherboard does and so does everything 
purchased after including my laptops.


Bob


--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." - Brian W. Kernighan 




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

Re: [Discuss-gnuradio] Re: Re: frequency offset of USRP

[Bob McGwier]

But after you acquire, it is a simple matter to detect lock and then 
gear shift to a narrower tracking loop.


Bob



Sl Peng wrote:

Yes!
This method works  for the acquisition, but does not work for the 
tracking loop.
Because the chip rate is relevant to the Doppler shift frequency. So 
how about your program? Can you suggest me some other ways to deal with 
this issue?



Trond Danielsen wrote:
  

2008/3/30, Sl Peng <[EMAIL PROTECTED]>:


Thanks Trond!
 I think this thread just tell me there should be a frequency offset, but
 I did not find any answer about how do deal with this problem in this
 thread.
  

There are several ways to deal with this issue, but a simple solution
that I have used my self is to just increase the Doppler frequency
search range of your acquisition procedure.

--
Trond Danielsen



  



--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." - Brian W. Kernighan 




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

Re: [Discuss-gnuradio] OFDM Updates

[Bob McGwier]

I wonder if you are told several more times that it is already released 
in an svn branch if you will finally look to see how to get it?


http://gnuradio.org/trac/browser/gnuradio/branches/developers/trondeau/ofdm

That took me less than 2 minutes to find.  It will take you less than 
two minutes to figure out how to do an svn download on that source.


What doesn't work is up to you to fix.  That is the nature of GPL 
projects such as this one. 


Have fun.

Bob



CHIN-YA HUANG wrote:

Hi Tom,

Would you mind release your modified code for me as reference first? Thanks

Chin-Ya
- Original Message -
From: Tom Rondeau <[EMAIL PROTECTED]>
Date: Wednesday, March 26, 2008 9:50 am
Subject: Re: [Discuss-gnuradio] OFDM Updates
To: CHIN-YA HUANG <[EMAIL PROTECTED]>
Cc: discuss-gnuradio@gnu.org

  

CHIN-YA HUANG wrote:


Hello Tom,

Based on your information below I know the problem will be receiver. 
  
However, if I want to solve the receiver's problem. Where is the 
starting point you suggestion? From the gnu-radio core part?


Chin-Ya
  
  
This problem will be fixed once I get time to merge my current branch, 


which will be in a few days, hopefully.

Tom




From:   Tom Rondeau
Subject:[Discuss-gnuradio] OFDM Updates
Date:   Thu, 07 Feb 2008 14:09:58 +
User-agent: Thunderbird 2.0.0.9 (Windows/20071031)
For anyone working with the OFDM code, my latest check-in to the 
  
trunk fixes some of the main issues of transmitting over the air. 
Using benchmark_ofdm_rx and benchmark_ofdm_tx on different machines, I 
am now able to successfully capture most packets with any modulation 
at the appropriate signal level.

I say most packets because there is still an issue involved in the 
  
receiver where the regenerator signal pops up before the peak detector 
signal resets it and causes a problem in the packet sampler. To see 
what I mean, run


"benchmark_ofdm.py --log"

And look at the output of the regen and peak detector blocks:
gr_plot_char.py ofdm_sync_pn-regen_b.dat ofdm_sync_pn-peaks_b.dat


This will plot a series of 0's with a few 1's, where the peaks 
  
occur. The peak detector sends it out once, and then the regenerator 
takes over. For every packet, there is one output of the peak 
detector. If you look, sometimes the peak detector will hit just after 
a regenerated signal. By this point, it's too late and the 
ofdm_sampler has already triggered off of the regen signal and ignores 
the peak.

It's a bit of a hassle, but I'll look into it soon. Any help is 
  

appreciated, though :)


Tom

  
  



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

  



--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." - Brian W. Kernighan 




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

Re: [Discuss-gnuradio] new 802.11b receiver

[Bob McGwier]

Mohammad:

Do you know Fehrouz Farhang-B?  I am sure you must.  He is an 
acquaintance of mine.  Are you in the Wireless Communications Lab or the 
DSP Lab (Signal Processing Group)?


I have before, and I wish to recommend again, Fehrouz book on SDR 
techniques to people here.


http://www2.elen.utah.edu/~farhang/

Who is directing your thesis work?  I want to remind you and everyone 
else listening, that we will soon have the USRP2.  It will definitely 
support the 802.11b and g.  It would be good to have the code early so 
we can make a plan on moving it to the USRP2 to support the full bandwidth.


I am looking forward to visit your department at some time in the next 
few months.  I hope to be able to meet you.


Thank your for doing this work!
Bob McGwier



Mohammad Hamed Firooz wrote:

Quoting George Nychis <[EMAIL PROTECTED]>:




Brian Padalino wrote:

On Mon, Mar 24, 2008 at 1:02 AM, Mohammad Hamed Firooz
<[EMAIL PROTECTED]> wrote:

  Hi,
 As you may know, BBN guys have developed a receiver for 802.11b. But
 due to the USB limitation, they had to cut the spectrum which 
leads to

 low SNR. We have developed a new receiver by doing some operation
 (especially de-spreading) inside the FPGA (before sending data to 
USB).

 Therefore, our receiver use the whole spectrum to abstract the data.
 you can find more information and the codes in our website:
 http://span.ece.utah.edu/pmwiki/pmwiki.php?n=Main.80211bReceiver


So, where's the Verilog for the changed FPGA build?



Considering the amount of research in 802.11 networks, I'm sure it 
will be extremely helpful for someone in the future who might want to 
modify your implementation for you to host the Verilog code... just 
as Matt was nice enough to provide you his FPGA code for the USRP ;)


Maybe make it a separate archive that you are hosting.

Nonetheless, cool and thanks for sharing!  I'm sure someone will poke 
around with this.


- George



Sure, I will probably post the Verilog codes by tomorrow. Right now, I 
am trying to make it more readable and neat. Sorry for the delay.





--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." - Brian W. Kernighan 




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

[Discuss-gnuradio] Re: [hpsdr] AB2KT and the opera

[Bob McGwier]

Frank Brickle wrote:
On Mon, Mar 10, 2008 at 11:47 AM, Bob McGwier <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:
 


Well I apologize for sending that note out inviting everyone to
come to
a sold out performance.   I hope no one was inconvenienced...


For the record, it should be noted that the N4HY crowd in the audience 
led the cheering, so the level of enthusiasm should be viewed with 
some skepticism.


Okay, so I brought half of New Jersey with me.  Bill Andersen (master of 
ceremonies) said WOW, did you bring half of New Jersey with you?  ;-).  
He then introduced me to the conductor for the guitar ensemble and I 
could not figure out why until the conductor (prodded by Bill) 
introduced himself as an ex-Marine who left an intelligence division in 
Iraq on medical disability and then out.  He then introduced me to his 
sister,  who was STILL such a non-com and was headed back.  They showed 
me a picture the OTHER sister who was still there!   

Let me assure you,  NEVER EVER judge a book by its cover.  You would not 
have picked this long haired, VERY stereotypical musical scene type nor 
his GORGEOUS sisters out as Marines.


When Bill and I compared notes,  we found that Frank has almost managed 
to keep his musical and "polymath" worlds completely separated.  We have 
each known Frank as long as the other and I never heard Frank mention 
Bill until the (now infamous) George Antheil Music Festival (coinventor 
of Spread Spectrum with Hedy Lamarr and major composer).


The presenters may actually have made some money on this show. That is 
the part nobody could have predicted.
With packed house,  and people TURNED AWAY at the box office (I heard 
them doing it as Meghan arrived late),  I believe all parties made 
money.  Congratulations indeed.


After many decades of being a composer, it's my belief that writing 
music is a lot like architecture: the fundamental task is to make sure 
nobody gets killed or injured by your work. By that standard, the 
evening was a raging success.


And here I thought that the process was simply living long enough 
without getting killed or killing yourself so that your contemporaries 
were too senile or tired to know better.  ;-).


My greatest thanks to everyone.

Frank


Our thanks to you for allowing us to have so much fun by having you as a 
peer. The evening was fun beyond belief until I picked up the bill for 
four people at Trattoria del Arte. 


Now! Can we do some ham radio?

;-)

Bob


--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." - Brian W. Kernighan 




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