[Ground-station] Baseband => decimation - questions

Mon Jan 28 04:40:28 PST 2019

Thank you Ron for clarifying and also for the nice images :)
I hoped that we could have avoided a second down conversion in the analog
domain but you're right: analog filters .. :(
So using the AD9361 could actually help us a great deal to save time and
headaches and get faster to our goals as it seems.

Ahmet

On Mon, Jan 28, 2019 at 1:06 PM Ron Economos via Ground-Station
<ground-station at lists.openresearch.institute> wrote:

> Yes, direct sampling could be used. But to get good IF image rejection,
> you would probably need two stages of analog down-conversion. One to 700
> MHz or so and then another to the low IF (at least 5 MHz). So that's two
> local oscillators that contribute to phase noise.
>
> High speed ADC's aren't cheap either. The common device used in a lot of
> designs is the LTC2208. 120 Msps is a little overkill, but then you have
> more options for the frequency of the low IF.
>
> I'm also told that volume pricing of the AD9361 is much much less than the
> single quantity price you see on DigiKey. The bladeRF 2.0 uses the AD9361
> and is only $480.
> To get IQ from a single ADC, you use a DDC (digital down converter) in an
> FPGA. In this case, decimation is used to get from 120 Msps to the desired
> sample rate.
>
> [image: ddc]
>
> Ron W6RZ
>
> On 1/28/19 02:16, Ahmet Inan wrote:
>
> Wow that is a nice little expensive chip. It even takes care of the
> problems I mentioned.
> But does it need to be an expensive part?
> Wouldn't a low IF receiver design with only one ADC channel and a bigger
> FFT for the channelizer (or another down conversion in the digital domain)
> make us happier?
> It would even avoid the imbalance problems of the IQ signal.
> Of course then the FPGA gets more expensive .. but I like the digital
> domain more than tinkering with analog components :D
> IMHO, it is more important to have a fixed and low jitter ADC clock for
> the channelization as the fine tuning and equalization for each user needs
> to be done separately after channelization in the digital domain anyway.
> Ahmet
>
> On Sun, Jan 27, 2019 at 11:52 PM Ron Economos via Ground-Station
> <ground-station at lists.openresearch.institute>
> <ground-station at lists.openresearch.institute> wrote:
>
>> Yes, the ADC's are clocked at a variable rate. It's all done inside the
>> AD9361. On the B2x0, you can oversample a little depending on the sample
>> rate. The maximum clock is 61.44 MHz, so sample rates of 30.72 to 61.44
>> Msps are limited to 1X, 15.36 to 30.72 Msps = 2X, 7.68 to 15.6 Msps = 4X
>> and so on.
>>
>> You can have any sample rate you want with the B2x0. For example,
>> DVB-T/T2 is 64,000,000 / 7 = 9.14285714285714...... Msps. There's a minimum
>> step size, so you can't get that exact sample rate, but pretty close.
>>
>> The ADC's inside the AD9361 are sigma-delta 1-bit design, so they're
>> highly oversampled themselves. But that isn't of concern to the user.
>>
>> Ron W6RZ
>> On 1/27/19 11:25, Zach Leffke via Ground-Station wrote:
>>
>> This is cool.  Ron maybe you can school me a bit here.....
>>
>> 1.  Got it with the Quadrature ADC, running at half the required rate,
>> but producing I and Q, so Nyquist is happy.....
>>
>> 2.  So you are saying the ADCs are clocked at variable rates?  Here is my
>> major disconnect......with a B210 and UHD, I can request sample rates
>> (complex) from something like 200 kHz to 20 MHz (but have to make sure the
>> clock rate of the USRP divided by the sample rate requested is an even
>> integer).  I thought the ADC clocks ran at a fixed rate and then decimation
>> was performed in the FPGA, and that the 'even integer' requirement was
>> derived from the DSP going on in the FPGA (and integer math being more
>> computationally efficient).  It sounds like you are saying that there is
>> maybe a bank of acceptable pre-scalers that when I request a particular
>> rate, the appropriate pre-scaler is applied to the master clock, and that
>> is the rate the ADC is clocked at.  Am I getting that right?
>>
>> Seems like there may be pros and cons to either technique.  With a fixed
>> ADC rate that is massively oversampling the input signal, can't we achieve
>> increased dynamic range?  For every factor of 4 oversampling we gain 1 bit
>> in ADC resolution, or 6 dB in dynamic range.  I thought this was how the
>> Ettus products worked and similarly how the Flex Radio systems worked (with
>> the FPGA handling the half-band filtering and decimation to the desired
>> output rate requested by the host computer).  I have no experience with the
>> BladeRF or LimeSDRs.  I know in the UHD source block you can tweak the
>> clock rate of the motherboards, but generally I thought that's how they
>> worked.  I feel like there might be another pro in there in terms of
>> Aliasing and relaxed filtering requirements when oversampling (images are
>> farther apart)?  A con to this technique I would guess is higher power
>> consumption (ADCs running at a higher rate and needing the pre-processing
>> for the decimation).  If the clock rate of the ADC can be controlled on the
>> other hand, you would lose the oversampling capability, but would decrease
>> power consumption.  Seems like the hardware would have to be a little more
>> complicated in order to handle the multiply or divides to achieve the
>> desired clock rate (that I assume is derived from a reference master clock
>> that is higher than the ADC clock rate).  That control capability though is
>> probably not that much more taxing though in terms of power (just picking
>> the right prescaler).
>>
>> Could it be that some SDRs use one technique (like the one I described,
>> massive oversample then decimate, maybe USRPs), and others use a different
>> technique (like the one you described, maybe BladeRF, LimeSDR, etc.)?
>>
>>
>> If I'm roughly accurate in the above description, then isn't the question
>> Michelle is driving towards is what technique would we want to use?
>> Presumably for a ground station implementation, power isn't a concern
>> (compared to the payload) and therefore it would be desirable to oversample
>> and have the added benefits of higher dynamic range.  In other words, maybe
>> the power consumption trade-off is worth it.  Then again, maybe higher
>> dynamic range isn't really necessary (only a single downlink) and its not
>> worth the added DSP complexity.
>>
>> On the payload side, I would guess that having a higher dynamic range on
>> the uplink is actually desirable and worth the tradeoff in power
>> consumption.  I'm basing this on the assumption that if 1000 hams build
>> ground stations, the uplink powers will be wildly different and we may need
>> to handle very strong and very weak uplink signals, and thus a higher
>> dynamic range would be desirable.  On the other hand.....using something
>> like an AD9361 with 12 bits of resolution is 72 dB of dynamic range out of
>> the gate (maybe a little less when determining ENOB).......maybe that's
>> enough and oversampling isn't necessary.........
>>
>>
>> This is good stuff, I like learning new things.  Am I roughly getting
>> this right or am I out in left field some where?
>>
>>
>> -Zach, KJ4QLP
>>
>> Research Associate
>> Aerospace Systems Lab
>> Ted & Karyn Hume Center for National Security & Technology
>> Virginia Polytechnic Institute & State University
>> Work Phone: 540-231-4174
>> Cell Phone: 540-808-6305
>>
>> On 1/27/2019 4:07 AM, Ron Economos via Ground-Station wrote:
>>
>> SDR's like the Ettus B2x0, bladeRF and LimeSDR are direct conversion.
>> Here's a block diagram of the architecture.
>>
>> [image: direct conversion]
>>
>> The PLL is tuned to the frequency of interest. The IF is 0 Hz. Each ADC
>> runs at the desired sample rate and provides 1/2 the sample rate of
>> bandwidth. The analog baseband low-pass filters are set to 1/2 the
>> bandwidth. No decimation required.
>>
>> In fact, the bladeRF has no filtering at all in it's FPGA. If you set the
>> baseband analog filters to wider than the desired bandwidth, you can see
>> the aliasing (the TX is also direct conversion). The sample rate for this
>> OFDM signal was 6.86 MHz.
>> [image: aliasing]
>>
>> Same signal with the baseband filter set properly to 5.5 MHz (each
>> low-pass filter set to 2.75 MHz).
>>
>> [image: no alias]
>>
>> Ron W6RZ
>> On 1/26/19 23:51, Zach Leffke via Ground-Station wrote:
>>
>> I'll attempt to clarify without adding to much noise......I think I'm
>> seeing both sides of this here......Though I'm no DSP expert, so fair
>> warning I might misspeak a bit.
>>
>> A lot of what has been discussed so far is about down conversion, not
>> decimation.........
>>
>> The trick is the 'guts' of the SDR, specifically the RFIC and the ADC
>> used.  Say we have an IF of 700 MHz coming out of an LNB.  The upper edge
>> of our signal would be at 705 MHz.  According to Nyquist, you would have to
>> sample that IF signal at 1410 Megasamples per second (at least).  Any lower
>> than that, and images of the sampled signal will overlap and corrupt the
>> data (Aliasing).  Say your ADC had 14 bits.......that's a lot of data,
>> probably more than most FPGAs can handle.
>>
>> The trick in the SDR (pick your vendor, I'm staying generic here) is that
>> it has a tunable front end that performs another level of down conversion
>> in the analog domain before sampling (for example, the AD9361 in Ettus
>> B210s, E310s, etc).  This takes the 700 MHz signal down to say 20 MHz (made
>> that number up), with an ADC running at a fixed rate..... say 80 MHz (also
>> made that number up).
>>
>> At this point, my DSP-fu is weak, but where I'm going with this is that
>> the 80 MHz sampling is real samples, represents 40 MHz of RF bandwidth
>> (Nyquist).  This can be represented as a stream of complex samples (IQ)
>> running at half the rate, though each sample is twice the size, one for I
>> and one for Q .......(Nyquist isn't violated, because even at half the
>> rate, you have two samples, one In-phase, and one Quadrature)......
>>
>> So now we have a stream at 40 MSPS (complex), spanning from 0 to +40 MHz,
>> with our signal camped out at +20 MHz.  So then we tune digitally to center
>> our signal at 0 MHz...aka complex baseband.  Now we have a stream still at
>> 40 MSPS (complex), but spanning from -20 MHz to +20 MHz.  Negative
>> frequencies are OK in the complex domain.  Our signal of interest is now
>> centered at 0 MHz, but is spanning from -5 MHz to +5 MHz.
>>
>> I think what Michelle is getting at is that we don't want to have an FPGA
>> processing a 40 MHz wide stream of data, when we only need to worry about
>> 10 MHz.  Since our signal is centered at 0 MHz, we can start throwing away
>> samples........Decimation.  We can toss 3 out of every 4 samples out
>> (decimate by 4, and filter), which leaves us with a 10 MSPS stream of
>> complex samples.  This also has some benefit in that we are also rejecting
>> the noise contributions of those unnecessary samples that we tossed out
>> (linked to the B in kTB).
>>
>> Everything that was (horribly) described above is handled 'under the
>> hood' by the UHD drivers in Ettus products for example.  When you tell a
>> UHD source block the sample rate you want (usually the 'samp_rate' variable
>> that shows up in the flowgraph) what you are actually telling it is the
>> 'requested' sample rate on the output of the above process.  The onboard
>> ADC still runs at the fixed higher rate (80 Mhz in my example), but based
>> on your input into the UHD source block, it will automatically select the
>> right parameters to ensure that after sampling, conversion to complex
>> baseband (including tuning your requested center frequency to 0 MHz),
>> decimation and filtering, that the rate you requested is fed out to the
>> host computer.  This is why you have to be careful about selecting sample
>> rates with UHD.........some of you have probably seen the debug output
>> where it warns you that the division of the ADC clock rate by the requested
>> sample rate is not an even integer and to expect 'CIC
>> rolloff'........basically it couldn't cleanly do the decimation you
>> requested (again....something here about the value of half band filters in
>> the FPGA that are part of the conversion to complex baseband and
>> decimation.....sorry for my weak DSP-fu).  You know you got it wrong when
>> you see a 'hump' of spectrum when the spectrum should be 'flat'.
>>
>> Now we can run that 10 MSPS complex stream of samples through the
>> demodulation process and extract the 'frames of interest' for any
>> particular user........that would be demultiplexing (throw out the frames
>> for everyone else, I only want the frames for me).
>>
>> I would offer that on the ground side, there is no channelizer in the
>> mix.....you must receive the entire 10 MHz signal to recover the full
>> downlink data stream, since there is only one time multiplexed, 10 MHz wide
>> signal.
>>
>> On the satellite payload on the other hand....you WILL want a
>> channelizer.  Lets say the uplink is 10 MHz wide, and supports 1000
>> channels, so each 10 kHz wide.  In order to demodulate 1000 channels in
>> parallel, somewhere in there you need to tune 1000 times to center each
>> uplink signal to complex baseband and decimate to 10 ksps (complex).
>> executing 1000 'tunes' in parallel at the full 10 MSPS rate is very very
>> wasteful........Think of the channelizer as a really efficient way of
>> performing the tuning and decimation so that each output channel of the
>> channelizer is only 10 ksps and it is properly 'centered' on the desired
>> uplink channel.  it will require more horsepower than a single tune and
>> single decimate 'string' but is less processing intensive than 1000 of
>> those strings running in parallel.
>>
>>
>> I didn't mention anything about other sampling tricks (Nyquist zones, and
>> potential spectral inversion issues), or the benefits of oversampling
>> (dynamic range), integer vs float representation.........maybe on another
>> thread one day.
>>
>> So if you are going to roll your own hardware..........first a lot of
>> downconversion from 10 GHz (maybe an LNB to get to say L-Band or maybe
>> something to get to a 'ham band IF' at 432 or 144).  Thats not enough.
>> You'll have to then downconvert again to something that can be handled by
>> the selected ADC and whatever clock rate it is running at (Nyquist rules
>> apply here).  Filtering and careful consideration of mixing products will
>> matter!  phase noise of the LOs will matter in all that
>> downconversion.......Also, gain gain gain... will matter to make sure that
>> you are fully exercising the full range of the ADC and not just toggling
>> the the lowest couple of bits  (but not too much gain.....clipping).  Then
>> the complex baseband conversion and decimation and on to demodulation,
>> demultiplexing, etc. etc.......A lot of the above is what is handled 'under
>> the hood' by most of the commercial SDRs out there (i.e. UHD) so that the
>> end user can easily get up and running with the 'more interesting' stuff
>> downstream.........
>>
>> Hopefully this helped clarify the issue.....sorry if it added more noise
>> (my DSP-fu is weak).  Not sure if I actually answered any questions.......
>>
>>
>> -Zach, KJ4QLP
>>
>> Research Associate
>> Aerospace Systems Lab
>> Ted & Karyn Hume Center for National Security & Technology
>> Virginia Polytechnic Institute & State University
>> Work Phone: 540-231-4174
>> Cell Phone: 540-808-6305
>>
>> On 1/25/2019 7:27 PM, Ron Economos via Ground-Station wrote:
>>
>> Okay. De-multiplexing is a much better and less confusing terminology. As
>> you stated, decimation is a DSP thing and channelizing the downlink payload
>> has nothing to do with DSP (all the DSP has already been down in order to
>> deliver payload packets).
>>
>> Ron W6RZ
>> On 1/25/19 16:17, Michelle Thompson wrote:
>>
>> To me, decimation is what we do in order to channelize in the payload.
>>
>> I don't think that's exactly what I'm being asked about in the ground
>> station receiver, though.
>>
>> -Michelle W5NYV
>>
>>
>>
>>
>> On Fri, Jan 25, 2019 at 4:14 PM Ron Economos <w6rz at comcast.net> wrote:
>>
>>> I'm not sure we are talking about the same thing yet. So what exactly do
>>> you expect to decimate and why?
>>>
>>> Ron W6RZ
>>> On 1/25/19 16:07, Michelle Thompson wrote:
>>>
>>> The beginning of wisdom being the definition of terms and all, it would
>>> be good to make sure we're all talking about the same thing.
>>>
>>> So far, I've used LNBs and USRPs for receive, with the LNB doing an IF
>>> at 618MHz (LNB-on-a-Stick) and giving reasonable performance.
>>>
>>> Decimation to me is a DSP thing, or used to reduce power consumption
>>> when you don't need to sample as high as you can.
>>>
>>> -Michelle W5NYV
>>>
>>>
>>>
>>>
>>> On Fri, Jan 25, 2019 at 3:52 PM Ron Economos via Ground-Station
>>> <ground-station at lists.openresearch.institute>
>>> <ground-station at lists.openresearch.institute> wrote:
>>>
>>>> The standard IF for DVB-S2 receivers is 950 to 2150 MHz.
>>>>
>>>> DB6NT was selling a down-converter from 10489-10500 MHz to 1129-1140
>>>> MHz for P4A.
>>>>
>>>>
>>>> https://shop.kuhne-electronic.com/kuhne/en/shop/new/MKU+LNC+10+OSCAR+P4A/?card=1832
>>>>
>>>> I'm not sure what decimation has to do with receiving DVB-S2. The
>>>> entire 10 MHz signal needs to be demodulated. Individual baseband frames
>>>> will be selected for processing, but I call that de-multiplexing.
>>>>
>>>> Ron W6RZ
>>>> On 1/25/19 15:32, David Vieira via Ground-Station wrote:
>>>>
>>>> Michelle - Thanks for posting.  I'll frame some of the questions.
>>>>
>>>> Typical 10 GHz terrestrial contesting rigs are Heterodyne; that is a
>>>> Mixer works with a Local Oscillator (LO) to take the RF down to an IF
>>>> (Intermediate Frequency).
>>>> For an SDR, that IF can be digitized by an Analog-Digital Converter.
>>>>
>>>> The most popular IF for contesting/SSB rigs is 144 MHz.
>>>> For a data BW of 10 MHz that may or may not be a fast enough IF
>>>> carrier.  If we can digitize and recover the data, it would allow a lot of
>>>> re-use of existing equipment.
>>>>
>>>> I've heard suggestions/proposals up to the 1.2 GHz Ham band.
>>>> In some sense, the IF carrier could be 144/220/440/915/1200 MHz, or
>>>> even any Non-Ham frequency in between.
>>>>
>>>> There are a lot of proof of existence designs for a 10 GHz Mixed down
>>>> to an IF; and lots of off the shelf ADC dev-boards.  (catch me off thread
>>>> for details).
>>>>
>>>> Some questions I have are:
>>>> ---from an FPGA side of the SDR, what data rate(s) can the FPGA absorb
>>>> in to a decimator?
>>>>
>>>> Must we decide upfront on a single frequency; or
>>>> preferably allow flexibility in the RF front end design (ie, Mixer, PLL
>>>> and Local Oscl hardware choices) by allowing a wide and programmable
>>>> variety of ADC and decimation rates?
>>>>
>>>> {This is where RF and Digital folks must communicate across walls.}  ;-)
>>>>
>>>> Comments welcome.
>>>>
>>>> regards,
>>>> David
>>>> KI6CLA
>>>>
>>>>
>>>> On Friday, January 25, 2019, 2:41:54 PM PST, Michelle Thompson via
>>>> Ground-Station <ground-station at lists.openresearch.institute>
>>>> <ground-station at lists.openresearch.institute> wrote:
>>>>
>>>>
>>>> While we are striving to enable all sorts of wonderful designs by
>>>> putting prototypes into GNU Radio, a central goal is to design our own
>>>> hardware.
>>>>
>>>> We've had a lot of progress on the protocol and algorithm front (GSE,
>>>> LDPC, some of the polyphase).
>>>>
>>>> Some fundamental decisions about our own hardware need to be made.
>>>>
>>>> When we receive, we expect to have to decimate. This is because we are
>>>> receiving at a relatively high frequency (10GHz).
>>>>
>>>> Our bandwidth is (up to) 10MHz. For DVB-S2/X, we fix our sampling rate,
>>>> depending on what bandwidth we want to support. We have a lot of freedom
>>>> here.
>>>>
>>>> Picking the right frequencies for the receive chain is therefore
>>>> important.
>>>>
>>>> What are our options?
>>>>
>>>> What options make the best sense?
>>>>
>>>> I'd like to build and test as soon as possible, so let's get some
>>>> discussion going.
>>>>
>>>> -Michelle W5NYV
>>>>
>>>>
>>>> _______________________________________________
>>>> Ground-Station mailing list
>>>> Ground-Station at lists.openresearch.institute
>>>> http://lists.openresearch.institute/mailman/listinfo/ground-station
>>>>
>>>> _______________________________________________
>>>> Ground-Station mailing listGround-Station at lists.openresearch.institutehttp://lists.openresearch.institute/mailman/listinfo/ground-station
>>>>
>>>> _______________________________________________
>>>> Ground-Station mailing list
>>>> Ground-Station at lists.openresearch.institute
>>>> http://lists.openresearch.institute/mailman/listinfo/ground-station
>>>>
>>>
>> _______________________________________________
>> Ground-Station mailing listGround-Station at lists.openresearch.institutehttp://lists.openresearch.institute/mailman/listinfo/ground-station
>>
>>
>> _______________________________________________
>> Ground-Station mailing listGround-Station at lists.openresearch.institutehttp://lists.openresearch.institute/mailman/listinfo/ground-station
>>
>>
>> _______________________________________________
>> Ground-Station mailing listGround-Station at lists.openresearch.institutehttp://lists.openresearch.institute/mailman/listinfo/ground-station
>>
>>
>> _______________________________________________
>> Ground-Station mailing listGround-Station at lists.openresearch.institutehttp://lists.openresearch.institute/mailman/listinfo/ground-station
>>
>> _______________________________________________
>> Ground-Station mailing list
>> Ground-Station at lists.openresearch.institute
>> http://lists.openresearch.institute/mailman/listinfo/ground-station
>>
>
>
> --
>
> Ahmet Inan
>
> Co-founder and CEO of aicodix GmbH
> https://www.aicodix.de/
>
> _______________________________________________
> Ground-Station mailing list
> Ground-Station at lists.openresearch.institute
> http://lists.openresearch.institute/mailman/listinfo/ground-station
>

-- 

Ahmet Inan

Co-founder and CEO of aicodix GmbH
https://www.aicodix.de/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20190128/acecb0ee/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ddc.png
Type: image/png
Size: 23299 bytes
Desc: not available
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20190128/acecb0ee/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: directconversion.png
Type: image/png
Size: 21558 bytes
Desc: not available
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20190128/acecb0ee/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alias28.png
Type: image/png
Size: 21965 bytes
Desc: not available
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20190128/acecb0ee/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alias55.png
Type: image/png
Size: 21331 bytes
Desc: not available
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20190128/acecb0ee/attachment-0003.png>