fooforever
Posts: 20
Joined: Wed Aug 15, 2012 11:21 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Thu Aug 10, 2017 1:04 pm

Thanks for the grate work so far. I've got the rawcam up and running on my pi and am trying to work out the command line switches for the gain and exposure. Are the two parameters passed in here codes that get written directly to the registers? Or are they milliseconds and 0-8 like in other camera apps?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4692
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 Aug 10, 2017 1:25 pm

fooforever wrote:
Thu Aug 10, 2017 1:04 pm
Thanks for the grate work so far. I've got the rawcam up and running on my pi and am trying to work out the command line switches for the gain and exposure. Are the two parameters passed in here codes that get written directly to the registers? Or are they milliseconds and 0-8 like in other camera apps?
They are the values written straight into the registers, mainly as the conversion from units of time to those register values is dependent on numerous other settings (eg line length, PLL settings, master oscillator frequency), and there are also several conversion formulae for taking gain to register value.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

fooforever
Posts: 20
Joined: Wed Aug 15, 2012 11:21 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Thu Aug 10, 2017 2:41 pm

Is there anywhere I can find that info or are the specifics yet to be worked out?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4692
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 Aug 10, 2017 2:59 pm

Gain formulae are in the respective datasheets.
Line length for the one listed IMX219 mode is 18.904usecs.
Line length for the OV5647 modes are:
29.584usecs
32.503usecs
183.789usecs
23.216usecs
23.216usecs
31.390usecs
31.749usecs
21.165usecs
respectively.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

fooforever
Posts: 20
Joined: Wed Aug 15, 2012 11:21 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Thu Aug 10, 2017 4:08 pm

How are the long exposures being achieved then? Surely exposure time has to be less than line length.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4692
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 Aug 10, 2017 4:11 pm

fooforever wrote:
Thu Aug 10, 2017 4:08 pm
How are the long exposures being achieved then? Surely exposure time has to be less than line length.
Er, no. Far from it.
Please have a read of http://picamera.readthedocs.io/en/latest/fov.html for how rolling shutter sensors work.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

fooforever
Posts: 20
Joined: Wed Aug 15, 2012 11:21 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Thu Aug 10, 2017 4:25 pm

So the times your quoting above are actually read out times then? Which of course multiples of define the exposure time. And I remember reading earlier in the thread that 'dead lines' are effectively used at the end of the frame to get longer exposure times. So that makes sense. And as of current understanding on this thread, there isn't and know way to work out settings in time for exposure and a gain of 1 for example?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4692
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 Aug 10, 2017 6:34 pm

Those times are the readout time per line.
The minimum frame time / maximum frame rate is defined by the number of lines in the frame (possibly with a couple added) times the per line time.
Lower frame rates are set by adding extra dummy lines to the frame length.
Exposure time can be any multiple of the per line time up to the configured number of lines in the frame.

I guess the mode structure can be extended to include the per line time, which would allow the app to accept an exposure time and configure the sensor appropriately.
Likewise the sensor structure could be extended to include a function pointer to a function that converts a float of the gain into a register value.
Pull requests for either of those would be accepted :) Just add them as new parameters so that backward compatibility is maintained.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

fooforever
Posts: 20
Joined: Wed Aug 15, 2012 11:21 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Aug 11, 2017 1:45 pm

Sorry to pester with possibly silly questions, but I'm trying to get this right in my head.
So the number that is set into the exposure registers is the number of lines between the reset and read on the sensor?

So for example in mode 3 to get a 1ms exposure the exposure register would be set to 7? Which would actually give an exposure of 971.5us (7*138.789).

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4692
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 Aug 11, 2017 1:57 pm

fooforever wrote:
Fri Aug 11, 2017 1:45 pm
Sorry to pester with possibly silly questions, but I'm trying to get this right in my head.
So the number that is set into the exposure registers is the number of lines between the reset and read on the sensor?

So for example in mode 3 to get a 1ms exposure the exposure register would be set to 7? Which would actually give an exposure of 971.5us (7*138.789).
Sounds about right, although you've made a typo - the line length is 183.789usecs, not 138. The register value would therefore be 5 to give 0.9189ms, or 6 to give 1.102ms.
Max value for the frame length (ie frame rate, aka VTS) register is 32767, so 32767 * 0.183789 = 6.022seconds, and that corresponds to the max exposure time that can be achieved on OV5647.

