Hi Håken, dear Community,
oh no, I just got an LLM-generated reply to my (high-effort) reply to this email, and
realized this is the same user that tried me to get a vibe-coded cryptographic module(!!!)
merged upstream, then didn't even understand that no matter how much automatedly generated
fuzzing you throw at things, if that doesn't actually test functionality, it's worthless.
Ok, not going to bother with this module or your code in general anymore. Taking my email
and pasting it into a chatbot to give me, in a single email,
- "You're right to be curious",
- "You're exactly right about the trade-off.",
- "You've identified a real issue!",
- "You're correct",
- "You're absolutely right",
- "You're right to question it."
That degree of unmitigated LLM appeasement bullshit is not only sad, that's actively
insulting to me. Sorry, I can't put this in any nicer terms. You're sending an email with
questions, and once someone answers them, you take their reply, without having asked them,
feed them into an LLM, spending about none effort on understanding the answers you've
gotten at all, and send the reply to me, *as if that was an actual effort on your end*.
If I wanted to chat with a large language model, I would. I don't need you to sit between
a multi-billion dollar company's service and me and copy and paste text.
I invest my time in this projects for *the humans using GNU Radio*. I don't know why you
conjure this digital noise, but it's not productive. Especially because you're clearly
pushing for terrible cryptographic decisions, I can't decide whether this is just gross
incompetence on your end, or whether you're trying to covertly introduce broken
cryptography into FOSS projects. The more of your filler projects I see, the more I tend
towards the latter. If you're trying to poison the well here, please do go away.
I decide how I spend my time on GNU Radio trying to help the community, the code base, and
the long-term ecosystem development.
Assuming you do this out of positive intent:
You don't seem to realize that throwing vibe coded / LLM-generated nonsense at the
community actually consumes our human resources. I sure as hell am *less* happy to
volunteer my time working on GNU Radio after this interaction.
Best regards,
Marcus
On 2025-12-12 4:00 PM, Marcus Müller wrote:
> Hi Håken!
>
> That sounds very exciting! I haven't had time to look at your source code, I'd especially
> be interested in your synchronization methods and your choice of LDPC codes (we're deep
> into the "short code length for limited latency" vs "code effectiveness" tradeoff area here!)
>
> You're using ChaCha20, which is a stream cipher, right? That's interesting because if you
> lose a single ciphertext block, say, to a single uncorrectable bit error after FEC, then
> you need a way of continuing to work. How does that work? Do you keep multiple Key/Nonce
> pairs around and round-robin between a larger number of ChaCha20 instances, to give you
> some leeway to continue to decode OPUS while the receiving end asks for a keystream
> reinitialization?
>
> To kick off a bit more discussion, let me quickly answer your questions to the best of my
> abilities:
>
>> 1. *Channel modeling:* Are the GNU Radio fading channel models (Rayleigh/Rician)
>> representative of real-world mobile conditions, or should I expect different results
>> on-air?
>
> They are what they say on the box :) It's hard to say whether Rayleigh or Rician fading
> describes the channels you are aiming at. Intercontinental HF links are different than
> indoors 5.8 GHz channels!
> So, you need to define your use case first.
>
>> 2. *LDPC implementation:* I'm using hard-decision decoding for simplicity. For those
>> who've implemented soft-decision LDPC in GNU Radio, what's the practical performance
>> gain (measured, not theoretical)?
>
> That depends on very many factors, mostly on decoder design, block length and maximum
> iteration count.
>
> I'm assuming you're just using the belief propagation sum-product decoder that is in gr-
> fec? That does do soft decoding, you'd need to pass in soft-bit RX values, though.
>
> It's really been a while since I thought about FSKs higher than 2-FSK (that aren't
> differnetial).
> Gut feeling here says that 4-FSK it's a pretty suboptimal use of signal power.
> I suspect that the first thing you'd do is drop the FSK approach there, and go for a
> modulation scheme that allows for soft-bits where, at least in AWGN, the entropy per bit
> is a bit better behaved? But I'm really swimming dangerously close to the edge of my
> channel decoder knowledge there.
>
>> 3. *Frequency offset:* The ±1 kHz sensitivity is possible concerning.
>
> Is it? What carrier frequencies are you aiming at? What are your synchronization options?
> Let's start with some back-of-envelop calculations here: You're aiming at a 8000 b/s rate,
> using a r=2/3 code that's 12000 b/s code, using 8-FSK, that's 4 kSym/s.
>
> Unless you're overly wasteful with your FSK spacing, that's a rather narrow channel, and
> tolerating 1/4 of the symbol rate as frequency offset is rather phenomenally good!
>
> Hence, recommendation to describe your current frequency synchronization in more detail.
> You're clearly doing something (else much less than a quarter-symbol rate frequency error
> should lead to breakdowns) right already!
>
>> Has anyone
>> implemented effective AFC for FSK in GNU Radio? Recommendations for libraries or
>> approaches?
>
> Depends on what you're currently doing, and what your framing, pilot, preamble, and system
> synchronization structure (is this just one-way? Or can both ends agree on corrections?) are.
>
>> 4. *Performance validation:* How do simulation results typically compare to hardware
>> testing in your experience?
>
> I think you'll realize that the only possible answer to this is "it depends" :D
>
> > What factors cause the biggest discrepancies?
>
> The things you don't expect :) Sorry! This is a bit broad. As said, synchronization and
> system aspects are often more relevant than textbook knowledge would suggest, but I
> clearly don't know what background you're doing this from, and hence, what you've covered
> already.
>
> Best,
> Marcus
