The Unfancy Remote | WIP DIY reliable remote

[thunkar]

So, this was fun. Spent last week on a crazy goose chase, tracking down a nasty bug that would cause the receiver to lock up.

After changing the RF code back and forth in a thousand different ways, I mistakenly flashed the RX firmware on the TX…the error was gone.

There was an intermittent internal short on one of the ESP32 C3 boards. Yay.

Great news is that timings are even tighter now after adding an unreasonable amount of tracing:

[thunkar]

Weekly update

• Not be convinced by the current performance
• Read that ExpressLRS goes up to 500Hz in LoRa mode.
• Realize I must be doing something horribly wrong bc I cannot fathom how to get to those numbers
• Instrument the code more to get meaningful metrics
• Spent a week obsessing over microsecond level improvements
• Read more, understand better how LoRa works and where the limits are
• Push said limits, get up to 200Hz
• Dial it back to 100 to improve reliability

• …be happy?

Key takeaways:

• My task scheduler was too naive for the tight timings required. It’s adaptive now and can wiggle task start times around so RX and TX get in sync.
• Most importantly, realized I wasn’t measuring packet jitter properly. It’s great to have low mean packet times, but just like with FPS, 1% lows are more important. This is VASTLY improved now.

[thunkar]

Surfacing the newly gathered TM data to the webapp…

Funnily enough, running the WiFi significantly deteriorates the sensitivity (this was a test at the edge of “good” reception), which makes total sense (2x 2.4GHz antennas blasting each other within mms of distance). Again, WiFi is only for setup/troubleshooting, never to be run while riding.

I think I’m done mucking about. Ready to put this thing on a board and start testing

[thunkar]

Testing has officially started on my new board!

So far so good! Identified a few issues, fortunately quick fixes:

• ADC on the ESP32 is a little bit noisier than I thought. Implemented a very basic filter (take 10 samples, remove highest and lowest values as outliers, take the mean). This takes care of the problem in under 1ms, making the signal nice and smooth!
• RF loop issue that could cause package loss in bursts (essentially it was a lot more likely to miss a high number of packages after a single one had already been lost)
• Dual trigger brake deadband was too narrow, causing the remote to brake slightly under vibrations. Increased based value, but will be configurable soon.

Side note, I recently built a thing for work using the same ESP32 platform (and most of the base scheduler code!) that had to be super user friendly. As part of that, I discovered how to create a website that can flash these things, thanks to the awesome work by the esphome/homeassistant team. This means end users can just build the thing, go to a website and flash their remote, no vscode/platformio/github shenanigans. Will probably make a basic landing page for this just for fun and convenience