If you set the exposure register to a greater number than the frame length register, then expect issues.

Mode 3 wouldn't be the best choice of mode for a short exposure such as 1ms - it is only used for frame rates < 1fps by the firmware due to the otherwise coarse step size on exposure and frame rate.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

fooforever
Posts: 20
Joined: Wed Aug 15, 2012 11:21 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Mon Aug 21, 2017 2:47 pm

Just sent a pull request for exposure time setting, I've checked it out on the V1.3 camera but don't have a V2 to play with. Seems to work good for me. The rounding is a bit primitive but thought id do it like that rather than add dependencies to the math library.

I know 6by9 probably can't help but if anyone else is watching this topic and can point me in the direction of a datasheet with some gain formulas I'll implement something similar for that.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4692
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 Aug 21, 2017 3:43 pm

fooforever wrote:
Mon Aug 21, 2017 2:47 pm
Just sent a pull request for exposure time setting, I've checked it out on the V1.3 camera but don't have a V2 to play with. Seems to work good for me. The rounding is a bit primitive but thought id do it like that rather than add dependencies to the math library.
Thank you. Comment made on the PR.
fooforever wrote:I know 6by9 probably can't help but if anyone else is watching this topic and can point me in the direction of a datasheet with some gain formulas I'll implement something similar for that.
I can point to public resources :-)
IMX219 - https://github.com/rellimmot/Sony-IMX21 ... Pi-V2-CMOS section 5-8. (This is why I wanted to make it clear that it wasn't always linear. Often the register is referred to as taking a gain code. The values of m0, m1, c0, and c1 ideally should be read from registers to make it auto-configuring, but no one ever does.
OV5647 - http://cdn.sparkfun.com/datasheets/Dev/ ... 7_full.pdf register 0x350a and 0x350b. Check values in 0x3503 as well. However the docs don't give much detail. Google for "ov5647 driver" and you'll find things like https://android.googlesource.com/kernel ... m/ov5647.c. You may be able to make use of the OV5640 datasheet as a related sensor (it has a built in ISP, but is otherwise almost identical to OV5647).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

fooforever
Posts: 20
Joined: Wed Aug 15, 2012 11:21 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Thu Aug 31, 2017 4:01 pm

On second thoughts looking at the gain, is there much point mapping it to some other arbitrary scale? I don't think so. Because that is all that would be doing, right?

Also is there any documentation anywhere that can help me use this for my own application? I've tried adapting your source, not to much avail :/ All I want to be able to do is get single images and set the camera parameters properly. But the closest I've got is bits of images (unreliably at that) by checking for the MMAL_BUFFER_HEADER_FLAG_FRAME flag in the callback. Your code doesn't seem to even do anything like that, so how do you know you've got a full image?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4692
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 Aug 31, 2017 4:22 pm

fooforever wrote:
Thu Aug 31, 2017 4:01 pm
On second thoughts looking at the gain, is there much point mapping it to some other arbitrary scale? I don't think so. Because that is all that would be doing, right?
You can map it back to being a multiplication factor which is pretty standard.
To get to an ISO value requires calibration/knowledge of the sensor so isn't worthwhile.
fooforever wrote:Also is there any documentation anywhere that can help me use this for my own application? I've tried adapting your source, not to much avail :/ All I want to be able to do is get single images and set the camera parameters properly. But the closest I've got is bits of images (unreliably at that) by checking for the MMAL_BUFFER_HEADER_FLAG_FRAME flag in the callback. Your code doesn't seem to even do anything like that, so how do you know you've got a full image?
Almost all the data is in the first post.
You'll get two buffers - one with MMAL_BUFFER_HEADER_FLAG_CODECSIDEINFO set in the flags field, and one without. Both will have MMAL_BUFFER_HEADER_FLAG_FRAME set. Ignore the one with it set as that is the metadata side channel and is unused with both OV5647 and IMX219 sensors.

The image frame should be valid from the second buffer. The first buffer may be OK, but no guarantees. This is down to the way that the rolling shutter sensors often start streaming and where/how they start the reset and readout pointers - have a read of http://picamera.readthedocs.io/en/latest/fov.html for more details on the mechanics of how rolling shutter operation.
Some sensors do have extra control logic in them to get the first frame correctly exposed - consult the sensor datasheet for info on that
Similarly any changes in gain or exposure whilst streaming will often take multiple frames to be correctly adopted - if you want specific values then set them before starting streaming, and don't expect instant changes if you're implementing any form of AE or AGC control.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
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

