Adjusting exposure in dark environment conditions

[FBMinis]

It would be useful if this excellent program would allow adjusting the exposure level in dark environments. If not automatically, maybe in a percentage set through a telegram message like /10pc, ..., /50pc.

I've played with other programs that do it but they had some inconsistencies and I'm just a hobbyist, I couldn't solve them.

Here is a resized photo taken with v9.6:

Here is a resized photo (UXGA res, white balance set to cloudy) taken with https://github.com/raduprv/esp32-cam_ov2640-timelapse/blob/main/ov2640_timelapse_github.ino:

All I've found regarding the ov2640 sensor, I uploaded to this repository:
https://github.com/FBMinis/ov2640driversource

It seems the author accesses the register bank and "manually" adjusts a few of them after evaluating the "light" level, but I would get overexposed photos during the day,. Letting the sensor stabilize for a few milliseconds, while a wifi connection was established, before capturing the frame buffer seemed to mitigate it, but I could never fix it.

[jameszah]

I pasted the raduprv code as an option in telegram -- it works but changes the framesize to uxga, which is okay but it seems to do this with the frame length and line adjust, rather than just the framesize adjustment, so breaks the video recorder. I suppose you would want to use the full sensor if you are doing stills in the dark. Do you understand the raduprv stuff about "frame length adjustment" and "line adjust" ??? I looked at that a last year, but gave up on it.

Another option is to shut off the exposure control inside the camera, and let the esp32 make the exposure decisions, using those registers or just the camera driver calls. I'll have a look at it.

[FBMinis]

Do you understand the raduprv stuff about "frame length adjustment" and "line adjust" ??? I looked at that a last year, but gave up on it.

I don't know how he decided to do things that way. I exchanged a few messages with him through the Issues section and google his online presence, and I realized it involved a lot of trial and error, due to the absence of a final datasheet version for the ov2640 sensor - which would include info about specific registers.

raduprv/esp32-cam_ov2640-timelapse#5
espressif/esp32-camera#203

I found this today, which seems to be a bit of a breakthrough:

esphome/esphome#1584

esphome/esphome#3090

https://github.com/esphome/esphome/compare/dev...CarlosGS:patch-17?diff=split#diff-f205e83b01167d6f78e8280705d21898142c784d9c33670888b95c2c553ac3dc

[jameszah]

https://github.com/jameszah/ESP32-CAM-Video-Telegram/tree/main/test

Try this one - mostly working -- some capture failures???

I think those register parameters just force the sensor (or the shutter) to stay open for 500 or 5000ms to absorb light in the darkness. So not great for video.

use /radu to set up the exposure for current conditions - then it stays like that until you do it again.

You could add it in advance of every timed picture, although it can take 10 seconds plus, with all my test pictures.

[jameszah]

When you talk about the "heat" is that generated by reading the sensor, or just by the room ambient heat? I have trouble with various shades of green or purple after I change the registers, and start new pictures. It does settle down after 1 minute, but I have been trying to read the sensor many times to clear whatever -- but maybe let it sit for 10 seconds and cool, before reading it again?

[paoloinverse]

I'm generally talking about the sensor's temperature. The sensor's temperature is the result of the balance between the electrical power dissipated in the sensor's silicon, the power dissipated from the sensor into the heat sink and the power transferred between the heat sink and the ambient air. Operating a sensor without a heat sink, means the thermal resistance between the sensor and the ambient is very high, therefore the sensor will overheat while in use and reach an excessively high temperature.

The sensor's temperature is the key. The dark current is basically a temperature-dependent current leaking from the sensor's photodiodes into the corresponding pixel capacitances, charging the capacitance even when there is no light hitting the photodiode. The final result is the photodiode, and therefore the sensor, "sees" a uniform background "illumination" which does not actually exist, and yet it is slowly saturating the sensor. A completely black scenery appears a dull gray and finally completely white the longer your exposure gets. The ABLC function should mostly take care of this, but it seems normally disabled and I couldn't find a way to enable it. Same goes for the manual color channel balance, which could take care of your problem, see below.

