Introduction

As anyone who has developed hardware will tell you, hardware’s hard! With 6 years' hindsight developing Instant Detect 2.0 at the Zoological Society of London (ZSL), it felt like a good time to share a summary of our testing and optimisation journey in the hope that it will provide some useful insight and learning points to others. 

If you are not sure what Instant Detect 2.0 is and want to understand our vision for the system, please see this article I wrote all the way back in 2019 – Instant Detect 2.0 Emerges.

Testing image transmission over LoRa radio with a prototype Instant Detect 2.0 camera on Primrose Hill in 2019. The receiving Base Station is 1 km away inside London Zoo. Credit: Sam Seccombe

Development Mentality

When embarking on Instant Detect 2.0, we felt strongly that if conservationists and ranger teams were to spend their precious funding buying the system, then it had to work reliably every single time, with little maintenance and for long durations. The worst thing a new conservation technology can do is become another maintenance burden on already stretched field teams. This meant Instant Detect 2.0 had to work perfectly from day 1. 

With this philosophy in mind, we planned to conduct extremely thorough testing and optimisation of the system before product launch to ensure that it was truly up to standard. At the time we optimistically thought this might take around 6-12 months…  

A Gate-Phase Approach

We intended to develop Instant Detect 2.0 in a single development cycle, rather than a series of iterative prototypes. To do so, our development partner Cambridge Design Partnership (CDP) followed a gate-phase approach where each new part of the system was tested against functional performance requirements before advancing to the next phase of development. We expected this approach to take a bit longer, but would be cheaper in the long run and result in less wastage.

This meant that by the time the first Instant Detect 2.0 prototypes were delivered in early 2019, CDP had already systematically bench tested the system’s various sub-components against our specifications. Test highlights included a low-light level camera module shootout, a lens cost/quality comparison study, extensive PIR sensor sensitivity tuning (requiring a teddy pangolin), and connectors and enclosures spending 24 hours in a freezer before being systematically dropped from a great height. We were therefore reasonably confident with the initial prototype designs. 

At this juncture I would like to thank all those at CDP who worked so hard on Instant Detect 2.0, with special mentions going to Mike Beadman, Andrew Feldhaus and Tom Brittain for going the extra mile for us.

‘Garden’ bench testing of the Instant Detect 2.0 camera PIR sensor sensitivity at Cambridge Design Partnership in 2018 using a teddy pangolin as the target. Credit: Sam Seccombe

First Field Testing

With only 3 Base Stations, 3 Sensor Endpoints and 9 Cameras built by CDP, our newly minted hardware felt very precious to us. Obviously, it was now time to test it to destruction! 

Due to a donor requirement, two of these systems were taken almost immediately to the Kenyan bush for a month’s intensive field testing. It is important to stress that this testing was not using up anyone else’s time, nor was anyone expecting anything from the testing other than improving the system.

Eat, sleep, test, repeat. Camera comparison testing in Kenya 2019. Credit: Sam Seccombe

Using white markers (loo rolls) to conduct walk tests at various ranges from the Instant Detect 2.0 camera to test capture and recovery speed.  Credit: Sam Seccombe

During this intensive testing period the system’s firmware improved dramatically. This was achieved by having a constant flow of testing data sent back to CDP, and CDP sending improved firmware to re-test back multiple times a day. 

Sometimes, between 10 – 30 ‘unofficial’ firmware builds would need to be tested before an issue was fully resolved and an ‘official’ firmware build could then be released. By the end of the trip, we were on Revision 24 of the ‘official’ firmware.

I remember being told around this time that the last 5% of hardware development will typically take up to a third of the entire development time. I didn’t believe it then but 6 years later and I can confirm how true this is.

The most useful output of the Kenya testing was validation of the system’s mechanical design. Having buried a Base Station and Sensor Endpoint for a week in water-logged soil without issue, we were confident that our enclosures, connectors and assembly processes were robust and would survive hot, dusty and wet conditions.

An Instant Detect 2.0 Base Station was buried for a week in water-logged soil to validate the enclosures and connecters were water and dust proof. Credit: Zuzanna Catling

The Castaway 

Off the back of the Kenya testing, we were feeling relatively confident in the system’s performance. We knew we had a lot more optimisation to do, but it felt like we had a minimal viable product. So later that summer we took a gamble and sent one of our precious systems to the incredibly remote and uninhabited Henderson Island in the middle of the South Pacific to become a castaway.

Henderson Island is one of the most isolated islands on the planet. You cannot get much further from a major landmass. Credit: Google Maps

In June 2019, an exploration team from the PEW-Bertarelli Foundation and the Howell Conservation Fund visited Henderson Island to conduct a monumental beach plastic clean up - read about it here – and they wanted to install Instant Detect 2.0 to monitor how much plastic washed back up again over the next four years. Shout out to Johnny Briggs for being our first ever Instant Detect 2.0 user!   

