A Matter Wi-Fi Light Bulb in Rust on the Raspberry Pi Pico 2 W

None of those are using WiFi. Most use a different radio technology and require a hub to bridge the network.

Regarding the SDR, the Pico can act as a USB host (honestly a huge win as you can plug in a keyboard/mouse). But it’s not able to run at USB 2 speed. There’s no software for it and the CPU probably isn’t powerful enough. So in that case a Linux machine is completely justified. I tell people to reach for a Pi when they need both Linux and GPIO. But if you just need GPIO you should really save the money (and get major wins in simplicity) with the Pico.

I get the familiar angle of using a Pi Zero. But don’t be intimidated by the Pico. Especially these days with the help of an LLM, you’re not slowed down too much. The version of Python they run feels very familiar. The tooling is good. They’re awesome!

In MCU land you can definitely listen to and decode OTA sensor data without using something as powerful as an RTL-SDR.

Consider common consumer wireless indoor/outdoor thermometers which have a temperature sensor you place outside and a display you place inside. Most of these use a much simpler radio protocol than WiFi or Bluetooth, and have nowhere near the compute power or memory resources to come anywhere near running Linux.

On the transmit side they typically have a fixed frequency oscillator (commonly near 433 MHz or a little over 900 MHz) connected to an antenna through a transistor. They send data by turning that transistor on and off. There are a variety of ways they might do this. Some might do it as pulses with different widths for 1 and 0. Some might do it by having have say 200 us on followed by 200 us off mean 1 and 200 us off followed by 200 us on mean 0. There are many more.

For home built stuff you can by cheap transmit modules to help with this, such as this one [1]. I'm linking to Sparkfun because they have good documentation, but you can find these all over the place.

On the receive side they use a simple receiver tuned to the same frequency (but with enough tolerance that it isn't a problem that both sides are probably using cheap oscillators that aren't very stable or accurate). Here a receiver module for home built stuff [2].

From what I've read the ways these work is that they automatically adjust the gain to have a constant high output level, but there is some lag in that. If there is nobody transmitting the output is just amplified background noise.

Then when someone starts transmitting the gain gets turned down so it is just enough for their signal to have max output. Let's say they are sending 1s as a pulse of 200 us on, 100 us off and 0s as 100 us on, 200 us off. With the gain set so the on level is at maximum output the off level will be quite a bit below that. As long as the gain adjustment is slow enough that it doesn't turn up the gain too much during that up to 200 us off, the next on will still be readily distinguished.

In that example the transmitter is sending 1 bit every 300 us. The firmware in the receiver can look for high/low and low/high transitions in the radio output, looking for the pattern of several consecutive 300 us intervals with 100 us on/200 us off or 200 us on/100 us off. Interpret that is a bit string, and make sure when you design your protocol your transmissions start with some kind of signature so you can tell you are actually listening to the right sender, and it should work. If you designed the radio protocol reasonably you should be able to do the recognition with some kind of efficient state machine.

[1] https://www.sparkfun.com/rf-link-transmitter-434mhz.html

[2] https://www.sparkfun.com/rf-link-receiver-4800bps-434mhz.htm...

Thread is also IP(v6)-based. But in this context, Thread would go a fair ways toward solving stavros's concern, as it means security could be enforced on the Border Router(s), rather than each individual device.

Yes, this is true, but I think over Thread it's also fairly complicated, as a protocol. I'm not very familiar with it, though, admittedly.

re: wifi/ble together

That sounds like the crate didn't have coexistence enabled or the defaults were really odd - so much boring stuff to write about BLE/WiFi Coex, but the short is "the default settings" are pretty good for low bandwidth IoT devices.

I'll peek at the code out of interest :)