Hi there,
I’ll go George Washington on that, YES … I can NOT tell a lie.
In my own opinion
GL 
PJ 
That’s great. Do you know what was going wrong when you were getting pink images earlier?
Nope.
But around the time I had that problem I did sort out the focus of the camera, it was quite a way out.
I will check if the delays after the switch from standby to active are critical.
Light sleep current of the bare bones ESP32S3 board is 3mA, so 4mA for the board with camera and SD card is not too much of an issue.
I doubt SEEED can do much about the ESP32S3 light sleep current, that would be down to Espressif.
Yup. It depends on what you’re trying to achieve.
If you want your device to run for months 4mA is not going to be good enough but it’s just fine for my application which needs to run pretty much continuously during the day but deep sleep at night. Having switched to OV3660 I can now get 1mA deep sleep current overnight and if I can stretch out the day time activity with short periods of light sleep I might get battery life up to one week and then I’d be delighted.
Yes - I had problems with adjusting the focus. The camera lenses seem to be glued into an ‘infinity’ position and the glue needs breaking before the lens can be focussed. I ended up making a 3D printed focus puller which fits over the lens and engages with the crenellated edges to allow me to change the focus without requiring the services of an 8-year old with nimble fingers.
In your example sketch you didn’t post your definition of photo_save(filename).
Not sure if you’re aware but the camera driver typically actually ‘takes’ the photo when you return the frame buffer using esp_camera_fb_return().
So if you return the frame buffer before putting the camera into standby I think you’ll find the first photo you get when you call esp_camera_fb_get() will be the last one before standby.
Each photo has a fb->timestamp and fb->timestamp.tv_sec can be compared with millis() *1000 to see how old it is in seconds. Might be interesting to explore.
Supposedly the driver was altered so that if you set config.grab_mode to CAMERA_GRAB_LATEST and config.fb_count to 2 or more it will keep replacing old frames with new ones in the background. (The driver sets up an RTOS task called cam_task to do this in another thread). I’m not sure that this always works and anyway I don’t really want new frames continually being transferred from the camera to the CPU just in case you happen to call esp_camera_fb_get and want the latest. This must consume power. I’d rather be in control with grab_mode = CAMERA_GRAB_WHEN_EMPTY and unblock the driver by calling esp_camera_fb_return immediately before esp_camera_fb_get() so it requests a new frame only when you’ve made space for it.
It would be interesting to explore if there is a difference in current drain when taking occasional pictures in CAMERA_GRAB_LATEST mode vs CAMERA_GRAB_WHEN_EMPTY mode.
1 Like
NB Looking at the datasheet for OV3660 the standby current is apparently 20uA -40 uA so I guess most of the additional power consumption in light sleep when using the Sense board is due to the regulators, SD card and microphone.
1 Like
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