Fix typos and mistakes

content/en/posts/the-supersensor-2.0/index.md

@@ -9,7 +9,7 @@ tags:
 
 ## Keep Iterating
 
-Well over a year ago I created [the SuperSensor all=in-one presence and voice control sensor](/posts/the-supersensor), marking the final evolution of my desire for a voice control satellite and environment/presence sensor. However, I had a lot of fights with that original revision over it's first year of operation, enough so that I decided to iterate on it. Introducing SuperSensor 2.0, new and improved, which I've now been running for a few months and am happy to share.
+Well over a year ago I created [the SuperSensor all-in-one presence and voice control sensor](/posts/the-supersensor), marking the final evolution of my desire for a voice control satellite and environment/presence sensor. However, I had a lot of fights with that original revision over it's first year of operation, enough so that I decided to iterate on it. Introducing SuperSensor 2.0, new and improved, which I've now been running for a few months and am happy to share.
 
 ## The Key Changes
 
@@ -19,11 +19,11 @@ There are 4 key changes from the SuperSensor 1.x to the 2.x:
 
 The original Supersensor design leveraged the Bosch BME680 sensor to provide temperature, humidity, atmospheric pressure, and air quality reporting. At the time, this seemed like the perfect sensor for an all-in-one device, letting us truly monitor the environment in all aspects.
 
-Unfortunately, this sensor ended up being a complete flop, and doing more research post-mortem, I found I was not alone. The main issue with this sensor was its IAQ functionality, the reason I went with the 680 over the 280. When using the official Bosch libraries with the non-IDF (Arduino) ESP framework, the VOC sensor would seem to work fine for days or even weeks at a time. However as it was left running, the IAQ value would creep up and up as the sensor continuously "recalibrated" itself to the current environment, eventually reporting IAQ values of 500+ with no basis in reality. I originally speculated that this had something to do with the wildfire smoke last summer, but even over the winter the problem persisted. I ended up spending most of last summer, and several weeks this spring, tweaking and tweaking this sensor trying to get it to function properly, including a very long but ill-fated attempt to do custom IAQ calculations, first on my own and then with AI assistance. But even with all that, ultimately this part of the sensor proved to be utterly usless.
+Unfortunately, this sensor ended up being a complete flop, and doing more research post-mortem, I found I was not alone. The main issue with this sensor was its IAQ functionality, the reason I went with the 680 over the 280. When using the official Bosch libraries with the non-IDF (Arduino) ESP framework, the VOC sensor would seem to work fine for days or even weeks at a time. However as it was left running, the IAQ value would creep up and up as the sensor continuously "re-calibrated" itself to the current environment, eventually reporting IAQ values of 500+ with no basis in reality. I originally speculated that this had something to do with the wildfire smoke last summer, but even over the winter the problem persisted. I ended up spending most of last summer, and several weeks this spring, tweaking and tweaking this sensor trying to get it to function properly, including a very long but ill-fated attempt to do custom IAQ calculations, first on my own and then with AI assistance. But even with all that, ultimately this part of the sensor proved to be utterly useless.
 
 Air quality is something I care a lot about as an asthmatic with allergies, so I really wanted something that would work well in that regard. Thus, after more research, I settled on the Sensirion SGPXX line of air quality sensors. I initially started by testing the SGP30, but unfortunately the quality control of these sensors from AliExpress is utterly abysmal, and out of over 20 purchased, only ~10 worked anywhere close to reliably, and even those 10 I could not truly trust (are they reporting 0 VOC because there *is* 0 VOC, or because they borked again? Who knows!). I then moved to the SGP41, which is used in several actual commercial products such as the AirGradient One, and thus provides a more reliable experience, including open-source algorithms for calculating VOC concentrations and the ability to leverage the aforementioned product as a reference for calculating other values from the sensor. Overall this has been a very positive change, and I've found the values these sensors report both consistent and sensible, a winning combination in my book.
 
-To make things even more compact, I also moved to the Sensirion SHT4x line of temperature/humidity sensors, specifically the SHT45 which is the most accurate one available. While I could have stuck with the Bosch BME280 line, I ultimately found that atmospheric pressure wasn't all that useful on a room-by-room basis (and because I got a proper Ecowitt weather station for that instead), and I found that actually finding BM*E*280's versus BMP280's was incredibly hard due to constant mislabling on Aliexpress, Amazon, and elsewhere. Using two GY-form-factor sensors also let me make a much more compact sensor as mentioned below.
+To make things even more compact, I also moved to the Sensirion SHT4x line of temperature/humidity sensors, specifically the SHT45 which is the most accurate one available. While I could have stuck with the Bosch BME280 line, I ultimately found that atmospheric pressure wasn't all that useful on a room-by-room basis (and because I got a proper Ecowitt weather station for that instead), and I found that actually finding BM*E*280's versus BMP280's was incredibly hard due to constant mislabelling on AliExpress, Amazon, and elsewhere. Using two GY-form-factor sensors also let me make a much more compact sensor as mentioned below.
 
 I was actually so happy with these sensors that I even went so far as to design a "micro" air quality sensor using just the SGP41 and SHT45, along with an ESP32-C3, for use in other places like my 3D printer exhaust filter and my server rack.
 
@@ -41,9 +41,9 @@ With the updated sensor list, I redesigned the PCB from scratch. This let me opt
 
 ### Code Improvements
 
