[Ground-station] Baseband => decimation - questions

Ron Economos w6rz at comcast.net
Sun Jan 27 17:51:05 EST 2019


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.
>>
>> 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.
>>
>> aliasing
>>
>> Same signal with the baseband filter set properly to 5.5 MHz (each 
>> low-pass filter set to 2.75 MHz).
>>
>> 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 
>>>>> <mailto: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>
>>>>>>     <mailto: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>
>>>>>>>         <mailto: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
>>>>>>>         <mailto:Ground-Station at lists.openresearch.institute>
>>>>>>>         http://lists.openresearch.institute/mailman/listinfo/ground-station
>>>>>>>
>>>>>>>         _______________________________________________
>>>>>>>         Ground-Station mailing list
>>>>>>>         Ground-Station at lists.openresearch.institute  <mailto:Ground-Station at lists.openresearch.institute>
>>>>>>>         http://lists.openresearch.institute/mailman/listinfo/ground-station
>>>>>>         _______________________________________________
>>>>>>         Ground-Station mailing list
>>>>>>         Ground-Station at lists.openresearch.institute
>>>>>>         <mailto:Ground-Station at lists.openresearch.institute>
>>>>>>         http://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 list
>>> Ground-Station at lists.openresearch.institute
>>> http://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 list
> Ground-Station at lists.openresearch.institute
> http://lists.openresearch.institute/mailman/listinfo/ground-station
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station/attachments/20190127/757eb904/attachment-0001.html>
-------------- 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/attachments/20190127/757eb904/attachment-0003.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/attachments/20190127/757eb904/attachment-0004.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/attachments/20190127/757eb904/attachment-0005.png>


More information about the Ground-Station mailing list