With minimal training on the system and with newly minted Revision 27 firmware, the expedition team departed, and we waited nervously to hear how they would get on with the system deployment. We were therefore ecstatic when on checking our cloud site from the comfort of our desks in London one day, we started getting regular images of this beautiful tropical beach coming through.

An image sent to the cloud by the Instant Detect 2.0 system deployed on Henderson Island’s beach in 2019. The image has been slightly colour corrected. Credit: Johnny Briggs

For two weeks this proved addictive viewing, but then the feed stopped and nothing further was received. Unfortunately, by this point the team had left the island and would not be back for years. 

The Instant Detect 2.0 system was rigged up on Henderson Island’s beach with a large lead acid battery and a solar panel. The battery boxes were buried after this picture was taken. Credit: Johnny Briggs

Despite this early deployment failure, it had still provided good validation that non-technical users with minimal training could set-up and successfully deploy the Instant Detect 2.0 system by themselves. Being intuitive and easy-to-use by non-technical users was one of the key design requirements of Instant Detect 2.0, so this was great news.

It took a further 5 years and several failed attempts until we finally found out what happened to the Henderson Island system. When it was found in 2024 it was great to see that by and large it was all still intact. Thank you for finding it Hanna Dijkstra and the Plastic Odyssey expedition 2024.

The Henderson Island camera was found in 2024 largely intact. Credit: Hannah Dijkstra

Certification Testing

Developing conservation technology is not always exotic and exciting though. To be legally able to sell new technology, it needs to be appropriately certified and marked, e.g. CE, UKCA, FCC. If you look at any product you buy you should see these marks on their label somewhere (depending on where you are). Now you know about them you will start noticing them everywhere…

Towards the end of 2019 we started our certification odyssey. I could write a whole article on certification as this part of the development went on for over a year and required significant re-budgeting. Instead, here is a quick summary. 

Firstly, a common misconception in the conservation technology sector is that if you use already certified and marked components when developing a new technology, then you don’t need to do certification of your new device. This is wrong. It turns out that any new electronic circuitry can seriously affect certification performance of certified components, so really any new device should be certified anew. 

What are we actually talking about here? Well, thankfully all electronic devices that are for sale have to pass electro-magnetic compatibility (EMC) tests to prove that they won’t interfere with other electronics. In addition, transmitting devices also need to pass radio frequency (RF) regulatory compliance tests to ensure they conform to correct power and frequency usage. 

If you think this seems a bit controlling, take a minute to imagine the sort of carnage that would occur if anyone could just build electronics without any sort of restrictions. Things could be lethal, nothing would work near each other and it would end up becoming survival of the most powerful transmitter! 

Once you have identified what certification marking and standards you need to pass, you take your devices to an external certification test house for pre-compliance testing. Here, experts stick your device in an anechoic chamber, which does looks pretty cool, and then use really sensitive antennas to measure what emissions are being given off over a wide spectrum of frequencies. Another test they do is to zap it with high voltages to see how it would perform in a lightning strike. Our poor precious hardware.

I felt just like India Jones when retrieving the Instant Detect 2.0 camera from the anechoic chamber. Credit: Sam Seccombe

After conducting some initial pre-compliance testing on Instant Detect 2.0 for CE and UKCA certification, it became evident that some major re-designs were needed of the system’s electronic printed circuit boards (PCBs). 

We had designed Instant Detect 2.0 so that broken PCBs could be easily replaced by users in the field. As such, the PCBs connect to each other using pins, a bit like PCB Lego. However, we soon discovered that these little pins will sometimes act as tiny antennas and were causing our devices to be too electronically noisy.

An exploded view of the Instant Detect 2.0 camera showing how the PCBs pin together. Unfortunately, these pins can sometimes act like tiny antennas! Credit: Cambridge Design Partnership

It turns out that electronic design is more magic than science, and small variables in circuit board track lengths and the number of times a track passes from one side of the board to the other (a via) can result in big changes in emissions. To resolve these issues, we ended up doing quite a significant electronic re-design, with our PCBs going from 4 layers to 6 layers, thereby doubling the number of ground planes, as well as increasing our electronic shielding. 

The green line shows the permissible emissions limits for all frequencies and the red line shows the Instant Detect 2.0 Base Station’s emissions during pre-compliance testing. Two emissions are still too high and were later fixed using extra shielding. Credit: Cambridge Design Partnership

Transition to Manufacturing

With the third iteration of our PCBs performing well in pre-compliance testing, and with good confidence in the mechanical design, it was time to find a manufacturing partner. 