Thu Aug 31, 2017 10:29 pm

deeluk wrote:
Mon Jul 17, 2017 3:10 pm
6by9 wrote:
deeluk wrote: 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.
I've made some progress on our 2 camera compute module setup. I have 2 cameras connected to the CM both are on i2c bus 0. I can independently stream from each camera using the MMAL camera number port parameter. The problem I'm having now is I2C.

I want to have both cameras enabled on the same I2C bus at the same time. As such, I have set up GPIO such that pins 0 and 1 are using alt function 0 and pins 28 and 29 are also using alt function 0. I believe this puts both cameras physically on the I2C bus 0. My plan was to power up one camera (by power up I mean take camera out of reset), reprogram it's I2C address so that it doesn't conflict with the second camera (which is identical). Then power up the second camera. In this way, I could address each independently via separate I2C addresses.

However, what appears to happen is that whenever both gpio 0/1 and 28/29 are enabled on I2C bus 0 there is a conflict. I can independently talk to each camera over I2C iff only 0/1 OR 28/29 are on I2C0. When they're both on I2C0, neither camera responds (or they conflict and blow up each other's response).

Is there a way to make this work? Is there a better way?

Derek

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4692
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 Sep 01, 2017 6:39 am

deeluk wrote:
Thu Aug 31, 2017 10:29 pm
I've made some progress on our 2 camera compute module setup. I have 2 cameras connected to the CM both are on i2c bus 0. I can independently stream from each camera using the MMAL camera number port parameter. The problem I'm having now is I2C.

I want to have both cameras enabled on the same I2C bus at the same time. As such, I have set up GPIO such that pins 0 and 1 are using alt function 0 and pins 28 and 29 are also using alt function 0. I believe this puts both cameras physically on the I2C bus 0. My plan was to power up one camera (by power up I mean take camera out of reset), reprogram it's I2C address so that it doesn't conflict with the second camera (which is identical). Then power up the second camera. In this way, I could address each independently via separate I2C addresses.

However, what appears to happen is that whenever both gpio 0/1 and 28/29 are enabled on I2C bus 0 there is a conflict. I can independently talk to each camera over I2C iff only 0/1 OR 28/29 are on I2C0. When they're both on I2C0, neither camera responds (or they conflict and blow up each other's response).

Is there a way to make this work? Is there a better way?
You MUST set back one of the sets of pins to input when the other is on ALT0 - that's just the way it is.
I2C lines are pulled high by a resistor, and the controller/device pulls it low with an open drain driver to give a 0. The device ACKs each byte by pulling the line low for an ACK bit (NAK is leaving the line high).
When two sets of pins are muxed to the same I2C controller AIUI the two lines are logical ORed together, so typically one of the busses leaves the line alone (logical 1), whilst the other may ACK (logical 0). 1 OR 0 = 1, or NAK, so the controller thinks the transfer failed and will typically abort any further bytes.

Your case is a little different as there should be a device on each bus that ACKs the transfer. 0 OR 0 = 0, so should be read as an ACK. Reading back any other data that may differ between the devices will fail.

If you want to do it in a really neat manner, then there is a Linux driver called i2c-mux-pinctrl that automatically switches the pin muxing based and presents the two sets of pins as independent files at /dev/i2c-N. The one funny thing about it is that the base (unmuxed, unconnected) I2C controller also gets given a /dev entry but may be set not to talk to anything - that bus needs to be ignored. If I can get it configured correctly for all platforms then I intend to try and merge this into the standard kernel, but I've not got everything working yet.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
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 Sep 01, 2017 2:24 pm

6by9 wrote:
Fri Sep 01, 2017 6:39 am
deeluk wrote:
Thu Aug 31, 2017 10:29 pm
I've made some progress on our 2 camera compute module setup. I have 2 cameras connected to the CM both are on i2c bus 0. I can independently stream from each camera using the MMAL camera number port parameter. The problem I'm having now is I2C.

I want to have both cameras enabled on the same I2C bus at the same time. As such, I have set up GPIO such that pins 0 and 1 are using alt function 0 and pins 28 and 29 are also using alt function 0. I believe this puts both cameras physically on the I2C bus 0. My plan was to power up one camera (by power up I mean take camera out of reset), reprogram it's I2C address so that it doesn't conflict with the second camera (which is identical). Then power up the second camera. In this way, I could address each independently via separate I2C addresses.