Since the dark current leaking from the photodiodes is strongly temperature-dependent, using a good heat sink, with a fan and possibly a Peltier cell to actively cool the sensor will greatly reduce the dark current and therefore increase the maximum possible exposure time, while also reducing all of the physical noise sources.

Your problem with the shades of green and purple seems somewhat unrelated, it looks more like the automatic white balance / gamma correction loop require some time before reaching a stable operating point. When I use the OV2640 I normally disable the AWB, but a full minute before settling down? This looks suspicious.
More than waiting 10 seconds for the sensor to cool down, I'd attach it to a good aluminium or copper heat sink and see if there are any improvements. Also try disabling AWB and AWB_GAIN.

[jameszah]

Thanks - I'll try the awb and awb_gain -- I'm normally using the camera in daylight - often outside, where there would be significant heat and sunlight, but those effects must be hidden under the bright light. It seems connected with the change in register configuration which must mess up that calculation - my latest attempt was 8 seconds delay after register change, then 4 pictures, then another 8 seconds, and then save a jpg ... and it usually comes out green (in the 0-10 light level as seen by the automatic 2640 mode). But 60 seconds later without changing the settings it always come out fine.

[jameszah]

Do you know these registers to fiddle with the colors ... and do your own white balance calculation?
They don't seem to be in my copy of the manual, but are part of the esp32-camera driver for office/sunny/cloudy etc.
I can force them all to x7f to get a flat full color which seems to get rid of my green and purple problem after changing the camera settings, but when I go back to automatic mode, the white balance is better.

      sensor_t * sss = esp_camera_sensor_get();
      sss->set_reg(sss, 0xff, 0xff, 0x00); //banksel
      sss->set_reg(sss, 0xc7, 0x50, 0x50); //enable color control
      sss->set_reg(sss, 0xcc, 0xff, 0x05); //red 0..127 decimal
      sss->set_reg(sss, 0xcd, 0xff, 0x05); //green
      sss->set_reg(sss, 0xce, 0xff, 0x7e); //blue

[paoloinverse]

So I've done a few tests with my code, apparently I can trigger that strange hue shift, and it takes a large number of frames before it settles down. To be fair, I was streaming at about 10 fps and the hue settled down to normal in 2~3 seconds. If your frame rate is low, or you're taking longer exposures I assume the problem might get really bad.
But first of all, thank you for finding out about the channel registers! I didn't know where to look, I always assumed the presets were actually hardcoded in the sensor itself and the manual channel control never touched.
I agree, the normal AWB is more natural, but then we might want to try and read 0xcc 0xcd and 0xce while AWB is on: if their values are updated by the sensor, we might be able to find out the correct combination.
By the way, have you considered looking into the RAW_GAMMA switch too?
This might have something to do with correct color rendering as well.

