Dvb T V1 1 Firmware Sunplus Box
Edelira Longinotti
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
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.
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 ?
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 ViCAMIII 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 ( ).
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.
Cheers,
Alasdair
I purchased a 35s this week and was shocked to find this five year old design is still on its original firmware. So I went looking for the means to flash the thing.The CPU, or microcontroller if you will, is an SPLB31A with 256K of ROM according to the Sunplus data sheet. There is no mention of how the software is loaded.Is it in fact the case that ROM in the SPLB31A means masked ROM? Thus updating the firmware requires creating new photo masks for the chip lithography?Thanks. Re: HP 35s - No Firmware Update?
Message #2 Posted by Paul Dale on 18 Apr 2012, 7:57 a.m.,
in response to message #1 by Stephen Panarelli
Quote:I purchased a 35s this week and was shocked to find this five year old design is still on its original firmware. So I went looking for the means to flash the thing.HP-35S was introduced in 2007. TI-85 was introduced in 1993 and went through 10 versions before being discontinued 4 years later. I hope I don't shock you further. :P Re: HP 35s - No Firmware Update?
Message #4 Posted by Paul Dale on 18 Apr 2012, 8:22 a.m.,
in response to message #1 by Stephen Panarelli
Quote:Concerning the 35s I've found its display to be quiteuninspired, essentially being an inflexible charactercell configuration with the concession of fully RWM-mappedpixels. The hp-42s did far better than that some 20 yearsearlier.The HP-35s is really disappointing, especially the display (beside the catastrophic software). First notably from the typographic point of view the digits / characters have ill-favored proportions, they are much too high and have the wrong spacing, and---besides the reflective screen---the resolution is to low for a good readability, in particular of greek characters. Squarish 'pixels' should solve the first problem---and they free up space for a third display line.BTW there's a very nice technique for pure character-based displays, much better than 7x5 dot matrix elements (have a look at the brochure): -US/Default.aspxIn comparision to my every-day work-horse HP-15C from 1985---I give this masterpiece of 'engineering art' five stars in every category---the HP-35s gets four stars for the keyboard (five for the ENTER key!) and the color scheme [1], three stars for the general design of the casing (good: the rubber feets), at most two stars for its display and casing quality, and less than one for the (current) firmware and the processing speed (compared e.g. with the HP-15C LE).Martin[1] I give only three stars for the label font---the "Futura" is caused by HP's (IMHO) not very elegant corporate design. And it's very thoughtless or dilettantish for example to write the units "kg / lb" and "cm / in" correctly in lower-case letters but "KM / MILE" in capitals!Edited: 19 Apr 2012, 5:55 a.m. Re: HP 35s - display quality / e-ink
Message #10 Posted by Martin Paech on 19 Apr 2012, 7:44 a.m.,
in response to message #9 by Martin Paech
This process is no different from that of qsat, cobox, nusky or speed hd decoders. You need to download the original firmware of the dead decoder, extract it, rename it and copy to flash. See the easy steps below:
It allows you to flash or install the Stock Firmware (ROM) on the devices powered by Sunplus Chipset. All you need to have is the correct firmware (ROM) of your device > Install the USB Driver > Launch the Tool > Click on the Advanced tab and Load the Firmware > Go to the Basics Tab > Click on the ISP Button to begin the flashing process.
It comes in support of the devices running on the Sunplus chipset. Once you have installed the correct USB Driver of your mobile device, FRM Pro can easily detect the connected device on the computer and get ready to flash the firmware on the mobile.
aa06259810