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

[Roland Turner]

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
    <https://sive.rs/infinity>. 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20221210/ef53860f/attachment-0001.htm>