However, what appears to happen is that whenever both gpio 0/1 and 28/29 are enabled on I2C bus 0 there is a conflict. I can independently talk to each camera over I2C iff only 0/1 OR 28/29 are on I2C0. When they're both on I2C0, neither camera responds (or they conflict and blow up each other's response).

Is there a way to make this work? Is there a better way?
You MUST set back one of the sets of pins to input when the other is on ALT0 - that's just the way it is.
I2C lines are pulled high by a resistor, and the controller/device pulls it low with an open drain driver to give a 0. The device ACKs each byte by pulling the line low for an ACK bit (NAK is leaving the line high).
When two sets of pins are muxed to the same I2C controller AIUI the two lines are logical ORed together, so typically one of the busses leaves the line alone (logical 1), whilst the other may ACK (logical 0). 1 OR 0 = 1, or NAK, so the controller thinks the transfer failed and will typically abort any further bytes.

Your case is a little different as there should be a device on each bus that ACKs the transfer. 0 OR 0 = 0, so should be read as an ACK. Reading back any other data that may differ between the devices will fail.

If you want to do it in a really neat manner, then there is a Linux driver called i2c-mux-pinctrl that automatically switches the pin muxing based and presents the two sets of pins as independent files at /dev/i2c-N. The one funny thing about it is that the base (unmuxed, unconnected) I2C controller also gets given a /dev entry but may be set not to talk to anything - that bus needs to be ignored. If I can get it configured correctly for all platforms then I intend to try and merge this into the standard kernel, but I've not got everything working yet.
Thanks for that info. Just after I posted this I had another thought and tried a different tack that seems to work as well. I connected both SDA and SCL lines from cam0 and cam1 to the same gpio pair (gpio 0/1) using a Y jumper. When I go to access the cameras, I take the first one out of reset and reprogram its I2C address. Then I bring in the second one and leave it at the default. Doing this I can see both on I2C bus 0 at the same time. I'm about to go try to stream from both of them at the same time. Fingers crossed.

Do you see any problems with what I did with the physical connection? I understand what you said above about how I2C works electrically to a degree. I'm not an EE tho. A colleague has been helping me work through this on the EE front. I don't really grok why the physical connection works but placing both on the bus via GPIO does not.

Again, thank you for all your help.

Derek

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4692
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 Sep 01, 2017 2:55 pm

deeluk wrote:
Fri Sep 01, 2017 2:24 pm
Thanks for that info. Just after I posted this I had another thought and tried a different tack that seems to work as well. I connected both SDA and SCL lines from cam0 and cam1 to the same gpio pair (gpio 0/1) using a Y jumper. When I go to access the cameras, I take the first one out of reset and reprogram its I2C address. Then I bring in the second one and leave it at the default. Doing this I can see both on I2C bus 0 at the same time. I'm about to go try to stream from both of them at the same time. Fingers crossed.
If you can reprogram the I2C address of your device then that is probably the best way to go. It's even nicer if you can reset the address permanently, but that is rarely possible.
You still need to send two commands to start both streaming, but that is no different to having them on different sets of GPIOs.
deeluk wrote:Do you see any problems with what I did with the physical connection? I understand what you said above about how I2C works electrically to a degree. I'm not an EE tho. A colleague has been helping me work through this on the EE front. I don't really grok why the physical connection works but placing both on the bus via GPIO does not.
Physically connecting two I2C devices with different addresses to the same I2C bus is absolutely fine - many people do the every day with I2C devices of various kinds.
The issue with the pinmuxing is that you have put extra logic in the way which doesn't behave the same as a peice of wire. I'm not sure I fully understand exactly what is going on inside the silicon, but simply put muxing the same peripheral to multiple pins results in bad behaviour.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
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

Tue Sep 05, 2017 8:30 pm

I just wanted to report back that after getting past the I2C issues, I now have stereo streaming using the rawcam interface up and running on a PI compute module (at 120fps :o ) with 2 CSI-2 image sensors. Thanks to all on this thread for the background info and especially to 6by9 for all of the support and help.

HermannSW
Posts: 388
Joined: Fri Jul 22, 2016 9:09 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Wed Sep 06, 2017 9:09 am

Hi,

> I now have stereo streaming using the rawcam interface up and running on a PI compute module (at 120fps :o ) with 2 CSI-2 image sensors.
>
independent from 2 cameras and compute module, can you please share some details on how you achieved 120fps with Pi camera?
Is that possible with one camera and eg. Pi Zero as well?