-I've made several fairly major revisions to the SuperSensor over the last year on the ESPHome code side. Mostly, this has involved tweaking the voice handling functionality and fixing quirks and bugs when the units restart and connect to Home Assistant. I've also changed the framework back and forth a few times, but have finally settled on ESP-IDF for the final v2.0 release. IDF simply performs a lot better, keeps the ESP cooler, and provides more flexibility. We've also been able to benefit from multiple improvements in ESPHome, such as MicroWakeWord, which have signifiantly improved voice performance and reliability.
+I've made several fairly major revisions to the SuperSensor over the last year on the ESPHome code side. Mostly, this has involved tweaking the voice handling functionality and fixing quirks and bugs when the units restart and connect to Home Assistant. I've also changed the framework back and forth a few times, but have finally settled on ESP-IDF for the final v2.0 release. IDF simply performs a lot better, keeps the ESP cooler, and provides more flexibility. We've also been able to benefit from multiple improvements in ESPHome, such as MicroWakeWord, which have significantly improved voice performance and reliability.
 
-The updated ESPHome code is [available over on GitHub in a new repository](https://github.com/joshuaboniface/supersensor2) to keep it separate from the 1.x code. The old 1.x code is now deprecated and I will not be updating it futher, with all enhancements now on the 2.x version.
+The updated ESPHome code is [available over on GitHub in a new repository](https://github.com/joshuaboniface/supersensor2) to keep it separate from the 1.x code. The old 1.x code is now deprecated and I will not be updating it further, with all enhancements now on the 2.x version.
 
 ## Updated Parts List for v2.0 (Prices as of May 2025)
 
@@ -72,7 +72,7 @@ Overall, the cost is about $2 more than the original SuperSensor, despite the se
 
 ## Layout, Assembly, and Final Product
 
-One noteworthy change to the assembly of the SuperSensor 2.x is that for this version, I'm socketing every part on every sensor. My initial testing batch did feature soldered components on the front like with the Supersensor 1.x, but between desoldering parts on those original boards, and then desoldering some *again* during the R&D phases, I found it far easier to just socket everything going forward. This adds a negligible amount to the parts list but provides a lot of convenience if I need to swap a defective component or make a change (for instance from the SGP30 to the SGP41).
+One noteworthy change to the assembly of the SuperSensor 2.x is that for this version, I'm socketing every part on every sensor. My initial testing batch did feature soldered components on the front like with the Supersensor 1.x, but between de-soldering parts on those original boards, and then de-soldering some *again* during the R&D phases, I found it far easier to just socket everything going forward. This adds a negligible amount to the parts list but provides a lot of convenience if I need to swap a defective component or make a change (for instance from the SGP30 to the SGP41).
 
 And now for the pictures!
 
@@ -80,7 +80,7 @@ Here's an overall shot showing both a completed unit and the breakout of all the
 
 ![Parts](parts.jpg)
 
-Here is the blank PCB, from both the front and back. The board does reference the SGP30, despite be now using the SGP41, but these modules have the same pinout and form factor. The design on my GitHub uses a more generic `SGPXX`/`SHTXX` labeling.
+Here is the blank PCB, from both the front and back. The board does reference the SGP30, despite be now using the SGP41, but these modules have the same pin-out and form factor. The design on my GitHub uses a more generic `SGPXX`/`SHTXX` labelling.
 
 ![Blank PCB Front & Back](pcb.jpg)
 
@@ -108,11 +108,11 @@ But other elements are used in various automations, templates, and other places
 
 ## What's Next?
 
-So far I've been very happy with v2.0, and I've made a total of 15: 9 to replace all of my existing sensors, and 6 more as spares or to place in other areas of my house (I haven't, but I might). I was able to desolder and transfer most of the existing sensor modules to avoid waste, and the socketed ESP32s made swapping those a breeze.
+So far I've been very happy with v2.0, and I've made a total of 15: 9 to replace all of my existing sensors, and 6 more as spares or to place in other areas of my house (I haven't, but I might). I was able to de-solder and transfer most of the existing sensor modules to avoid waste, and the socketed ESP32s made swapping those a breeze.
 
 What does the future hold? One thing I'd love to do is make this even more compact by including all the individual components onto the PCB as SMD, avoiding needing through-pin modules. This would make things much more compact and sleek. Perhaps this will be v3.0, but only time will tell!
 
-I've also been constantly contempating a case for the Supersensor, but ultimately 3D modeling has not been something I've been particularly interested in. I personally like the bare-PCB look, especially with the black PCB and variously-coloured sensor modules, and while I think a case would be possible, the effort required to properly measure and design it is beyond my modelling skills. If someone would like to contribute one I'd love to see it - my vision has always been for a black cover with holes for the sensor inlets, and then a clear bar along the bottom over the LEDs and microphone to create a light-bar effect. Maybe I'll actually get around to it at some point eventually, but for now I haven't.
+I've also been constantly contemplating a case for the Supersensor, but ultimately 3D modelling has not been something I've been particularly interested in. I personally like the bare-PCB look, especially with the black PCB and variously-coloured sensor modules, and while I think a case would be possible, the effort required to properly measure and design it is beyond my modelling skills. If someone would like to contribute one I'd love to see it - my vision has always been for a black cover with holes for the sensor inlets, and then a clear bar along the bottom over the LEDs and microphone to create a light-bar effect. Maybe I'll actually get around to it at some point eventually, but for now I haven't.
 
 Happy sensing!