<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 10/12/22 09:09, Michelle Thompson
wrote:</div>
<div class="moz-cite-prefix"><br>
</div>
<blockquote type="cite"
cite="mid:CACvjz2WEhfrwF3+z+8GduWwGJiS3Vb01pHP6DMdwq25TSxSs=Q@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">That's a great question.
We have a recipe for the uplink, a recipe for the downlink that can
fit on a PLUTO,</pre>
</blockquote>
<p>To clarify: recipes covering 5 GHz and 10 GHz operation on air,
sufficient that they can be assembled on a workbench? (If so:
URL?)</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CACvjz2WEhfrwF3+z+8GduWwGJiS3Vb01pHP6DMdwq25TSxSs=Q@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<p>It feels a little presumptuous as a non-participant in the
project advising here, but a few thoughts in case they're of
interest:</p>
<ul>
<li>QoS does not seem like a <a moz-do-not-send="true"
href="https://sive.rs/infinity">version 0.1 problem</a>. 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).<br>
</li>
<li>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.</li>
<li>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.)</li>
</ul>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CACvjz2WEhfrwF3+z+8GduWwGJiS3Vb01pHP6DMdwq25TSxSs=Q@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<p>+1</p>
<p><br>
</p>
<p>- Roland</p>
<br>
</body>
</html>