[Ground-station] Baseband => decimation - questions
Ron Economos
w6rz at comcast.net
Sun Jan 27 14:51:05 PST 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-openresearch.institute/attachments/20190127/757eb904/attachment.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-openresearch.institute/attachments/20190127/757eb904/attachment.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/20190127/757eb904/attachment-0001.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/20190127/757eb904/attachment-0002.png>
More information about the Ground-Station
mailing list