Qiang1016
Posts: 2
Joined: Fri May 05, 2017 6:39 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Mon May 08, 2017 5:42 pm

6by9,

Thank you. It works now with your new update.




Qiang

ientapoliti
Posts: 4
Joined: Wed Dec 07, 2016 8:57 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Thu May 18, 2017 12:11 am

Hi,

I've managed to get raspiraw working to some extent. I am using a Raspberry Pi 3 with v2.1 camera (IMX219).

First, when I try to run camera_i2c, it says that I have the wrong cpu version. I have 2a22082 (BCM2709), whereas the code is looking for a22082 (or a02082). I just added in the line 'a02082'|'a22082'|'2a22082' to camera_i2c and that seems to fix it.

Second, when I capture data using the IMX219, nearly all of the values are 0x10 in every frame tested. I tested this using:

Code: Select all

xxd -l 1000 output.raw
0x10 0x10 0x10 0x10 0x00
.

I tried capturing with a v1.3 sensor and that seems to work. So it's just the IMX219.

I could spend some time on getting this to work, since I'm building lab equipment and would love to be able to use a cheap, small sensor. I would be willing to find i2c register values or anything else needed if I get a little direction in what to look for!

Thanks!

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

Re: Raw sensor access / CSI-2 receiver peripheral

Thu May 18, 2017 9:36 am

ientapoliti wrote:First, when I try to run camera_i2c, it says that I have the wrong cpu version. I have 2a22082 (BCM2709), whereas the code is looking for a22082 (or a02082). I just added in the line 'a02082'|'a22082'|'2a22082' to camera_i2c and that seems to fix it.
I hit the same problem that my Pi2 is 2a01041. It looks like the 2000000 is denoting that the board has been overvoltaged at some point.
A bit of searching and I have awk magic that just looks at the last 6 characters. I'll push that in a moment. Now pushed to the branch.
ientapoliti wrote:Second, when I capture data using the IMX219, nearly all of the values are 0x10 in every frame tested. I tested this using:

Code: Select all

xxd -l 1000 output.raw
0x10 0x10 0x10 0x10 0x00
.

I tried capturing with a v1.3 sensor and that seems to work. So it's just the IMX219.

I could spend some time on getting this to work, since I'm building lab equipment and would love to be able to use a cheap, small sensor. I would be willing to find i2c register values or anything else needed if I get a little direction in what to look for!
I only added the exposure and gain control for IMX219 a few weeks back, and I'm not convinced it is correct. As noted in the source, some of the info I have is under NDA so I have to be able to show that anything I'm using is in the public domain before making changes. If you determine settings that work then I am happy to accept pull requests :D

The black level for IMX219 is around 64, so ((0x10 << 2) | 0x00) sounds about right. Certainly it sounds like it is down in the noise due to some incorrect registers. Have you tried increasing the exposure time? raspiraw has no automatic exposure or gain control - it is all up to you to set it sensibly. There are links to the relevant docs and alternate drivers that should allow you to compare and contrast.
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.

ientapoliti
Posts: 4
Joined: Wed Dec 07, 2016 8:57 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Thu May 18, 2017 9:53 pm

6by9 wrote: I hit the same problem that my Pi2 is 2a01041. It looks like the 2000000 is denoting that the board has been overvoltaged at some point. A bit of searching and I have awk magic that just looks at the last 6 characters. I'll push that in a moment. Now pushed to the branch.
Thanks! This works perfectly now.
6by9 wrote: The black level for IMX219 is around 64, so ((0x10 << 2) | 0x00) sounds about right. Certainly it sounds like it is down in the noise due to some incorrect registers. Have you tried increasing the exposure time? raspiraw has no automatic exposure or gain control - it is all up to you to set it sensibly. There are links to the relevant docs and alternate drivers that should allow you to compare and contrast.
So, I tested a multitude of exposure and gain settings. Exposure seems to have a shift around 3,000 or so, where it will either set or not set vts. Still, whether exposure < 3,0000 or exposure > 3,000, all images are black.
Exposure: 2,000 Gain: 60. Black image
Exposure 5,000 Gain: 60. Black image.
Exposure 50,000 Gain: 60. Black image
Exposure 50,000. Gain: 0. Black image.

