[Ground-station] Question for ORI:

[Michelle Thompson]

I worked on SDX, and have a lot of stories about it.

A recent attempt to do something similar, I think, was what Howie DeFelice
was trying to accomplish with AMSAT ASCENT and the CubeQuest Challenge
entry. That was a 160 kS/s setup.

LoRa is popular and LoRa is problematic. It's popular for particular
reasons and we have to address those if we want to see open alternatives
chosen. I believe Pierros will describe the situation in a powerful and
effective way with his writing.

What actions do we need to take? What is our role?

The core part of the original question is "We need something that can ping
Swarm with "I'm alive" and also get two way messaging for
TT&C/Health/Whatevs. Does Open Research have anyone that knows how to
navigate the regulatory bits to make LORA usable as an inter satellite
relay?"

If not LoRa, because it isn't open and I do not believe we can force it to
be even with regulatory magic, then what do we have in our repertoire that
would provide the functions described?

Douglas identified the basic technology required and thought maybe Phil
Karn had done some work here, but Bruce Perens framed it as "dirt-cheap SS
data links between so-far-terrestrial embedded microprocessors with a link
budget to go miles at the lowest data rate and long life on small
batteries". Jay Francis reinforces the value of this type of work and
highlights specific hardware concerns and questions.

The following is a very brief summary from Douglas:

"For over the air signals, I would rather see us use a completely open
source implementation written in C (or some high level language) to
generate the bits, bytes, forward error correction and digital
samples-ready-for-a-D-to-A-converter and which can be run on a variety of
processors rather than get stuck with a particular custom hardware chip
that goes out of production long before the end-of-life of the satellite."

This gets reinforced by Zach (C/C++). You do not need an FPGA to accomplish
this sort of link. (Note: there are very small FPGAs and they are not
impossibly bad choices for this sort of work.)

We're talking about an in-space network to get the swarm in touch with each
other and take care of the basic business.

So, what's the processor that would be the best choice for going into
service to support open source space-space links? (Douglas et al)

Pierros brings up these three projects:

LSF PQ9ISH-COMMS
AX5043 based
https://gitlab.com/librespacefoundation/pq9ish/pq9ish-comms-vu-hw/

UBNanosat Lab LFR
Si446x based
https://github.com/UBNanosatLab/lfr-hardware

Planet Labs OpenLST
CC1110 based
https://github.com/OpenLST/openlst


This is an area of interest. The original questions are great, there's
several people that want to help figure things out and have volunteered,
and there are several bodies of work that are potentially "almost there".

1) We do need to articulate a position about LoRa that makes sense and
provides constructive paths forward.

2) We need to identify what is perceived as missing in open source work. Is
it just price (I think Bruce said this), or also education, or marketing
(several people have cited this)?

This messaging deficiency can be addressed with some organization, but
fighting price without an alternative is really hard.

If there is a technology or implementation gap, then that can be addressed
with some engineering demonstrations - but then we're back to consistently
promoting the solution.

That means 1) is really important.

-Michelle W5NYV




On Thu, Apr 1, 2021 at 4:21 PM Leffke, Zachary via Ground-Station
<ground-station at lists.openresearch.institute> wrote:

> Seconded….I was gonna write long winded stuff, but Howie summed up what I
> was thinking pretty well. (that won’t keep me from writing more though).
> What follows is a bit off topic, so feel free to skip, though IMHO is the
> kind of area that excites me for the hobby and is not unrelated to ideas
> for building our own capabilities akin to TDRSS/Iridium/Globalstar for low
> rate, reliable ‘pings’ to other Amateur spacecraft.
>
>
>
> I’ve been fascinated by crosslink mission concepts for a long time now.
> If GEO goals ever pan out, I would love to see an ‘Amateur TDRSS’ concept
> worked into the mission objectives (crosslink sub-sub bands worked into
> existing Amateur Satellite Service sub bands?).  Something APRS-like in
> terms of interoperation (not the underlying protocols) for things like
> LEO-LEO crosslinks would be exciting as well (an ‘amateur Iridium’ or
> ‘Amateur Globalstar’ type concept).  Would love the ‘first to hear’ award
> for some future spacecraft to go to someone that heard it via a crosslink
> two seconds after power up.  As far as protocols involved, not sure I have
> enough experience to vote one way or the other on heavy FEC narrowband vs
> SS for the general goal of ‘reliable, low bit rate, dirt cheap, and easy
> pings.’ (isn’t this a debate that has lasted through generations of
> engineers?)  I do think whoever fields such a crosslink system (whatever
> the flight regime) would have to either agree on one or the other, or agree
> on something like SDR technology that could ‘do both’ to support a
> heterogeneous mix of devices.
>
>
>
> Some more long-winded stuff about fully open source / open hardware
> software radio satellite transponders (feel free to skip, these are just
> ideas….and ideas are a dime a dozen), not completely unrelated to a
> crosslink style mission:
>
>
>
> I think there is a ‘technology gap’ that exists.  Way back when AMSAT flew
> an SDX with some pretty cool features (15 years ago or there about
> right?).  Jump ahead to today and for a few hundred thousand bucks, you can
> get highly proprietary (though highly reliable) space rated SDRs (AstroSDR,
> Tethers Unlimited, I think GOMSpace has one that is cheaper, not sure
> there, etc.)……..or you can harden cheaper terrestrial SDRs (AMSAT GOLF and
> E310) or you can ‘roll your own’ (Hawkeye360).  All those designs are based
> on Xilinx FPGAs (Xynqs with embedded ARMs) married to AD93XX ADC/DACs or
> similar…..but can do things like 54 MHz instantaneous bandwidths, or full
> DVB-S2X modulation/demodulation, etc….
>
>
>
> I’m not knocking any of the high-end stuff…..but where is the 100 kHz to
> say maybe 1 MHz wide SDR based transponder?  Where is the recreation of the
> same type of thing that was done on ARISSat-1 (I think that’s where the
> first SDX flew right?), but on a 1U cubesat with modern technology….maybe a
> stretch goal of making it reconfigurable in orbit.  I’m not talking highly
> sophisticated anything here, I’m talking the incremental step from an
> analog transponder to something that can do some amount of onboard
> processing that is interesting……like switching between narrowband FEC or SS
> (or doing both simultaneously) to support a crosslink type mission,
> handling doppler, or FM up / SSB down, or simple FFT based power monitoring
> and normalization from Uplink to downlink, or notching out uplink
> alligators on the downlink (re-implement G6LVB’s STELLA power equalizer),
> or ranging experiments, etc.  ARISSat-1 I think was ahead of its time a
> bit, and just recreating that SDX capability with modern technology would
> be super cool and worth while to pursue IMHO (fully open source, open
> hardware as always).
>
>
>
> Last collection of random thoughts that are hopefully relevant (mostly
> about software radio transponders):
>
> 1.       To bruces point about capable microcontrollers……..I’ve wanted to
> build a ‘simple SDX’ for a long time (but lack the time, full range of
> skillsets required, and realize I’m probably being “blissfully ignorant” of
> the challenges involved….so mostly toyed with the idea when I’m bored).
> Somewhere in the last year or two there was QEX article about hooking a DAC
> up to microcontroller that reignited this interest….and then I discovered
> the STM32F4 family (ARM Cortex-M4s, 180 MHz speeds, etc.):
> https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html
> ….way more capable than whatever flew on the SDX (which I think was like 1
> MHz speed or something like that right?), and I would think fully capable
> of keeping up with say a 1 MHz complex sampling rate.
>
> 2.       Liquid-dsp:  https://github.com/jgaeddert/liquid-dsp.  Written
> in C, and from the github description:  “liquid-dsp is a free and
> open-source digital signal processing (DSP) library designed specifically
> for software-defined radios on embedded platforms. The aim is to provide a
> lightweight DSP library that does not rely on a myriad of external
> dependencies or proprietary and otherwise cumbersome frameworks.”  Full
> disclosure, this was created by one of my VT colleagues, when he was a PhD
> student, and he’s now back with VT as a researcher at Hume, so I might be
> biased……super smart dude and he still maintains the repo (also by the way,
> he got the JPEG compression working for us on the two VT FOX cameras, also
> STM32 based, when he was a Postdoc….the VT watermark in the images was his
> handywork).  In some short discussions with him on this topic, he seems to
> think getting liquid working with an STM32F4 might be super easy (though
> again, he’s a genius in my opinion….so ‘easy’ with a grain of salt).
>
> 3.       The STM32F4 family also has an ‘audio processing’ flavor to it
> with built in DACs and ADCs for that sort of thing, and I think some kind
> of coprocessor built in (maybe for something like FFTs, been a while since
> I looked into this) so I’m wondering if some of that can be leveraged (akin
> to the funcube showing up as a ‘sound card’ and IQ samples pumped over
> stereo L/R channels)…..not sure if this really makes sense though, but
> maybe…..if not, then external DACs/ADCs.
>
> 4.       Combine 1-3 and I feel like that’s a pretty solid core device
> for some simple, cheap SDR transponder experimentation.
>
> 5.       I feel like there are also some examples out there for useful
> technology, like DIY softrock SDRs or something like that…..but not for
> space based transponders.
>
> 6.       Suitable up/down converters with traditional good ole analog RF
> engineering would be needed (maybe that’s obvious).
>
>
>
> Making a fully open hardware / open source transponder, even if it lacks
> the super high end capabilities of existing commercial stuff I think would
> be super cool and worthwhile to pursue.  Keeping the signal processing in
> the C/C++ domain (as opposed to say FPGA wizardry…not saying we shouldn’t
> also pursue FPGA based designs in general, just not the design I’m
> currently running my mouth about) might encourage more development support
> and volunteers since it would be a bit more accessible to folks.
> Experiments in novel crosslink techniques (including modulation schemes),
> spectrum monitoring, illegal transmitter hunting (talk about policing the
> bands…), etc. could all be ‘on the table’ for the mission concepts……..and
> when not trying that stuff……turn it over for normal transponder use with
> novel modes……and I haven’t even gotten into low cost digital phased array
> concepts (for spacecraft) I think would be cool to pursue as well.
>
>
>
> -Zach, KJ4QLP
>
>
>
>
>
> --
>
> Research Associate
>
> Aerospace & Ocean 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
>
>
>
> *From:* Ground-Station
> <ground-station-bounces at lists.openresearch.institute> *On Behalf Of *Howie
> DeFelice via Ground-Station
> *Sent:* Wednesday, March 31, 2021 7:40 PM
> *To:* Bruce Perens <bruce at perens.com>; Douglas Quagliana <
> dquagliana at gmail.com>
> *Cc:* Michelle Thompson via Ground-Station
> <ground-station at lists.openresearch.institute>
> *Subject:* Re: [Ground-station] Question for ORI:
>
>
>
> I’m not a patent expert but it appears the first one listed covers the
> generation of spread spectrum “chirps” using a fractional N synthesizer.
> The other patent covers the  data formatting and modulation scheme.
> Assuming we have to stay away from those two aspects, we could still use
> chirp spread spectrum, just not generated the same way. The biggest
> advantage to chirped spread spectrum from a satellite operations
> perspective is that it’s inherently resistant to doppler issues. As long as
> the signal is in the receiver bandwidth and you can detect the direction of
> the chirp you can decode the signal.  Using a chirp spread spectrum
> physical layer into a an adapted 802.16 mesh network configuration could
> provide a way to have satellite augmented ground networks (or vice versa)
> without having to have a planned constellation of satellites. If every new
> LEO carried the transponder, the network would automatically form and
> grow.  When satellites are visible to each other traffic would also be
> repeated satellite to satellite. If the frequency plan was compatible to
> QO-100 transatlantic relays could be possible into the QO-100 footprint.
>
>
>
> Howie AB2S
>
>
>
>
>
> *From: *Bruce Perens via Ground-Station
> <ground-station at lists.openresearch.institute>
> *Sent: *Wednesday, March 31, 2021 7:13 PM
> *To: *Douglas Quagliana <dquagliana at gmail.com>
> *Cc: *Michelle Thompson via Ground-Station
> <ground-station at lists.openresearch.institute>
> *Subject: *Re: [Ground-station] Question for ORI:
>
>
>
>
>
>
>
> On Wed, Mar 31, 2021 at 3:43 PM Douglas Quagliana <dquagliana at gmail.com>
> wrote:
>
> Bruce writes:
>
> > someone more skilled than me would be sitting down to make an open data
> link implementation built on some cheap microprocessor
>
>
>
> If I understand what you're saying, Phil has already written several
> downlink schemes.
>
>
>
> Yes, but I am not aware of Phil addressing this particular application,
> which is dirt-cheap SS data links between so-far-terrestrial embedded
> microprocessors with a link budget to go miles at the lowest data rate and
> long life on small batteries. I hold out some hope that the functionality
> of their chip can be duplicated with a relatively small number of discrete
> components and a cheap microprocessor. Certainly we have ones that can do
> significant DSP in the $4 range these days, and they idle at microamps
> drain.
>
>
>
>     Thanks
>
>
>
>     Bruce
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20210406/035bac75/attachment-0001.html>