Simple RF control application for the gnu radio and AI researchers

1. Just take a simple worm.

2. It has a very simple neural net, that emits and recieve very low frequency radio waves.

3. Highly likely it may be useful to use short impulses, like in the PSU.

4. To send and receive even very low frequency waves you can use very short antennas if impedance is matched.

5. The modern beam forming is possible with the sub-mm accuracy, and with high speed sampling rate you can sample neurons group by group.

You can start with that.

The next step depends on what is the real algorithmic complexity of the human brain and behavior is.

But to estimate it you can just take a look at the IPCAMERAS, and get that is is very small.

And the real algorithmic complexity of human brain is relatively low.

https://transitional-writes.dreamwidth.org/44972.html

It seems the minimum description length principle could be used to deduce minimum ethics. At least you can compare ethics by the length. What about the following question: how to shoot met-art girl in the dark underground? ~2026-24709-41 (talk) 16:43, 8 June 2026 (UTC)

https://en.wikipedia.org/wiki/Talk:Solomonoff%27s_theory_of_inductive_inference

Kirill Abramovich
Samara, Russia
wieker@gmail.com

GRCon26 - Abstracts due by June 13 - THIS WEEK!

Just a reminder that GRCon26 (21-24 Sept 2026, Raleigh, NC) Call for Participation closes June 13.  Please submit abstracts in time for consideration.

https://events.gnuradio.org/event/28/abstracts/

All event information can be found here: https://events.gnuradio.org/event/28/

If you have any questions, please don't hesitate to contact us - grcon@gnuradio.org.

Looking forward to seeing all of you in Raleigh in September!!

Josh

Hi, can we discuss possible Solomonoff induction flow for radio engineers?

Hi,

can we at least discuss the following thing:

1. If we assume that the algorithmic complexity
of neural processes is relatively small
(you could take a look at the Potapov monography
for some arguments)

2. As far as I know a lot of neural processes in human brain are electric (or electro-chemistry)
in nature. They have a little power and a small
frequency (~ 1-1000 Hz).
So they emit very low frequency radio waves.

3. You can detect those radio waves on
small antennas if the impedance of such antennas
is matched. This is basically the citation
from the book on electrodynamics.
I uploaded one such book on Twirpix site.

4. So you can create a lot of such receivers
- microstrip filter to filter very high frequencies
- impedance matched microstrip antenna
- resistor for noise for oversampling
- very fast comparator to sample signal
in a very large array on a chip using
standard CMOS or some sort of full-custom process
(maybe even with some new materials)

5. BreamForming and large arrays of digital correlators with sub-mm positioning accuracy
could be achived.

so it seems there is no theoretical
obstacles to implement some sort of
RF human brain sensing or even control
if you can implement reverse structure
with array of a large amount of RF amplifiers
with sub-mm beam forming accuracy

See here more:

https://transitional-writes.dreamwidth.org/44972.html

Kirill Abramovich

Samara, Russia

wieker@gmail.com

wieker0@yandex.ru

Re: Accumulating into output_items[0] across multiple general_work()

Hi Dani, Thanks for your response, very informative! I guess it's probably reasonable not to base a block implementation on an assumption of “it works because I looked at the source code”. And you’re right, it’s true that exotic buffer implementations are free to hand off output buffers how ever they want to (which I think need very specific reasons to do so, but still not contract-breaking). My block is actually not (just) an FFT, it’s a bit more complicated, I just mentioned that for the sake of giving a simple example use case, but your insight is valuable. Thanks again, Wael > On Jun 4, 2026, at 11:43 PM, Daniel Estévez <daniel@destevez.net> wrote: > > Hi Wael, > > This is a great question. My understanding is basically the same as the conclusion you've arrived to. In practice this works correctly for GR3 regular CPU buffers, because the buffer is a ring buffer and the write pointer is not advanced if you return zero as the number of items that your general_work() call has produced. So the next general_work() call sees the same data that the previous call wrote in the output buffer. If I remember correctly, this also works in the same way for GR4 regular CPU buffers. > > However, I think this is going into undocumented assumptions of how the buffer system should work. I don't think this is solidly written down anywhere, but for me the contract that general_work() has with the output buffer is that it should never read data from the output buffer, and it needs to write exactly as many items at the beginning of the buffer as the number of items that are being produced. Anything else might break under an exotic customs buffer implementation. For instance, I could imagine an implementation which hands off an output buffer taken from a common buffer pool, with no guarantee that the buffer is the same in consecutive calls even if no data was produced. > > Since your use case is accumulating many FFT frames, I would say that storing the accumulator as a member in the block class and copying the result to the output buffer whenever the accumulation has finished is quite acceptable. The output data rate is going to be quite low, so the memory copies add very little overhead. > > Another comment is that a very long integration can be realized by cascading multiple shorter integrations, which can be realized with the in-tree Integrate block. For instance you could integrate 1e9 FFTs by cascading three Integrate blocks, each set to a integration of 1e3. When using floating point numbers this approach is also better numerically, because otherwise you are sequentially adding numbers to an accumulator that ends up being approximately 1e9 times larger than the input numbers, which doesn't really work because the float32 machine epsilon is 1e-7. > > Best, > Dani. > > On 05/06/2026 03:27, Wael Farah wrote: >> Hi all, >> I have a block whose output items are running averages over a long integration (for the sake of simplicity say a power spectrum accumulated over millions of FFT frames, way too many to hold as one input buffer). >> The implementation that fell out naturally is: in general_work(), add the next batch of partial contributions directly into output_items[0] [n_emitted], return 0 while the integration is still incomplete, and only return n_emitted > 0 when one or more integrations are done. It's pretty tempting to do as this would practically avoid an extra memory allocation for an internal buffer and a memcpy back to output_items when accumulation is ready. >> However, this relies on the assumption that returning 0 leaves the write pointer unadvanced, so the next general_work() call sees the same memory at output_items[0][n_emitted] and I can keep adding into it. >> As far as I can tell, this works on current GR (no-op when produce_each(0) <https://github.com/gnuradio/gnuradio/blob/main/ gnuradio-runtime/lib/block_detail.cc#L123-L132> -> write pointer not updated), but it’s more like an implementation detail rather than it being documented as part of the scheduler API. >> Two questions: >> 1) Is the "accumulate into output_items[0] across calls" pattern supported, or am I in undocumented/unidentified scheduler/buffer behavior territory? >> 2) If it's not supported, is there any reason beyond "no API guarantee”; e.g. would it break under certain custom buffers or futuristically GR4? >> If the answer is just "use an internal buffer," happy to refactor. >> Thanks! >> Wael >