My sensors are all running without infrared filter, so the normal AWB makes the colors washed out and the scene in sunlight converge to tones of gray (it's okay for my applications: I need to capture the full spectrum anyways and prefer using external colored glass filters to do what I want precisely.

About the black level calibration function, I found this 3rd party driver that's surprisingly well documented. Apparently, they either had access to the full final datasheet or talked with omivision directly.
Look for the keywork BLC:

https://github.com/adasngle/testmywatch/blob/master/custom/drv/Image_sensor/OV2640/image_sensor_OV2640.c
It would seem the 0x71 page 1 is the key one:
CamWriteCmosSensor(OV2640_PAGE_SETTING_REG, 0x01);
CamWriteCmosSensor(0x71,0x00);//freeze blc

and then there are two distinct values to activate BLC and perhaps a couple more registers that are involved but undocumented:

this one is used in the preview mode

// compensate OV2640 ABLC for every frame
CamWriteCmosSensor(OV2640_PAGE_SETTING_REG, 0x01);
CamWriteCmosSensor(0x71, 0x94); // reserved register

Force recalibration:

// To force OV2640 re-calibrate ABLC by changing global gain
CamWriteCmosSensor(OV2640_PAGE_SETTING_REG,0x01);
iTemp = CamReadCmosSensor(0x00);

if (iTemp == 0xFF)        
iTemp = iTemp - 0x1;    

else
iTemp = iTemp + 0x1;

CamWriteCmosSensor(0x00,iTemp);

CamWriteCmosSensor(0x71,0x96); //compensate OV2640 ABLC for every frame

Uh-oh the value is now 0x96?!? So apparently the bit 1 of 0x71 does something more!

Now then, let's look at the initial setting code for the OV2640, especially this delimited block of code:
//
CamWriteCmosSensor(0x20, 0x80); // reserved
CamWriteCmosSensor(0x28, 0x30); // reserved
CamWriteCmosSensor(0x6C, 0x00); // reserved
CamWriteCmosSensor(0x6E, 0x00); // reserved
CamWriteCmosSensor(0x70, 0x02); // reserved
CamWriteCmosSensor(0x71, 0x94); // reserved
CamWriteCmosSensor(0x73, 0xc1); // reserved
//
This block covers only "reserved" registers the last 5 of which are in the reserved range 63-7E page 1 of the preliminary datasheet.
apart from 0x71, the other reserved registers are touched only during setup.
My next run of tests will cover the values of these registers, but from what I see, 0x71 is normally set to zero in the ESP32 version of the OV 2640 driver.

Do you know these registers to fiddle with the colors ... and do your own white balance calculation? They don't seem to be in my copy of the manual, but are part of the esp32-camera driver for office/sunny/cloudy etc. I can force them all to x7f to get a flat full color which seems to get rid of my green and purple problem after changing the camera settings, but when I go back to automatic mode, the white balance is better.

      sensor_t * sss = esp_camera_sensor_get();
      sss->set_reg(sss, 0xff, 0xff, 0x00); //banksel
      sss->set_reg(sss, 0xc7, 0x50, 0x50); //enable color control
      sss->set_reg(sss, 0xcc, 0xff, 0x05); //red 0..127 decimal
      sss->set_reg(sss, 0xcd, 0xff, 0x05); //green
      sss->set_reg(sss, 0xce, 0xff, 0x7e); //blue

[FBMinis]

Took some photos inside the house after sending /radu and the increased light was noticeable, then placed the Cam outside (daytime) and the photos came over exposed, mostly blank. After sending /radu again I expect his settings would be completely disabled but the photos came back almost black and some moments later they'd come with a greenish hue.

Sending /clip made the Cam reboot.

I will try again in the evening but thank you for your time once more.

The option /fphoto is a welcome addition. Previously I was turning the flash ON, take a photo, turn it Off and then take another photo to make sure the LED was off (surprisingly bright led, isn't it?). On occasion, I've also kept it On while recording a /clip.

I've been running v9.5 for 8 days now without a single glitch, whereas with v8.9 I'd get some random reboots. I've also tested v9.6 with no negative results but have yet to put it in place.

[jameszah]

You have to call /radu every time the light changes.
So in a 10 second clip, you could call it once, but 10 minutes apart, or after moving camera, you would need to call it. Or add it to the timed photo to call it before every automatic photo.

[jameszah]

Also does not reboot into radu mode.

[FBMinis]

Thank you, I hadn't figured that out, I will keep it in mind.

[FBMinis]

In this example, I took a photo after booting, then called radu and the photo came out over exposed. Next, I brought the camera in, called radu again and the photos are almost black.

[jameszah]

ESP32-CAM-Video-Telegram/test/ESP32-CAM-Video-Telegram_9.7/radu.cpp

Line 72 in b9df451

s->set_framesize(s, (framesize_t)framesize); // framesize gets reset somewhere

Thinking of redoing the radu routine -- try to make an equation, and reset the camera less often. It resets the camera somewhere in the early lines of code (the framesize is reset), and then I reset it again when I change the framesize back, and then it is reset again for night mode, ...

I think it needs one reset, then a delay to measure the light, then set all those registers, then start a new snapshot for the long exposure to the darkness.
I pasted the code into a spreadsheet ... but then I needed a rest.

<style> </style>

		47	46		2a	2a dec	2b	2b dec	lla4msb	lla	2d	2e	45		aec1510	11	13	c	FrameLength	agc98
0		40			f0	240	ff	255	15	4095			3f		63	1	0	8	16384	0
1		40			d0	208	ff	255	13	3583			3f		63	1	0	8	16384	0
2		40			b0	176	ff	255	11	3071			3f		63	1	0	8	16384	0
3		40			70	112	ff	255	7	2047			3f		63	1	0	8	16384	0
4		40			40	64	ff	255	4	1279			3f		63	1	0	8	16384	0
5		20			80	128	ff	255	8	2303			3f		63	1	0	8	8192	0
6		20			40	64	ff	255	4	1279			3f		63	1	0	8	8192	0
7		20			30	48	ff	255	3	1023			3f		63	1	0	8	8192	0
8		20			20	32	ff	255	2	767			3f		63	1	0	8	8192	0
9		20			10	16	ff	255	1	511			3f		63	1	0	8	8192	0
10		10			70	112	ff	255	7	2047			3f		63	1	0	8	4096	0
12		10			60	96	ff	255	6	1791			3f		63	1	0	8	4096	0
14		10			40	64	ff	255	4	1279			3f		63	1	0	8	4096	0
18		8			b0	176	ff	255	11	3071			3f		63	1	0	8	2048	0
20		8			80	128	ff	255	8	2303			3f		63	1	0	8	2048	0
23		4			d0	208	ff	255	13	3583			3f		63	1	0	8	1024	0
27		4			80	128	ff	255	8	2303			3f		63	1	0	8	1024	0
31		4			60	96	ff	255	6	1791			3f		63	1	0	8	1024	0
35		2			70	112	ff	255	7	2047			3f		63	1	0	8	512	0
40		2			40	64	ff	255	4	1279			3f		63	1	0	8	512	0
45		4			a0	160	ff	255	10	2815			3f		63	1	0	8	1024	0
50		4			70	112	ff	255	7	2047			3f		63		0	8	1024	0
55		4			30	48	ff	255	3	1023			3f		63		0	8	1024	0
64		2			80	128	ff	255	8	2303			3f		63		0	8	512	0
75		2			50	80	bf	191	5	1471			3f		63		0	8	512	0
90		2			20	32	8f	143	2	655			3f		63		0	8	512	0
100		2			10	16	7f	127	1	383			3f		63		0	8	512	0
110		1			10	16	5f	95	1	351			3f		63		0	8	256	0
120		0			0	0	2f	47	0	47			3f		63		0	8	0	0
130		0			0	0	0	0	0	0			3f		63		0	8	0	0
						0		0	0	0					0
140	150	0	d0		ff	255	ff	255	15	4095	0	0	ff		63				208	3
	160	0	c0		b0	176	ff	255	11	3071	0	0	10		16				192	0
	170	0	b0		80	128	ff	255	8	2303	0	0	10		16				176	0
	180	0	a8		80	128	ff	255	8	2303	0	0	10		16				168	0
	190	0	a6		80	128	ff	255	8	2303	0	0	90		16				166	2
	200	0	a4		80	128	ff	255	8	2303	0	0	10		16				164	0
	210	0	98		60	96	ff	255	6	1791	0	0	10		16				152	0
	220	0	80		20	32	ff	255	2	767	0	0	10		16				128	0
	230	0	70		20	32	ff	255	2	767	0	0	10		16				112	0
	240	0	60		20	32	80	128	2	640	0	0	10		16				96	0
	253	0	10		0	0	40	64	0	64	0	0	10		16				16	0

[FBMinis]

It's admirable how you are reverse-engineering and finding a pattern between all those registers. Considering how exceptional v9.6 already is, I'm sure you will make it even better with a night-mode option. I'm just sorry I can't help more at this point.

[FBMinis]

Any progress on this? I'm eagerly waiting for this feature to be included.

Best wishes for 2023 : )

[jameszah]

I haven't got back to that yet.

Have you seen this:

https://github.com/paoloinverse/CameraWebServerRecordeR_AstroEdition

It is a fork of this one:

https://github.com/jameszah/CameraWebServerRecorder

... which is a modified version of the espressif camera app where you can control all the parameters of the ov2640 camera and its registers, where I added the video recorder to sd function. The fork by @paoloinverse adds the file manager and download code to fetch your videos. He describes which parameters to edit to take videos of the sky. I think you have to interactively make the adjustments for your sky, and then click record.

My idea was to measure the darkness and then add the register changes to record any level or darkness , and then add it to the telegram version, and the sd recorder version .... but have not got back to it yet.

[paoloinverse]

Hello,
apart from writing a bit of code to touch the AddVSYNC lines register (this is what does the big trick, along with setting the XCLOCK to 1MHz) and three other registers needed to stabilize the builtin autoexposure loop, I modified all the code segments that retrieve the frame buffer. The hardwired timeout makes the framebuffer call to fail silently and return nothing if the VSYNC time exceeds such timeout (it should be around 500ms, if I recall correctly). So what I did was to keep requesting the framebuffer at increasingly larger intervals until a valid pointer is returned. Without this modification, retrieving very long exposures would have been practically impossible. It goes without saying that recording a timelapse with very long exposures (say exceeding tens of seconds) might require a modification of the recorder code, as the intervals would otherwise be inconsistent. My mod is really designed for single very long exposures, so the frame buffer delay is not calculated in advance based on register settings, it's rather determined dynamically at each FB request.

Setting the prescaler register even to relatively low values appears to destabilize the sensor's internals, so I just stopped trying to use it to implement a form of night mode. AddVSYNC seems to really be the best way to go.

Be aware that before finding out about this, I reverse engineered and rewrote from scratch about 95% of the low level ESP32 drivers for the OV2640 and OV7255 sensors. I explored all of the documented registers in depth and determined what was useful, what was useless, and I also failed miserably at finding out how to enable and control the black level subtraction function.
However, I found out that cooling the OV2640 sensor, even mildly so, dramatically lowers the dark current to the point that actual astrophotography becomes a feasible option.

[jameszah]

Interesting ... I have not experimented with your instructions at your github to understand them. I think you key them in by hand -- they are not in the program???

So the AddVSYNC you are talking about is bank 1, 2d and 2e ? - radu uses these for the higher light levels?

Following the lowlight area from the raduprv program, I am just using this code below, where the case 0 has setting for 0-->50 and the number is the light level from 0x2f read while the camera is in automatic mode. Above 50, I leave the camera in automatic mode and it tries to control light to about 58-61. I am trying to get it working day and night and make the laborious effort to read the light and reset the camera occasionally.

The main thing is 0x47 frame length, and 0x2a to extend the exposure.

The exposure times come out like this:

There is some issue with the 4 second limit, that returns a frame capture failure ... so I lower the jpg quality to keep it under 4 seconds, and I am only using HD.

I think I am just scratching the surface of the complexity 😄

    s->set_reg(s, 0xff, 0xff, 0x01); //banksel
    s->set_reg(s, 0x13, 0xff, 0); //manual everything
    s->set_reg(s, 0x0c, 0x6, 0x8); //manual banding
 
case 0:  
        s->set_reg(s, 0x47, 0xff, 0x40); //Frame Length Adjustment MSBs
        s->set_reg(s, 0x2a, 0xf0, 0xff); //line adjust MSB
        s->set_reg(s, 0x2b, 0xff, 0xff); //line adjust

    s->set_reg(s, 0x43, 0xff, 0x40); //magic value to give us the frame faster (bit 6 must be 1)
    s->set_reg(s, 0xff, 0xff, 0x00); //banksel
    s->set_reg(s, 0xd3, 0xff, 0x8); //clock

    s->set_reg(s, 0x42, 0xff, 0x2f); //image quality (lower is bad)

    //no sharpening
    s->set_reg(s, 0x92, 0xff, 0x1);
    s->set_reg(s, 0x93, 0xff, 0x0);

[paoloinverse]

Sorry, I've never heard of raduprv before now, I'm looking into it right now.

Yeah, the default values for the options I added aren't hardcoded right now, although I plan to do it and to write a function to store them on the SD card and recall them on boot.

Regarding AddVSync, I'm only touching the MSB part of the register, on bank 1, reg 0x2e. The LSB is untouched, I don't need to fine tune anything right now.
About the Frame Length Adjustment register, 0x47 appears to be enforcing a hard limit to the frame lenght, so it actually limits what 0x2e can do.
About 0x2a, its effect appears to be a minor one, at the moment I haven't re-implemented it but yeah, if one wants to explore even longer exposures 0x2a will help.
To be honest, unless you actively cool the sensor or use it in low ambient temperatures (near freezing of below), the dark current effect will become very apparent before you finish the exposure.

Regarding the graph, it seems to be strictly raduprv -related. I'll comment on it later.

[FBMinis]

I just realized you didn't get my reply, I don't know what happened...

Thank you for mentioning that project, I wasn't aware of it. I tried it and indeed I was able to get some over-exposed photos. Hopefully you'll be able to merge that function with your code.

[jameszah]

https://youtu.be/WnQoIrel93o

Some progress on above video. 18? hours of 5 minute photos.

It is set up to use the regular exposure in the daytime and switch to radu mode at night. Some glitches in the transition.

The blinking light is not actually blinking, but the exposure is changing every frame. The light-meter in the camera is re-scaled every time you change the exposure, so I think I have to start at a fixed exposure, change the parameters for each exposure.

I think you would need a bright moon or stars to get anything without a bit of electric light.

Youtube seems to have added some stuttering ???

[FBMinis]

That area you're capturing probably looks pitch black without the radu mode, correct?

I have been away from home for over a month, I have not been able to test that CameraWebServerRecordeR_AstroEdition .

I have a camera pointing west for 4 months now, sending me photos periodically. The streetlights in the village have been replaced with LED and this area is quite well lit now but v9.5 can't capture it.

Another camera also running for 4 months.

10W LED buld (3000K)

months.

[jameszah]

Still struggling with the twilight - mode 0 day, mode 1 night - flips a couple times

[FBMinis]

Looking promising! I tried the AstroEdition firmware this weekend, it was challenging to play with all the variables but in the end I was able to get some decend photos. So far I haven't found much else by the same author, I wonder what kind of stuff he's been photographing.

[paoloinverse]

So far I just got the M12 telescope adapter ready but I haven't had the time yet to take night sky pictures.

The main thing is, right after I got the long exposure code working I embarked on the task of calibrating the spectral response of the OV2640 sensor and that has been quite rewarding. I now have working code for the wavelength calibration of a transmission grating spectrometer based on the OV2640 camera, and doing the black body part to get the spectral response is a matter of probably one more month, assuming I can pull together the optical path. Now I'm designing the parts to be 3D printed. Relevant screenshot (please don't mind the fake data points, those are default values before the actual calibration):
You see, long exposures are a must for spectrometry as well ;)

