Rocket Engine Measurement System: From Concept to MVP
A comprehensive approach to designing electronics, software, and UI for demanding tests.
Client
Mil-Tech rocketry startup
Services
Hardware Engineering
Embedded Development
Design Engineering
Product Design
Industries
Mil-Tech
Rocketry
Date
Oct 2024
Project Overview
As an Hardware & Design Engineer, I've architected and build an MVP of a user-friendly and easy to scale system to measure rocket engines characteristics in high-resolution. From System-Level Thinking to Hands-on Engineering & Prototyping.
About Product
Self-guided anti-aircraft missile.
Self-guided anti-aircraft missile.
About Client
Unnamed Mil-Tech rocketry startup.
Unnamed Mil-Tech rocketry startup.
Problems & Goals
Problem Statement
The business needed to finalize the design of their high-performance rocket engine but lacked high-resolution, high-frequency measurement systems to do it properly.
Project Goal
Architect and build a fast, easy, and effective way to measure and collect thrust characteristics of the engines to enable continuous improvements across rocket iterations. Solution needs to be:
Easy to scale in future;
Easy to use with existing equipment by low-skilled personnel;
Reasonable development, operation, and maintenance costs;
Easily accessible (market availablity) parts;
Power independent, wireless, offline-use.
Solution
The ADS1256 unit serves as the main ADC, measuring up to 4 differential channels, controlled by a single ESP32 unit that runs two tasks simultaneously via RTOS. The first task operates a Wi-Fi AP and webserver that handles private network requests from the client PWA app to control the measurement system. The second task manages the measurement process, data filtering, and high-speed data recording to the connected SD card.
Electronics
Low-cost, minimalistic electronics built with components that have strong community support and high market availability to keep maintenance and future development simple and affordable. The system operates wirelessly on battery power with USB-C recharging capability, making it easy to work with.
Software
The PWA-based front-end client makes it easy to access, distribute, and update the app while keeping it private and providing offline usability to handle poor connection quality or complete absence of connectivity.
The C++ back-end code is developed using the widely popular and well-supported Arduino IDE, primarily relying on native libraries. An RTOS (Real-Time Operating System) is employed to ensure minimal execution latency for web server and measurement tasks.
// Meassurement RTOS task creation BaseType_t measureTaskStatus = xTaskCreate(taskMeasure_func, "taskMeasure", 32768, nullptr, 1, &taskMeasure); if (measureTaskStatus == pdPASS) { Serial.println("[==== ] Задача вимірювання запущена"); } else { Serial.println("Failed to create Measure task. Restarting..."); esp_restart(); // Перезапуск ESP32 } // Web-server RTOS task creation BaseType_t webTaskStatus = xTaskCreate(taskWeb_func, "taskWeb", 16384, nullptr, 0, &taskWeb); if (webTaskStatus == pdPASS) { Serial.println("[======== ] Веб-задача запущена"); } else { Serial.println("Failed to create Web task. Restarting..."); esp_restart(); // Перезапуск ESP32 }
UX/UI
The design follows AAA-compliant WCAG standards, ensuring an accessible, mobile-first UI for operating the test stand and wirelessly monitoring measurement data from a safe location. A basic UI kit has also been established to enhance scalability and facilitate the addition of new features in the future.
Casing
The MVP-stage casing is fully 3D-printed to securely house the electronics, ensuring protection and safety. It includes additional features such as a built-in tripod mount hole for ease of use and a sliding lid to simplify future development and debugging processes.
My approach
From System-Level Thinking to Hands-on Engineering & Prototyping.
I was solely responsible for the Electronics, Software, and UI/UX, which made the development process more challenging but allowed for a more cohesive and well-architected solution.
From a Product Designer’s perspective, I began by aligning business goals with user needs. Understanding the Customer Journey Map (CJM) and User Flow enabled me to define key product features, which in turn guided the selection of the hardware and software stack required to deliver the desired user experience. I prioritized affordability and simplicity, carefully eliminating unnecessary components while maintaining essential functionality.
Key Challenges & Design Decisions
Initial Solution Architecture & Product Design
Initially, I planned to store the web app on the MCU, but transferring it to the client proved too time-consuming, especially for larger websites. This approach was also inefficient for app update cycles, as I had to re-flash the MCU every time I modified the frontend. Additionally, using chart libraries like Chart.js locally required significant storage space. Ultimately, I decided to host the web app as a Progressive Web App (PWA), making it publicly accessible with the option to install it on a device for offline use.
After discussions with researchers and analyzing the Customer Journey Map (CJM) and User Flow, I identified that the test stand would be used with multiple rocket engines to determine optimal characteristics. This necessitated differentiating data from various engines. I designed a feature allowing users to input engine and propellant data before testing, along with the ability to add post-study notes, all recorded in the same file as the measurement data.
Working closely with the Design Engineer, I gained a deeper understanding of the test stand's functionality, safety measures, and typical operating environments. This insight guided my focus on delivering an AAA-compliant WCAG design to ensure maximum accessibility across diverse environments. To enhance safety, I introduced system feedback messages at the UI level, along with audio and visual feedback at the hardware level.
Finally, to safeguard recorded data and ensure usability, I added recording rate and web refresh rate indicators to the UI. This feature keeps users informed about actual latency, helping them make informed decisions before proceeding with tests or starting the engine.
Hardware Debugging
Originally, I used the Arduino UNO R3 Wi-Fi for this project, but its limited memory and underpowered CPU made it unsuitable for running multiple heavy RTOS tasks efficiently. I switched to the ESP32-Wroom-32U, which features a significantly more powerful CPU, larger memory, native Wi-Fi support, and a robust community for troubleshooting and development.
This project requires a sample rate of 200 Hz. However, the initially used HX711 could only achieve up to 80 samples per second, which was insufficient. To meet the requirement, I replaced it with the ADS1256, an ADC capable of sampling at up to 30,000 samples per second, ensuring the necessary performance.
During multiple failed attempts to configure the ADS1256 to work correctly with the YZC-516 load cell (purchased from Aliexpress), I initially suspected the ADC itself as the issue. The ADS1256 is not widely used, has many Chinese board variations, and lacks a wide range of well-documented libraries. However, after extensive debugging, I discovered the issue was with the load cell, not the ADC.
The root cause turned out to be conflicting specification information for the load cell. The Aliexpress product page specified an excitation voltage of 10–15V, while the datasheet included with the package listed it as 5–10V. Additionally, the datasheet referenced a different model name, leading me to believe it was mistakenly included by the seller. On other websites, the YZC-516's excitation voltage was specified as 9–12V.
To resolve this, I initially averaged the values and worked with a 10–12V excitation voltage. After spending significant time debugging the ADS1256, I eventually discovered through experimentation that the load cell required a 5V excitation voltage. Switching to 5V resolved all issues with the ADC and allowed the system to function correctly.
Server & Client Communication
While working closely with the front-end developer, we discovered challenges in setting up communication between an HTTP server in a private network and an HTTPS public resource. These issues resulted in browser errors like CORS violations and mixed-content restrictions. I researched potential solutions to address these problems.
The ESP32 lacks robust libraries for running HTTPS servers, and such servers demand significantly more resources than the ESP32 can easily handle. Consequently, I decided to stick with an HTTP server for now. Another option was to configure a mini DNS server on the ESP32 within the private network to trick the browser into recognizing it as a secure website. However, after initial exploration, I realized this approach would require considerable time to implement.
For the MVP stage, we opted for a simpler solution by adjusting the chrome://flags settings, allowing the PWA to run seamlessly during development and testing.
Low Latency Measure & Record
I successfully achieved high speed and low noise for both measurement and recording rates. Since the ADS1256 and SD card both utilize the SPI bus, I designed a solution that sequentially communicates with each SPI device on the same bus. By optimizing the process to switch between devices quickly, I managed to achieve a sampling rate of one sample every 5ms with a fallibility of ±100g.
One key optimization for the SD card recording task was the implementation of incremental flushing to the SD card. By writing data in batches of 5000 samples, I enabled recording rates faster than 1ms, significantly improving efficiency.
if (logFile) { //...// if (samples % 5000 == 0) { // Злив даних на SD-карту logFile.flush(); } //...// }
Given the multiple tasks running on the RTOS, both requiring access to the SPI bus, I introduced a bool variable (spiFree) to monitor the availability of the SPI bus. This approach prevented potential development errors caused by concurrent access to the SPI.
To address the significant noise produced by the highly sensitive ADS1256, I implemented a digital median filter using eight samples. While this slightly reduced the final sample rate to 5ms, it greatly improved the clarity and accuracy of the results.
In-Field Usage & Debugging Friendly 3D-Printed Case
I used Autodesk Fusion 360 to design a compact casing for the electronics, ensuring protection from environmental factors while allowing for adjustments and repairs on the go—an essential feature for the initial testing phase of this setup. To enhance usability, I incorporated a built-in tripod mount, eliminating the need for users to bring a separate mounting solution.
Summary Outcome
Results
The MVP was successfully completed, tested, and approved by the research team.
The first rocket engine tests utilizing this measurement system are scheduled for the end of January 2025. The team has plans to use the system for multiple rocket engine tests throughout the year.
Learnings
Be more diligent when reviewing specifications for components purchased on platforms like Aliexpress;
Pay closer attention to the selection of components, as some (e.g., the ADS1256) were more challenging to implement than anticipated;
Be mindful of Progressive Web App (PWA) requirements, including HTTPS, mixed content issues, and the hardware capabilities needed for server-side operations.
Rocket Engine Measurement System: From Concept to MVP
A comprehensive approach to designing electronics, software, and UI for demanding tests.
Client
Mil-Tech rocketry startup
Services
Hardware Engineering
Embedded Development
Design Engineering
Product Design
Industries
Mil-Tech
Rocketry
Date
Oct 2024
Through extensive user research, we discovered that many e-bike users felt overwhelmed by the technology and controls on their bikes. To address this, we created a simple and intuitive interface that allows riders to easily adjust their level of assist and monitor their battery life. We also incorporated GPS navigation, allowing riders to plan their route and track their progress.
Through extensive user research, we discovered that many e-bike users felt overwhelmed by the technology and controls on their bikes. To address this, we created a simple and intuitive interface that allows riders to easily adjust their level of assist and monitor their battery life. We also incorporated GPS navigation, allowing riders to plan their route and track their progress.
Project Overview
As an Hardware & Design Engineer, I've architected and build an MVP of a user-friendly and easy to scale system to measure rocket engines characteristics in high-resolution. From System-Level Thinking to Hands-on Engineering & Prototyping.
About Product
Self-guided anti-aircraft missile.
Self-guided anti-aircraft missile.
About Client
Unnamed Mil-Tech rocketry startup.
Unnamed Mil-Tech rocketry startup.
Problems & Goals
Problem Statement
The business needed to finalize the design of their high-performance rocket engine but lacked high-resolution, high-frequency measurement systems to do it properly.
Project Goal
Architect and build a fast, easy, and effective way to measure and collect thrust characteristics of the engines to enable continuous improvements across rocket iterations. Solution needs to be:
Easy to scale in future;
Easy to use with existing equipment by low-skilled personnel;
Reasonable development, operation, and maintenance costs;
Easily accessible (market availablity) parts;
Power independent, wireless, offline-use.
Solution
The ADS1256 unit serves as the main ADC, measuring up to 4 differential channels, controlled by a single ESP32 unit that runs two tasks simultaneously via RTOS. The first task operates a Wi-Fi AP and webserver that handles private network requests from the client PWA app to control the measurement system. The second task manages the measurement process, data filtering, and high-speed data recording to the connected SD card.
Electronics
Low-cost, minimalistic electronics built with components that have strong community support and high market availability to keep maintenance and future development simple and affordable. The system operates wirelessly on battery power with USB-C recharging capability, making it easy to work with.
Software
The PWA-based front-end client makes it easy to access, distribute, and update the app while keeping it private and providing offline usability to handle poor connection quality or complete absence of connectivity.
UX/UI
The design follows AAA-compliant WCAG standards, ensuring an accessible, mobile-first UI for operating the test stand and wirelessly monitoring measurement data from a safe location. A basic UI kit has also been established to enhance scalability and facilitate the addition of new features in the future.
The C++ back-end code is developed using the widely popular and well-supported Arduino IDE, primarily relying on native libraries. An RTOS (Real-Time Operating System) is employed to ensure minimal execution latency for web server and measurement tasks.
// Meassurement RTOS task creation BaseType_t measureTaskStatus = xTaskCreate(taskMeasure_func, "taskMeasure", 32768, nullptr, 1, &taskMeasure); if (measureTaskStatus == pdPASS) { Serial.println("[==== ] Задача вимірювання запущена"); } else { Serial.println("Failed to create Measure task. Restarting..."); esp_restart(); // Перезапуск ESP32 } // Web-server RTOS task creation BaseType_t webTaskStatus = xTaskCreate(taskWeb_func, "taskWeb", 16384, nullptr, 0, &taskWeb); if (webTaskStatus == pdPASS) { Serial.println("[======== ] Веб-задача запущена"); } else { Serial.println("Failed to create Web task. Restarting..."); esp_restart(); // Перезапуск ESP32 }
Casing
The MVP-stage casing is fully 3D-printed to securely house the electronics, ensuring protection and safety. It includes additional features such as a built-in tripod mount hole for ease of use and a sliding lid to simplify future development and debugging processes.
My approach
I was solely responsible for the Electronics, Software, and UI/UX, which made the development process more challenging but allowed for a more cohesive and well-architected solution.
From System-Level Thinking to Hands-on Engineering & Prototyping.
From a Product Designer’s perspective, I began by aligning business goals with user needs. Understanding the Customer Journey Map (CJM) and User Flow enabled me to define key product features, which in turn guided the selection of the hardware and software stack required to deliver the desired user experience. I prioritized affordability and simplicity, carefully eliminating unnecessary components while maintaining essential functionality.
Key Challenges & Design Decisions
Initial Solution Architecture & Product Design
Initially, I planned to store the web app on the MCU, but transferring it to the client proved too time-consuming, especially for larger websites. This approach was also inefficient for app update cycles, as I had to re-flash the MCU every time I modified the frontend. Additionally, using chart libraries like Chart.js locally required significant storage space. Ultimately, I decided to host the web app as a Progressive Web App (PWA), making it publicly accessible with the option to install it on a device for offline use.
After discussions with researchers and analyzing the Customer Journey Map (CJM) and User Flow, I identified that the test stand would be used with multiple rocket engines to determine optimal characteristics. This necessitated differentiating data from various engines. I designed a feature allowing users to input engine and propellant data before testing, along with the ability to add post-study notes, all recorded in the same file as the measurement data.
Working closely with the Design Engineer, I gained a deeper understanding of the test stand's functionality, safety measures, and typical operating environments. This insight guided my focus on delivering an AAA-compliant WCAG design to ensure maximum accessibility across diverse environments. To enhance safety, I introduced system feedback messages at the UI level, along with audio and visual feedback at the hardware level.
Finally, to safeguard recorded data and ensure usability, I added recording rate and web refresh rate indicators to the UI. This feature keeps users informed about actual latency, helping them make informed decisions before proceeding with tests or starting the engine.
Hardware Debugging
Originally, I used the Arduino UNO R3 Wi-Fi for this project, but its limited memory and underpowered CPU made it unsuitable for running multiple heavy RTOS tasks efficiently. I switched to the ESP32-Wroom-32U, which features a significantly more powerful CPU, larger memory, native Wi-Fi support, and a robust community for troubleshooting and development.
This project requires a sample rate of 200 Hz. However, the initially used HX711 could only achieve up to 80 samples per second, which was insufficient. To meet the requirement, I replaced it with the ADS1256, an ADC capable of sampling at up to 30,000 samples per second, ensuring the necessary performance.
During multiple failed attempts to configure the ADS1256 to work correctly with the YZC-516 load cell (purchased from Aliexpress), I initially suspected the ADC itself as the issue. The ADS1256 is not widely used, has many Chinese board variations, and lacks a wide range of well-documented libraries. However, after extensive debugging, I discovered the issue was with the load cell, not the ADC.
Server & Client Communication
While working closely with the front-end developer, we discovered challenges in setting up communication between an HTTP server in a private network and an HTTPS public resource. These issues resulted in browser errors like CORS violations and mixed-content restrictions. I researched potential solutions to address these problems.
The root cause turned out to be conflicting specification information for the load cell. The Aliexpress product page specified an excitation voltage of 10–15V, while the datasheet included with the package listed it as 5–10V. Additionally, the datasheet referenced a different model name, leading me to believe it was mistakenly included by the seller. On other websites, the YZC-516's excitation voltage was specified as 9–12V.
To resolve this, I initially averaged the values and worked with a 10–12V excitation voltage. After spending significant time debugging the ADS1256, I eventually discovered through experimentation that the load cell required a 5V excitation voltage. Switching to 5V resolved all issues with the ADC and allowed the system to function correctly.
The ESP32 lacks robust libraries for running HTTPS servers, and such servers demand significantly more resources than the ESP32 can easily handle. Consequently, I decided to stick with an HTTP server for now. Another option was to configure a mini DNS server on the ESP32 within the private network to trick the browser into recognizing it as a secure website. However, after initial exploration, I realized this approach would require considerable time to implement.
For the MVP stage, we opted for a simpler solution by adjusting the chrome://flags settings, allowing the PWA to run seamlessly during development and testing.
Low Latency Measure & Record
I successfully achieved high speed and low noise for both measurement and recording rates. Since the ADS1256 and SD card both utilize the SPI bus, I designed a solution that sequentially communicates with each SPI device on the same bus. By optimizing the process to switch between devices quickly, I managed to achieve a sampling rate of one sample every 5ms with a fallibility of ±100g.
In-Field Usage & Debugging Friendly 3D-Printed Case
I used Autodesk Fusion 360 to design a compact casing for the electronics, ensuring protection from environmental factors while allowing for adjustments and repairs on the go—an essential feature for the initial testing phase of this setup. To enhance usability, I incorporated a built-in tripod mount, eliminating the need for users to bring a separate mounting solution.
One key optimization for the SD card recording task was the implementation of incremental flushing to the SD card. By writing data in batches of 5000 samples, I enabled recording rates faster than 1ms, significantly improving efficiency.
Summary Outcome
Results
The MVP was successfully completed, tested, and approved by the research team.
The first rocket engine tests utilizing this measurement system are scheduled for the end of January 2025. The team has plans to use the system for multiple rocket engine tests throughout the year.
Learnings
Be more diligent when reviewing specifications for components purchased on platforms like Aliexpress;
Pay closer attention to the selection of components, as some (e.g., the ADS1256) were more challenging to implement than anticipated;
Be mindful of Progressive Web App (PWA) requirements, including HTTPS, mixed content issues, and the hardware capabilities needed for server-side operations.
if (logFile) { //...// if (samples % 5000 == 0) { // Злив даних на SD-карту logFile.flush(); } //...// }
Given the multiple tasks running on the RTOS, both requiring access to the SPI bus, I introduced a bool variable (spiFree) to monitor the availability of the SPI bus. This approach prevented potential development errors caused by concurrent access to the SPI.
To address the significant noise produced by the highly sensitive ADS1256, I implemented a digital median filter using eight samples. While this slightly reduced the final sample rate to 5ms, it greatly improved the clarity and accuracy of the results.
Rocket Engine Measurement System: From Concept to MVP
A comprehensive approach to designing electronics, software, and UI for demanding tests.
Client
Mil-Tech rocketry startup
Services
Hardware Engineering
Embedded Development
Design Engineering
Product Design
Industries
Mil-Tech
Rocketry
Date
Oct 2024
Through extensive user research, we discovered that many e-bike users felt overwhelmed by the technology and controls on their bikes. To address this, we created a simple and intuitive interface that allows riders to easily adjust their level of assist and monitor their battery life. We also incorporated GPS navigation, allowing riders to plan their route and track their progress.
Through extensive user research, we discovered that many e-bike users felt overwhelmed by the technology and controls on their bikes. To address this, we created a simple and intuitive interface that allows riders to easily adjust their level of assist and monitor their battery life. We also incorporated GPS navigation, allowing riders to plan their route and track their progress.
Project Overview
As an Hardware & Design Engineer, I've architected and build an MVP of a user-friendly and easy to scale system to measure rocket engines characteristics in high-resolution. From System-Level Thinking to Hands-on Engineering & Prototyping.
About Product
Self-guided anti-aircraft missile.
Self-guided anti-aircraft missile.
About Client
Unnamed Mil-Tech rocketry startup.
Unnamed Mil-Tech rocketry startup.
Problems & Goals
Problem Statement
The business needed to finalize the design of their high-performance rocket engine but lacked high-resolution, high-frequency measurement systems to do it properly.
Project Goal
Architect and build a fast, easy, and effective way to measure and collect thrust characteristics of the engines to enable continuous improvements across rocket iterations. Solution needs to be:
Easy to scale in future;
Easy to use with existing equipment by low-skilled personnel;
Reasonable development, operation, and maintenance costs;
Easily accessible (market availablity) parts;
Power independent, wireless, offline-use.
Solution
The ADS1256 unit serves as the main ADC, measuring up to 4 differential channels, controlled by a single ESP32 unit that runs two tasks simultaneously via RTOS. The first task operates a Wi-Fi AP and webserver that handles private network requests from the client PWA app to control the measurement system. The second task manages the measurement process, data filtering, and high-speed data recording to the connected SD card.
Electronics
Low-cost, minimalistic electronics built with components that have strong community support and high market availability to keep maintenance and future development simple and affordable. The system operates wirelessly on battery power with USB-C recharging capability, making it easy to work with.
Software
The PWA-based front-end client makes it easy to access, distribute, and update the app while keeping it private and providing offline usability to handle poor connection quality or complete absence of connectivity.
The C++ back-end code is developed using the widely popular and well-supported Arduino IDE, primarily relying on native libraries. An RTOS (Real-Time Operating System) is employed to ensure minimal execution latency for web server and measurement tasks.
// Meassurement RTOS task creation BaseType_t measureTaskStatus = xTaskCreate(taskMeasure_func, "taskMeasure", 32768, nullptr, 1, &taskMeasure); if (measureTaskStatus == pdPASS) { Serial.println("[==== ] Задача вимірювання запущена"); } else { Serial.println("Failed to create Measure task. Restarting..."); esp_restart(); // Перезапуск ESP32 } // Web-server RTOS task creation BaseType_t webTaskStatus = xTaskCreate(taskWeb_func, "taskWeb", 16384, nullptr, 0, &taskWeb); if (webTaskStatus == pdPASS) { Serial.println("[======== ] Веб-задача запущена"); } else { Serial.println("Failed to create Web task. Restarting..."); esp_restart(); // Перезапуск ESP32 }
UX/UI
The design follows AAA-compliant WCAG standards, ensuring an accessible, mobile-first UI for operating the test stand and wirelessly monitoring measurement data from a safe location. A basic UI kit has also been established to enhance scalability and facilitate the addition of new features in the future.
Casing
The MVP-stage casing is fully 3D-printed to securely house the electronics, ensuring protection and safety. It includes additional features such as a built-in tripod mount hole for ease of use and a sliding lid to simplify future development and debugging processes.
My approach
I was solely responsible for the Electronics, Software, and UI/UX, which made the development process more challenging but allowed for a more cohesive and well-architected solution.
From System-Level Thinking to Hands-on Engineering & Prototyping.
From a Product Designer’s perspective, I began by aligning business goals with user needs. Understanding the Customer Journey Map (CJM) and User Flow enabled me to define key product features, which in turn guided the selection of the hardware and software stack required to deliver the desired user experience. I prioritized affordability and simplicity, carefully eliminating unnecessary components while maintaining essential functionality.
Key Challenges & Design Decisions
Initial Solution Architecture & Product Design
Initially, I planned to store the web app on the MCU, but transferring it to the client proved too time-consuming, especially for larger websites. This approach was also inefficient for app update cycles, as I had to re-flash the MCU every time I modified the frontend. Additionally, using chart libraries like Chart.js locally required significant storage space. Ultimately, I decided to host the web app as a Progressive Web App (PWA), making it publicly accessible with the option to install it on a device for offline use.
After discussions with researchers and analyzing the Customer Journey Map (CJM) and User Flow, I identified that the test stand would be used with multiple rocket engines to determine optimal characteristics. This necessitated differentiating data from various engines. I designed a feature allowing users to input engine and propellant data before testing, along with the ability to add post-study notes, all recorded in the same file as the measurement data.
Working closely with the Design Engineer, I gained a deeper understanding of the test stand's functionality, safety measures, and typical operating environments. This insight guided my focus on delivering an AAA-compliant WCAG design to ensure maximum accessibility across diverse environments. To enhance safety, I introduced system feedback messages at the UI level, along with audio and visual feedback at the hardware level.
Finally, to safeguard recorded data and ensure usability, I added recording rate and web refresh rate indicators to the UI. This feature keeps users informed about actual latency, helping them make informed decisions before proceeding with tests or starting the engine.
Hardware Debugging
Originally, I used the Arduino UNO R3 Wi-Fi for this project, but its limited memory and underpowered CPU made it unsuitable for running multiple heavy RTOS tasks efficiently. I switched to the ESP32-Wroom-32U, which features a significantly more powerful CPU, larger memory, native Wi-Fi support, and a robust community for troubleshooting and development.
This project requires a sample rate of 200 Hz. However, the initially used HX711 could only achieve up to 80 samples per second, which was insufficient. To meet the requirement, I replaced it with the ADS1256, an ADC capable of sampling at up to 30,000 samples per second, ensuring the necessary performance.
During multiple failed attempts to configure the ADS1256 to work correctly with the YZC-516 load cell (purchased from Aliexpress), I initially suspected the ADC itself as the issue. The ADS1256 is not widely used, has many Chinese board variations, and lacks a wide range of well-documented libraries. However, after extensive debugging, I discovered the issue was with the load cell, not the ADC.
The root cause turned out to be conflicting specification information for the load cell. The Aliexpress product page specified an excitation voltage of 10–15V, while the datasheet included with the package listed it as 5–10V. Additionally, the datasheet referenced a different model name, leading me to believe it was mistakenly included by the seller. On other websites, the YZC-516's excitation voltage was specified as 9–12V.
To resolve this, I initially averaged the values and worked with a 10–12V excitation voltage. After spending significant time debugging the ADS1256, I eventually discovered through experimentation that the load cell required a 5V excitation voltage. Switching to 5V resolved all issues with the ADC and allowed the system to function correctly.
Server & Client Communication
While working closely with the front-end developer, we discovered challenges in setting up communication between an HTTP server in a private network and an HTTPS public resource. These issues resulted in browser errors like CORS violations and mixed-content restrictions. I researched potential solutions to address these problems.
The ESP32 lacks robust libraries for running HTTPS servers, and such servers demand significantly more resources than the ESP32 can easily handle. Consequently, I decided to stick with an HTTP server for now. Another option was to configure a mini DNS server on the ESP32 within the private network to trick the browser into recognizing it as a secure website. However, after initial exploration, I realized this approach would require considerable time to implement.
For the MVP stage, we opted for a simpler solution by adjusting the chrome://flags settings, allowing the PWA to run seamlessly during development and testing.
Low Latency Measure & Record
I successfully achieved high speed and low noise for both measurement and recording rates. Since the ADS1256 and SD card both utilize the SPI bus, I designed a solution that sequentially communicates with each SPI device on the same bus. By optimizing the process to switch between devices quickly, I managed to achieve a sampling rate of one sample every 5ms with a fallibility of ±100g.
One key optimization for the SD card recording task was the implementation of incremental flushing to the SD card. By writing data in batches of 5000 samples, I enabled recording rates faster than 1ms, significantly improving efficiency.
if (logFile) { //...// if (samples % 5000 == 0) { // Злив даних на SD-карту logFile.flush(); } //...// }
Given the multiple tasks running on the RTOS, both requiring access to the SPI bus, I introduced a bool variable (spiFree) to monitor the availability of the SPI bus. This approach prevented potential development errors caused by concurrent access to the SPI.
To address the significant noise produced by the highly sensitive ADS1256, I implemented a digital median filter using eight samples. While this slightly reduced the final sample rate to 5ms, it greatly improved the clarity and accuracy of the results.
In-Field Usage & Debugging Friendly 3D-Printed Case
I used Autodesk Fusion 360 to design a compact casing for the electronics, ensuring protection from environmental factors while allowing for adjustments and repairs on the go—an essential feature for the initial testing phase of this setup. To enhance usability, I incorporated a built-in tripod mount, eliminating the need for users to bring a separate mounting solution.
Learnings
Be more diligent when reviewing specifications for components purchased on platforms like Aliexpress;
Pay closer attention to the selection of components, as some (e.g., the ADS1256) were more challenging to implement than anticipated;
Be mindful of Progressive Web App (PWA) requirements, including HTTPS, mixed content issues, and the hardware capabilities needed for server-side operations.