Field Testing Update: Finding Problems Before They Reach the Herd

One of the reasons we're running the Ori Cattle Pilot Program is simple: we want to find problems during testing - not after thousands of ear tags are in the field.

This week, our testing did exactly that.

During ongoing field testing of our cattle ear tags, we observed that batteries in several test units were depleting much faster than expected. That triggered an investigation by our engineering team into the tags' power consumption and firmware.

The investigation identified the cause: a recent firmware change had inadvertently affected the tags' low-power operation. The result was significantly higher power consumption while the tags were otherwise supposed to be conserving energy.

Importantly, this testing occurred before broader deployment of these units to Pilot Program customers.

So, what happens when we find something like this?
We don't simply push ahead with manufacturing or fulfillment to preserve a date on a calendar.

We investigate it. We identify the cause. We make the correction. And then we test again.

Corrected firmware has now been prepared, and we're moving into controlled validation.  Once we have evidence that the change is performing as intended, we'll determine the next steps for the upcoming hardware.

That additional validation takes time, and it's one of the reasons hardware manufacturing and deployment schedules can sometimes move.

Why not just ship?
Technology history provides some pretty significant reminders of what can happen when product problems aren't caught early enough.

• Samsung's Galaxy Note7, for example, reached consumers before battery problems resulted in a large-scale recall. The U.S. Consumer Product Safety Commission reported overheating batteries, fires, injuries and property damage associated with those devices.

• Fitbit later recalled roughly one million Ionic smartwatches in the U.S. after receiving reports of batteries overheating and causing burn injuries.

  
  

Ori's situation is not comparable to those safety incidents. Our testing has identified a power-consumption issue, not an overheating or fire issue. However, the comparison is about something much simpler:
Problems are considerably better to find during testing than after widespread deployment.

That's why a delay isn't always evidence that development has stopped. Sometimes it's evidence that the development process is doing exactly what it's supposed to do.

What this means for the Ori Pilot Program
Our Pilot Program isn't simply about getting early Ori ear tags onto cattle. It's about validating the entire system under real-world conditions — hardware, firmware, battery performance, LoRaWAN connectivity, gateways, data transmission and ultimately how the system performs where it matters: in the field.

That means we're going to test. We're going to find things. We're going to make changes. And we're going to test those changes again.
We won't pretend every step will happen perfectly the first time.

What we can commit to is being deliberate about identifying problems before they become our customers' problems.

We'll share another development update as testing continues.