Fixes

src/pug/blog/report_26.pug

@@ -12,7 +12,7 @@ block content
 
   p These small ESP modules feature a #[em 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.
 
-  p We are glad to report that the  #[em 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.
+  p We are glad to report that the  #[em 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 #[+ax('https://www.espressif.com/en/solutions/low-power-solutions/esp-now') ESP-NOW] 2.4GHz wireless protocol.
 
   p 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:
 
@@ -31,7 +31,7 @@ block content
 
 
   h3 Dongle case
-  p The plan for the #[em 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 the minimalist and low-poly design as the Alpakka itself.
+  p The plan for the #[em 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.
   p While the design is not yet final (missing the pairing button), is pretty usable by now, and we already love it.
 
   +figure(
@@ -69,9 +69,9 @@ block content
     'medium inline',
   )
 
-  p We tested that connection quality (latency, jitter, range and stability) was on par with the previous results on the ESP-C6 devkits. Wireless connectivity was achieved with #[+ax('https://www.espressif.com/en/solutions/low-power-solutions/esp-now') ESP-NOW] 2.4GHz wireless protocol.
+  p We tested that connection quality (latency, jitter, range and stability) was on par with the previous results on the ESP-C6 devkits.
 
-  p Regarding power, we made sure that the inclusion of the #[em ESP8684] wasn't raising the consumption too much (old ESP32 were infamous for using a lot of energy). Fortunately new Espressif modules are much better:
+  p Regarding power, we made sure that the inclusion of the #[em 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:
 
   p: b
   table.inline.mono
@@ -103,21 +103,21 @@ block content
 
   p Why? for context, there are several ways to estimate the remaining battery:
   ul
-    li Measuring the voltage and make a calculation based on the discharge curve.
-    li Deducting the amount of energy based on the time the device has been running, keeping track of what it was doing.
+    li Measuring the voltage and making an estimation based on the discharge curve.
+    li Making an estimation based on the time the device was running, and the tasks it was performing.
     li Setting a trigger after the voltage goes below some specific threshold.
 
-  p 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 #[em low-battery alert] provided by the battery management chip, which triggers at #[em 3.2v].
+  p 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 #[em low-battery alert] provided by the battery management chip, which triggers at #[em 3.1v].
 
-  p 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 #[em 3.2v] and the #[em 2.7v] cutoff of the RP2040.
+  p 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 #[em 3.1v] and the #[em 2.7v] cutoff of the RP2040.
 
-  p The problem is that with the introduction of the #[em ESP8684] (which cutoffs much sooner at #[em 3.0v]), in combination with the low-battery alert not being very precise (anything in the #[em 2.95v ~ 3.25v] range), we got effectively no low-battery alert at all.
+  p The problem is that with the introduction of the #[em ESP8684] (which cutoffs much sooner at #[em 3.0v]), in combination with the low-battery alert not being very accurate (anything in the #[em 2.95v ~ 3.25v] range), we got effectively no low-battery alert at all.
 
-  p 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 #[em ~2.5v], potentially extending the battery life a couple of hours.
+  p 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 #[em ~2.5v], also extending the battery life a bit more.
 
   p More software #[em 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.
 
-  p Overall, we consider these end-to-end prototypes and huge success.
+  p Overall, we consider these end-to-end prototypes a huge success.
 
   hr
   p Thanks for the support! 🤍 <br>- Michael and Marcos