[FBMinis]

Came across this project, thought you might be interested:

https://verens.com/2020/12/29/computerised-telescope/

[jameszah]

Mostly working now, but still getting strange green shades when I change radu mode, but it is fine for the next minute at same settings ... taking a 25 pictures with various delays still ends up with some of these greens ????

[FBMinis]

Do you get that green even if you disable auto-wb and set it to cloudy mode, for example?

// Adjust sensor settings
s->set_whitebal(s, 1); // 0 = disable , 1 = enable
s->set_awb_gain(s, 1); // 0 = disable , 1 = enable
s->set_wb_mode(s, 2); // 0 to 4 - if awb_gain enabled (0 - Auto, 1 - Sunny, 2 - Cloudy, 3 - Office, 4 - Home)

[jameszah]

"cloudy" mode etc, just change those registers to an appropriate mix of light someone came up with.
That set_wb_mode() routine seems to fail half the time, but just writing the registers is relaiable.

https://github.com/espressif/esp32-camera/blob/36b8b4e096fbd5ecd6896eb113a2fb63b4769460/sensors/ov2640.c#L304

https://github.com/espressif/esp32-camera/blob/36b8b4e096fbd5ecd6896eb113a2fb63b4769460/sensors/private_include/ov2640_settings.h#L465

#define NUM_WB_MODES (4)
static const uint8_t wb_modes_regs[NUM_WB_MODES + 1][3] = {
    {0XCC, 0XCD, 0XCE },
    {0x5E, 0X41, 0x54 }, /* sunny */
    {0x65, 0X41, 0x4F }, /* cloudy */
    {0x52, 0X41, 0x66 }, /* office */
    {0x42, 0X3F, 0x71 }, /* home */
};

