Closed jpmeijers closed 2 years ago
I see we have full control over this: https://github.com/cjj25/Yi-RTS3903N-RTSPServer/blob/7763840399c08659c6b2e875bc4bca5a30f7f58b/build/src/stream.c#L138
In that case maybe we can come up with some hysteresis algorithm, and maybe add two config parameters to control the hysteresis levels. https://en.wikipedia.org/wiki/Hysteresis
Testing this it seems like reading the analog pin is noisy. In constant light I get this:
~ # cat /sys/devices/platform/rts_saradc.0/in0_input
3216
...
~ # cat /sys/devices/platform/rts_saradc.0/in0_input
3190
~ # cat /sys/devices/platform/rts_saradc.0/in0_input
168
~ # cat /sys/devices/platform/rts_saradc.0/in0_input
3087
~ # cat /sys/devices/platform/rts_saradc.0/in0_input
3187
~ # cat /sys/devices/platform/rts_saradc.0/in0_input
3236
~ # cat /sys/devices/platform/rts_saradc.0/in0_input
3297
~ # cat /sys/devices/platform/rts_saradc.0/in0_input
74
~ # cat /sys/devices/platform/rts_saradc.0/in0_input
3248
~ # cat /sys/devices/platform/rts_saradc.0/in0_input
3200
~ # cat /sys/devices/platform/rts_saradc.0/in0_input
3013
...
~ # cat /sys/devices/platform/rts_saradc.0/in0_input
3161
~ # cat /sys/devices/platform/rts_saradc.0/in0_input
93
~ # cat /sys/devices/platform/rts_saradc.0/in0_input
3216
I see similar noise in light conditions:
/var/tmp/sd # cat /sys/devices/platform/rts_saradc.0/in0_input
74
/var/tmp/sd # cat /sys/devices/platform/rts_saradc.0/in0_input
1086
/var/tmp/sd # cat /sys/devices/platform/rts_saradc.0/in0_input
71
...
/var/tmp/sd # cat /sys/devices/platform/rts_saradc.0/in0_input
81
/var/tmp/sd # cat /sys/devices/platform/rts_saradc.0/in0_input
912
/var/tmp/sd # cat /sys/devices/platform/rts_saradc.0/in0_input
84
...
/var/tmp/sd # cat /sys/devices/platform/rts_saradc.0/in0_input
74
/var/tmp/sd # cat /sys/devices/platform/rts_saradc.0/in0_input
999
/var/tmp/sd # cat /sys/devices/platform/rts_saradc.0/in0_input
71
Currently testing two things:
My PR does improve the switching, and solves the unnecessary clicks. I however realised that my camera's infrared reflects in the window, blinding the camera at night. Forcing day mode and relying on the outdoor lighting is therefore better.
Looking into this further I realised that my camera's IR is automatically controlled (in hardware?). Even if I override manage_ir_cut
to always switch off IR, my IR still goes on. IR and camera switch to night mode are also not synchronised, indicating that IR is not controlled by stream
.
Forcing day_mode_or_night_mode
to always switch to day mode, and two layers of insulation tape (one layer black, one layer white) over the IR LEDs results in a usable video.
You've been busy :)
Thank for your contribution, everything looks good and will more than likely get added to the repo. I just need to find a little time to test it.
I'm working on a romfs repack tool for these cameras that allow us to easily modify flash rom files and reflash them, the external stuff (light sensor and motors) are not connected at the minute while I'm playing with the SPI flash.
I realised that my camera's IR is automatically controlled (in hardware?)
You're right, all of the cameras I've seen so far manage this function automatically.
Where my camera is installed there is an outdoor light very close to it. This causes the camera to switch between night mode and day mode constantly. Causing an irritating click sound once or twice a minute, but also confusing my NVR's motion detection.
I see there is an option to lock the camera in night mode (
RTS_VIDEO_CTRL_ID_IR_MODE
). Is there a similar option to lock the camera into day mode?In my case the outdoor light gives enough light to use non-IR mode during the night. I also do not have control over this light, so I can not (legally) switch it off.