Thank you for pointing that out.
I have added a disclaimer to the repository:
This is AI-generated code. The developer has a neurological condition
that makes it impossible to use and learn traditional programming. The
developer has put in a significant effort. This code might not work
properly. Use at your own risk.
This code has not been reviewed by professional coders, it is a large
task. If there are tests available in the codebase, please review those.
Den 13.12.2025 13:32, skrev Marcus Müller:
Hey Håken,
> From what I can tell of the code, it is not "toy code ".
But that's the whole thing here: No matter whether you yourself can
tell, it really is toy code. Your "hard decision decoder" is not a
decoder at all, your cryptography is broken beyond what an LLM can
randomly repair based on feedback from a third party and so on.
I like that you use the wording "toy code". I think what is happening
here is that you're toying with LLMs to generate code for you, and
you're considering that a good entertaining way of building something.
And: I somewhat get it! That's a cool way of experimentation! I think
you might benefit more if you did *smaller* things, because clearly,
the code you generate isn't understood by you (to a very large degree,
at least).
And: you do have to realize that I, and others, looking at the forks
of project on your github account, do need to read your code when you
send PRs, and that if you publish a project like this, you are
actually harming people who think it works. It doesn't, and
specifically you throwing broken cryptography into projects endangers
people who would actually rely on it.
That's why I'll have to say this:
I do value every would-be contributor to the GNU Radio project,
including you! That's why I so enthusiastically replying to your first
email.
But when you do a "Feedback Request", that's a big ask. That's
actively sinking hours. I've been contacted by **multiple** developers
who now also have looked at your code. That means you burned through a
couple Thousand norse kroner worth of "consulting" time, if you want
to think of it in monetary terms (I prefer not to).
So please don't be sad if I say this:
Dear Håken,
your code is autogenerated and doesn't do what you think it does. SDR
is a rich field, and it requires not only writing of code that looks
plausible and works on the tests that the same machine that wrote the
code adds when you ask it to add tests.
It actually requires understanding what you're implementing there.
Your email read plausibly much like you understood a bit of what
you're doing. I understand now that this "sounding plausible" was me
falling for the usual "LLM-generated confidence" trap. That's on me –
I just wasn't expecting it on the mailing list.
So, I do apologize for the harsh tone, but will insist that you
understand that sending code for review that you didn't have the time
or capacity to **fully** understand yourself is not a *contribution*,
but a *detraction*.
I don't think you realize that. But in the GNU Radio project, I merge
no code at all that I haven't *fully* understood (there is exceptions,
if someone who is trusted by the project knows the specific area
better, I can defer understanding every single line to them, but no
line goes into the code base that isn't understood).
If you don't understand (not even having written it) the code you're
sending, then I still have to. That means you asking an LLM to write
1000 lines of code in a few hours is going to cost an actual expert
more time than you spent on this to review stuff.
That is not sustainable, especially because you generate code you
don't actually seem to have need for yet, you just want to "wish it
into existence", and LLMs betray you into believing they can do that
for you. But they just make you take useful human time.
Best regards,
Marcus
On 2025-12-12 6:29 PM, Håken Hveem wrote:
Sorry. I never intended any harm. I use AI assisted programming due
to a neurological issue, it makes it impossible for me to program.
At least I know how to use the tool correctly and test it.
From what I can tell of the code, it is not "toy code ".
Den 12.12.2025 17:25, skrev Marcus Müller:
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
