I think that engineers telling other
engineers (military) that something isn't
sufficient is making a lot of
assumptions that should not be made.
I don't think we need quite that call to inaction :-) . I can certainly see the problem on my Starlink connection, and can classify the degradation of performance under load that should not be there. It's insufficient for a low latency video call, which I think is an easy definition of a lowest-common-denominator for anything involving vehicle control.
And if you want to propose some
solution, then define the metrics of that solution. First,
what is max latency/jitter/whatever
that the application can handle and still be useful?
Why exactly is your ham thing failing,
and what latency/jitter would resolve it. And/or, what mitigation
in your software/procedures would solve
it.
My ham application is equivalent to a low-latency voice-only WebRTC call. There are diagnostics for them, and for the video call mentioned above. I would hope that Taht could put together numbers.
I know that Dave & crew have made
some improvements to the wifi stack, but it is far from
solved even today. Maybe effort is
better done on wifi where developers that are not @spacex
can actually make changes and test
results.
This does seem to be a call to inaction, doesn't it? Dave and Co. have been working on WiFi for quite some time and have good papers.