Any idea of what registers I should be looking for? I have found some examples of code such as here:

https://github.com/rellimmot/Sony-IMX21 ... w_Sensor.c

My suspicion is that it has something to do with frame length, line length, or pclk.

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

Re: Raw sensor access / CSI-2 receiver peripheral

Fri May 19, 2017 10:46 am

ientapoliti wrote:So, I tested a multitude of exposure and gain settings. Exposure seems to have a shift around 3,000 or so, where it will either set or not set vts. Still, whether exposure < 3,0000 or exposure > 3,000, all images are black.
Exposure: 2,000 Gain: 60. Black image
Exposure 5,000 Gain: 60. Black image.
Exposure 50,000 Gain: 60. Black image
Exposure 50,000. Gain: 0. Black image.

Any idea of what registers I should be looking for? I have found some examples of code such as here:

https://github.com/rellimmot/Sony-IMX21 ... w_Sensor.c

My suspicion is that it has something to do with frame length, line length, or pclk.
Almost certainly it's something along those lines.
My first suggestion would be to revert the branch to before I made the mods for controlling exposure. I seem to recall that gave some image even though exposure was short and gain low. Commit 7fb5097 would be the obvious candidate.

There is a datasheet at https://github.com/rellimmot/Sony-IMX21 ... Pi-V2-CMOS, you've found one driver, and there's another at https://android.googlesource.com/kernel ... o/imx219.c. The Android driver should be correct as I know the team involved and it went into a shipping phone.
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.

ientapoliti
Posts: 4
Joined: Wed Dec 07, 2016 8:57 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Sun May 21, 2017 3:33 am

I figured the best way to figure out what the native code is doing is to use an I2C sniffer.

So, I wrote a sniffer to read the pins 44 & 45 that the Raspberry Pi is using while connecting to and setting up the camera (IMX219).

Link is here:

https://gist.github.com/ientapoliti/7c0 ... 7f8a53359e

edit: I just added a pull request. The code in the pull request gives me image data for the IMX219 image sensor. I haven't had a chance to sniff out the i2c discrepancies for other modes (e.g. preview vs. still).

ientapoliti
Posts: 4
Joined: Wed Dec 07, 2016 8:57 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Sun May 21, 2017 6:37 pm

It seems that now none of the i2c params are working. I can't get an image whether I use the original raspiraw params or the params I posted yesterday.

I captured another set of registers, this time using the command:
raspistill -t 1000 -ss 1000000 -ex off -awb off -md 2 -o test.png
That's found here: https://gist.github.com/ientapoliti/e26 ... 1eb15f2b07

Not quite sure what to make of it yet. I will have to read through the specification more carefully to find out why values are what they are. If I just copy and paste those registers into the IMX219.h header, even if I splice it at the {0x0100, 0x01} part, it still doesn't capture an image correctly.

ymorvan
Posts: 1
Joined: Mon May 29, 2017 12:40 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Mon May 29, 2017 7:07 pm

Hello, I am a new forum user and co-developer of a product that uses motion tracking.

We have been using the PlayStation 3 Eye camera so far, and requiring our users to own a computer. We'd like to offer our product as a self contained object, and are considering building the hardware around Raspberry Pi.

This thread (and others) has been very useful to get an idea of the steps involved in getting the camera side of things off the ground (neither I or my co-developer have much hardware expertise).

I have a few questions to try and get an idea of the work involved.

For our application, we only need monochrome images, but at a minimum of 120 frames per second, and with as low latency as possible.

Is it correct to say that we could use the Raspberry Pi camera module v2 in a mode that allows the raw bayer data to be transferred over the 2 MIPI lanes at a rate of 120 fps or above, then do a weighted sum of the bayer components on the GPU and access the result in our application? Could this be done with 0 copying out of GPU memory?

Alternatively we are looking at the OV7251 sensor (which has a global shutter). Is this a fair description of the work involved?:
-design a camera module around this sensor that is compatible with the Pi's MIPI port
-adapt 6by9's rawcam code to set the OV7251 module's registers correctly and configure MMAL to receive the frames correctly