Hermann.
--> Raspberry camera / gstreamer / raspiraw (bookmark list):
https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/6by9/raspiraw      https://github.com/Hermann-SW/raspiraw

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4692
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

Wed Sep 06, 2017 2:20 pm

HermannSW wrote:
Wed Sep 06, 2017 9:09 am
independent from 2 cameras and compute module, can you please share some details on how you achieved 120fps with Pi camera?
Is that possible with one camera and eg. Pi Zero as well?
Read back through deeluk's posts here and you'll see he is NOT using a Pi camera, but some other CSI-2 sensor.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
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

Wed Sep 06, 2017 3:09 pm

6by9 wrote:
Wed Sep 06, 2017 2:20 pm
HermannSW wrote:
Wed Sep 06, 2017 9:09 am
independent from 2 cameras and compute module, can you please share some details on how you achieved 120fps with Pi camera?
Is that possible with one camera and eg. Pi Zero as well?
Read back through deeluk's posts here and you'll see he is NOT using a Pi camera, but some other CSI-2 sensor.
Yes, sorry I should have been more specific with that 120 fps claim. This is not the Pi camera, it is a different low resolution monochrome sensor. It is streaming at 400x400 @ 120 fps. I'm working on a proof of concept for a computer vision application. We'll probably take the resolution down further to 200x200. The first step was to prove that this path was even feasible. Right now I'm running 2 instances of a Qt app that displays the camera stream in real time. All that rendering drags the X server to its knees. But it works!

fooforever
Posts: 20
Joined: Wed Aug 15, 2012 11:21 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Thu Oct 05, 2017 11:04 am

Is there an example anywhere of how to capture single frames using this method? I'm trying to find a way of just capturing the raw data that we can get out using this method and sending it over the network when a command is received. I already have an example working in python but I wanted to go quicker so this was the obvious way. However I can't really tell whats boilerplate code and what is just used for the command line setup etc. I've been messing round with it for ages trying to figure it out but I've yet to get a full proper image out. Can anyone help?

HermannSW
Posts: 388
Joined: Fri Jul 22, 2016 9:09 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Thu Oct 05, 2017 4:57 pm

> Is there an example anywhere of how to capture single frames using this method?
>
I see no single frame option in raspiraw help.

Yesterday I replaced small code block storing frames on SD card by code to draw frames in framebuffer:
viewtopic.php?f=43&t=189661&p=1218763#p1218763

You could modify raspiraw as well, but should not take the very first frame.
Change

Code: Select all

                if(!(buffer->flags&MMAL_BUFFER_HEADER_FLAG_CODECSIDEINFO) &&
                   (((count++)%cfg->saverate)==0))
to

Code: Select all

                if(!(buffer->flags&MMAL_BUFFER_HEADER_FLAG_CODECSIDEINFO) &&
                   ((count++)==cfg->saverate))
And add an exit at end of SD card write block -- that is harsh but will do what you search for.
--> Raspberry camera / gstreamer / raspiraw (bookmark list):
https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/6by9/raspiraw      https://github.com/Hermann-SW/raspiraw

fooforever
Posts: 20
Joined: Wed Aug 15, 2012 11:21 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Oct 06, 2017 2:39 pm

So yeah I went back to that sort of approach, I start the app streaming then just request frames when i want them from the callback by setting a flag when I receive the command I'm looking for. So the callback looks something like this:

Code: Select all

		if(!(buffer->flags&MMAL_BUFFER_HEADER_FLAG_CODECSIDEINFO) && send_frame)
		{
			if(!frameBuffer)
				frameBuffer = malloc(buffer->length);
			frameBufferLength = buffer->length;
			memcpy(frameBuffer, buffer->data, buffer->length);
			send_frame = false;

		}
		buffer->length = 0;
		mmal_port_send_buffer(port, buffer);
It all relies on send_frame being set and unset. This works fine I can send the data out in another function that handles all the networking stuff. But when I get images out the other end they look something like this:
Image

I seem to be getting either a repeated top bit of the frame at the bottom or the top of the next frame. Any idea what's going wrong? Obviously this doesn't happen with the saved images, but as far as I'm aware im kinda handling everything in the same way.

Return to “Camera board”

Who is online

Users browsing this forum: No registered users and 10 guests