6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7416
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: low-level interfacing to OV5647

Wed Apr 29, 2015 4:21 pm

@jbeale - slightly odd request. Seeing as you appear to have I2C analysis tools, could you capture and post the I2C comms when using raspi[still|vid] with -md 2 (5MPix mode)? Even better if you force the exposure time with -ss 60000 first.

There is method in my madness (honest), and things will hopefully become clearer very soon :)
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
jbeale
Posts: 3499
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: low-level interfacing to OV5647

Wed Apr 29, 2015 4:42 pm

Hi 6by9. Haven't played with this since my last post on it two years ago... I decided then my time was more usefully spent elsewhere than random probing of undocumented registers. However I'd be happy to help out with an I2C dump if that's useful to you. Will need to wait until tonight. I presume I'll want to upgrade the Pi to the current firmware version first.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7416
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: low-level interfacing to OV5647

Wed Apr 29, 2015 5:24 pm

jbeale wrote:Hi 6by9. Haven't played with this since my last post on it two years ago... I decided then my time was more usefully spent elsewhere than random probing of undocumented registers. However I'd be happy to help out with an I2C dump if that's useful to you. Will need to wait until tonight. I presume I'll want to upgrade the Pi to the current firmware version first.
Thanks. Before the weekend would be useful, but not desperate. Any firmware that supports the mode selection (ie since end August 2014) will be fine.
No need to analyse the dump. I'm just trying to side-step NDAs :D
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
jbeale
Posts: 3499
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: low-level interfacing to OV5647

Thu Apr 30, 2015 4:56 am

