ESP-32 Flight Datalogger – Supply Chain Break

ESP-32 Flight Datalogger – Supply Chain Break

Hardware build can begin once the design, development, and testing phases are complete. The ESP32-Cam project development hardware could have been reused. The problem with reuse is that the hardware is no longer available in a development capacity and the project is locked. If any damage or modification occurs during the hardware build, this can cause delays. For that reason, additional parts were sourced and purchased with the intent of using them for the build.

There were plenty of ESP32-Cam modules, capacitors, and voltage regulators in stock, so there was no need to order spares. The current and barometric sensors were one offs and spares were purchased. In addition, control switches were also ordered. Now with dedicated parts for the build, the development hardware would be available if needed.

While sourcing parts, the BMP085 barometric sensor was no longer available. It had been superseded by hardware that was two generations ahead of it. The new hardware had significant changes to it which would require firmware rework. With less than 2 weeks left before the deadline, this was no longer an option. Fortunately the next generation of senor was available, the BMP180. This sensor didn’t appear to have those changes, but this would prove to be an assumption that was incorrect.

The hardware order had priority and was placed with the quickest turnaround. When the parts arrived, the new barometric senor was assembled on the development system for testing. During field testing, the system appeared to operate as expected. While reviewing the data collected, it became clear that the new barometric senor wasn’t working.

The code base for the BMP085 was based off the Adafruit_BMP085.h library. The BMP180 was not backward compatible with that library. New code base was found that used the SFE_BMP180.h library. However, the code base was congested with many nested functions. An attempt at reorganize the code was limited to 2 hours due to a looming deadline that was only 1 week away. However, that attempt was abandoned when it became clear it would take much longer to complete. This left the only option for the hardware build to use the barometric development hardware.

Was it possible this could have been avoided, knowing the hardware availability early in the design phase? It might have, but the design phase was based from hardware that was already available. The design didn’t include seeking out new untested hardware with the hope it would work in development. Development and testing were the phases where the hardware was vetted. Availability was essentially an afterthought. Had the design phase based hardware use on availability, it would have been clear that a decision about the barometric senor would need to be made early on. That might have allowed development and testing to be centered around hardware that hadn’t been retired.

It is what it is at this late stage, the build phase will be covered in the next section.

Comments are closed.