[Ground-station] Ready-to-build recipes?

[Michelle Thompson]

Guidance and advice are greatly appreciated.

I'll speak about adaptive coding and modulation, since that's what I
know the most about. We've demonstrated constant coding and modulation
six or seven times since October 2021, and I think we have a solid
handle on it. The best place to see this work is here:
https://github.com/phase4ground/documents/tree/master/Engineering/Transmitters/DVB-S2-Multimedia-Beacon

The flowgraphs provide a way to do 10GHz transmitting at a fixed
modcod and show the thinking behind the Default Digital Downlink
content.

This work is part of the San Bernardino Microwave Society ARRL Club
grant application, along with the narrowband digital beacon work from
David Laag and Chip Angle. It didn't get an award in the first round,
but was recently submitted to the second round. We'll receive word on
that soon! We have some of the materials for terrestrial deployment
donated, but not everything in hand yet.

For 5GHz uplink transmission, see the Opulent Voice section, here:
https://github.com/phase4ground/opv-cxx-demod

Here's some videos showing the uplink in action where the hardware and
software are working together:
https://www.youtube.com/playlist?list=PLSfJ4B57S8DlsK8UPDDoq_BH6zDiAjhKX

The control loop for adaptive coding and modulation (ACM) is,
essentially, based on the signal to noise ratio seen at the receiver.
We can indeed keep demonstrating fixed modulation and coding frames
for the downlink, and probably should since these demos are popular,
enjoyable, and are great outreach. However, our encoder is designed to
produce all of the modcods in DVB-S2 based on a single configuration
word sent before each baseband frame. The config adapter layer is in
there, the recent COBS work is in the process of being integrated, so
we've been spending time getting things ready to do ACM. The actuation
part (are you capable of sending arbitrary modcods?) of the downlink
is working. The sensing part (which modcod shall we send?) is what
needs to start working.

That information (select the right modcod) comes from the SNR control
loop outlined in the AMSAT-DL ACM article and can also be influenced
by what kind of traffic is transported by the uplink protocol (Opulent
Voice). This raises QoS questions, potentially based on the type of
traffic, but I readily admit that QoS is possibly not needed at all.
Especially if Opulent Voice performs the way we expect it to.

We anticipate simple approaches working very well, even up into very
congested conditions. DVB-S2 is very well done. We're taking full
advantage of the implementation guidelines, but we can also enjoy some
things not usually available to commercial broadcasters.

Thank you for the thoughtful and helpful comments and questions. I'd
especially like to highlight the part about updating firmware and
software. I think that's something we must make as easy as possible.
Having a powerful FPGA at the heart of a radio means we have the full
potential of upgrading in the field. However, we can all find examples
where updates are an incredibly clunky process, where the designs were
not tested before delivery, where "the community" was expected to
write all the code, or where basic functions simply do not exist. We
want to avoid things like this. The way we increase our chances of
success is by being as open as possible and listening to the wisdom of
people with experience.

(Anyone else from any of the teams, please chime in and fill in
anything I've missed)

-Michelle Thompson

On Fri, Dec 9, 2022 at 7:52 PM Roland Turner via Ground-Station
<ground-station at lists.openresearch.institute> wrote:
>
> On 10/12/22 09:09, Michelle Thompson wrote:
>
> That's a great question.
>
> We have a recipe for the uplink, a recipe for the downlink that can
> fit on a PLUTO,
>
> To clarify: recipes covering 5 GHz and 10 GHz operation on air, sufficient that they can be assembled on a workbench? (If so: URL?)
>
>
> but the central multiplexing part is not what I would
> call "working". You might have seen the call for input about quality
> of service or QoS priorities this past week.
>
> It feels a little presumptuous as a non-participant in the project advising here, but a few thoughts in case they're of interest:
>
> QoS does not seem like a version 0.1 problem. In your shoes, I'd be working towards a working single-QoS repeatable benchtop prototype recipe sufficient for others to implement first, then working on getting clever about resource allocation (not just power, time, and spectrum, but also RAM or "what to drop"). The multiplexer should initially be the simplest possible thing that can do any useful work at all. (I assume something like a small, fixed-length transmit buffer, strict FIFO, and unconditional dropping of new frames offered when the buffer is full).
> Adaptive coding similarly does not seem like a version 0.1 problem. In your shoes at this point I'd simply pick a single coding scheme and implement on that basis; incorporate adaptive coding a little further along. Bear in mind that at this point you're taking fully capable SDRs for granted: early adopters can load new software/firmware at the drop of a hat. Take a look at what's happening on-air with FT8 version changes for example.
> Even when it comes time to deal with resource allocation to make adaptive coding decisions, I suspect that simple is best. In conference WiFi situations for example, raising the SNR threshold (below which a station is dropped) with activity works remarkably well. When the channel is fairly quiet, weaker stations can operate. When it's busy, stations which need more air time for the same number of bits get flicked first. (Granted, the range of bit rates is much broader for WiFi, so the the impact is far greater there.)
>
>
> I think I can speak for everyone working on the design that there will
> be clear messaging when we do have an end-to-end build. There is
> nothing I would like better than to start deploying it in the places
> where we've been invited to install it.
>
> +1
>
>
> - Roland
>
>