I made a quick 'n' dirty connection to the I2C lines on a R-Pi camera board. Those two resistors at upper right marked 183 are 18k pullups from SCL, SDA to +3V3 and the wire at far left (near J1 silkscreen label) is ground. (The camera board schematic is not published, but the ribbon cable connects 1-to-1 with the RPi board connector J3 which is published: https://www.raspberrypi.org/documentati ... matics.pdf )

Image
Attached is a zip file with four I2C logs of the traffic between R-Pi and camera module, matching the four commands listed (two raspistill, and two raspivid). The files show only the valid I2C transactions, but there are two groups of six bytes sent before these, maybe just to "warm up" the interface: 0x6C 6D 6C 6D 6C 6D (eg. 0-length Write and Read commands) then a gap of 1.02 msec and then those six bytes again, another gap and the start of a third group, whereupon the camera returns with 0x00 0x00 and then the command flow starts, with a query of register 300A which reads out as 0x56 0x47 (sound familiar? This is the Omnivision OV5647 sensor.) The I2C clock by the way is always 100 kHz.
RPi-cam-I2C-preamble.jpg
I2C preamble bytes
RPi-cam-I2C-preamble.jpg (59.3 KiB) Viewed 6936 times

Code: Select all

Commands logged in the zip file:
rstill-2s.csv :  raspistill -md 2 -ss 60000 -o t2.jpg
rstill-3.csv  :  raspistill -ss 60000 -o t3.jpg
rvid-1.csv    :  raspivid -md 2 -t 5000 -o t1.h264
rvid-2.csv    :  raspivid -t 5000 -o t2.h264

[email protected] ~ $ uname -a
Linux rp21 3.18.12-v7+ #782 SMP PREEMPT Tue Apr 28 19:54:13 BST 2015 armv7l GNU/Linux
[email protected] ~ $ vcgencmd version
Apr 28 2015 18:46:46
Copyright (c) 2012 Broadcom
version f33c3f25a8bdb3522ba6b47871e15897acc223da (clean) (release)
raspstill-vid-i2c-logs.zip
(56.92 KiB) Downloaded 354 times
For the casually curious, here's a snippet from the start of one log file. The second column "Packet ID" shows the groups of I2C bytes from "I2C Bus Start" to "I2C Bus Stop" conditions.

Code: Select all

# raspivid -md 2 -t 5000 -o t1.h264
Time [s],Packet ID,Address,Data,Read/Write,ACK/NAK
                                       # packets 1-14 are empty Write/Read commands
0.0038339375,15,0x6D,0x00,Read,ACK     # first null byte read as OV5647 I2C interface wakes up
0.0039239375,15,0x6D,0x00,Read,NAK     # second null byte
0.00413475,16,0x6C,0x30,Write,ACK      # Packet 16: setup register address 0x300A
0.00422475,16,0x6C,0x0A,Write,ACK
0.0044248125,17,0x6D,0x56,Read,ACK    # Packet 17: read out contents: 0x5647
0.0045148125,17,0x6D,0x47,Read,NAK
0.005199625,18,0x6C,0x01,Write,ACK   # Packet 18: write register 0x01 03 with 01
0.005289625,18,0x6C,0x03,Write,ACK
0.005379625,18,0x6C,0x01,Write,ACK  
0.005589625,19,0x6C,0x01,Write,ACK  # Packet 19:  ...etc.
0.0056796875,19,0x6C,0x00,Write,ACK  
0.0057696875,19,0x6C,0x00,Write,ACK
0.088782375,20,0x6C,0x01,Write,ACK
0.088872375,20,0x6C,0x00,Write,ACK
0.088962375,20,0x6C,0x00,Write,ACK

User avatar
jbeale
Posts: 3499
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: low-level interfacing to OV5647

Thu Apr 30, 2015 6:05 am

Here are three additional I2C logs in case of interest, resulting from these commands:

Code: Select all

raspivid -md 2 -ex night -t 5000 -o t1.h264
raspivid -md 2 -ss 60000 -t 5000 -o t1.h264
raspivid -ss 60000 -t 5000 -o t1.h264
raspivid-i2c-logs2.zip
additional raspivid I2C logs
(24.05 KiB) Downloaded 292 times

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7416
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: low-level interfacing to OV5647

Thu Apr 30, 2015 6:44 am

Perfect. Thank you very much.

I hadn't noticed that the driver did a readback of each write during startup. I guess someone had I2C issues when they first brought the camera up, although it appears not to check the return values so it doesn't actually do much good :?
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23876
Joined: Sat Jul 30, 2011 7:41 pm

Re: low-level interfacing to OV5647

Thu Apr 30, 2015 7:50 am

6by9 wrote:Perfect. Thank you very much.

I hadn't noticed that the driver did a readback of each write during startup. I guess someone had I2C issues when they first brought the camera up, although it appears not to check the return values so it doesn't actually do much good :?
Sounds like Bruce Code (tm)
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7416
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: low-level interfacing to OV5647

Thu Apr 30, 2015 9:04 am

jamesh wrote:
6by9 wrote:I hadn't noticed that the driver did a readback of each write during startup. I guess someone had I2C issues when they first brought the camera up, although it appears not to check the return values so it doesn't actually do much good :?
Sounds like Bruce Code (tm)
No comments as to why they bothered, and flawed logic - yes, I expected ABG or JNAH to be the committer ;)
Some history lost as initial dev was brought across with that logic by dc4 as a block integrate. Checking the source branch for the integrate we actually see our other friend known for dodgy drivers, also with the initials AG. To be fair, there was a logging line on that branch that printed out the read back value, so it's whoever removed that that ought to have looked at the surrounding code - not going to check who did that in case I incriminate myself!
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23876
Joined: Sat Jul 30, 2011 7:41 pm

Re: low-level interfacing to OV5647

Thu Apr 30, 2015 9:10 am

6by9 wrote:
jamesh wrote:
6by9 wrote:I hadn't noticed that the driver did a readback of each write during startup. I guess someone had I2C issues when they first brought the camera up, although it appears not to check the return values so it doesn't actually do much good :?
Sounds like Bruce Code (tm)
No comments as to why they bothered, and flawed logic - yes, I expected ABG or JNAH to be the committer ;)
Some history lost as initial dev was brought across with that logic by dc4 as a block integrate. Checking the source branch for the integrate we actually see our other friend known for dodgy drivers, also with the initials AG. To be fair, there was a logging line on that branch that printed out the read back value, so it's whoever removed that that ought to have looked at the surrounding code - not going to check who did that in case I incriminate myself!
Ah yes, the other AG. Forgot about that one. IIRC, the 5647 was one of his....
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7416
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: low-level interfacing to OV5647

Thu Apr 30, 2015 11:20 am

jamesh wrote:Ah yes, the other AG. Forgot about that one. IIRC, the 5647 was one of his....
Yup, when I saw it I also remembered the pain of fixing flips in the sensor, not clipping exposure times correctly, you fixed not obeying framerate requests at all, and there's also a commit for an issue where you could get recursive calling between two functions and die in a heap.
All in all, a lovely job of doing a half-baked driver to start with. And so many people in the community want to have a go at it too as it "can't be that hard"....
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7416
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: low-level interfacing to OV5647

Fri May 01, 2015 9:34 pm

All is revealed viewtopic.php?f=43&t=109137
Many thanks again for doing that.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

oringo
Posts: 2
Joined: Tue May 12, 2015 2:44 pm

Re: low-level interfacing to OV5647

Tue May 12, 2015 3:23 pm

jbeale and 6by9,

I'm new to this forum, and thank you both for doing the work to make the camera interface more hackable.

I've been decoding the I2C dumps provided by jamesh, and I think some of the missing registers can be found if you search for omv 5642 v1.11 spec. Nevertheless, combining both specs still doesn't give you the whole picture.

There's something interesting I noticed about the 5647 spec. Register 0x3b07 configures the frame exposure (FREX) mode. The I2C dump provided by jamesh indicates that a value of 0xC is written to 0x3b07, which would mean (in 5647 spec) that frame exposure is enabled, frex_inv is selected (not sure what that means), and FREX mode 1 is selected (which means external FREX pin is used to control the exposure. However, this is inconsistent with our understanding of the raspberry pi camera. First, we know that the pi camera is operating in rolling shutter mode (i.e. not FREX mode), and, secondly, RPi doesn't output a FREX signal to control the exposure (CAM_GPIO and CAM_CLK have all been discussed before).

However, if you read the 5642 spec, writing 0xC to this register (0x3b07) would've made more sense. It would've selected the rolling shutter mode in the camera. So this is leading me to suspect the preliminary 5647 specs that's circulated on the web is either deliberately badly written or just very poorly written.

Finally, the mechanism to trigger the shutter is still a mystery to me. The last commands in the I2C dump is a group register write command to the exposure duration registers. Perhaps that's a back-handed/undocumented way to trigger the exposure?

User avatar
jbeale
Posts: 3499
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: low-level interfacing to OV5647

Tue May 12, 2015 4:50 pm

As far as I know, I'm the only one who has provided I2C dumps online, although it's pretty easy to do for anyone with a RPi, camera board and I2C analyzer (the Dangerousprototypes Bus Pirate is under $30).

The OV sensor chips are very complex, and I believe the documentation is intentionally vague and incomplete, maybe to discourage competitors. My understanding is that the only people who really know how to program the chips, are under NDA that prevents them from telling. However I'd love to be proved wrong on that.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23876
Joined: Sat Jul 30, 2011 7:41 pm

Re: low-level interfacing to OV5647

Tue May 12, 2015 4:55 pm

jbeale wrote:As far as I know, I'm the only one who has provided I2C dumps online, although it's pretty easy to do for anyone with a RPi, camera board and I2C analyzer (the Dangerousprototypes Bus Pirate is under $30).

The OV sensor chips are very complex, and I believe the documentation is intentionally vague and incomplete, maybe to discourage competitors. My understanding is that the only people who really know how to program the chips, are under NDA that prevents them from telling. However I'd love to be proved wrong on that.
I wouldn't ascribe to maliciousness what could be ascribed to getting the engineers to write the documentation. Even people under NDA still need to talk to Omnivision themselves. A lot.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I think it’s wrong that only one company makes the game Monopoly.” – Steven Wright

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7416
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: low-level interfacing to OV5647

Tue May 12, 2015 9:01 pm

oringo wrote:I'm new to this forum, and thank you both for doing the work to make the camera interface more hackable.

I've been decoding the I2C dumps provided by jamesh, and I think some of the missing registers can be found if you search for omv 5642 v1.11 spec. Nevertheless, combining both specs still doesn't give you the whole picture.
jbeale needs to take the credit for those register sets, for which I am very grateful. Jamesh has done lots of great work, but not this time.

In answer to the comment on FREX registers I refer you to the comments in the source with reference the registers (https://github.com/6by9/userland/blob/r ... iraw.c#L73):

Code: Select all

// These register settings were as logged off the line
// by jbeale. There is a datasheet for OV5647 floating
// about on the internet, but the Pi Foundation have
// information from Omnivision under NDA, therefore
// we can not offer support on this.
// There is some information/discussion on the Freescale
// i.MX6 forums about supporting OV5647 on that board.
// There may be information available there that is of use.
//
// REQUESTS FOR SUPPORT ABOUT THESE REGISTER VALUES WILL
// BE IGNORED.
I can not, and will not, get into discussions about them, and the same is probably true for jamesh.
The values were derived with assistance from one of the Ominvision support engineers under an NDA.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

oringo
Posts: 2
Joined: Tue May 12, 2015 2:44 pm

Re: low-level interfacing to OV5647

Tue May 12, 2015 10:44 pm

jbeale wrote:As far as I know, I'm the only one who has provided I2C dumps online, although it's pretty easy to do for anyone with a RPi, camera board and I2C analyzer (the Dangerousprototypes Bus Pirate is under $30).

The OV sensor chips are very complex, and I believe the documentation is intentionally vague and incomplete, maybe to discourage competitors. My understanding is that the only people who really know how to program the chips, are under NDA that prevents them from telling. However I'd love to be proved wrong on that.
Sorry, I meant the I2C dumps provided by jbeale. I got jamesh and jbeagle mixed up :). I've sent out a request for the official datasheet via omnivision's website, not sure if I will get it without an NDA. If I do, I'd be able to make a comparison to the unofficial version.

I should explain why I am interested. My hope is to be able to unlock the global shutter mode for this sensor to make it do more interesting computer vision work. My plan is to try and write a different value to 0x3b07 and see if the sensor will still capture frames. 6by9 has provided a nice framework for it, which I intend to use. I'm guessing I need to use mode 2 and use 0x3b08 to strobe the exposure, and set up the exposure value in 0x3b01, 0x3b04, and 0x3b05. Currently the i2c dump indicates that it's setting the exposure through 0x3501, 0x3502, and 0x3503.

User avatar
jbeale
Posts: 3499
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: low-level interfacing to OV5647

Tue May 12, 2015 10:51 pm

My experience suggests official OV documents are hard to get, but good luck! If you want to experiment, I'd try changing some values and see what happens. Maybe won't do anything or lock up, but even in the worst case, the camera board is not that expensive...

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7416
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: low-level interfacing to OV5647

Wed May 13, 2015 8:45 pm

jbeale wrote:My experience suggests official OV documents are hard to get, but good luck! If you want to experiment, I'd try changing some values and see what happens. Maybe won't do anything or lock up, but even in the worst case, the camera board is not that expensive...
AFAIK there is no OTP or other memory in use on the OV5647, so you shouldn't be able to kill it via I2C ever. Whether it will produce frames is a very different question.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

sudo-i
Posts: 6
Joined: Thu Jan 08, 2015 11:37 pm

Re: low-level interfacing to OV5647

Wed Jun 17, 2015 12:28 pm

well, on this video he used similar sensor to raspberry pi offical camera, https://www.youtube.com/watch?v=_eOmupheXlE on the datasheet there is another option like cen_global_o 0x3021, maybe we can enable it and alternate timing to get clear HDR video from 720p60 (currently using it on Magic Lantern with my Canon t2i, works fine)
trying to make the best outta my time on this pale blue dot.

zenmsav
Posts: 4
Joined: Mon Jul 13, 2015 7:42 pm

Re: low-level interfacing to OV5647

Tue Jul 14, 2015 5:16 pm

Hello, I'm relatively new to raspberry pi and the camera. I'm searching for the ever elusive frame lock solution, and thought this might be a place to start looking. JBeale, can you provide a picture of how your pi and logic analyzer are setup, I have access to a 32 channel Link Instruments Logic Analyzer at my university however I don't really know how to safely set it up. Additionally, all of the deadbeat EE professors are "too busy" to help me. Really, all I need need is a setup that I can listen in to the entire CSI while operating my R-Pi and Camera normally.

User avatar
jbeale
Posts: 3499
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: low-level interfacing to OV5647

Tue Jul 14, 2015 10:59 pm

This is the connection I made between my logic analyzer and the RPi camera board. You only need three wires: ground, SDA, SCL. The logic level is 3.3 volts.
viewtopic.php?f=43&t=47798&start=25#p748855

I don't know what you mean by "frame lock". If you mean lock exposure, that is already possible through software. If you mean synchronize to the start-of-frame for each frame when recording video, I'm not sure that is possible even with the I2C signals exposed, because the image data goes through a separate high-speed (>350 MHz?) MIPI2 interface and that is asynchronous to the slow speed 100 kHz I2C.

If you are interested in timing: I was playing around with the recently-unveiled raw interface to the camera (raspiraw) as mentioned here:
viewtopic.php?f=43&t=109137&start=50#p787670

and the raspiraw program spits out an image buffer (callback?) time apparently measured in microseconds. I'm not sure what clock that is or how to relate it to an external "real time" signal, but it certainly has high resolution.

zenmsav
Posts: 4
Joined: Mon Jul 13, 2015 7:42 pm

Re: low-level interfacing to OV5647

Wed Jul 15, 2015 1:54 am

Wow, okay thank you for all of that information. I'm unclear what the difference between exposure lock and start of frame lock are different. Additionally, I was unaware of the raw mode you discussed. I was also looking into compoundpi python api however I was having some difficulty installing it on the client side which is a ubuntu laptop(I'm new to linux and ubuntu) thank you for the help I'm over the Atlantic but I'm very pleased with how active this community is.

DonSerge84
Posts: 5
Joined: Sun Nov 01, 2015 5:18 pm

Re: low-level interfacing to OV5647

Tue Nov 03, 2015 11:58 pm

Hi everybody
@jbeale: do you think it is possible to recognize a new frame starting, analysing the i2c or MIPI channels? My intention is to realize start-of-frame-sync between several RPis. This is my idea:

-choose cam settings that lead to a constant frame length
-detect every start of frame by analysing the CSI
-make a PLL between the start of frames of each RPi adjusting their clock speeds :) (assuming that clock speed adjusting at run time is possible and there is a dependency between system clock and SCI clock)

User avatar
jbeale
Posts: 3499
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: low-level interfacing to OV5647

Wed Nov 04, 2015 6:22 am

Not sure but If I recall correctly, once the camera is setup for continuous video acquisition there may not be I2C traffic; the start-of-frame signalling may be only on the MIPI CSI2 (high-speed) bus, not the relatively slow 100 or 400 kHz I2C bus. I don't have an analyzer fast enough to work on the MIPI bus. It's possible that some lower-speed hack might still work if there is enough "dead time" between frames to be detected with a limited bandwidth envelope detector, or the like.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7416
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: low-level interfacing to OV5647

Wed Nov 04, 2015 11:23 am

Start of frame signalling is only present on the CSI-2 bus, not I2C. I2C is only used for issuing control commands to the sensor. You'll need a moderately powerful FPGA to extract the relevant signals from the CSI-2 stream, but that's probably unnecessary.

Both the MMAL camera component and the rawcam present the GPU system time (usecs since boot IIRC) of the start of frame interrupt in the buffer pts field. The MMAL camera component supports parameter MMAL_PARAMETER_FRAME_RATE that takes a rational value for the frame rate and can be adjusted whilst streaming.
Compare your frame timestamps, and then alter the frame rate of one of the sensors to compensate for any drift. Don't tweak the value too often as there is probably 2 frames of latency on it being applied.
You will need to make sure that the use_stc_timestamp field in MMAL_PARAMETER_CAMERA_CONFIG is set to MMAL_PARAM_TIMESTAMP_MODE_RAW_STC.

With rawcam, you'll need to tweak the frame extension length to alter the frame rate. Due to NDA's I can't give any information on that, but you could compare the I2C commands between running at 30fps and 29fps and reverse engineer what we do. Tie that up with the datasheet and that should confirm what is happening.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Return to “Camera board”