It might be based on this from 2017.
ArduCAM/Arduino#170 (comment)

This c3, bit 3, does not seem to have any control once you start using registers c7,cc,cd,ce.

      sss->set_reg(sss, 0xff, 0xff, 0x00); //banksel
      int awb = sss->get_reg(sss, 0xc3, 0x08);
      sss->set_reg(sss, 0xc3, 0x08, 0x08);

There are various white-balance algorithms on the internet, which would need raw rgb colors that are mixed by the algorithm. So you would fetch an rgb, then decide how to program the jpeg program inside the camera to deliver the correct colors without all the processing on the esp32 cpu.

[FBMinis]

Finally, I've been using your 'radu()' method to consistently capture over exposed photos in the dark. Every 30min between 7pm and 6am, I call the function 10 seconds after 'setup()' finishes running, a photo in UXGA resolution is taken and sent to Telegram using AsyncTelegram2 library.

While testing, I was using a powerbank and calling deepsleep between photos (now I use a DS3231 to power off). The results often included weird colors and cropped frames. Then I started powering everything with 4xAA Nimh and it's been running fine (I have another one running with smartphone battery through HT7833 LDO). It's a balancing act that includes letting the sensor stabilize and using a noiseless power supply, I'm guess.

In the gallery bellow, the dark photos were taken at like 18h30pm, then the 'radu()' kicks in.

