[Ground-station] Baseband => decimation - questions
Ron Economos
w6rz at comcast.net
Mon Jan 28 04:04:34 PST 2019
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.
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> 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.
>>>
>>> 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 <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 <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
>
>
>
> --
>
> 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/780ae407/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/780ae407/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/780ae407/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/780ae407/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/780ae407/attachment-0003.png>
More information about the Ground-Station
mailing list