WiFi repeaters are getting super cheap now ($5!) and can contain quite open hardware. Try to make the most out of the QCA953X based ones.
To make the experience fit your profile, pick a username and tell us what interests you.
OpenWrt 23.05 SNAPSHOT firmware for the QCA9533 based repeater
octet-stream - 6.50 MB - 10/15/2023 at 14:34
Toolchain for cross compiling for the OpenWrt 23.05 SNAPSHOT firmware attached here
x-xz - 35.44 MB - 10/10/2023 at 08:53
Minimal OpenWrt 21.02 firmware for the QCA9533 based repeater
octet-stream - 5.00 MB - 09/21/2023 at 10:00
Toolchain for cross compiling for the OpenWrt 21.02 firmware attached here
x-bzip - 44.99 MB - 09/21/2023 at 10:12
Support for the latest OpenWrt succeeded! You can get the latest and greatest here:
and use the "Peater QCA9533" Target Profile. I also added a precompiled firmware and toolchain in the files section to this project. I'll try to sync with openwrt/main for a while to have it always up to date, and also get a PR through so that won't be needed anymore
First time flashing goes via UART and uboot again (or if you find another way please comment in the post, over SSH with sysupgrade should be possible too):
setenv ipaddr <make up an ip> setenv serverip <tftp server ip> tftp 0x80060000 openwrt-ath79-generic-peater-squashfs-sysupgrade.bin erase 0x9f050000 +0x7a0000 cp.b $fileaddr 0x9f050000 0x7a0000 setenv bootcmd "bootm 0x9f050000" saveenv
After entering the shell the firewall should be cleared first to allow access via SSH or Luci:
nft flush ruleset
and the network config in /etc/config/network can be tidied up a bit:
root@OpenWrt:/# cat /etc/config/network config interface 'loopback' option device 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config device option name 'br-lan' option type 'bridge' list ports 'eth1' config interface 'lan' option device 'br-lan' option proto 'dhcp' root@OpenWrt:/#
Also don't forget to disable BPF JIT if you want to use the wireless interface as a monitor:
root@OpenWrt:/# cat /etc/sysctl.conf # Defaults are configured in /etc/sysctl.d/* and can be customized in this file net.core.bpf_jit_enable=0 root@OpenWrt:/#
EDIT: fixing config/network and the bpf jit is now done automatically on first boot, I've uploaded a new frimware image with this to this project page. (also nft flush does not seem to be necessary)
Fun ideas seem to come in quick succession at the moment, after I remember that rtl_433 was ported to the ESP32: https://github.com/NorthernMan54/rtl_433_ESP
This workaround will be needed since the QCA9533 lacks USB, otherwise rtl-sdr would open up so much more functionality!
I already have an SX1278 in the parts bin so that will be my main target, which will also enable LoRa to be added to the bridge. Actually getting the SX1278 running on the repeater will be the meat of this part of the project, with the 433 decoder a nice use case.
EDIT: It looks like most of the hard work has already been done: https://github.com/starnight/LoRa.
Also RadioLib supports the SX1278 and can run on Linux: https://github.com/jgromes/RadioLib/wiki/Porting-to-non-Arduino-Platforms
And there is this: https://github.com/dernasherbrezon/sx127x
Those three repos above should suffice for getting this to work.
Actually the sx1278 is supported out of the box by the micropython bundled with openwrt! https://github.com/micropython/micropython-lib/tree/master/micropython/lora
That will very likely be the way I will approach this, at least for initial testing. One thing left here now is getting SPI to work.
EDIT2: So getting SPI to work was fairly tricky, the cs-gpios in the device tree is not working anymore since the move to the ar934x-spi driver: https://github.com/openwrt/openwrt/commit/ebf0d8d. Setting a CS line now involves pin muxing, which I do not know how to do.
This took me a while to figure out, and I opted to use the older ar7100-spi driver so I can use cs-gpios again, and I chose the WPS led pin to be my CS for spidev0.1. I've uploaded a new firmware to this project with this configuration. (plus setting correct config/network and bpf jit on first boot, so this gets done automatically now!)
This log will be evolving when I continue on this.
After getting the ESPNOW - MQTT bridge working, next thing I thought of is adding IR send and receive support to it. This will require a bit of extra hardware, but should be limited to just an IR LED and photoresistor. Initial plan is to attach them to the LED gpios that are already on the QCA9533 board, but let's see how this goes. And it will be added to the aforementioned bridge of course, to make a ESPNOW - MQTT - IR bridge (hub?).
This log is a placeholder for now, until I find these parts in my parts bin.
After getting the more recent OpenWrt 21 running on the repeater, I decided to first try to get some useful functionality out of it. For quite a while I wanted a more hassle free way to get simple data from some sensors into my home automation, and since my favorite microcontroller is the ESP32 an ESPNOW to MQTT bridge was the logical subject.
This turned out to be actually quite straightforward, because there are already many many project that focus on either one of these two, although rarely together. My work is evolving in this repository:
and it is already able to forward all ESPNOW messages it receives to the MQTT broker, in an executable only 20kB in size! That is thanks to the toolchain that is produced when compiling the OpenWrt 21 firmware.
One thing not to forget though is that OpenWrt 21 has a bug in BPF filtering 802.11 monitor mode data, for this to work properly you need to disable BPF JIT:
echo 0 > /proc/sys/net/core/bpf_jit_enable
Or make this survive a reboot:
root@OpenWrt:~# cat /etc/sysctl.conf # Defaults are configured in /etc/sysctl.d/* and can be customized in this file net.core.bpf_jit_enable=0 root@OpenWrt:~#
I'll update this log when I get the other direction running: sending out an MQTT message over ESPNOW.
EDIT: both directions are working now, with the small footnote that it is still capturing its own ESPNOW frames, and pushing them back over MQTT. This is not a deal breaker for me at the moment, but will probably become an issue when the bridge is under stress.
For now, it's running nicely. Keep in mind that the bridge sends out it's ESPNOW frames to the broadcast address, so have that configured as a peer if you want to receive them on your ESP32.
The hardware is not locked down almost at all, just a vanilla install of Lede. You could go through the setup as per the instructions that came with it and then connect over SSH, or you could solder the UART pins that are clearly marked on the pcb and connect to a PC (that's what I did).
The board draws very little power, my USB to UART stick had enough juice on the 5v pin to power it up. It shows the u-boot and Linux boot log over the standard 115200 baud. You can cancel the bootloader and drop in an u-boot shell, or let Lede fully boot and then press Enter to get a root shell.
Now there are two options:
1) Keep the current (perfectly fine) Lede install, and start modifying that. You'll need a 3rd part toolchain if you want to compile code for it, which can be found here:
Don't forget to use static linking (-static), because the C lib will not match. This means 0.5MB extra per application!
2) Compile OpenWrt and update. This will get you a bit newer kernel, but most importantly, a compatible toolchain! Here is a repo specifically for that (you could completely skip 'make menuconfig'):
I've also attached a firmware image made with this code, and the corresponding toolchain in the "Files" section here.
First time flashing this firmware will have to be done via the uboot console (Luci will not accept this sysupgrade.bin as it thinks it's for another device), with instructions here:
setenv ipaddr <make up an ip> setenv serverip <tftp server ip> tftp 0x80060000 openwrt-ath79-generic-embstar-squashfs-sysupgrade.bin erase 0x9f050000 +0x7a0000 cp.b $fileaddr 0x9f050000 0x7a0000 setenv bootcmd "bootm 0x9f050000" saveenv
EDIT: apparently the openwrt 21.02 in the repo has an issue with bpf filters on wireless:
so to make tcpdump capture filters (and bpf filters in your code) work one needs to disable bpf jit:
echo 0 > /proc/sys/net/core/bpf_jit_enable
There are several vendors that sell this type of repeater for very low prices. Here is a list of links where I bought mine, and confirm that they contain the QCA9533 (but that is not a guarantee that yours will!)
https://www.aliexpress.com/item/1005005619754911.html (I've been ordering the EU-whiite variant)
UPDATE: I receiver a total of 6 from above shop now, 5 with QCA9533 and one with QCA9531. The latter is the same as the 33, except it has additional USB and PCIe! Let's see if I can get that broken out, that would open up a whole lot of opportunities, especially the USB.
This is still the cheapest I can find (less than 5 euros including shipping), and seems reliable qua hardware.
Become a member to follow this project and never miss any updates
By using our website and services, you expressly agree to the placement of our performance, functionality, and advertising cookies. Learn More