[hpsdr] IP3 >+50 dBm ?
Ron Skelton
ron-skelton at charter.net
Sun Aug 26 14:47:59 PDT 2007
I don't comprehend the argument that such a high dynamic range is not
meaningful in view of the phase noise of oscillators and would
appreciate someone lightening my darkness.
My understanding is that dynamic range is defined and bounded by
noise entering or created at the front end and the signal level where
any portion of the chain becomes saturated (for want of a better
term). This being so we can increase dynamic range by lowering the
noise floor or by increasing the point of saturation or both. The
achievable noise floor at HF and below is determined by incoming not
internal noise. In any event it seems to me the highest possible
point of saturation is required assuming the usual case of exposure
to high levels of unwanted signals.
At 01:42 PM 8/25/2007, you wrote:
>Send Hpsdr mailing list submissions to
> hpsdr at lists.hpsdr.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.hpsdr.org/listinfo.cgi/hpsdr-hpsdr.org
>or, via email, send a message with subject or body 'help' to
> hpsdr-request at lists.hpsdr.org
>
>You can reach the person managing the list at
> hpsdr-owner at lists.hpsdr.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Hpsdr digest..."
>
>
>PLEASE change your subject line in any replies to this digest to
>reflect the actual subject!!! We all thank you for this thoughtfullness.
>
>Today's Topics:
>
> 1. Use a Softrock IF and SDR Shell with Your Old Rig to Make it
> New (Rob Frohne)
> 2. Re: Blackfin 32*32 bits multiply (Darrell Harmon)
> 3. Re: Blackfin 32*32 bits multiply (Robert McGwier)
> 4. Re: Blackfin 32*32 bits multiply (Lyle Johnson)
> 5. 2007/Aug/25 FRF TeamSpeak audio (Mike Naruta)
> 6. Re: Not Hpsdr - A Front-End with an IIP3 > +50dBm ?
> (Giancarlo Moda)
> 7. Re: Janus/Ozy with Linux? (Ramakrishnan Muthukrishnan)
> 8. Somethings on noise (KA2WEU at aol.com)
> 9. Re: Ulrich Rohde article on VCXO noise (Ken N9VV)
> 10. Re: Janus/Ozy with Linux? (Frank Brickle)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 24 Aug 2007 16:19:31 -0700
>From: Rob Frohne <frohro at wallawalla.edu>
>Subject: [hpsdr] Use a Softrock IF and SDR Shell with Your Old Rig to
> Make it New
>To: softrock40 at yahoogroups.com, dttsp-linux
> <dttsp-linux at yahoogroups.com>, HPSDR Reflector <hpsdr at hpsdr.org>
>Message-ID: <1187997571.8171.52.camel at frohro-d600>
>Content-Type: text/plain
>
>Hi Everyone,
>
>I have been having a lot of fun lately playing with a $12 Softrock and
>my TS-850SAT. I made a quick web page describing the project and making
>the software source available. Have a look at:
>
>http://www.wallawalla.edu/frohro/SDR/SDR-Shell/
>
>Thanks to Bob, N4HY, Frank, AB2KT, Tony, KB9YIG, and Edson, JF1AFN for
>all the open source software that helped me make this a quick project.
>Most of my time was spent modifying Edson's SDR-Shell to include Hamlib
>control of the RIG, and the computer display. It may work with other
>rigs too, especially with Kenwood rigs.
>
>73,
>
>Rob, KL7NA
>
>
>
>
>------------------------------
>
>Message: 2
>Date: Fri, 24 Aug 2007 20:11:35 -0500
>From: Darrell Harmon <dlharmon at dlharmon.com>
>Subject: Re: [hpsdr] Blackfin 32*32 bits multiply
>To: hpsdr list <hpsdr at hpsdr.org>
>Message-ID: <46CF81C7.7000105 at dlharmon.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Philip Covington wrote:
> > ***** High Performance Software Defined Radio Discussion List *****
> >
> > On 8/21/07, Greg Overkamp <overkamp at yahoo.com> wrote:
> >
> >> ***** High Performance Software Defined Radio Discussion List *****
> >>
> >> A 32x32 bit multiply produces a 64-bit result. In the
> >>
> >> case of the Blackfin 32x32 bit multiply (I am
> >> referring to the built-in 32x32 bit multiply, not one
> >> that you would write yourself as a macro) the result
> >> can only be saved to a 32-bit register. This means
> >> that you would need to scale down either the
> >> coefficients or the data in order to prevent overflow
> >> on storing the multiplier result, which really defeats
> >> the purpose of having a 32x32 bit multiply.
> >>
> >> Most integer DSPs have accumulators that are even
> >> larger than the multiply result, which allows the
> >> intermediate sum-of-products in an FIR filter, for
> >> example, to grow larger than the size of the multiply
> >> result (64-bits in the case of a 32x32 bit multiply).
> >> The final FIR result may be within range of the size
> >> of the multiplier output width, while the intermediate
> >> sum could have grown larger than this width. The extra
> >> accumulator width prevents saturation from occurring
> >> during the sum-of-products. The Blackfin does indeed
> >> do this for its 16x16 bit multiply by providing a
> >> 40-bit accumulator rather than a 32-bit accumulator
> >> (recall the Motorola DSP56000 with its 24x24
> >> multiplier and 56-bit accumulator).
> >>
> >> A 32x32 bit multiply with a 32-bit result is only
> >> useful if you know ahead of time that either your data
> >> or your coefficients will not be 32 bits. When using
> >> 24-bit data converters, you would have to use 8-bit
> >> FIR coefficients in order to guarantee no overflow of
> >> the multiplier! I really think that application note
> >> EE-186 is wishful thinking on ADI's part in order to
> >> try to sell its Blackfin processor to audio folks.
> >>
> >> The Blackfin looks like a great 16-bit DSP, but for
> >> high resolution audio work (or baseband SDR using
> >> 24-bit converters) I think a better choice would be a
> >> DSP that has native 32-bit arithmetic.
> >>
> >> Greg
> >> WD9DEX
> >>
> >
> > Thanks Greg! FINALLY someone talking some sense about the Blackfin (as
> > opposed to the armchair DSP engineers)!
> >
> > 73 Phil N8VB
> > _______________________________________________
> > HPSDR Discussion List
> > To post msg: hpsdr at hpsdr.org
> > Subscription help: http://lists.hpsdr.org/listinfo.cgi/hpsdr-hpsdr.org
> > HPSDR web page: http://hpsdr.org
> > Archives: http://lists.hpsdr.org/pipermail/hpsdr-hpsdr.org/
> >
> >
>
>The result of the EE-186 style multiplication is actually the upper 32
>bits of the 64 bit result. If the coefficients are scaled by 2^31, it
>works nicely with 31 bit precision in the calculations. However, it is
>just a workaround and is slow. I mainly use the Blackfin for moving data
>between USB and an FPGA and controlling hardware. It is essentially just
>being used as an extremely fast microcontroller. Athlon64 and Core2 (and
>FPGAs of course) are what I prefer for DSP these days.
>
>I would like to see some discussion of other DSPs with either 32 bit
>MACs with 80 bit accumulators or floating point that are hobbyist
>friendly. The main reason I have not used a floating point DSP is the
>expensive closed tools. GCC is what drew me to use the Blackfin.
>
>Darrell Harmon
>
>
>
>------------------------------
>
>Message: 3
>Date: Fri, 24 Aug 2007 21:42:29 -0400
>From: Robert McGwier <rwmcgwier at gmail.com>
>Subject: Re: [hpsdr] Blackfin 32*32 bits multiply
>To: High Performance Software Defined Radio Discussion List
> <hpsdr at hpsdr.org>
>Message-ID: <46CF8905.4070102 at gmail.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>But an even more important feature of the 32x32 bit multipliers and
>larger accumulators (and this was true of the DSP56000, 24 bit
>architectre and others) is that the actual instruction used for doing
>FIR filters is much more than just a multiply. It does multiply, add
>the result to the larger accumulator, reads in the next coefficient and
>the next piece of data from the buffers, etc., does modulo arithmetic on
>these buffer pointers and accomplishes ALL of this in ONE instruction.
>
>Now add to this the complication in the current TI family of very long
>instruction words and the need to optimize the order of instructions and
>it becomes apparent why the expensive development tools are required. It
>is nearly impossible to optimize this by hand, even if you are writing
>directly for the assembler.
>
>Bob
>
> > Philip Covington wrote:
> >> ***** High Performance Software Defined Radio Discussion List *****
> >>
> >> On 8/21/07, Greg Overkamp <overkamp at yahoo.com> wrote:
> >>
> >>> ***** High Performance Software Defined Radio Discussion List *****
> >>>
> >>> A 32x32 bit multiply produces a 64-bit result. In the
> >>>
> >>> case of the Blackfin 32x32 bit multiply (I am
> >>> referring to the built-in 32x32 bit multiply, not one
> >>> that you would write yourself as a macro) the result
> >>> can only be saved to a 32-bit register. This means
> >>> that you would need to scale down either the
> >>> coefficients or the data in order to prevent overflow
> >>> on storing the multiplier result, which really defeats
> >>> the purpose of having a 32x32 bit multiply.
> >>>
> >>> Most integer DSPs have accumulators that are even
> >>> larger than the multiply result, which allows the
> >>> intermediate sum-of-products in an FIR filter, for
> >>> example, to grow larger than the size of the multiply
> >>> result (64-bits in the case of a 32x32 bit multiply).
> >>> The final FIR result may be within range of the size
> >>> of the multiplier output width, while the intermediate
> >>> sum could have grown larger than this width. The extra
> >>> accumulator width prevents saturation from occurring
> >>> during the sum-of-products. The Blackfin does indeed
> >>> do this for its 16x16 bit multiply by providing a
> >>> 40-bit accumulator rather than a 32-bit accumulator
> >>> (recall the Motorola DSP56000 with its 24x24
> >>> multiplier and 56-bit accumulator).
> >>>
> >>> A 32x32 bit multiply with a 32-bit result is only
> >>> useful if you know ahead of time that either your data
> >>> or your coefficients will not be 32 bits. When using
> >>> 24-bit data converters, you would have to use 8-bit
> >>> FIR coefficients in order to guarantee no overflow of
> >>> the multiplier! I really think that application note
> >>> EE-186 is wishful thinking on ADI's part in order to
> >>> try to sell its Blackfin processor to audio folks.
> >>>
> >>> The Blackfin looks like a great 16-bit DSP, but for
> >>> high resolution audio work (or baseband SDR using
> >>> 24-bit converters) I think a better choice would be a
> >>> DSP that has native 32-bit arithmetic.
> >>>
> >>> Greg
> >>> WD9DEX
> >>>
> >> Thanks Greg! FINALLY someone talking some sense about the Blackfin (as
> >> opposed to the armchair DSP engineers)!
> >>
> >> 73 Phil N8VB
> >> _______________________________________________
>
>
>--
>AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
>TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
>"If you're going to be crazy, you have to get paid for it or
>else you're going to be locked up." Hunter S. Thompson
>
>
>------------------------------
>
>Message: 4
>Date: Fri, 24 Aug 2007 20:51:07 -0700
>From: Lyle Johnson <kk7p at wavecable.com>
>Subject: Re: [hpsdr] Blackfin 32*32 bits multiply
>To: hpsdr list <hpsdr at hpsdr.org>
>Message-ID: <46CFA72B.2010608 at wavecable.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> > I would like to see some discussion of other DSPs with either 32 bit
> > MACs with 80 bit accumulators or floating point that are hobbyist
> > friendly. The main reason I have not used a floating point DSP is the
> > expensive closed tools. GCC is what drew me to use the Blackfin.
>
>TMS320VC33 32-bit floating point DSP has free tools from the TI website
>(download the code for the "University SDK") as well as gnu (from the
>University of Canterbury, New Zealand).
>
>73,
>
>Lyle KK7P
>
>
>
>------------------------------
>
>Message: 5
>Date: Sat, 25 Aug 2007 10:41:12 -0400
>From: Mike Naruta <mnaruta at comcast.net>
>Subject: [hpsdr] 2007/Aug/25 FRF TeamSpeak audio
>To: FlexRadio <FlexRadio at flex-radio.biz>, HPSDR Reflector
> <hpsdr at hpsdr.org>
>Message-ID: <46D03F88.20503 at comcast.net>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>The 25/Aug Flex Radio Friends TeamSpeak
>zipped mp3 (35 minutes) plus text file
>of comments is available at:
>
>
>< http://www.hamsdr.com/dnld.aspx?id=646 >
>
>or
>
>< http://www.hamsdr.com/dnld.aspx >
>
>
>
>Also available is the same recording,
>but with a 50% tempo increase ( 23 minutes)
>plus text file of comments.
>
>< http://www.hamsdr.com/dnld.aspx?id=647 >
>
>
>
>Mike - AA8K
>
>
>
>
>------------------------------
>
>Message: 6
>Date: Sat, 25 Aug 2007 08:55:39 -0700 (PDT)
>From: Giancarlo Moda <i7swx at yahoo.com>
>Subject: Re: [hpsdr] Not Hpsdr - A Front-End with an IIP3 > +50dBm ?
>To: Bob McGwier <n4hy at idaccr.org>, KA2WEU at aol.com
>Cc: i7swx at yahoo.com, hpsdr at hpsdr.org
>Message-ID: <810192.80612.qm at web32510.mail.mud.yahoo.com>
>Content-Type: text/plain; charset=iso-8859-1
>
>Hi Ulrich and Bob (and All),
>
>Thank you very much for your comments following my
>report as on Subj following the work of Martein,
>PA3AKE.
>
>I believe that sharing information and experiences,
>plus comments from people that have experiences like
>not too many of us, is a way to help the progress of
>and also a way of learning for all radio amateurs,
>including the so called "button pushers".
>
>With a technology bringing new components and moving
>the amateur radio hobby into the future towards the
>complete Digital transceiver, it may sound or look
>"strange" if people are still fiddling the the analog
>critical stages of our equipments and to improve them.
>As hams we are not doing business, except some with
>good ideas, we are doing something to better our
>knowledge and when possible to share it with otthers,
>but first we work and swet for our own pleasure ...
>
>After the H-Mode Mixer (G3SBI) removed the mixer from
>the list of critical stages in a receiver (also OK in
>TX) we "discovered" our equipments IMD problems were
>now produced by the passive components, like coils and
>transformers, and, a very important one... we really
>understood the "heard" problem due to the phase noise
>of oscillators.
>
>I do remember the articles in HamRadio, QST and QEX
>were our friend Ulrich, at that time DL2LR, was
>spending a lot of words to show us the critical points
>of each rx stage, including the oscillators and all
>his suggestions.
>
>I believe a lot of water is gone under the bridges and
>phase noise is getting lower with the improvements of
>DDS, see the changes from the AD9851 to the AD9951 and
>now the AD9910 and AD9912 (yes we have a new problem
>... the spurs !).
>
>Till the ADC will really perform as we hope, I do not
>see why not to invest to improve today or yesterday
>circuits.... maybe in a few years time we will have
>oscillators, DDS and the like with so low phase noise
>that we will have to spend our time to invent
>problems.... So, why not to search for the best
>improvement as possible in the front end and "live
>temporary" with "phase noise" problems ?
>
>This point just remind me of what happen when Enzo
>Ferrari, the founder of the well known racing car
>company, decided to stop to be a racing driver and
>wanted to build his "dream racing car", after the
>second world war. It seems one of the people with
>which he discussed his project told him ..."why do you
>want to design a car with a so advanced engine and
>body when our fuel is so poor in octanes (it was
>necessary to add castroil to the fuel at that time)
>and the roads are not and will never be good for high
>speed?" ... Well, if he had listen to this person we
>would not had the fastest cars in Italy and no Ferrari
>or Lamborhini... etc. Today we have super octanes
>fuels and motorways where one can drive up to 300kmh
>(nearly 200 miles/h) ..not possible due to law speed
>limits 130kmh)...(our road phase noise)... hi
>
>I believe many of us know how difficult it is to
>perform measurement and particularly when equipment
>stages have high performances.
>
>Bob mentioned the ARRL tests on equipment and then go
>and check the ones done by Sherwood (different). I am
>a little puzzled with this. In Europe we are most used
>to the measurements reported by Peter Hart, G3SJX, in
>the RSGB RadCom magazine. His review reports figures
>are often different from the ones published by ARRL
>for the same equipment and he is and has always
>reported the note "limited by oscillator phase noise"
>and other interesting IMD, DR and IP3.
>
>Regarding the subject, I have contacted Martein,
>PA3AKE, and he kindly sent me a few notes I am sure
>readers will find interesting. Please see below.
>
>73
>
>Gian
>I7SWX
>
> >From Martein, PA3AKE
>
>"Phase noise of the local oscillator is indeed very
>important at these
>intercept point levels. This is the phase noise I
>measured with the recently already out-dated AD9951
>DDS clocked at 500MHz with a $6 digikey ECS 100MHz
>quartz oscillator helically multiplied by 5 ala I0CG:
>
>2KHz -137dBc/Hz
>3KHz -140dBc/Hz
>5KHz -145dBc/Hz
>10KHz -147dBc/Hz
>20KHz -148dBc/Hz
>50KHz -150dBc/Hz
>100KHz -150dBc/Hz
>
>These measurements are done with the DDS at 12.6MHz
>(80M LO) and measuring reciprocal mixing with a 500Hz
>wide quartz filter filterering the pilot signal in the
>80M band. The signal to noise ratio of the pilot
>signal(3dB above MDS) was observed with SpectrumLab PC
>software.
>
>These results are not bad at all! This is partially
>because we are using a DOWN-CONVERSION frontend
>resulting in a relatively low LO frequency and hence
>better phase noise from todays DDS chips. This is why
>I choose for a down conversion HAM band only frontend.
>The LO, the mixer and the roofing filter are much
>easier to build with the quality that is needed. I
>have no ambition nor the means to even consider a DC
>to visible light reciever with a +50dBm intercept
>point.
>
>AD9951 phase noise is excelent when giving it a clean
>clock, but about 2 or 3 months ago the AD9910 DDS is
>released that potentially has much improved phase
>noise performance. If one takes the time to compare
>the residual-phase-noise plots of the AD9951 and the
>AD9910 it is obvious that the AD9910 adds much less
>phase noise then the older AD9951. The AD9910 in
>combination with a good (ultra) low noise clock will
>outperform the AD9951 hands down.
>
>Let us put this in perspective a little bit. The phase
>noise of the LO of the KW7CD Star-10 tranceiver,
>mentioned in this thread is shown in the
>QEX-2001 beyond fractional article part 2. If I read
>the graph correctly I get these figures:
>
>2KHz -110dBc/Hz
>10KHz -120dBc/Hz
>
>Further out the noise and the spurs seems to get worse
>again. This is a PLL based solution, although probably
>state of the art at that time, it cannot
>compete with todays mainstream technology.
>
>The AD9910 and possibly AD9912 (no residual phase
>noise plots are available at this time of the AD9912)
>are the so called SUPER DDS's predicted by KW7CD in
>the QEX series and they are available today and they
>make the PLL based LO a noisy relic of the past.
>AD9910 in combination with a Wenzel or similar quality
>low phase noise VHF OCXO multiplied to 1GHz will give
>the DOWN-CONVERSION front-end the LO that
>complements the frontends +50dBm intercept point
>possible today with off-the shelf affordeable
>components.
>
>Martein
>pa3ake
>
>From: KA2WEU at aol.com View Contact Details Add
>Mobile Alert
>Date: Thu, 23 Aug 2007 11:34:28 EDT
>Subject: Re: [hpsdr] Not Hpsdr - A Front-End with an
>IIP3 > +50dBm ?
>To: i7swx at yahoo.com
>CC: hpsdr at hpsdr.org
> Given the current SSB Phase noise of oscillators,
>this IP3 is useless.
>
>73 de Ulrich
>
> > >
> > >
> >
>--- Bob McGwier <n4hy at idaccr.org> wrote:
>
> > Indeed, especially if you compute IP3 the way the
> > ARRL labs does, by
> > raising the level of the two tones injected into the
> > DUT until they 3rd
> > order product gets to be S5. That would be really
> > really difficult with
> > the test equipment they have and a front end with a
> > "50 dBm IP3" and for
> > most radios to take that much signal, but let's
> > suppose they did it.
> >
> > It appears from this test that the IP3 and the
> > IMD-DR dynamic range are
> > large. However, if dynamic range, which is the
> > more important thing
> > takes into account the rise in the noise floor
> > induced by the two tones
> > or a single tone, the dynamic range is more limited
> > than would be
> > indicated by the ARRL test method.
> >
> > I refer interested readers to the Sherwood test
> > table:
> >
> > http://www.sherweng.com/table.html
> >
> > I then suggest that ARRL members compare the numbers
> > Sherwood has
> > measured to those measured by the ARRL labs for the
> > receivers/transceivers that are compared. You will
> > see that inevitably
> > the dynamic range numbers are lower than those
> > measured in the ARRL labs
> > because Sherwood takes LO phase noise into
> > consideration. You will see
> > MANY entries in his table where they are footnoted
> > with "phase noise and
> > not IMD limited".
> >
> > I think his Ip3 numbers have been computed from the
> > DR measurement when
> > the more accurate way to compute IP3 is the S5 test
> > but I would rather
> > he compute USABLE IP3 and the imputed dynamic range
> > by taking LO phase
> > noise into account than the other way around.
> >
> > As usual, Ulrich is right on the money here.
> >
> > For the superior transceiver being built by Cornell
> > Dentra and being
> > written up in QEX (and which many know about from
> > his writing and web
> > page), he does get there with oscillators that have
> > sufficiently low
> > phase noise to use it. You cannot even begin to
> > figure out how much it
> > would cost to build such a thing. He uses parts
> > that were used in
> > serious projects and then surplussed and for which
> > the government or
> > commercial entity paid a boat load of bucks. You
> > might be able to
> > duplicate his work if you had the resources of Bill
> > Gates or Warren
> > Buffet to throw around. It is not reproducible
> > (though it is brilliant).
> >
> > Bob
> > N4HY
> >
> >
> > > _______________________________________________
> > > HPSDR Discussion List
> > > To post msg: hpsdr at hpsdr.org
> > > Subscription help:
> > http://lists.hpsdr.org/listinfo.cgi/hpsdr-hpsdr.org
> > > HPSDR web page: http://hpsdr.org
> > > Archives:
> > http://lists.hpsdr.org/pipermail/hpsdr-hpsdr.org/
> >
> >
> > --
> > Robert W. McGwier, Ph.D.
> > Center for Communications Research
> > 805 Bunn Drive
> > Princeton, NJ 08540
> > (609)-924-XXX-4600
> > (sig required by employer, remove X's for phone #)
> >
> >
>
>
>
>
>
>
>____________________________________________________________________________________
>Building a website is a piece of cake. Yahoo! Small Business gives
>you all the tools to get online.
>http://smallbusiness.yahoo.com/webhosting
>
>
>------------------------------
>
>Message: 7
>Date: Sat, 25 Aug 2007 21:26:02 +0530
>From: "Ramakrishnan Muthukrishnan" <vu3rdd at gmail.com>
>Subject: Re: [hpsdr] Janus/Ozy with Linux?
>To: frohro at wallawalla.edu
>Cc: HPSDR Reflector <hpsdr at hpsdr.org>
>Message-ID:
> <23fcff0f0708250856j33fe55dbld9fecd44103261bd at mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>On 8/24/07, Rob Frohne <frohro at wallawalla.edu> wrote:
> > Hi Ramakrishnan,
> >
> > The GUI is really not hard to do; it just takes some time. I've done a
> > lot of work on Edson's QT SDR-Shell in the last couple of weeks, and now
>
>I just checked out sdr-shell. It is really great! I had only seen its
>predecessor dttsp-shell. Thanks Edson.
>
> > How hard would it be to integrate Janus/Ozy/Atlas into ALSA? I note you
> > didn't mention that option. I suspect that is the hardest way, but also
> > perhaps has some benefits for the labor.
>
>I think there were afew suggestions on that on this list before. If I
>remember, we have an ALSA developer on the list. Perhaps it is quite
>possible.
>
>It will be much simpler to write a I/O plugin (like gr-alsa or gr-jack
>in gnuradio) than hack ALSA itself to do the job. But I may be wrong.
>
> > It seems to me that the GUI and interfacing Janus/Ozy/Atlas to Linux are
> > kind of two separate issues. Am I missing something?
>
>Yes, Perhaps I mixed them because I was thinking for the past couple
>of days about GUIs and tried to write a bit of code and found it a bit
>too hard to do GUI programming. :-) May be because I have never done
>it so far in my programming life.
>
>I just completed my softrock v6.2. It recieves just fine on my
>soundcard. Now I have to hook it up with A/J/O.
>
>73
>Ramakrishnan, VU3RDD
>
>
>------------------------------
>
>Message: 8
>Date: Sat, 25 Aug 2007 12:07:48 EDT
>From: KA2WEU at aol.com
>Subject: [hpsdr] Somethings on noise
>To: hpsdr at hpsdr.org
>Message-ID: <c3b.1a7286f0.3401add4 at aol.com>
>Content-Type: text/plain; charset="utf-8"
>
>
>_[Components]_ (http://www.mwrf.com/Topics/TopicID/717/717.html)
>Technique Trims VCXO Phase Noise
>This patented circuit approach can improve the phase-noise performance and
>frequency stability of even low-cost voltage-controlled crystal oscillators.
>
>_Ulrich L. Rohde,_ (http://www.mwrf.com/Authors/AuthorID/1399/1399.html)
>_Ajay Kumar Poddar_ (http://www.mwrf.com/Authors/AuthorID/1659/1659.html)
>| ED Online ID #16332 | _August 2007_
>(http://www.mwrf.com/Issues/IssueID/602/602.html)
>
>
>Frequency reference standards are essential to achieving frequency accuracy
>and phase stability in electronic systems. Such sources require the chief
>characteristics of low phase noise and good frequency stability.1-13 The best
>oscillator performance can be expensive, however. Fortunately, a patented
>approach has been developed to design and optimize the performance of
>voltage-controlled crystal oscillators (VCXOs), even those with relative low
>quality-factor (Q) resonators, to achieve excellent phase noise and
>frequency stability.
>A typical oscillator consists of a tuned circuit and an active device such as
> a transistor. Ideally, the tuned circuit provides a high loaded Q,
> generally
> from less than 100 for simple circuits to more than 1 million for
>crystal-resonator-based circuits. Noise arises from the active
>device as well as from
>resonator losses. Noise from a bipolar transistor, for example, stems from
>base and collector contributions and from device parasitic elements,
>such as the
> base-spreading resistor. The filtering effect of the resonator tends to
>remove the device noise, with higher Qs delivering greater
>filtering effects. The
> Leeson equation relates these noise effects.1 The formula was modified by
>Rohde for use with VCOs.2
>The equation is linear, with many unknowns. Among the more difficult
>oscillator performance parameters to predict are output power, noise figure,
>operating Q, and flicker corner frequency. The parameters can not be
>derived for
>linear conditions but require large-signal (nonlinear) analysis.3 But by
>combining Leeson's formula with the contributions of the tuning diode,2 Eq. 3
>results, making it possible to calculate oscillator noise based on a linear
>approach:
>
>where:
>??(fm) = the ratio of sideband power in a 1-Hz bandwidth to the total power
>(in dB) at the frequency offset (fm);
>f0 = the center frequency;
>fc = the flicker frequency;
>QL = the loaded quality factor (Q) of the tuned circuit;
>F = the noise factor;
>kT = 4.1 10?21 at 300?K (room temperature);
>Psav = average power at oscillator output;
>R = the equivalent noise resistance of tuning diode (typically 50 ? to 10 k?
>); and
>Ko = the oscillator voltage gain.
>Equation 1 is limited by the fact that loaded Q typically must be estimated;
>the same applies to the noise factor. The following equations, based on this
>equivalent circuit, are the exact values for Psav, QL, and F, which are
>required for the Leeson equation. _Figure 1_
>(http://www.mwrf.com/Files/30/16332/Figure_01.gif) shows the
>typical simplified Colpitts oscillator giving some
>insights into the novel noise calculation approach.4
> >From ref. 3, the noise factor can be calculated by:
>
>After some small approximation,
>
>_Figure 2_ (http://www.mwrf.com/Files/30/16332/Figure_02.gif) (left)
>illustrates the dependency of the noise factor on
>feedback capacitors C1 and C2.
> >From Eq. 1, the phase noise of the oscillator circuit can be enhanced by
>optimizing the noise factor terms as given in Eq. 3 with respect to feedback
>capacitors C1 and C2.
>Equation 4 can be found by substituting 1/re for Y21+ (+ sign denotes the
>large-signal Y-parameter).
>
>When an isolating amplifier is added, the noise of an LC oscillator is
>determined by Eq. 5.
>
>where:
>G = the compressed power gain of the loop amplifier;
>F = the noise factor of the loop amplifier;
>k = Boltzmann's constant;
>T = the temperature (in degrees K);
>P0 = the carrier power level (in W) at the output of the loop amplifier;
>F0 = the carrier frequency (in Hz); fm = carrier offset frequency (in Hz);
>QL = (?F0?g) = the loaded Q of the resonator in the feedback loop; and aR
>and aE = the flicker noise constants for the resonator and loop amplifier,
>respectively.
>
>
><-- prev. page [1] _2_
>(http://www.mwrf.com/Articles/Index.cfm?ArticleID=16332&pg=2) _3_
>(http://www.mwrf.com/Articles/Index.cfm?ArticleID=16332&pg=3) _4_
>(http://www.mwrf.com/Articles/Index.cfm?ArticleID=16332&pg=4)
>_next page -->_
>(http://www.mwrf.com/Articles/Index.cfm?ArticleID=16332&pg=2)
>
>
>
>************************************** Get a sneak peek of the all-new AOL at
>http://discover.aol.com/memed/aolcom30tour
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
>http://lists.hpsdr.org/pipermail/hpsdr-hpsdr.org/attachments/20070825/e78ef136/attachment-0001.html
>
>
>------------------------------
>
>Message: 9
>Date: Sat, 25 Aug 2007 11:15:11 -0500
>From: Ken N9VV <n9vv at wowway.com>
>Subject: Re: [hpsdr] Ulrich Rohde article on VCXO noise
>To: Open High Performance SDR Project <hpsdr at hpsdr.org>
>Message-ID: <46D0558F.60100 at wowway.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Full link to Microwaves & RF article:
>http://www.mwrf.com/Articles/Index.cfm?Ad=1&ArticleID=16332&pg=1
>
>
>KA2WEU at aol.com wrote:
> > [Components] <http://www.mwrf.com/Topics/TopicID/717/717.html>
> > Technique Trims VCXO Phase Noise
> > This patented circuit approach can improve the phase-noise performance
> > and frequency stability of even low-cost voltage-controlled crystal
> > oscillators.
> >
> > Ulrich L. Rohde, <http://www.mwrf.com/Authors/AuthorID/1399/1399.html>
> > Ajay Kumar Poddar <http://www.mwrf.com/Authors/AuthorID/1659/1659.html>
> > | ED Online ID #16332 | August 2007
> > <http://www.mwrf.com/Issues/IssueID/602/602.html>
>
>
>------------------------------
>
>Message: 10
>Date: Sat, 25 Aug 2007 13:17:21 -0700
>From: Frank Brickle <brickle at pobox.com>
>Subject: Re: [hpsdr] Janus/Ozy with Linux?
>To: Ramakrishnan Muthukrishnan <vu3rdd at gmail.com>
>Cc: HPSDR Reflector <hpsdr at hpsdr.org>
>Message-ID: <46D08E51.8090703 at pobox.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Ramakrishnan Muthukrishnan wrote:
>
> >> How hard would it be to integrate Janus/Ozy/Atlas into ALSA? I note you
> >> didn't mention that option. I suspect that is the hardest way, but also
> >> perhaps has some benefits for the labor.
> >
> > I think there were afew suggestions on that on this list before. If I
> > remember, we have an ALSA developer on the list. Perhaps it is quite
> > possible.
>
>There's a fundamental problem. Both audio and control paths lead through
>libusb. That means on Linux they're both in user space, since libusb is
>user-side code.
>
>Unfortunately, ALSA drivers (the sound part of the configuration only)
>need to be loadable in the kernel.
>
>Forget hacking ALSA. It's basically incompatible with this design.
>That's not to say there's no way to integrate OJ under Linux. The
>solution has to be somewhere at the user level, outside the kernel, however.
>
>The immediately obvious strategy is to create a daemon talking to OJ via
>libusb, which splits and merges the control and audio streams and makes
>them available at the application side as file descriptors. That way
>ALSA can think it's MUXing to files for the audio data (using the file
>PCM plugins), and the hardware control functions can simply use ordinary
>IO for the control stream data.
>
>73
>Frank
>AB2KT
>
>
>------------------------------
>
>_______________________________________________
>HPSDR Discussion List
>To post msg: hpsdr at hpsdr.org
>Subscription help: http://lists.hpsdr.org/listinfo.cgi/hpsdr-hpsdr.org
>HPSDR web page: http://hpsdr.org
>Archives: http://lists.hpsdr.org/pipermail/hpsdr-hpsdr.org/
>
>End of Hpsdr Digest, Vol 18, Issue 22
>*************************************
>
>
>--
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.5.484 / Virus Database: 269.12.8/973 - Release Date:
>8/25/2007 5:00 PM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20070826/01ae2cf2/attachment-0003.htm>
More information about the Hpsdr
mailing list