How complex and time consuming are these two tasks (and any other tasks I've missed)?
Jamesh's posts suggest very, but in our case we only need monochrome data and one setting (e.g. 120 fps at 640 x 480, 2 ms exposure and 0 gain).

I am focusing on the electronics and how they'd interface with our software for now (as opposed to the optics).

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

Re: Raw sensor access / CSI-2 receiver peripheral

Thu Jun 01, 2017 11:15 am

ymorvan wrote:For our application, we only need monochrome images, but at a minimum of 120 frames per second, and with as low latency as possible.
The sensor itself has a Bayer filter, so you can't trivially get monochrome images. You will have to do some form of demosaicing.
ymorvan wrote:Is it correct to say that we could use the Raspberry Pi camera module v2 in a mode that allows the raw bayer data to be transferred over the 2 MIPI lanes at a rate of 120 fps or above, then do a weighted sum of the bayer components on the GPU and access the result in our application? Could this be done with 0 copying out of GPU memory?
There are register sets that will allow you to read out 1280x720 at 120fps, or 640x480 at 120fps. Both have a cropped field of view - see the PiCamera docs for nice pictures of how they are cropped.
There is no simple option of doing a weighted sum on the GPU. You could write your own routines to do so either on the VPU or QPUs and run it via the mailbox interface, or use NEON on the ARM cores. You could use the ISP component, but that is still under development so may not do exactly what you want.
All options (possibly except NEON) can be done efficiently in GPU memory. I wouldn't say zero copy as the processing from Bayer will be a read and a write, so whether the image goes back to the original buffer or not is pretty irrelevant. You can then map those buffers into ARM memory to access them without copying.
ymorvan wrote:Alternatively we are looking at the OV7251 sensor (which has a global shutter). Is this a fair description of the work involved?:
-design a camera module around this sensor that is compatible with the Pi's MIPI port
-adapt 6by9's rawcam code to set the OV7251 module's registers correctly and configure MMAL to receive the frames correctly
That's reasonable.
ymorvan wrote:How complex and time consuming are these two tasks (and any other tasks I've missed)?
Jamesh's posts suggest very, but in our case we only need monochrome data and one setting (e.g. 120 fps at 640 x 480, 2 ms exposure and 0 gain).

I am focusing on the electronics and how they'd interface with our software for now (as opposed to the optics).
If you are:
- only working in monochrome
- have a working I2C register set producing the resolution you
- not needing auto exposure/gain control, or have it enabled in the sensor
then you are likely to have some success. The hardest bit is probably sourcing the sensor in the first place.
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.

deeluk
Posts: 14
Joined: Wed Apr 12, 2017 5:35 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Jun 09, 2017 3:45 pm

I am still trying to bring up a new camera sensor using this framework. I am having trouble debugging exactly where my problem lies at the moment. I am using the same basic framework as that used in raspiraw. I program the device via i2c putting it in streaming mode at a given resolution and framerate (using register settings provided by the sensor manufacturer). I plug in my callback via MMAL. But no streaming ever occurs. Is there a good way of debugging what is happening (or not) over CSI-2 within the kernel? If it were working, I would expect the callback to start firing with raw data buffers at 120 Hz. I am configuring the camera to output 400x400 8bpp @ 120 fps.

Derek

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

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Jun 09, 2017 4:35 pm

deeluk wrote:I am still trying to bring up a new camera sensor using this framework. I am having trouble debugging exactly where my problem lies at the moment. I am using the same basic framework as that used in raspiraw. I program the device via i2c putting it in streaming mode at a given resolution and framerate (using register settings provided by the sensor manufacturer). I plug in my callback via MMAL. But no streaming ever occurs. Is there a good way of debugging what is happening (or not) over CSI-2 within the kernel? If it were working, I would expect the callback to start firing with raw data buffers at 120 Hz. I am configuring the camera to output 400x400 8bpp @ 120 fps.
What data format are you producing for your 8bpp, and therefore what data type ID are you using? If that is set incorrectly then you're unlikely to get sensible frame callbacks.

If you're really wanting to have a closer look at the hardware then you can now change tack. The V4L2 subdevice driver is now working, although I'm initially working with people to test it against the TC358743 HDMI to CSI2 bridge chip. viewtopic.php?f=38&t=120702&start=250#p1164774. No guarantee that it will make anything any clearer though.
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.

deeluk
Posts: 14
Joined: Wed Apr 12, 2017 5:35 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Jun 09, 2017 7:42 pm

6by9 wrote:
deeluk wrote:I am still trying to bring up a new camera sensor using this framework. I am having trouble debugging exactly where my problem lies at the moment. I am using the same basic framework as that used in raspiraw. I program the device via i2c putting it in streaming mode at a given resolution and framerate (using register settings provided by the sensor manufacturer). I plug in my callback via MMAL. But no streaming ever occurs. Is there a good way of debugging what is happening (or not) over CSI-2 within the kernel? If it were working, I would expect the callback to start firing with raw data buffers at 120 Hz. I am configuring the camera to output 400x400 8bpp @ 120 fps.
What data format are you producing for your 8bpp, and therefore what data type ID are you using? If that is set incorrectly then you're unlikely to get sensible frame callbacks.

If you're really wanting to have a closer look at the hardware then you can now change tack. The V4L2 subdevice driver is now working, although I'm initially working with people to test it against the TC358743 HDMI to CSI2 bridge chip. viewtopic.php?f=38&t=120702&start=250#p1164774. No guarantee that it will make anything any clearer though.
If I understand your question correctly, I'm setting MMAL_PORT encoding to MMAL_ENCODING_SBGGR8. I set the receiver pack and unpack config both to NONE. The V4L2 subdev route is interesting, I will check that out.

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

Re: Raw sensor access / CSI-2 receiver peripheral

Sat Jun 10, 2017 6:28 am

deeluk wrote:If I understand your question correctly, I'm setting MMAL_PORT encoding to MMAL_ENCODING_SBGGR8. I set the receiver pack and unpack config both to NONE.
No, that's not what I was referring to. Read the MIPI spec section on the data identifier, which is made up of the data type and virtual channel. That value is set in rawcam via the image_id field of MMAL_PARAMETER_CAMERA_RX_CONFIG_T.
The default is set to 0x2B for Bayer raw 10, but if you're using Bayer raw 8 then you need 0x2A.
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.

ronb127
Posts: 7
Joined: Fri Jun 23, 2017 10:23 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Jun 23, 2017 10:28 pm

For those of you who try to use raspiraw with Sony imx219 (camera module v2):
The latest code would give you black images (0x10). This happens because the digital gain is set to zero!
To correct this simply change imx219_modes.h:54 from {0x0158, 0x00} to {0x0158, 0x01}.

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

Re: Raw sensor access / CSI-2 receiver peripheral

Sat Jun 24, 2017 7:28 am

ronb127 wrote:For those of you who try to use raspiraw with Sony imx219 (camera module v2):
The latest code would give you black images (0x10). This happens because the digital gain is set to zero!
To correct this simply change imx219_modes.h:54 from {0x0158, 0x00} to {0x0158, 0x01}.
As stated in the headers, I can't offer support on the register set - others have captured them off the I2C bus, or some settings have been pulled in from other public domain sources.
If you have improvements then please create a pull request and I'll review and merge them. In this case I think you're right.
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.

Varvisi
Posts: 1
Joined: Fri Jun 30, 2017 4:31 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Sun Jul 02, 2017 7:25 pm

ronb127 wrote:For those of you who try to use raspiraw with Sony imx219 (camera module v2):
The latest code would give you black images (0x10). This happens because the digital gain is set to zero!
To correct this simply change imx219_modes.h:54 from {0x0158, 0x00} to {0x0158, 0x01}.
It's not just the digital gain - the integration time is also pretty low (256 lines) and there's no analogue gain, either. So the resulting image will be overall very dark. In my initial attempts I tried to just raise the analogue and digital gains, but even then the image was too dark due to the low exposure time. Especially if you're in a darkish room you'll get a very dark image with the default settings (so even if you get past the black threshold it'll still be mostly black).

Just specifying arbitrarily high exposure times (as ientapoliti tried) is not enough either as it'll eventually get too long for the configured frame time.

After playing around with raspiraw without much luck I ended up rolling own camera controller (in c++14) - you can find it under https://github.com/RlyDontKnow/raspi-image
It's not as ironed out as raspiraw, but the timing control should be working - although I'm still not 100% sure on some conversions, so actual values might be off by some constant factor.

You can specify a desired frame time (or a don't care if you don't have a target fps) and an integration time and it'll do it's best to find a set of parameters that achieves those timings.

deeluk
Posts: 14
Joined: Wed Apr 12, 2017 5:35 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Mon Jul 03, 2017 5:36 pm

6by9 wrote:
deeluk wrote:If I understand your question correctly, I'm setting MMAL_PORT encoding to MMAL_ENCODING_SBGGR8. I set the receiver pack and unpack config both to NONE.
No, that's not what I was referring to. Read the MIPI spec section on the data identifier, which is made up of the data type and virtual channel. That value is set in rawcam via the image_id field of MMAL_PARAMETER_CAMERA_RX_CONFIG_T.
The default is set to 0x2B for Bayer raw 10, but if you're using Bayer raw 8 then you need 0x2A.
Thank you so much. Sorry I disappeared for a bit, went on an extended vacation. While I was out, a colleague used this information and now we have our camera up and streaming. Thanks again for all your help!

deeluk
Posts: 14
Joined: Wed Apr 12, 2017 5:35 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Jul 14, 2017 2:37 pm

Will this method of raw sensor access work with the stereoscopic modes of MMAL as described here: viewtopic.php?p=600720 on a RPi compute module with 2 cameras?

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

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Jul 14, 2017 3:09 pm

deeluk wrote:Will this method of raw sensor access work with the stereoscopic modes of MMAL as described here: viewtopic.php?p=600720 on a RPi compute module with 2 cameras?
Not really as you are the one in control of the two cameras, not the GPU - how are you achieving synchronisation?
Certainly I haven't implemented the ISP component in a way that supports two inputs to merge into a stereoscopic frame, although that would be possible I suppose.
I'm not sure we added the plumbing for signalling stereoscopic correctly from raw buffers, but mainly relied on using MMAL_ENCODING_OPAQUE. Rawcam doesn't support that (it has no internal image pools to share).

I suppose the simplest thing is to bounce it back to you as to what aspect of stereoscopic you are wanting. Video encode, stills encode, display, or something else?
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.

deeluk
Posts: 14
Joined: Wed Apr 12, 2017 5:35 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Jul 14, 2017 7:04 pm

6by9 wrote:
deeluk wrote:Will this method of raw sensor access work with the stereoscopic modes of MMAL as described here: viewtopic.php?p=600720 on a RPi compute module with 2 cameras?
Not really as you are the one in control of the two cameras, not the GPU - how are you achieving synchronisation?
Certainly I haven't implemented the ISP component in a way that supports two inputs to merge into a stereoscopic frame, although that would be possible I suppose.
I'm not sure we added the plumbing for signalling stereoscopic correctly from raw buffers, but mainly relied on using MMAL_ENCODING_OPAQUE. Rawcam doesn't support that (it has no internal image pools to share).

I suppose the simplest thing is to bounce it back to you as to what aspect of stereoscopic you are wanting. Video encode, stills encode, display, or something else?
I'm just trying to get at the raw camera data from the two sensors. So, stills. I thought I read elsewhere that as long as the two cameras were being driven from the same clock, synchronization would not be an issue.

Did I read the whole stereo support article wrong? I thought the functionality provided there was to take the CSI-2 output of 2 cameras and stack the sensor data either horizontally or vertically using MMAL_STEREOSCOPIC_MODE_T. Thus in this mode, buffer callbacks contain the data from both sensors.

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

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Jul 14, 2017 8:10 pm

deeluk wrote:I'm just trying to get at the raw camera data from the two sensors. So, stills. I thought I read elsewhere that as long as the two cameras were being driven from the same clock, synchronization would not be an issue.
If they are driven from the same clock and started at the same time, then they will generally stay in sync. But they aren't driven from the same clock, and starting them is up to your application when using rawcam.
deeluk wrote:Did I read the whole stereo support article wrong? I thought the functionality provided there was to take the CSI-2 output of 2 cameras and stack the sensor data either horizontally or vertically using MMAL_STEREOSCOPIC_MODE_T. Thus in this mode, buffer callbacks contain the data from both sensors.
Yes, but ONLY when using the full camera stack, not when using rawcam.

To talk to two cameras using rawcam, you need two independent rawcam components, which will therefore deliver to independent buffers.

If you're after synchronised raw still captures, then IIRC raspistill with stereoscopic requests and the -r /--raw flag should save both raw images (it'll make for a big file though).
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.

deeluk
Posts: 14
Joined: Wed Apr 12, 2017 5:35 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Jul 14, 2017 9:58 pm

6by9 wrote:If you're after synchronised raw still captures, then IIRC raspistill with stereoscopic requests and the -r /--raw flag should save both raw images (it'll make for a big file though).
I really need programmatic access, not file based output. Sounds like it is not possible at this point. The camera modules I'm using are running at relatively low resolutions (400x400 or less).

deeluk
Posts: 14
Joined: Wed Apr 12, 2017 5:35 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Jul 14, 2017 10:02 pm

6by9 wrote: If they are driven from the same clock and started at the same time, then they will generally stay in sync. But they aren't driven from the same clock, and starting them is up to your application when using rawcam.
Oh, and I forgot to mention, in our stereo setup, both cameras will be driven from the same clock. I am not using the RPi camera board (in case that was not clear). It is a different CSI-2 camera sensor on a custom board.

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

Re: Raw sensor access / CSI-2 receiver peripheral

Mon Jul 17, 2017 9:01 am

deeluk wrote:
6by9 wrote: If they are driven from the same clock and started at the same time, then they will generally stay in sync. But they aren't driven from the same clock, and starting them is up to your application when using rawcam.
Oh, and I forgot to mention, in our stereo setup, both cameras will be driven from the same clock. I am not using the RPi camera board (in case that was not clear). It is a different CSI-2 camera sensor on a custom board.
OK, different kettle of fish if not the Pi camera boards - you possibly had mentioned that before, but life's too short to go back and check history on every post.

Hopefully what I had previous said is that the two sensors won't drift with respect to each other if driven off the same clock.

You still have a potential offset for when you start the two sensors streaming.
Some sensors support a hardware connection between the two that allows one to be slaved off the other, or both to be slaved off some other external trigger. You'd need to read through your sensor spec sheet to work that one out.
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.

deeluk
Posts: 14
Joined: Wed Apr 12, 2017 5:35 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Mon Jul 17, 2017 3:10 pm

6by9 wrote:
deeluk wrote:
6by9 wrote: If they are driven from the same clock and started at the same time, then they will generally stay in sync. But they aren't driven from the same clock, and starting them is up to your application when using rawcam.
Oh, and I forgot to mention, in our stereo setup, both cameras will be driven from the same clock. I am not using the RPi camera board (in case that was not clear). It is a different CSI-2 camera sensor on a custom board.
OK, different kettle of fish if not the Pi camera boards - you possibly had mentioned that before, but life's too short to go back and check history on every post.

Hopefully what I had previous said is that the two sensors won't drift with respect to each other if driven off the same clock.

You still have a potential offset for when you start the two sensors streaming.
Some sensors support a hardware connection between the two that allows one to be slaved off the other, or both to be slaved off some other external trigger. You'd need to read through your sensor spec sheet to work that one out.
Hmm, so is there a possibility to make this work? With 2 rawcam components as you mentioned previously. I assume the same process can create 2 components and plug in 2 separate callbacks? We won't get combined side by side or stacked frames, but that's OK. The hardware does have the capability to slave one camera off of the other.

Return to “Camera board”