Adafruit ESP32 Feathers with RadioLib

[Velocet]

Describe you new feature you'd like

There are two suggestions i see when i look at this amazing project:

• Size constrains (cause you are always complaining about it)
  • You can advice the compiler to optimize for size but you need ESP-IDF to do it: How to modify an sdkconfig option in Arduino?
  • CONFIG_COMPILER_OPTIMIZATION
  • I don't see any reason to not target ESP32 boards with more RAM?
• CC1101 only
  • Why not use RadioLib for RF abstraction so different radios could be used?
  • I would target Adafruit ESP32 Feather boards with 2MB PSRAM. They are readily available, could be combined with a 433MHz Featherwing and some are even solderless. Sadly none of the newer SX1262 based LoRa32 boards has ASK support (only FSK).

[rstrouse]

Yeah I had no idea when I started this that I would run into this limit. I coded around the idea that I had limited stack and RAM without ever expecting to hit a code segment limit. I have built for the 8Mb flash S3 variants that completely eliminates the code segment issues but it eliminates all of the 4Mb boards out there as the partition tables in the firmware need to be manipulated.

Support-wise I get at least one a week where the wrong onboard files are selected so I am not so sure I want to head down a path with more variants and then I get into multiple builds. Even then only some features would be available on some boards.

Originally, I tried using the 64bit buffers of the CC1101 to detect protocol but that turned out to drop frames because either the wakeup and preamble are varied in length or because I just didn't understand the register settings on the CC1101. I regret not writing my own abstraction now that I have a better understanding of the ESP32 interrupts. Given our OOK nature of this there is economy in bit-banging the pulse counts.

I am looking at what the next major might look like on v5 of the idf since I think there is a memory leak in idf v4 that causes the PHY to crash. I think it is related to half-open sockets that are triggered by some event on the network where the board can go for weeks without issue then suddenly run into it. I don't know if it is related but 11b negotiation can also cause some issues.

That being said, I may abandon Arduino altogether and head down a straight idf route. I didn't go there initially because I could not figure out the Littlefs support. It looks like that has been ironed out and the Arduino libraries appear to be lagging.

[Velocet]

Thanks for clarification. There are way more low end boards out there as one would believe...

AFAIK all Somfy implementations bitbang the data out directly. Even the radios for io-homecontrol are used that way: They pump the uart data straight into the radio (+ clock signal) with minimal configuration. Try to add 1 byte of the preamble to the SyncWord! This should yield better results.
Have you tried SmartRF from TI for configuring the C1101?

Have you had a look at some of the sdkconfig.defaults settings? There is so much stuff to tweak .. this should def help. One other way around is to use ESP-IDF as a base and only import Arduino.h if needed.
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-guides/performance/ram-usage.html

[rstrouse]

I messed around with SmartRF but that really requires you to start with an analyzer. The problem with the preamble on the protocol is that it varies in length when you are trying to receive. This means that from the first to the last beat you need to count them to determine the meaning of the frame. There is a different length depending on whether it is 56 or 80 bit as well as when a repeat is sent. These conditions need to be captured. When I tried to use the internal buffers for receive it missed many of the frames. When I get some time I may go back to revisit the 64byte buffer in the CC1101 for receive. On the transmit I don't think it matters.

I am not having memory constraints heap, stack, or local with the code, My limits are due to code space storage on the device.

[Velocet]

You should have a look at ESPhome, HomeSpan or ExpressLR. They have some nice options in place regarding code size and such. Combined with some sdkdefault tweaks this should help you.

Would be interesting to sniff the SPI traffic between the MCU and radio from a Somfy remote to see how the radio is set up in the first place. At least for io-homecontrol this helped a lot to clarify things.

One thing that comes to mind: The RTX firmware has the RF setup in it. I will try to extract this config for you. Just gimme some time.

[Velocet]

I found the correct part in the firmware. Just need to annotate everything so you can map the registers and make sense of it.

In the meantime you can have a look at this SX1243 linux driver from Somfy: Somfy-RTS-KernelModule-4.14.223

Here is some decompiled LUAjit code from a TaHoma box:

• RTW-utils.lua)
• rtds-utils.lua

There are files missing for RTx. I will try to to find them inside my big messy pile of files 🤪