and love your work MichalSmielak! Looks like a very nice design indeed. 

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.

Cheers,

Al

Hi Alasdair.

I think an open source camera trap design is very possible. We've looked into the Sunplus chipsets but it seems very difficult to get a reference design and reference software. The SPCA1x28 series is a low end chipset that is very inexpensive, using an 8-bit 8032 processor and handling all the images in hardware. The low cost is likely why so many trail cam manufacturers use them, but the processor is based on an Intel 8051 instruction set circa 1981 and looks closely guarded by Sunplus. What seems to be happening is that companies are selling vanilla circuit boards with standard features and the trailcam manufacturers are using the standard features available in their trailcams with no modification of firmware. On the (Sun)plus side, having an 8-bit controller with 5MP cams means it's possible to idle at very low power and then turn on and trigger the cams quickly. 

We've looked at using an Allwinner chipset which is used in a lot of action cams and dashcams and modifying it into a trailcam. It's possible to run Linux and they support SD card interfaces and various cameras. It's also possible to buy just the chip so it's not tied to a platform like Raspberry Pi. This is useful because it's possible to make minimalist boards with just what's needed and also optimize it for power. An issue is that since it will be running a pretty heavy processor, it will be difficult to power optimize. Rough estimates are that at idle but full clock speed, the chip will consume around 90 mA. The Raspberry Pi Zero idles at around 80 mA for reference. Ideally, it'd be nice to get it around 1 mA.

We've also checked out using an ST32 ARM Cortex M4 chip with a parallel camera interface. These are pretty beefy processors but not Linux class like the Allwinner which is an ARM Cortex A7 class chip. Since the ST32F407 chip can run closer to bare metal (ie: no OS layer in the way), its possible to put it in very low power modes and then have it wake up. One issue though is that it doesn't have an SDRAM interface so it will cost a lot to have enough SRAM to buffer more than one image. 

Another possibility we were looking at was to have an FPGA running with custom logic and have it controlled by something like an Arduino or an ARM Cortex M3. There is already ArduinoCAM devices but the FPGA code is not open source. This is also a potentially interesting possibility because it would offer a low power device which could be in sleep mode except for the PIR sensor and quickly ramp up to take pictures. 

Whether we go with the Allwinner, Sunplus, ST, FPGA, or some other chip, it will probably be a big undertaking since hardware will need to be developed for the chip and system. The software will probably take the most time since custom drivers will likely need to be written as well as application software to handle the main functionality. I'm currently assuming that it will be a year-long project. But if it takes a year to come up with a design that can be useful in so many applications, it may be a small price to pay. 

Let me know if you're interested to discuss it more. I will probably move this part of the thread to a separate thread since I think it's diverged from the OP topic. 

Akiba 

FYI, the open source camera trap part of this thread has moved here:

https://www.wildlabs.net/community/thread/694