[SECURITY] Security vulnerability in CI reported, resolved without incidence

Dear GNU Radio community, today, we received a security advisory via the contact method we offer in a canonical place [1], alerting us to the following: The github CI workflow that can be used to re-render the conda template gets triggered and executed without checking that the author of the triggering PR has CI privileges. (For the CI that gets run when you open a PR, you need to be trusted, or else a maintainer needs to click on "Approve CI run" every time you post or update a CI; this is not true for the github "issue_comment" trigger, which honestly is, in line with the rest of github CI's documentation style, something you can infer with enough experience, from sources outside Github documentation. We didn't infer that, and we wonder why there are action security controls that do not apply to all ways to trigger actions. Still, it's our responsibility to keep things safe, and assuming controls work without checking seems to be something we need to add to our list of things to do when working with public CI.) That would have allowed an attacker to open a PR that does something nefarious (attack webservers, mine cryptocurrency, exfiltrate CI secrets, modify commits/source code). We received this report from Wang-Meimei, for which we are very thankful. Steps taken: 1. simply removed that workflow. That makes it impossible to trigger from PRs, even should they add it back: it needs to exist on the main branch to work. I have not been able to get the workflow to function correctly in the last six months, so functionally, this is not a restriction of our abilities. 2. investigated workflow runs of the past year. No execution of that workflow, aside from my own, have been found. There have not been any inconsistencies of the main branch history with local copies, so we can preclude any code modifications. 3. Started a review of the repository action secrets stored in github. As mentioned in 2., we are certain enough this was not exploited, but we are still working to rotate secrets, and flush caches where applicable. ("abundance of caution", but really, we should just be doing that in a situation like this, without needing to think about it.) Special thanks, again, go out to Wang-Meimei, who's been very helpful in their reporting. Best regards, Marcus Müller [1] as described in RFC 9116: https://gnuradio.org/.well-known/security.txt

IEEE Aerospace Conference 2027

Hello,

 

I am chairing the Software Defined and Cognitive Radio session at the upcoming IEEE Aerospace Conference (http://www.aeroconf.org, https://aeroconf.org/cms/content_attachments/26/download).  This large conference will take place March 6-13, 2027 in Big Sky, Montana.  The conference provides a world-class technical program and provides excellent opportunities for both networking and recreation. This is one of the few conferences where SDR can be put in the context of a complete system and can be applied to new missions and concepts of operations.

 

Last year there were a few papers dealing with application of machine/deep learning to radio design.  I hope to see even more next year!

Abstracts are due soon, but I can take them later as well, while the full paper is due end of October.  This session will focus on flexible radio architectures, including the use of GPPs, GPUs,  and FPGAs.  Reports of existing systems and testbeds are of significant interest.  This year I’d like to introduce work related to machine learning as applied to wireless communications.

 

Please forward this to your friends and colleagues working in the areas of SDR, ML for signal processing, and cognitive radio.

Regards,

Eugene.

Eugene Grayver, Ph.D.

Principal Engineer

310-336-1274

Accumulating into output_items[0] across multiple general_work()

Hi all,

I have a block whose output items are running averages over a long integration (for the sake of simplicity say a power spectrum accumulated over millions of FFT frames, way too many to hold as one input buffer).

The implementation that fell out naturally is: in general_work(), add the next batch of partial contributions directly into output_items[0][n_emitted], return 0 while the integration is still incomplete, and only return n_emitted > 0 when one or more integrations are done. It's pretty tempting to do as this would practically avoid an extra memory allocation for an internal buffer and a memcpy back to output_items when accumulation is ready.

However, this relies on the assumption that returning 0 leaves the write pointer unadvanced, so the next general_work() call sees the same memory at output_items[0][n_emitted] and I can keep adding into it. 

As far as I can tell, this works on current GR (no-op when produce_each(0) -> write pointer not updated), but it’s more like an implementation detail rather than it being documented as part of the scheduler API.

Two questions:

1) Is the "accumulate into output_items[0] across calls" pattern supported, or am I in undocumented/unidentified scheduler/buffer behavior territory?

2) If it's not supported, is there any reason beyond "no API guarantee”; e.g. would it break under certain custom buffers or futuristically GR4?

If the answer is just "use an internal buffer," happy to refactor.

Thanks!

Wael