Circa 34.7mA in CPU idle mode with CAMERA_GRAB_WHEN_EMPTY and 34.7mA in CAMERA_GRAB_LATEST mode.
Looks like the issue with ‘pink images’ was mainly due to SD card issues.
It took a while to spot. but on the SD card I was using Windows explorer would display the wrong thumbnail images for the actual image for reasons unknown. Which was confusing.
Anyway with a ‘better’ SD card I do still get the occasional ‘pink’ image but its about one in every couple of hundred.
Surprising. I thought there would be a difference. Thanks for checking.
And yes - I’ve also noticed that Windows Explorer sometimes caches out of date thumbnails.
Glad its not just my PC. What was misleading was that the same wrong thumbnail was used for lots of files, so if you got one pink image, it could in explorer look like the SD was full of pinkness.
On the ESP32 in particular I have found that the SD can also be a tad unreliable, especially if its shares the SPI bus with another device such as LoRa.
Re shared SPI: I assume you’re using different CS plns for the two devices? I found two devices could co-exist quite happily on the same SPI bus: See this sketch:
However, it was only a proof of concept. When I discovered the ESP32S3 had more IO pins and PS RAM I gave up on expanding GPIO on the ESP32Cam. It wasn’t worth the trouble
Hi there,
agree, But with the C6 doing 15-22 uA sleep current, surprised it’s not in the mix?
GL 
PJ 
none will get close to the nordic single digit uA chips. 
and get one of these if your using a S3
For sure.
I have used a LoRa device and SD on the same SPI bus extensively for LoRa to LoRa file\image transfers for ESP32CAM etc, see here;
https://stuartsprojects.github.io/
I did find a way of, reliably, using a LoRa device and SD card on a ESP32CAM, but it was a challenge, and it involves starting devices in the right order and using deep sleep to re-init the interfaces.
On ESP32 in particular when the LoRa device and SD card are on the same SPI bus, the SD card can stop working, The recovery is a power down of the card which is not that convenient. I don’t get the same issue on say an Arduino DUE.
Switch to an OV3360 camera and you dont need one, for picture taking.
A light sleep current of 4mA between pictures does not generate much heat.
Maybe SEEED should offer the OV3660 as an option ?
2 Likes
This is inspirational work. I hadn’t thought the Sense connector would be available as a CAD/CAM component but it clearly is. I was also confused initially as you’ve used a 30-way connector and the Sense connector is 34-way and by the pin numbering which is quite different from the Seeedstudio schematic numbering. But then I realised the 4 outer-most Sense connector pins are just extra GND and VCC pins and the numbering actually works if you squint hard enough!
I wonder if there’s a way to re-engineer the Seeedstudio board retaining the camera connector and Mic but adding control of the Powerdown camera pin. That might make the OV2640 useable in low power applications given that the software standby feature is broken. It doesn’t matter much to me now as I’m happy switching to the OV3660 but it could be of interest to others and maybe you could sell the design back to Seeedstudio
Do you know what the register write commands should be to put the OV2640 into standby ?
The OV2640 has a different register structure to the OV3660, it looks like you need to write register 0x09 in bank 1 with a value of 0x10.
I tried this;
sensor->set_reg(sensor, 0xFF, 0xFF, 0x01); //camera to reg bank 1
sensor->set_reg(sensor, 0x09, 0xFF, 0x10); //camera to standby
but get an error;
E (29729) sccb: SCCB_Write Failed addr:0x30, reg:0xff, data:0x01, ret:263
E (31730) sccb: SCCB_Write Failed addr:0x30, reg:0x09, data:0x00, ret:263
This is my source on putting OV2640 into standby:
It doesn’t seem to work, although there might be some bit twiddling niceties that we’re missing.
That’s why I was interested in controlling the PWDN pin
The Arduino IDE does not have an OV2640.c file.
You would need to solder a (fine) wire onto pin 8 of the camera connector on the sense board. Not easy.
You don’t need to modify OV2640.c. Just call the sensor->set_reg_bits(… ) function directly.
Regarding PWDN I had ruled out altering the existing Sense board. I thought if PJ_Glasso were to reverse engineer it in Eagle CAD (like his More I/O board) he could connect Camera pin 8 (PWDN) to, say, IO21/USER_LED.
‘sensor_t’ {aka ‘struct _sensor’} has no member named ‘set_reg_bits’; did you mean ‘set_reg’?
21 is also used as SD CS.
Sorry - I meant:
int ret = set_reg_bits(sensor, BANK_SENSOR, COM2, 4, 1, enable?1:0);
In the Seeed expansion board schematic there is a D2/SD_CS coming in from the CPU and this is grouped up with D8/D9/D10 and labelled as “SD Card” however D2 is connected through R11 which is marked as DNP (Do not place) so D2, despite the labelling doesn’t actually control the SD CS. As you point out the SD card CS pin is in fact driven by IO21/USER_LED through R12. Given that all the example code says use pin 21 I guess it would be perverse to change it despite the schematic labelling. So, PWDN could instead be controlled by D2/SD_CS on a re-engineered Sense board.given that it is not used for anything else. Basically, there is a spare GPIO going through that connector and it could be used to drive the hardware PWDN pin of an OV2640.
Does not seem to exist in the Arduino IDE core 2.0.14 for ESP32.
Were you using the Arduino IDE ?
For a PWDN pin you could grab one of the MIC pins …
Ah yes. Looking at my notes I see I could not access set_reg_bits either however set_reg is accessible. I called it as sensor->set_reg(sensor, 0x109, 0x10, 0x10) but I got:
E (61522) sccb: SCCB_Write Failed addr:0x30, reg:0x09, data:0x12, ret:263
just as the other guy reported. This seems to imply that the camera does shutdown but the SCCB interface closes too and cannot complete the write properly.
NB 0x109 does the bank switch and addresses register 09 all in one go
with all this sleep current talk… im gonna def have to take a nap…
1 Like
