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
>>
>
No comments:
Post a Comment