As a conservation charity, ZSL needed a manufacturing partner who would be able to do the full manufacturing and fulfilment of the system. This meant managing the full component procurement, building the PCBs, gluing and assembling the enclosures (known as box building), and then completing unit functional checks before shipping systems direct to our users.   

After conducting a thorough tendering process, we were very grateful to partner with NHT Electronics in Lancaster who were keen to support our conservation goals. I cannot recommend them enough and would like to thank Sam Hewitt for all his support over the years. 

It doesn’t matter how good your technology is, if no-one can afford to use it, it might as well not exist. Therefore, another key requirement for Instant Detect 2.0 was to make the system affordable, ideally with our devices priced similarly to high-end camera traps. 

The main way of reducing manufacturing costs is to build things in volume. This meant we had to purchase a large stock of some of the smaller bespoke components to get the unit price to an acceptable level. It was a bit daunting ordering 2000 units of some custom molded components at this stage, but it was the only way to get their unit prices down to acceptable levels. 

Again, I could probably write a whole article on manufacturing hardware and the challenges it poses, especially when you try to do it in the middle of a global pandemic! Do not get me started on supply chains and managing component obsolescence.

Once you have procured everything as cheaply as possible, the next stage of manufacturing is streamlining the production processes with the goal to be able to build things as efficiently and consistently as possible. This was achieved by developing a number of jigs, and continually refining our assembly and unit testing techniques. 

Box-build assembly of Intant Detect 2.0 at NHT Electronics. Credit: Sam Seccombe

One of the trickier things during assembly was focusing the camera lenses. For our camera this is done by hand and initially it was taking anywhere from 10 to 30 minutes for each lens. To streamline this process a special firmware build was created so that the camera takes an image every second and visually outputs the image and file size. Running this firmware means you can just slowly screw the lens in until the sharpest image with the biggest file size is hit, reducing lens focusing time to a few minutes. 

Pre-Alpha Testing

In late 2020, NHT completed our first Alpha hardware: 2 Base Stations, 14 Cameras and 5 Sensor Endpoints. We were also now on Revision 43 of the firmware for those keeping track. Pre-Alpha testing could now begin in force. 

The Alpha hardware of Instant Detect 2.0 in all its glory. Credit: Sam Seccombe

With an abundance of hardware now available but still going in and out of pandemic lockdowns, our pre-Alpha testing focused on systematically optimising each of the devices' sub-systems. Some of the improvements we made over this period were to fix day/night image quality, develop quicker and more reliable LoRa radio packet handling, and implement extensive satellite connection logic to handle sub-optimum satellite antenna placement. With the ability to run multiple tests at once for extended durations, we were also now uncovering deeper issues that might have otherwise been missed with shorter testing runs. 

Night image quality testing in a London park during the extended January 2021 lockdown. Credit: Jo Seccombe

One of these deeper issues was the devices’ power consumption in sleep state, which was higher than it was supposed to be. To fix this issue, we had to request a patch directly from the multinational chip supplier. Another deeper issue was the discovery of a minor memory leak. This leak only started to cause issues after hundreds of hours of run-time but would then result in a complete system lock-up!

At this point, I have to mention the unsung hero of Instant Detect 2.0 whose presence has been felt throughout this article, and without whom the system would never have got to where it is now. I am of course talking about Richard Hunt our firmware engineer. Richard started working on Instant Detect 2.0 at CDP in 2019 and is still doing so today from his own company Cool Jacket Coding. Instant Detect 2.0 is a testament to Richard’s expertise, ingenuity and passion. Thank you so much, Richard.

User Interfaces

In early 2021, a lot of effort was also focused on our user interfaces. Unfortunately, the pandemic meant our original cloud-based user interface developer Nominet was unable to continue their support to ZSL, so we had to build our own. Into the breach stepped the Octophin Digital team who had already developed the system’s Access Tool. With a tight budget they were able to develop the brilliant Instant Detect Cloud, a completely new cloud-based user interface that is easy to manage, clean to use and lightweight to host.

Each Instant Detect 2.0 user gets their own Instant Detect Cloud site where they can view and tag images, see alerts, monitor device ‘health’ and even change device settings. Credit: Sam Seccombe

We also spent a lot of time fixing ‘papercut’ issues with our Access Tool. ‘Papercuts’ are the small irritating issues that can compound until the user just gives up too frustrated to continue. Perennial ‘papercuts’ for me are the annoying interfaces provided when trying to reject cookies on the majority of news websites. 

Next Steps – Alpha Testing

For those who have read this far, it’s now early 2021, the system’s firmware is at Revision 53 and we are about to start full Alpha testing. To continue this journey, please see my next article - Instant Detect 2.0 – Alpha Testing.

Writing this article was a real blast from the past and I had actually forgotten just how much effort went into so many parts of the system’s development. Thank you to all those who made this work possible over this period.

Please also visit our website - Instant Detect 2.0.