<div dir="ltr">Wow that is a nice little expensive chip. It even takes care of the problems I mentioned.<div>But does it need to be an expensive part?</div><div>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?</div><div>It would even avoid the imbalance problems of the IQ signal.</div><div>Of course then the FPGA gets more expensive .. but I like the digital domain more than tinkering with analog components :D</div><div>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. </div><div>Ahmet</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 27, 2019 at 11:52 PM Ron Economos via Ground-Station <ground-station@lists.openresearch.institute> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>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.</p>
<p>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.<br>
</p>
<p>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.</p>
<p>Ron W6RZ<br>
</p>
<div class="gmail-m_-1082876484739499743moz-cite-prefix">On 1/27/19 11:25, Zach Leffke via
Ground-Station wrote:<br>
</div>
<blockquote type="cite">
<p>This is cool. Ron maybe you can school me a bit here.....</p>
<p>1. Got it with the Quadrature ADC, running at half the
required rate, but producing I and Q, so Nyquist is happy.....</p>
<p>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?<br>
</p>
<p>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).<br>
</p>
<p>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.)?</p>
<p><br>
</p>
<p>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.</p>
<p>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.........<br>
</p>
<p><br>
</p>
<p>This is good stuff, I like learning new things. Am I roughly
getting this right or am I out in left field some where?<br>
</p>
<p><br>
</p>
<p>-Zach, KJ4QLP<br>
</p>
<pre class="gmail-m_-1082876484739499743moz-signature" cols="72">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</pre>
<div class="gmail-m_-1082876484739499743moz-cite-prefix">On 1/27/2019 4:07 AM, Ron Economos
via Ground-Station wrote:<br>
</div>
<blockquote type="cite">
<p>SDR's like the Ettus B2x0, bladeRF and LimeSDR are direct
conversion. Here's a block diagram of the architecture.</p>
<p><img src="cid:16893e1347a5fd5757a1" alt="direct
conversion" width="768" height="483"></p>
<p>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.</p>
<p> 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.<br>
</p>
<img src="cid:16893e1347ac1f1a8d12" alt="aliasing" width="800" height="480">
<p>Same signal with the baseband filter set properly to 5.5 MHz
(each low-pass filter set to 2.75 MHz).</p>
<p><img src="cid:16893e1347ac6e5ec2b3" alt="no alias" width="800" height="480"><br>
</p>
<p>Ron W6RZ<br>
</p>
<div class="gmail-m_-1082876484739499743moz-cite-prefix">On 1/26/19 23:51, Zach Leffke via
Ground-Station wrote:<br>
</div>
<blockquote type="cite">
<p>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.</p>
<p>A lot of what has been discussed so far is about down
conversion, not decimation.........<br>
</p>
<p>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.</p>
<p>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). <br>
</p>
<p>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)......</p>
<p>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.<br>
</p>
<p>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).<br>
</p>
<p>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'.<br>
</p>
<p>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).</p>
<p>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.</p>
<p>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. <br>
</p>
<p><br>
</p>
<p>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.<br>
</p>
<p>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.........<br>
</p>
<p> </p>
<p>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.......<br>
</p>
<p><br>
</p>
<p>-Zach, KJ4QLP<br>
</p>
<pre class="gmail-m_-1082876484739499743moz-signature" cols="72">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</pre>
<div class="gmail-m_-1082876484739499743moz-cite-prefix">On 1/25/2019 7:27 PM, Ron
Economos via Ground-Station wrote:<br>
</div>
<blockquote type="cite">
<p>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).<br>
</p>
<p>Ron W6RZ<br>
</p>
<div class="gmail-m_-1082876484739499743moz-cite-prefix">On 1/25/19 16:17, Michelle
Thompson wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">To me, decimation is what we do in order to
channelize in the payload. <br>
<br>
I don't think that's exactly what I'm being asked about
in the ground station receiver, though. <br>
<br clear="all">
<div>
<div dir="ltr" class="gmail-m_-1082876484739499743gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">-Michelle W5NYV<br>
<br>
<div dir="ltr"><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail-m_-1082876484739499743gmail_attr">On Fri, Jan 25, 2019
at 4:14 PM Ron Economos <<a href="mailto:w6rz@comcast.net" target="_blank">w6rz@comcast.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>I'm not sure we are talking about the same thing
yet. So what exactly do you expect to decimate and
why?<br>
</p>
<p>Ron W6RZ<br>
</p>
<div class="gmail-m_-1082876484739499743gmail-m_8520444453280004698moz-cite-prefix">On
1/25/19 16:07, Michelle Thompson wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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. <br>
<br>
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. <br>
<br>
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. <br>
<br clear="all">
<div>
<div dir="ltr" class="gmail-m_-1082876484739499743gmail-m_8520444453280004698gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">-Michelle W5NYV<br>
<br>
<div dir="ltr"><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail-m_-1082876484739499743gmail-m_8520444453280004698gmail_attr">On
Fri, Jan 25, 2019 at 3:52 PM Ron Economos via
Ground-Station <a class="gmail-m_-1082876484739499743gmail-m_8520444453280004698moz-txt-link-rfc2396E" href="mailto:ground-station@lists.openresearch.institute" target="_blank"><ground-station@lists.openresearch.institute></a>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>The standard IF for DVB-S2 receivers is
950 to 2150 MHz.</p>
<p>DB6NT was selling a down-converter from
10489-10500 MHz to 1129-1140 MHz for P4A.</p>
<p><a class="gmail-m_-1082876484739499743gmail-m_8520444453280004698gmail-m_-6643074664132559776moz-txt-link-freetext" href="https://shop.kuhne-electronic.com/kuhne/en/shop/new/MKU+LNC+10+OSCAR+P4A/?card=1832" target="_blank">https://shop.kuhne-electronic.com/kuhne/en/shop/new/MKU+LNC+10+OSCAR+P4A/?card=1832</a></p>
<p>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.<br>
</p>
<p>Ron W6RZ<br>
</p>
<div class="gmail-m_-1082876484739499743gmail-m_8520444453280004698gmail-m_-6643074664132559776moz-cite-prefix">On
1/25/19 15:32, David Vieira via
Ground-Station wrote:<br>
</div>
<blockquote type="cite">
<div class="gmail-m_-1082876484739499743gmail-m_8520444453280004698gmail-m_-6643074664132559776ydp1f38d99eyahoo-style-wrap">
<div>Michelle - Thanks for posting.
I'll frame some of the questions.<br>
</div>
<div><br>
</div>
<div>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).</div>
<div>For an SDR, that IF can be
digitized by an Analog-Digital
Converter.</div>
<div><br>
</div>
<div>The most popular IF for
contesting/SSB rigs is 144 MHz. </div>
<div>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.</div>
<div><br>
</div>
<div>I've heard suggestions/proposals up
to the 1.2 GHz Ham band.</div>
<div>In some sense, the IF carrier could
be 144/220/440/915/1200 MHz, or even
any Non-Ham frequency in between.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>Some questions I have are: </div>
<div>---from an FPGA side of the SDR,
what data rate(s) can the FPGA absorb
in to a decimator? </div>
<div><br>
</div>
<div>Must we decide upfront on a single
frequency; or </div>
<div>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?</div>
<div><br>
</div>
<div>{This is where RF and Digital folks
must communicate across walls.} ;-)</div>
<div><br>
</div>
<div>Comments welcome.</div>
<div><br>
</div>
<div>regards,</div>
<div>David</div>
<div>KI6CLA</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div id="gmail-m_-1082876484739499743gmail-m_8520444453280004698gmail-m_-6643074664132559776ydp40e62e6byahoo_quoted_8708381549" class="gmail-m_-1082876484739499743gmail-m_8520444453280004698gmail-m_-6643074664132559776ydp40e62e6byahoo_quoted">
<div>
<div> On Friday, January 25, 2019,
2:41:54 PM PST, Michelle Thompson
via Ground-Station <a class="gmail-m_-1082876484739499743gmail-m_8520444453280004698gmail-m_-6643074664132559776moz-txt-link-rfc2396E" href="mailto:ground-station@lists.openresearch.institute" target="_blank"><ground-station@lists.openresearch.institute></a>
wrote: </div>
<div><br>
</div>
<div><br>
</div>
<div>
<div id="gmail-m_-1082876484739499743gmail-m_8520444453280004698gmail-m_-6643074664132559776ydp40e62e6byiv6388574106">
<div dir="ltr">
<div dir="ltr">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.<br>
<br>
We've had a lot of progress on
the protocol and algorithm
front (GSE, LDPC, some of the
polyphase). <br>
<br>
Some fundamental decisions
about our own hardware need to
be made.<br>
<br>
When we receive, we expect to
have to decimate. This is
because we are receiving at a
relatively high frequency
(10GHz).<br>
<br>
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.<br>
<br>
Picking the right frequencies
for the receive chain is
therefore important.<br>
<br>
What are our options? <br>
<br>
What options make the best
sense?<br>
<br>
I'd like to build and test as
soon as possible, so let's get
some discussion going.<br>
<br>
<div>
<div dir="ltr" class="gmail-m_-1082876484739499743gmail-m_8520444453280004698gmail-m_-6643074664132559776ydp40e62e6byiv6388574106gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">-Michelle
W5NYV<br>
<br>
<div dir="ltr"><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br>
Ground-Station mailing list<br>
<a href="mailto:Ground-Station@lists.openresearch.institute" rel="nofollow" target="_blank">Ground-Station@lists.openresearch.institute</a><br>
<a href="http://lists.openresearch.institute/mailman/listinfo/ground-station" rel="nofollow" target="_blank">http://lists.openresearch.institute/mailman/listinfo/ground-station</a><br>
</div>
</div>
</div>
<br>
<fieldset class="gmail-m_-1082876484739499743gmail-m_8520444453280004698gmail-m_-6643074664132559776mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-1082876484739499743gmail-m_8520444453280004698gmail-m_-6643074664132559776moz-quote-pre">_______________________________________________
Ground-Station mailing list
<a class="gmail-m_-1082876484739499743gmail-m_8520444453280004698gmail-m_-6643074664132559776moz-txt-link-abbreviated" href="mailto:Ground-Station@lists.openresearch.institute" target="_blank">Ground-Station@lists.openresearch.institute</a>
<a class="gmail-m_-1082876484739499743gmail-m_8520444453280004698gmail-m_-6643074664132559776moz-txt-link-freetext" href="http://lists.openresearch.institute/mailman/listinfo/ground-station" target="_blank">http://lists.openresearch.institute/mailman/listinfo/ground-station</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Ground-Station mailing list<br>
<a class="gmail-m_-1082876484739499743gmail-m_8520444453280004698moz-txt-link-abbreviated" href="mailto:Ground-Station@lists.openresearch.institute" target="_blank">Ground-Station@lists.openresearch.institute</a><br>
<a href="http://lists.openresearch.institute/mailman/listinfo/ground-station" rel="noreferrer" target="_blank">http://lists.openresearch.institute/mailman/listinfo/ground-station</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
<fieldset class="gmail-m_-1082876484739499743mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-1082876484739499743moz-quote-pre">_______________________________________________
Ground-Station mailing list
<a class="gmail-m_-1082876484739499743moz-txt-link-abbreviated" href="mailto:Ground-Station@lists.openresearch.institute" target="_blank">Ground-Station@lists.openresearch.institute</a>
<a class="gmail-m_-1082876484739499743moz-txt-link-freetext" href="http://lists.openresearch.institute/mailman/listinfo/ground-station" target="_blank">http://lists.openresearch.institute/mailman/listinfo/ground-station</a>
</pre>
</blockquote>
<br>
<fieldset class="gmail-m_-1082876484739499743mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-1082876484739499743moz-quote-pre">_______________________________________________
Ground-Station mailing list
<a class="gmail-m_-1082876484739499743moz-txt-link-abbreviated" href="mailto:Ground-Station@lists.openresearch.institute" target="_blank">Ground-Station@lists.openresearch.institute</a>
<a class="gmail-m_-1082876484739499743moz-txt-link-freetext" href="http://lists.openresearch.institute/mailman/listinfo/ground-station" target="_blank">http://lists.openresearch.institute/mailman/listinfo/ground-station</a>
</pre>
</blockquote>
<br>
<fieldset class="gmail-m_-1082876484739499743mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-1082876484739499743moz-quote-pre">_______________________________________________
Ground-Station mailing list
<a class="gmail-m_-1082876484739499743moz-txt-link-abbreviated" href="mailto:Ground-Station@lists.openresearch.institute" target="_blank">Ground-Station@lists.openresearch.institute</a>
<a class="gmail-m_-1082876484739499743moz-txt-link-freetext" href="http://lists.openresearch.institute/mailman/listinfo/ground-station" target="_blank">http://lists.openresearch.institute/mailman/listinfo/ground-station</a>
</pre>
</blockquote>
<br>
<fieldset class="gmail-m_-1082876484739499743mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-1082876484739499743moz-quote-pre">_______________________________________________
Ground-Station mailing list
<a class="gmail-m_-1082876484739499743moz-txt-link-abbreviated" href="mailto:Ground-Station@lists.openresearch.institute" target="_blank">Ground-Station@lists.openresearch.institute</a>
<a class="gmail-m_-1082876484739499743moz-txt-link-freetext" href="http://lists.openresearch.institute/mailman/listinfo/ground-station" target="_blank">http://lists.openresearch.institute/mailman/listinfo/ground-station</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Ground-Station mailing list<br>
Ground-Station@lists.openresearch.institute<br>
<a href="http://lists.openresearch.institute/mailman/listinfo/ground-station" rel="noreferrer" target="_blank">http://lists.openresearch.institute/mailman/listinfo/ground-station</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><br>Ahmet Inan<br><br>Co-founder and CEO of aicodix GmbH<br><a href="https://www.aicodix.de/" target="_blank">https://www.aicodix.de/</a><br></div>