Sensor Redundancy And Bench Confidence Update

The last update focused on planning, validation, and user trust.

Since then, the work moved back onto the Core bench in a very physical way.

The goal was not to add a flashy feature. It was to improve the sensing foundation that the rest of the product depends on.

That matters because Apex Infinity is not only a display, an app, or a cloud service. At the center of the platform is a device that has to understand what is happening in the air, preserve that evidence, and feed every other surface with data that can be trusted.

This phase tightened that foundation.

The sensing path moved forward

Core's pressure-sensing direction has been upgraded to a newer generation of hardware.

That change is not only about choosing a newer part. A sensor upgrade only matters if the surrounding system can actually use it well. Firmware needs to detect it. The device needs to read it reliably. The logs need to preserve what it saw. The validation loop needs to prove that the readings are sane. And the board direction needs to match the bench evidence before hardware decisions become expensive.

That is the standard this work is moving toward.

The bench device now has that newer sensing direction alive on the shared sensor bus. The important proof is simple: firmware can see the devices, distinguish them, and begin treating them as real runtime inputs rather than as schematic intentions.

That is a useful threshold.

Two sensors are better than one when the system knows why

The more important architecture change is that this sensing path is moving from one sensor to a paired approach.

That does not mean the product should blindly trust two numbers more than one. Redundancy only helps if the system is designed to use it deliberately.

For Apex, the first step is straightforward:

• keep each raw sensor reading visible
• compute one fused reading for runtime behavior
• preserve enough detail in the logs to understand what happened later
• flag disagreement instead of hiding it

That gives the platform the right balance. The live device can use a cleaner fused input, while engineering and future support can still see the two underlying measurements separately.

That distinction matters.

If the two sensors agree, the fused value can be more stable than either single reading by itself. If they drift apart, the system has evidence that something deserves attention. The second sensor is not only a backup. It is also a way to measure confidence.

Logging had to grow with the hardware

Adding a paired sensing path also forced the logging model to become more explicit.

It would have been easy to keep only one "pressure" field and let the firmware decide what that meant internally. That would have been the wrong direction.

The logs are part of Apex Infinity's trust model. They are how the platform explains what happened after the fact. They support replay, debugging, sync, field review, and eventually user-facing history. If the runtime system is using a fused measurement, the logs should say that clearly. If two raw sensors contributed to it, the logs should preserve that too.

So the log schema moved forward with the hardware:

• raw sensor A
• raw sensor B
• fused runtime pressure and temperature
• pair disagreement
• fusion status

That is more data, but it is not noise. It is the difference between "the device used a number" and "the device can explain where that number came from."

Bench validation is doing its job

This round also reinforced why bench validation exists.

The useful outcome was not only that the upgraded sensing path came alive. The useful outcome was that the bring-up process exposed issues while they were still cheap to investigate: wiring, bus behavior, device identity, runtime selection, logging format, and what should happen when only part of the sensing path is available.

That is exactly the kind of problem Apex wants to find on the bench.

The manufactured hardware path should not be the first place where firmware learns how the sensors behave together. The bench path exists so the device can prove identity, sampling, logging, and fallback behavior while the system is still accessible enough to inspect and adjust.

That is especially important now because Core hardware is moving toward a more serious production-readiness posture. The board, firmware, logging format, and validation loop all need to agree before the next hardware step carries more cost.

What this means for the product

The product-level meaning is simple: Apex Infinity is making its Core sensing foundation more robust.

A paired sensing path gives the platform a better way to stabilize the live input, detect disagreement, and preserve the evidence behind decisions. The upgraded hardware direction gives the board path a cleaner future. The logging changes make sure the data model keeps up with the physical device instead of hiding important context.

This is not a final field claim yet.

The next step is to flash the updated firmware, run the paired sensors for longer, inspect the logs, and make sure the fused path behaves the way the product expects. After that, the same evidence can feed the display, replay, storage, and manufacturing-readiness work with more confidence.

That is the real point of this phase.

Apex Infinity is not only adding sensors. It is teaching the platform how to reason about them.