News and research
Blog
News
Research
Other
Progress report #26
13 November 2024 <- Previous Next ->
ESP-based wireless prototypes
We created RF prototypes iterations 8 and 9, moving from a chip antenna to a pre-certified Espressif ESP-8684-MINI-1 for communication, but still using the RP2040 as main MCU.
These small ESP modules feature a single low-power RISC-V core with a built-in antenna, and we are testing them as a very flexible programmable communication module, with the tradeoff of having to create our own "AT command" firmware from it, and flash it from the main MCU.
We are glad to report that the RP2040<->ESP8684 communication, which is established via high frequency UART, have minimal impact on the latencies tested on the previous progress report (around 1.5 milliseconds), and retains an acceptable power usage (see table below). So it looks like a very viable candidate to move forward. Wireless connectivity was achieved with ESP-NOW 2.4GHz wireless protocol.
Prototype 9 implemented fixes for the ESP integration, and added a front-angled reset button so the controller can be restarted with a bobby pin if necessary. Find the differences:
Dongle case
The plan for the core module is to be reused on different devices, including the wireless dongle. But it would be weird to leave the module exposed and unprotected, so we designed a dongle case, keeping a similar minimalist and low-poly design than the Alpakka case.
While the design is not yet final (missing the pairing button), is pretty usable by now, and we already love it.
End-to-end prototypes
We put together a full controller with the new core modules (one in the controller and another as a dongle), including a 1200 mAh battery. With the purpose of validating the wireless connection, battery life, and overall experience in a real-life environment with:
- Real controller enclosing, antenna being between the PCB and the battery.
- Dongle with enclosing and behind the PC.
- Real living room with other wireless devices around, including plenty of neighbors' internet WLAN.
We tested that connection quality (latency, jitter, range and stability) was on par with the previous results on the ESP-C6 devkits.
Regarding power, we made sure that the inclusion of the ESP8684 was not increasing the consumption too much (old ESP32 were infamous for using a lot of energy). Fortunately new Espressif modules are much better:
Measured power consumption while gaming (250hz rate) | Wired | Wireless |
---|---|---|
RP2040 + IO + IMUs | ~25 mA | ~25 mA |
ESP8684 + antenna | ~70 mA | |
Expected battery life (1200 mAh) | ~12 hours |
On a real full-cycle test, playing Call of Duty BO6 and Deep Rock Galactic, battery discharged from full (4.12v) to almost empty (3.0v) in 10 hours+. Then the controller stopped working without giving a low-battery alert, now that's a problem!.
Why? for context, there are several ways to estimate the remaining battery:
- Measuring the voltage and making an estimation based on the discharge curve.
- Making an estimation based on the time the device was running, and the tasks it was performing.
- Setting a trigger after the voltage goes below some specific threshold.
For simplicity (and to avoid wasting precious analog GPIO pins), we won't measure voltage and we won't know the exact % of battery remaining, but have only a low-battery alert provided by the battery management chip, which triggers at 3.1v.
We originally thought that not using a buck-boost converter was an acceptable approach, since there should be plenty of time between the low-battery alert at 3.1v and the 2.7v cutoff of the RP2040.
The problem is that with the introduction of the ESP8684 (which cutoffs much sooner at 3.0v), in combination with the low-battery alert not being very accurate (anything in the 2.95v ~ 3.25v range), we got effectively no low-battery alert at all.
The solution is "simple", we will add a buck-boost converter in the next prototype iteration, which will convert any voltage coming out from the battery management IC into 3.3v, solving the low-battery problem, and in theory allowing the controller to extract more battery juice all the way down to ~2.5v, also extending the battery life a bit more.
More software optimizations will be done later to extend the battery life, but 10~12 hours seems like a good start for a high performance controller such as the Alpakka.
Overall, we consider these end-to-end prototypes a huge success.
Thanks for the support! 🤍
- Michael and Marcos