You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems BB's original circuits were designed to overcome protection/clamping diodes or back-power the 1.8V supplies of cameras that were powered down! They were out of specification and can't be reverted to. But my recent "fixes" suffer voltage drops at startup, introducing a risk of spurious triggering.
Specifically,
The 10K:10K divider pull-up is not strong enough to give a high level for more than one HQ camera, when some cameras are powered down.
Some readers have interpreted that 10K resistance as normative for an external driver (though it was indicated for a pull-up).
The voltage divider for Pico GPIO ->GS Camera XTR now gives safe voltage levels, but its quiescent state (when Pico is not driving the GPIO) will be low instead of floating.
The main part of the fix is a kernel/DT change (currently in the works here) to allow the camera's 1.8V supply rail to stay up even when the camera is not streaming, so it won't clamp its inputs to 0V.
Then we'll need to:
Describe how to use the new overlay parameter to keep the cameras powered on;
Remove the external fixed pull-up circuit for HQ Cameras;
Figure out the best startup order for Pico -> GS Camera;
Document the configuration file used to control CSI-2 timeouts (since it's needed but was undocumented);
Maybe fill in the fourth combination: How to drive multiple HQ cameras from an external trigger (since people seem to want to do it).
I've opened this as an issue rather than a PR to give me time to think about it and to invite comments.
The text was updated successfully, but these errors were encountered:
Another installment in the #3146 #3237 saga.
It seems BB's original circuits were designed to overcome protection/clamping diodes or back-power the 1.8V supplies of cameras that were powered down! They were out of specification and can't be reverted to. But my recent "fixes" suffer voltage drops at startup, introducing a risk of spurious triggering.
Specifically,
The main part of the fix is a kernel/DT change (currently in the works here) to allow the camera's 1.8V supply rail to stay up even when the camera is not streaming, so it won't clamp its inputs to 0V.
Then we'll need to:
I've opened this as an issue rather than a PR to give me time to think about it and to invite comments.
The text was updated successfully, but these errors were encountered: