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

Re: low-level interfacing to OV5647

Wed Nov 04, 2015 5:05 pm

By the way, needing a M12-mount camera for a R-Pi, I bought this item: http://www.ebay.com/itm/281212352673 and surprisingly I got a different board than what was pictured on ebay. The board I got (photo below) has FREX and STROBE connections. The actual OV5647 chip here is I assume a BGA package, as there is no flex cable. It works as a normal Pi camera, but unfortunately I have been unable to see FREX/STROBE signals. I thought there was some register config to output some exposure-synchronized signal, but I've not found it, so the software approach 6by9 suggests is maybe the best one.

Image
Image

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6901
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 5:29 pm

NB I'm assuming you're on a Compute Module with both sensors connected to the same device, and therefore the two GPU STC timestamps are comparable.

If the two cameras are on different modules, you can use MMAL_PARAMETER_SYSTEM_TIME against any port on any MMAL component to get back the current GPU STC value, which you can then compare to a synchronised clock within the Linux world.
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.

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

Re: low-level interfacing to OV5647

Thu Nov 05, 2015 6:29 pm

thank you both very much! i will report in case of any progress :)

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

Re: low-level interfacing to OV5647

Mon Nov 16, 2015 12:13 am

Hello again!

As 6by9 recommended I now modified raspivid to have access to FPS, StartOfFrameTime and GpuSystemTime. Hereby I made a PLL which allows to sync the StartOfFrame with an GPIO-interrupt by controlling FPS. Typical (oscillating) deviations are below 200µs. I´m sure its possible to work this up to a more stable value near 0, but that is good enough for the first tests. So far I want to thank 6by9 and jbeale one time more for their recommendations!
Now the only thing missing is the fixed exposure time or shutterspeed (not equal as a read). I have a typical FPS between 16 and 17 due to my sync, and need shuttertimes about 2ms (deviations up to +/-1ms would be ok).
I tried mmal_port_parameter_set_uint32(port, MMAL_PARAMETER_SHUTTER_SPEED, 2000), but it does not seem to have any effects. But as I googled the commands, I found that it depends on the order of the command and they can interact, like -ss, ISO, PFS, and gain and even if you cannot set one value manually, you can achieve it approximately by tricks with other values or parameters, which the interesting value interact with. But unfortunately I could not find any tangible possibility for me working. Do you have any ideas how to manage that? Thanks in advance!

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

Re: low-level interfacing to OV5647

Mon Nov 16, 2015 12:39 am

DonSerge84 wrote:As 6by9 recommended I now modified raspivid to have access to FPS, StartOfFrameTime and GpuSystemTime. Hereby I made a PLL which allows to sync the StartOfFrame with an GPIO-interrupt by controlling FPS. Typical (oscillating) deviations are below 200µs.
Thanks for reporting back! Great work; I am very interested in what you did to accomplish this. I'd be interested in going the other way, that is generating a GPIO pulse that is synchronized to the StartOfFrame, while letting the camera continue to run at its normal video frame rate (eg. 24 fps). Do you think it is possible?

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

Re: low-level interfacing to OV5647

Mon Nov 16, 2015 7:08 pm

hey ho.. I solved my problem! (the one I mentioned yesterday;))
It really seemed to be the order of commands. I got it working by changing the shutter speed value in raspicamcontrol, which indeed uses the same mmal_port_parameter_set_uint32-command but in the determinated order and at the beginning of all mmal fun..
jbeale wrote: I'd be interested in going the other way, that is generating a GPIO pulse that is synchronized to the StartOfFrame, while letting the camera continue to run at its normal video frame rate (eg. 24 fps). Do you think it is possible?
It should be possible to give out a GPIO-sequence identical to the StartOfFrame-sequence, but with little delay. I would try this way:
1. read out StartOfFrame time of every frame
2. add a (constant) delay of some µs (small as possible, as big as need to get this timestamp in the future with a forerun, which is guaranteed big enough to react for GPIO-algorithm
3. now you need to switch GPIO at this time. here I´m not sure whether its possible, to initiate a time interrupt, with variable values, you can set every frame. That would be the most graceful solution. Another possibility would be, to give that timestamps in another thread, which polls the actual time in a loop and switches the GPIO when its time..

nthomson
Posts: 3
Joined: Mon Aug 06, 2012 10:54 pm

Re: low-level interfacing to OV5647

Tue Dec 08, 2015 4:52 pm

What is the best way to get frame sync between several cameras on serveral raspberry pis do people think then? I have the same boards with exposed Frex and strobe pins (http://www.arducam.com/raspberry-pi-cam ... rformance/), so if I can figure out a way to sync via frex pin would be ideal but I have little understanding of the MMAL (or C lang or firmware) - I contacted the boards designer Lee about the FREX pin, we are now both trying to figure out how to enable it :)

Is MMAL what issues commands to camera to change values of registers in OV5647? Can I send my own I2C commands? The documentation (which apparently is NDA but a quick google may find it) says there are two frex modes,1 is as input, 2 is as output. If the broadcom blob / MMAL is enabling mode 1 as I2C dump shows then we should be able to enable capture via FREX pin? Obviously though this is not the case as a capture occurs by some other means.

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

Re: low-level interfacing to OV5647

Tue Dec 08, 2015 6:16 pm

nthomson wrote:What is the best way to get frame sync between several cameras on serveral raspberry pis do people think then? I have the same boards with exposed Frex and strobe pins (http://www.arducam.com/raspberry-pi-cam ... rformance/), so if I can figure out a way to sync via frex pin would be ideal but I have little understanding of the MMAL (or C lang or firmware) - I contacted the boards designer Lee about the FREX pin, we are now both trying to figure out how to enable it :)
Several other threads on this already.
I have discussed it with an Omnivision apps engineer - there is no frame sync input on OV5647. In all situations the OV5647 operates in a rolling shutter mode. FREX acts as a global reset on all pixels which then starts exposing them all. Readout will start after the configured exposure time, but the lines continue exposing until they are read out. If you do not have externally controlled lighting or a mechanical shutter then the frame will be exposed for significantly longer (~66ms longer if 5MPix) at the bottom than the top.
nthomson wrote:Is MMAL what issues commands to camera to change values of registers in OV5647? Can I send my own I2C commands? The documentation (which apparently is NDA but a quick google may find it) says there are two frex modes,1 is as input, 2 is as output. If the broadcom blob / MMAL is enabling mode 1 as I2C dump shows then we should be able to enable capture via FREX pin? Obviously though this is not the case as a capture occurs by some other means.
See viewtopic.php?f=43&t=48238&p=775909#p775909
If, and only if, someone picks up the raw CSI access code and alters the I2C register set to do something that activates FREX in a useful way, then I will look at it further at changing the firmware. Beware that the public datasheet is marked preliminary - I think I saw at least up to a V1.9.

Seeing as the main Pi Foundation camera doesn't expose the FREX pin, there is little motivation to add something that is only useful on a device that takes sales away from their own device.

MMAL is the top level API for communicating to the GPU. There are about 4 layers code below that to get down to the sensor driver and register set. Only the sensor driver concerns itself over I2C commands as the rest is deliberately structured to make it easy to support multiple sensor types. There is no plumbing to allow userspace to override the I2C register set, and I would not intend to add any.
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: 3441
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: low-level interfacing to OV5647

Wed Dec 09, 2015 9:32 pm

What I was hoping for was some output that signaled start-of-frame for each and every frame when in video mode. Back when I looked into it (using the "prelim" online datasheet) it seemed to me this FREX signal was intended for use only with an external flash signal when taking still images, and activating it via software (asynchronously) involved dropping one or more frames. I made a few tries at register settings to activate it without success. It seemed probable it would not work in video mode at all, at least as I had hoped, so I lost interest in exploring further at that point.

backinside
Posts: 16
Joined: Fri May 15, 2015 10:07 pm

Re: low-level interfacing to OV5647

Thu Jan 28, 2016 1:47 pm

Hi,

I'm trying to get some I2C dumps with the Bus Pirate, but when I capture the data, it does not make sense
For me it seems like it's a synchronization issue, but I'm not sure, how to fix it

One tutorials add resistors between the data lines and 5V, but since I do get data, I did not try this (http://dangerousprototypes.com/forum/vi ... ing#p61125)

A tutorial suggested that noise from the power supply could interference with the I2C at 100Khz, I've tried adding a small (18pf) capacitor, but it did not help
(http://www.starlino.com/bus_pirate_i2c_tutorial.html)

One site (http://www.digitalpeer.com/blog/sniffin ... bus-pirate) reduces the I2C speed to 32k for similar reasons, but I'm not sure, if it's possible to do that for the internal I2C bus and still make the camera work

Do you have any idea, what I'm doing wrong here?

Thanks,
Peter

Here is sample of the output:

[0x6C-[0x6D-[]
[0x6C-[0x6D-[0x6C-[0x6D-[]
[0x6C-[0x6D-[]
[0x6C-[0x6D-[]
[0x6C-[0x6D-[]
[0x6C-[0x6D-[0x6C-[0x6D-[]
[0x6C-[0x6D+0x00+]
[0x6C+0x60+[0x6D+0xAC+]
[0x6C+0x02+0x0C+]
[0x6C+0x02+0x00+]
[0x6C+0x02+0x00+]
[0x6C+0x02+0x0C+]
[0x6C+0x60+0xD0+]
[0x6C+0x60+0xD4+]
]
[0x6C+0x60+0xD8-]
[0x6C+0x60+0xF0+]

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.

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

Re: low-level interfacing to OV5647

Thu Jan 28, 2016 2:49 pm

backinside wrote:One tutorials add resistors between the data lines and 5V, but since I do get data, I did not try this (http://dangerousprototypes.com/forum/vi ... ing#p61125)
I2C on the Pi is only 3.3V. Pullups to 5V will potentially kill the Pi.
The OV5647 claims to be only tolerant to 3V on the I/O pins, so be even more careful if you were looking directly on the sensor side of the interface board. (It runs on 1.8V and 2.8V supply rails, hence the lower working voltages).
backinside wrote:One site (http://www.digitalpeer.com/blog/sniffin ... bus-pirate) reduces the I2C speed to 32k for similar reasons, but I'm not sure, if it's possible to do that for the internal I2C bus and still make the camera work
It can be modified, but only by rebuilding the firmware so it's not an option available to you.

You don't say exactly what you're trying to do with the register set. You have the 5MP register set in my raspiraw source. If you were after the register sets for the other modes I might suggest you think about other locations where this data might be stored. Hint: little endian.
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.

backinside
Posts: 16
Joined: Fri May 15, 2015 10:07 pm

Re: low-level interfacing to OV5647

Fri Jan 29, 2016 2:51 pm

6by9 wrote:
backinside wrote:One tutorials add resistors between the data lines and 5V, but since I do get data, I did not try this (http://dangerousprototypes.com/forum/vi ... ing#p61125)
I2C on the Pi is only 3.3V. Pullups to 5V will potentially kill the Pi.
The OV5647 claims to be only tolerant to 3V on the I/O pins, so be even more careful if you were looking directly on the sensor side of the interface board. (It runs on 1.8V and 2.8V supply rails, hence the lower working voltages).
Well I have no idea, if sniffing the traffic requires the pullups, and I'm not sure if you can say yes or no :)
On the other hand (I hope it's not against any NDA or whatnot) I'm not sure, why the dudes on the forum use external resistors, when the bus pirate has internal pullups (http://dangerousprototypes.com/docs/Pra ... _resistors)
As far as I can understand, these internap pullups can be configuret to use 3.3V
Can I demage my HW if I enable the internal pullups with 3.3V?
6by9 wrote:
backinside wrote:One site (http://www.digitalpeer.com/blog/sniffin ... bus-pirate) reduces the I2C speed to 32k for similar reasons, but I'm not sure, if it's possible to do that for the internal I2C bus and still make the camera work
It can be modified, but only by rebuilding the firmware so it's not an option available to you.
I was under the impression, that i2c_vc_baudrate dtparm is for this, is it not the case?
6by9 wrote:You don't say exactly what you're trying to do with the register set. You have the 5MP register set in my raspiraw source. If you were after the register sets for the other modes I might suggest you think about other locations where this data might be stored. Hint: little endian.
I'm fully aware of the raw sensor access codes, you said in a reply that "If someone were to capture the I2C data for each of the modes that the GPU has configured", and this is what I'm trying to do, mainly for fun :)

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

Re: low-level interfacing to OV5647

Fri Jan 29, 2016 4:05 pm

backinside wrote:Well I have no idea, if sniffing the traffic requires the pullups, and I'm not sure if you can say yes or no :)
On the other hand (I hope it's not against any NDA or whatnot) I'm not sure, why the dudes on the forum use external resistors, when the bus pirate has internal pullups (http://dangerousprototypes.com/docs/Pra ... _resistors)
As far as I can understand, these internap pullups can be configuret to use 3.3V
Can I demage my HW if I enable the internal pullups with 3.3V?
Sniffing should just look at the lines, and those lines should have pull ups fitted for normal operation.
What I am warning against is adding additional pull ups to 5V, as you may blow your Pi. There are already 3.3V pull ups fitted on the camera board.
backinside wrote:
6by9 wrote:
backinside wrote:One site (http://www.digitalpeer.com/blog/sniffin ... bus-pirate) reduces the I2C speed to 32k for similar reasons, but I'm not sure, if it's possible to do that for the internal I2C bus and still make the camera work
It can be modified, but only by rebuilding the firmware so it's not an option available to you.
I was under the impression, that i2c_vc_baudrate dtparm is for this, is it not the case?
Only if you've done dtparam=i2c_vc=on to take sole control of the I2C peripheral from the ARM. You haven't as the GPU will still be setting up i2c0 when it talks to the camera, and it thinks it can talk at 100kHz.
backinside wrote:
6by9 wrote:You don't say exactly what you're trying to do with the register set. You have the 5MP register set in my raspiraw source. If you were after the register sets for the other modes I might suggest you think about other locations where this data might be stored. Hint: little endian.
I'm fully aware of the raw sensor access codes, you said in a reply that "If someone were to capture the I2C data for each of the modes that the GPU has configured", and this is what I'm trying to do, mainly for fun :)
I can not condone reverse engineering any of start_x.elf, but there's nothing that can be done to stop it.

FYI little endian representation means 0x3a18 as a 16 bit word would show up in a dump as 18 3a.
Take that as you will, otherwise persevere with your bus pirate.
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.

backinside
Posts: 16
Joined: Fri May 15, 2015 10:07 pm

Re: low-level interfacing to OV5647

Sat Jan 30, 2016 7:24 am

6by9 wrote:
backinside wrote:Well I have no idea, if sniffing the traffic requires the pullups, and I'm not sure if you can say yes or no :)
On the other hand (I hope it's not against any NDA or whatnot) I'm not sure, why the dudes on the forum use external resistors, when the bus pirate has internal pullups (http://dangerousprototypes.com/docs/Pra ... _resistors)
As far as I can understand, these internap pullups can be configuret to use 3.3V
Can I demage my HW if I enable the internal pullups with 3.3V?
Sniffing should just look at the lines, and those lines should have pull ups fitted for normal operation.
What I am warning against is adding additional pull ups to 5V, as you may blow your Pi. There are already 3.3V pull ups fitted on the camera board.
That's what I thought, but I'm no electrical engineer :)
6by9 wrote:
backinside wrote:
6by9 wrote:You don't say exactly what you're trying to do with the register set. You have the 5MP register set in my raspiraw source. If you were after the register sets for the other modes I might suggest you think about other locations where this data might be stored. Hint: little endian.
I'm fully aware of the raw sensor access codes, you said in a reply that "If someone were to capture the I2C data for each of the modes that the GPU has configured", and this is what I'm trying to do, mainly for fun :)
I can not condone reverse engineering any of start_x.elf, but there's nothing that can be done to stop it.

FYI little endian representation means 0x3a18 as a 16 bit word would show up in a dump as 18 3a.
Take that as you will, otherwise persevere with your bus pirate.
Yes I know, and I know what you mean ... it would be still fun to sniff the traffic :)
I'll do my experiments with the existing formats, but if anybody have any ideas, why the Bus Pirate output is trashed, let me know :)

backinside
Posts: 16
Joined: Fri May 15, 2015 10:07 pm

Re: low-level interfacing to OV5647

Mon Feb 08, 2016 11:20 am

I've managed to capture the I2C traffic of the camera with the I2C bus of the same Pi :)
I've attached the 640x480 90FPS I2C logs
@6by9 can you confirm, that this is correct? (it's not against the NDA right? :) )
Am I right, that 720p60fps video is not an option?
Attachments
[email protected]
(761 Bytes) Downloaded 171 times

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

Re: low-level interfacing to OV5647

Tue Feb 09, 2016 10:44 pm

You've got two modes logged there - they each start [6C+01+00+00+].
The second is [email protected] The first is 1296x972 at up to 42fps (2x2 binned).

If you're wanting to log these, then you're best off using the "-md X" option for raspistill/vid to force only one mode to be accessible and therefore programmed. Refer to the PiCamera docs for the cleanest listing of the modes. You've now got modes 2 (5MPix in raspiraw), 4 (2x2 binned), and 7 (VGA @ 90). There is no 720P60 mode configured - see the docs.
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.

backinside
Posts: 16
Joined: Fri May 15, 2015 10:07 pm

Re: low-level interfacing to OV5647

Thu Feb 11, 2016 7:40 pm

6by9 wrote:You've got two modes logged there - they each start [6C+01+00+00+].
The second is [email protected] The first is 1296x972 at up to 42fps (2x2 binned).
Thank you, I'll try to log all the relevant combinations :)
What parameters are meaningful to track down?
I know exposure, can you share, what else might be useful from I2C communication?
6by9 wrote:If you're wanting to log these, then you're best off using the "-md X" option for raspistill/vid to force only one mode to be accessible and therefore programmed. Refer to the PiCamera docs for the cleanest listing of the modes. You've now got modes 2 (5MPix in raspiraw), 4 (2x2 binned), and 7 (VGA @ 90). There is no 720P60 mode configured - see the docs.
I understand, that although the product brief states, the sensor is capable to deliver 720p60fps and 960p45fps, and this is not available on the Pi. Can you share, if it's a Pi issue, a camera board issue, a camera module issue, or is it "just" a software issue? :)

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

Re: low-level interfacing to OV5647

Thu Feb 11, 2016 8:42 pm

backinside wrote:Thank you, I'll try to log all the relevant combinations :)
What parameters are meaningful to track down?
I know exposure, can you share, what else might be useful from I2C communication?
You might want to look for exposure, analogue gain, and flips. NB That flips will change the Bayer order.
I suspect that the actual register numbers will be the same as the provisional datasheet you'll find floating around the internet - might reduce your search somewhat.
backinside wrote:I understand, that although the product brief states, the sensor is capable to deliver 720p60fps and 960p45fps, and this is not available on the Pi. Can you share, if it's a Pi issue, a camera board issue, a camera module issue, or is it "just" a software issue? :)
I think I do have the register set for some other modes, but there are field of view issues.
720P60 was done by cropping the binned 1296x976 down to 1280x720, so you lose some horizontal FOV. We got 1296x730 at 49fps working. I looked the other month as it looked like it is was one simple value wrong for closer to 60fps, but it didn't want to work.
960P45 would also be a crop - probably 1280x960, when we get [email protected] - close enough and full field of view.
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.

backinside
Posts: 16
Joined: Fri May 15, 2015 10:07 pm

Re: low-level interfacing to OV5647

Fri Mar 04, 2016 2:44 am

Hi,

It seems, something went wrong with my setup, and I can't seem to figure out, why
I'm experiencing the same behavior on my Pi2 and my Pi3 if I try to use the camera, with dtparam=i2c_vc=on in the /boot/config.txt
raspivid gives me the following output:

Code: Select all

[email protected]:~ $ raspivid -md 2 -t 5000 -o t1.h264
mmal: mmal_vc_component_create: failed to create component 'vc.ril.camera' (1:ENOMEM)
mmal: mmal_component_create_core: could not create component 'vc.ril.camera' (1)
mmal: Failed to create camera component
mmal: main: Failed to create camera component
mmal: Camera is not detected. Please check carefully the camera module is installed correctly
If I remove the config option, and restart, the same command works fine
I've experienced this once before, but installing the whole system fixed it, but this time, it's a fresh install
Any ideas?

Best regards,
Peter

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

Re: low-level interfacing to OV5647

Fri Mar 04, 2016 7:45 am

i2c_vc will pinmux i2c-0 to GPIOs 0&1. For Pi2 the camera is on 28&29, and the GPU will deal with that if you're using raspivid. Having two pins muxed to the same I2C function will fail. That is what my camera_i2c script is correcting, although I pushed some dt-overlays yesterday that allow configuring the GPIOs the ARM sets up for i2c0.

Do NOT use i2c_vc=on on Pi3. i2c0 is used by the GPU for additional functions, including controlling the camera power control GPIOs! Discussion ongoing (end of viewtopic.php?f=44&t=137848) over what can be arranged there. The camera I2C GPIOs have also moved.
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.

backinside
Posts: 16
Joined: Fri May 15, 2015 10:07 pm

Re: low-level interfacing to OV5647

Sun Mar 06, 2016 4:49 pm

6by9 wrote:
backinside wrote:Thank you, I'll try to log all the relevant combinations :)
What parameters are meaningful to track down?
I know exposure, can you share, what else might be useful from I2C communication?
You might want to look for exposure, analogue gain, and flips. NB That flips will change the Bayer order.
I suspect that the actual register numbers will be the same as the provisional datasheet you'll find floating around the internet - might reduce your search somewhat.
can the exposure, analogue gain, and flips set by the raspivid?
I've recorded the -vf and -hf options, but the I2C communications stayed the same

I've attached all the modes I've recorded, I've cleaned them up as I could without actually testing them, I'll make a patch request as soon as I can make them work with raspiraw.c
Attachments
mds.zip
(3.54 KiB) Downloaded 157 times

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

Re: low-level interfacing to OV5647

Sun Mar 06, 2016 8:35 pm

backinside wrote: can the exposure, analogue gain, and flips set by the raspivid?
I've recorded the -vf and -hf options, but the I2C communications stayed the same
-hf for horizontal flip (aka mirror)
-vf for vertical flip.
-ss for shutter speed (exposure)
-ISO for analogue gain
All I can really do is point you at the leaked datasheet for OV5647 http://www.seeedstudio.com/wiki/images/ ... 7_full.pdf
Sections 4.1 and 4.5.1 might give you some answers.
backinside wrote: I've attached all the modes I've recorded, I've cleaned them up as I could without actually testing them, I'll make a patch request as soon as I can make them work with raspiraw.c
Great. I really ought to create a PR to get raspiraw merged into the main userland repo, but it wasn't the highest job on my list and it still has quite a few rough edges.
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.

backinside
Posts: 16
Joined: Fri May 15, 2015 10:07 pm

Re: low-level interfacing to OV5647

Mon Mar 07, 2016 7:10 am

6by9 wrote:
backinside wrote: I've attached all the modes I've recorded, I've cleaned them up as I could without actually testing them, I'll make a patch request as soon as I can make them work with raspiraw.c
Great. I really ought to create a PR to get raspiraw merged into the main userland repo, but it wasn't the highest job on my list and it still has quite a few rough edges.
One issue I have with the captured data, is that most of the communication is register writes, that I can translate to the array in the raspiraw.c code, but there are 2 places, that seems wired:
[6C+38+20+[6D+41-]
[6C+38+21+[6D+01-]
[6C+38+20+41+]
[6C+38+21+03+]
It's like the communication queries the current state of these registers, and than changes them
So I think I'll just leave the first two lines out, and see if it works
But the other line is more wired (for me):
[6C+38+0E+03+12+]
It's like it's a longer value, but I can't seem to find any indication, that this should be the case, can you help me figure out, what's happening?
Last edited by backinside on Tue Mar 08, 2016 8:14 am, edited 1 time in total.

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

Re: low-level interfacing to OV5647

Mon Mar 07, 2016 8:13 am

backinside wrote:
6by9 wrote:
backinside wrote: I've attached all the modes I've recorded, I've cleaned them up as I could without actually testing them, I'll make a patch request as soon as I can make them work with raspiraw.c
Great. I really ought to create a PR to get raspiraw merged into the main userland repo, but it wasn't the highest job on my list and it still has quite a few rough edges.
One issue I have with the captured data, is that most of the communication is register writes, that I can translate to the array in the raspiraw.c code, but there are 2 places, that seems wired:
[6C+38+20+[6D+41-]
[6C+38+21+[6D+01-]
[6C+38+20+41+]
[6C+38+21+03+]
It's like the communication queries the current state of these registers, and than changes them
So I think I'll just leave the first two lines out, and see if it works[/quote]
Er, refer to the datasheet for 0x3820 and 0x3821 and I'll think you'll get your answer to an earlier question. You can hard code values if you know your parameters.
backinside wrote:But the other line is more wired (for me):
[6C+38+0E+03+12+]
It's like it's a longer value, but I can't seem to find any indication, that this should be the case, can you help me figure out, what's happening?
Refer to the datasheet. 0x380E - TIMING_VTS - Total vertical size [9:8]
0x380F - TIMING_VTS - Total vertical size [7:0]
So guess what writing 16bits might do...
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.

backinside
Posts: 16
Joined: Fri May 15, 2015 10:07 pm

Re: low-level interfacing to OV5647

Tue Mar 08, 2016 8:08 am

One more new topic in the thread, than I'll start finishing my old topics :)
I've managed to start a raspiraw when another instance was already running
After killing both of them, I can't start a capture
The output halts here:

[email protected]:~/userland-rawcam/userland $ ./build/bin/raspiraw
mmal: mmal_port_alloc: component:vc.ril.rawcam type:1 extra:0
mmal: mmal_port_alloc: vc.ril.rawcam:ctr:0: created at 0x5814e0
mmal: mmal_vc_component_create: vc.ril.rawcam

restarting the system seems to fix the problem
I've encountered this issue before, but with this method, I can reproduce the issue
Is there a way, to reset the camera if this happens?

Return to “Camera board”