Cheers

[jameszah]

Nice - I haven't thought about the sensitivity of power.

I have my old version of that code refined a little -- it uses the total light in the picture as a light meter to decide if you need to recalculate the exposure. I think the radu system always started from reboot, and did that every time, but I was trying to generalize it. I think the problem is that in a very slow exposure, like 30 seconds, you need to let it do maybe 5 exposure to do the color balance and whatnot, so it is 2-3 minutes to stabalize. And I was trying to recalc the exposure before the photo, where after the previous photo would be a better time.
I think it needs actual light. A full moon does not provide enough light on the trees to take a picture, but the moon in the sky and sometime stars will work, or indirect artificial light is enough.

I thought there might be a way to get an infrared like picture, but I don't so.

[FBMinis]

Regarding the need for actual light, when I was using the powerbank and deepsleep solution during testing, I had the camera pointed to the living room, which is almost in complete darkness; i'd often get completely dark or completely blank frames during the night while radu() would be called. Right now with he battery power, I havent had a single failure day and night, and during the night it actually picks up the lights on the router and set-top box. Hard to pinpoint the exact changes in code and hardware that resulted, Im just glad it's working...

Regarding infrared photography, I played with the ov2640 with lenses taken from laptop webcams (M7*0.5mm thread), which dont have the IR filter glued to it. I'm considering getting one of these M12 lens mount with IR filter activated by a GPIO:

aliexpress.com/item/1005006013536767.html

[FBMinis]

stock 8225n v2.0 lens compared to dcx-ov2640-v2 160 degree lens from Aliexpress