GNU Radio, One Step at a Time

Hi all,

Reaching out to the GNU Radio community (and reconnecting if we met at GRCon25).

At AnySignal, we build vertically integrated RF systems for space and national security—spanning domain-specific hardware, DSP, and FPGA—with a strong emphasis on end-to-end algorithm development and deployment. GNU Radio and USRPs are central to how we validate and deploy real systems. AnySignal recently closed a $24M Series A, and we're rapidly expanding our team.

We're hiring DSP engineers, FPGA engineers, and GNU Radio developers who enjoy taking ideas from initial concept into volume deployments —this is not a legacy maintenance role.

You'd be working alongside a small, senior team that includes Josh Blum and engineers from SpaceX and other top aerospace programs. In 2026 alone, your work will support high-profile lunar missions, critical national security demonstrations, and advancing RF capabilities in key contested domains, with real ownership from algorithm design and implementation through fielded systems.

If this sounds interesting, apply w/ the links below, or email me directly.

DSP: https://jobs.lever.co/anysignal/4a2933b9-5faa-4555-8a5e-c517f7032b35
FPGA: https://jobs.lever.co/anysignal/89919556-1f67-49b7-9aaa-82a4daf21389

Best,
John Malsbury
CEO | AnySignal

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
>>>
>>
>

GNU Radio, One Step at a Time

Friday, December 19, 2025

Questions about suitable hardware for testing.

Thursday, December 18, 2025

DUC/DDC CH0: Frequency Shift (Hz) Error

Wednesday, December 17, 2025

Hiring for DSP / FPGA @ AnySignal

Monday, December 15, 2025

FOSDEM SDR/DSP devroom program

Sunday, December 14, 2025

Re: Suggestion how to multiplex 2 IQ-streams?

Suggestion how to multiplex 2 IQ-streams?

Saturday, December 13, 2025

Re: gr-sleipnir Digital Voice Protocol - Test Results and Feedback Request