Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bright flashes on 320x32 resolution with max fps after reboot #165

Open
skronstein opened this issue Mar 16, 2020 · 2 comments
Open

Bright flashes on 320x32 resolution with max fps after reboot #165

skronstein opened this issue Mar 16, 2020 · 2 comments
Labels
p2 This issue will impact most users of the camera, but the camera is still usable.

Comments

@skronstein
Copy link
Contributor

At 320x32 resolution with max fps, some frames are excessively bright. This only happened at max fps, and only after a reboot.
It went away after switching to another resolution and back to 320x32 resolution with max fps.
It also did not occur with fps lowered to 20k, even after a reboot.

tested on 0.4.0-beta27, FPGA revision 3.24

@skronstein skronstein added the p2 This issue will impact most users of the camera, but the camera is still usable. label Mar 16, 2020
@oskirby
Copy link
Contributor

oskirby commented Mar 26, 2020

These "bright flashes" can be recorded and they will show up in video memory like normal frames. However, when you observe them they are actually just random data, which tends to make them brighter than the valid frames thanks to FPN correction.

The frequency at which they occur seems to be related to the recording speed of the camera, and there appears to be something stateful about this corruption. Switching framerate and back will sometimes make the camera come good, after which no corruption will occur. When examining the register maps of the FPGA and camera both in the good and corrupted states shows identical register mappings.

I suspect that this is more likely due to some kind of race condition in the FPGA, either in the recording sequencer or the deserializer that is getting the write addresses wrong, and it is simply unable to handle these extreme framerates without triggering the bug.

@oskirby
Copy link
Contributor

oskirby commented Mar 26, 2020

This issue also occurs on the LUX2100 if you modify the lux2100 driver to use a smaller minimum vRes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p2 This issue will impact most users of the camera, but the camera is still usable.
Projects
None yet
Development

No branches or pull requests

2 participants