discussion / Sensors  / 31 October 2016

camera trap sensor zones - how much is hardware and how much firmware

Hello all

The passive infrared sensors on camera traps differ between makes and models and some of them are heavily biased towards movement in certain directions - Reconyx for example is strongy biased to movement across the bottom half of the field of view, which means that an animal can walk stright towards or away from a Reconyx camera and only be detected when it is less than 2m away.

Some of the detection zone arrangement depends on the hardware of the fresnel lenses that are moulded into the window in front of the PIR sensor, and the number and arrangement of sensors on the PIR (usually only 2 or 4 as far as I know - the fresnel elements make the heat image jump from one to another as the target moves smoothly across the field of view). To trigger an image capture there must also be some logic processing of the rising and falling signals from the PIR zones - does anyone know, for any camera trap, whether this is firmware (i.e. in principal it could be modified) or is it likely to be locked into the hardware of the chips ?

Thanks, Peter 

Hi Peter. 

I can't speak for the more expensive camera traps but the cheap camera traps are generally based off a reference design that's provided by the main IC supplier. In many cases, this would be Sunplus, a Chinese chip fab. From my experience in manufacturing, I would say that the camera trap (trail camera?) supplier likely does not care about correcting across the differences between the Fresnel lens zones. What they do is copy the IC supplier reference design, possibly with some slight modifications, then have a test to see if the PIR sensor detects motion. If it does, then that particular test passes and if the other hardware tests pass, then the device ships.

Hi Peter.

Not sure about the exact definition of standard components. For interfacing cameras to microcontrollers, the microcontrollers either need to support a MIPI high speed serial interface or a very specific camera parallel interface. Other than the the STM32 chips that suppor the Digital Camera Inferface Module (DCIM), you would need programmable logic (FPGA or CPLD) to interface a camera.

That's why there's not a lot of good open source camera traps. They're all somehow based on the Raspberry Pi which has a built in MIPI interface. The amount of electronics expertise needed to design a digital camera interface on a low power microcontroller is intense.

The commercial cheap trail cams use the Sunplus reference design. You can check out more info on that here. You can also check out trailcam specs here. There might be other chipsets that service the trailcam market but I doubt it. It's already quite niche and probably won't allow more than one low cost chip manufacturer survive.

In regards to other standard components, I agree. The PIR sensor, LEDs, and camera are all pretty normal electronics stuff. But the main innards to interface the microcontroller to the camera are where all the challenge is. At hackerfarm, we're investigating designing an open source custom logic device to bridge cheap microcontrollers with decent CMOS cameras for open source camera traps. It would be huge for us since we can finally see the animals that are near us and also formulate a strategy on the ones that eat our crops.


Hi Peter / Hackerfarm,

That is interesting indeed, as stripping cameras down will reveal a number of standard components. The reviewer may have been referring to a few specific vendors (Reconyx) as the bulk are certainly from standard components. I've been working with camera traps for about 11 years (co-founded Naturebytes that offers a consumer Rasp Pi version) and took a look at several brands and models a few years back, which revealed a very common SoC, with cheap variants using the SPCA1628. The mass-produced cameras nearly always copy or resell a standard design / firmware and you'll even see the same typos show up in interfaces etc (UWAY / ScoutGuard etc). The UM562 used the same cellular daughterboard as a number of other brands at the time. Reconyx certainly don't - there was at one time a schematic of their design, but I know for sure that a dedicated ViCAM®III is used to enable the rapid recovery / write that the cam is well known for. You pay much more, but that's a RISC processor providing up to 80mips.

In terms of PIRs, my experience is that quality differs immensely. From a cheap batch of 1000, it isn't uncommon to see 10% fail or produce poor detections during Q&A (HC-SR501 for example). Bushnell etc I believe use a good quality manufacturer, but because you're basically looking for a 1 or 0 signal change, zoning is the "cheap" answer that they all use, which is described in detail here (https://zslpublications.onlinelibrary.wiley.com/doi/pdf/10.1002/rse2.20).

Multi-zone and single zone fresnel lenses mask the detection to avoid sun glare, minimise one large heat source (hot wind) creating false positives etc, with Reconyx again known for multi-zone and less false positives than generic camera traps. Without a "middle ground" you can only trigger on or off with a PIR so the zones help, but firmware does control false positives / sensitivity. Usually this defaults to the "high / low" sensitivity settings, and to keep the camera's easy to configure there's no physical trimpot for a user to do this so it's done at the software level. Therefore to answer your quesiton, I'd say you are looking at a few different variables (make of IC, fresnel zones, firmware to tweak responses) but you could start with a Sunplus and get some different fresnel covers to experiment. There are good photos in the paper linked above showing the options. 

Lastly - Hackerfarm. Lovely write up of the AudioMoth recently. I am Alasdair from Arribada (we manufactuer the AudioMoth using GroupGets for Open Acoustic Devices). Thanks for your detailed breakdown, I'll loop you in to AudioMoth 2.0 dev with Andy (if he wasn't already been in touch :)

Open source camera trap reference designs - yes indeed. Lots of progress in the EPS32 space at the moment, but getting a good resolution, fast writes, quick recovery and good IR illumination is indeed challenging without resource and time to do it well. I have been thinking of looking at this moving forward with my Shuttleworth Fellowship, so I'd be interested to see what you have in mind there too.



Hi Akiba,

Sure thing. An open source camera trap reference design or SoC that meets commerical specifications is, in my eyes, one of the key missing elements in the world of camera traps due to the complexity of achieving comparable performance as that of a Bushnell / Reconyx. Nobody has cracked it yet, and if you're game, that would offer real value to the camera trapping community. I'd be keen to support a move in this direction.

I  supported an experimental programme of work a few years back that multiplexed the SD card, meaning anyone with an existing generic camera trap would use the modified SD and the camera would happily keep the bus, writing data / photos, but the bus would be switched on init so the previous data could be read by a third party radio or device, meaning cheap trail cameras could be modified and used and extended. A flat ribbon cable escaped the enclosure in this instance. I was also going to try and run busybox (think WiFi-SD cards) for wireless transfer but the prob was power as the SD card only received power during writes and the objective was 0 hacks - just a modified SD in a standard camera. Could still go down the firmware route, but it gets heavy supporting various different makes. A reference open design and injection moulded case would be the real answer.