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

Re: Raw sensor access / CSI-2 receiver peripheral

Tue May 12, 2015 9:12 pm

The OV2685 you have a reasonable chance to do real time stuff with as it appears to be able to produce YUV, as well as the raw Bayer data. I did update the image_encode component in the latest firmware image I have linked to to support the YUYV formats that this sensor is likely to produce (I haven't managed the same for video_encode yet). Whether your colleague's register set configures it for Bayer or YUV is something you'd need to check, and you would be using OV's AE and AWB algorithms which may not be ideal for your circumstances.

Please give it a whirl and report back - I'm genuinely interested in whether people manage to get this working with other sensors.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

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

Re: Raw sensor access / CSI-2 receiver peripheral

Sun May 17, 2015 12:26 pm

Can anyone who has actually tried this report back please. Particularly if it is with another sensor (I know, early days).
I want to make a call on whether to ask Dom to release it formally. (There should be no harm if there are issue, as it'll just sit there in the background doing nothing)
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

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

Re: Raw sensor access / CSI-2 receiver peripheral

Fri May 22, 2015 5:07 pm

Through other work, I now have a different device up and running over the CSI-2 bus :) Again only using userspace code though, not soc-camera (that'll still come hopefully).
I think that gives me enough confidence to get the firmware changes released officially, so it should be in a release in the next few days.
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.

tchiwam
Posts: 43
Joined: Mon Nov 24, 2014 4:01 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Sat May 23, 2015 1:17 am

Is this a 1/4" sensor or something bigger ?

tchiwam
Posts: 43
Joined: Mon Nov 24, 2014 4:01 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Sat May 23, 2015 2:48 am

Seems that my current problem is with the latest device tree kernel. They took the i2c-0 off. I'm trying to find it back before I can continue with this one.

Re-read the 1st post carefully, and now I have the i2c bus

Raspistill works, but not with dtparam=i2c_vc=on

I got as far as :
mmal: Failed to write register index 0
mmal: Failed to write register index 1
mmal: Failed to write register index 2
...
mmal: Failed to write register index 96
mmal: Failed to write register index 97

i2cdetect -y -a 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

I'll keep in investigating this tomorrow...

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

Re: Raw sensor access / CSI-2 receiver peripheral

Sat May 23, 2015 6:32 am

tchiwam wrote:Seems that my current problem is with the latest device tree kernel. They took the i2c-0 off. I'm trying to find it back before I can continue with this one.

Re-read the 1st post carefully, and now I have the i2c bus

Raspistill works, but not with dtparam=i2c_vc=on

I got as far as :
mmal: Failed to write register index 0
mmal: Failed to write register index 1
mmal: Failed to write register index 2
...
mmal: Failed to write register index 96
mmal: Failed to write register index 97

i2cdetect -y -a 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

I'll keep in investigating this tomorrow...
Did you also run the camera_i2c script (https://github.com/6by9/userland/blob/rawcam/camera_i2c) before trying? Loading i2c-0 resets the GPIOs so I2C0 appears on GPIOs 0 & 1, not 28 & 29 that go to the camera connector. It is mentioned in the first post, and others have obviously got it working.
NB If you forget to do that before trying raspistill/vid, then the GPU fails to find the sensor and caches that result, so you will have to reboot to redetect.
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.

tmorley
Posts: 5
Joined: Sat May 23, 2015 9:31 am

Re: Raw sensor access / CSI-2 receiver peripheral

Sat May 23, 2015 9:59 am

Wow, thanks for doing this, I've been looking at the camera recently and really wanting to be able to do all the configuration myself. This looks like it should do everything I want!

Hopefully I'll report back soon how it works for me!

Tim

tchiwam
Posts: 43
Joined: Mon Nov 24, 2014 4:01 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Sat May 23, 2015 4:48 pm

6by9 wrote:
tchiwam wrote:Seems that my current problem is with the latest device tree kernel. They took the i2c-0 off. I'm trying to find it back before I can continue with this one.

Re-read the 1st post carefully, and now I have the i2c bus

Raspistill works, but not with dtparam=i2c_vc=on

I got as far as :
mmal: Failed to write register index 0
mmal: Failed to write register index 1
mmal: Failed to write register index 2
...
mmal: Failed to write register index 96
mmal: Failed to write register index 97

i2cdetect -y -a 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

I'll keep in investigating this tomorrow...
Did you also run the camera_i2c script (https://github.com/6by9/userland/blob/rawcam/camera_i2c) before trying? Loading i2c-0 resets the GPIOs so I2C0 appears on GPIOs 0 & 1, not 28 & 29 that go to the camera connector. It is mentioned in the first post, and others have obviously got it working.
NB If you forget to do that before trying raspistill/vid, then the GPU fails to find the sensor and caches that result, so you will have to reboot to redetect.

Code: Select all

config.txt
gpu_mem=128
arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=2

start_file=start_x.elf
fixup_file=fixup_x.dat
disable_camera_led=1

decode_MPG2=0x....
decode_WVC1=0x....

dtparam=i2c_arm=on
dtparam=i2c_vc=on
#dtparam=i2c0=on
#dtparam=i2c=on
dtparam=spi=on
dtoverlay=pps-gpio,gpiopin=18
Then I do :
sudo modprobe i2c-dev
./camera_i2c
raspiraw
same trouble


Anyway, if this is merged with the main tree quite soon, I might just jump on that waggon and wait a little longer. Ill keep on investigating when I come back from my hike in the tundra.

tchiwam
Posts: 43
Joined: Mon Nov 24, 2014 4:01 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Mon May 25, 2015 1:12 am

Oh yes and it works !!!

Anyone here having the 6second and ISO800 registers ? I'd love to have those !!

Thank you and thank you again !

I had an old version of wiringPi ... That's all

tchiwam
Posts: 43
Joined: Mon Nov 24, 2014 4:01 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Mon May 25, 2015 4:13 am

Another note: with the raw firmware only 128MB of ram is available, even on a Rpi2

Something others might want to know :)

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

Re: Raw sensor access / CSI-2 receiver peripheral

Mon May 25, 2015 7:00 am

tchiwam wrote:Another note: with the raw firmware only 128MB of ram is available, even on a Rpi2

Something others might want to know :)
Test firmware only. There's some magic that they do for the release ones which I haven't replicated, but thanks for pointing it out to others.
tchiwam wrote:Anyone here having the 6second and ISO800 registers ? I'd love to have those !!
You could always have a go at working them out for yourself. https://github.com/raspberrypi/userland ... -101806950 I stated that the exposure time from the raspiraw I2C dump was 36.403ms, and analogue gain of (I think) x2.18. There is a provisional datasheet in the wild, and you should be able to work out the correct registers from there.

Upping from a 1sec max exposure to 6secs (effectively switching from mode 2 to mode 3) will probably require asking jbeale or someone nicely to capture the alternate I2C register set. There's nothing particularly magic about it - IIRC it's only about a dozen registers set differently.
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.

tmorley
Posts: 5
Joined: Sat May 23, 2015 9:31 am

Re: Raw sensor access / CSI-2 receiver peripheral

Mon May 25, 2015 12:27 pm

I've just done some i2c captures of various raspistill options, you can download them from http://ordered.chaos.org.uk/~tim/pi-camera/

Post here if there are any specific options you want me to try and grab!

tchiwam
Posts: 43
Joined: Mon Nov 24, 2014 4:01 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Tue May 26, 2015 4:25 pm

I think I know where the interesting parts are so I'll try to make them as soon as we can have a new firmware( more than 128MB cpu memory is needed). I've put them in a table and sorted the values that you already grabbed.

I use/need these:
awb off ( Playing with the analog or digital gain of r and b, same as ISO ?)
auto exposures off (anything that can play with the analog gain in anyway should be off)

Then the combinations of these:
ISO 800-400-200-100 (my guess they are the analog gain on separate channels, haven't found a common gain for the ISO)
shutter times of 1/4, 1/2, 1, 2, 4, 6 seconds

Once I have those sorted , then the RGB (awb r,b) independent gains, as I will have very narrow filters.

Once those are done I think that we can mark the registers as 'known' with human readable tags ;) I do not know if the tags can then be merged in the main repository or should they be stored in a separate repository...

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

Re: Raw sensor access / CSI-2 receiver peripheral

Tue May 26, 2015 5:07 pm

White balance isn't done on the sensor - this is spitting out raw Bayer data. The only useful settings in the sensor are exposure time, and analogue gain. Everything else you will have to do in post processing.

I take it you have Googled for the datasheet - you don't need to decode the entire register set (even those with the full datasheet can't do that as some bits aren't documented!), just the bits of interest.
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.

greenarchon
Posts: 5
Joined: Thu May 28, 2015 1:46 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Thu May 28, 2015 4:14 pm

6by9 wrote: [*]The hardware peripheral has quite a few nifty tricks up its sleeve, such as decompressing DPCM data, or repacking data to an alternate bit depth. This has not been tested, but the relevant enums are there.
Has anyone had any success playing with the bit depth (to get, say, 8 bit images)? I haven't had much success with the camera registers so I figured I'd try the GPU repacking (tried playing with MMAL_PARAMETER_CAMERA_RX_CONFIG_T->.{unpack, pack, encode} and MMAL_PORT_T->format->encoding) but I'm not having much success with it either. Among other things, I'm also not sure that I understand the difference between CAMERA_RX_CONFIG->encode and PORT->format->encoding, I don't know if someone with more experience with MMAL could shed some light on that point?

Also, on a slightly related note, how much of the repacking is done on a dedicated block on the GPU and how much of it uses the GPU's core QPU? (ie. is the CSI->RAM still done by DMA if repacking is involved?)

Thanks in advance (and thanks 6by9 for making this raw access possible in the first place)

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

Re: Raw sensor access / CSI-2 receiver peripheral

Thu May 28, 2015 5:05 pm

greenarchon wrote:Has anyone had any success playing with the bit depth (to get, say, 8 bit images)? I haven't had much success with the camera registers so I figured I'd try the GPU repacking (tried playing with MMAL_PARAMETER_CAMERA_RX_CONFIG_T->.{unpack, pack, encode} and MMAL_PORT_T->format->encoding) but I'm not having much success with it either. Among other things, I'm also not sure that I understand the difference between CAMERA_RX_CONFIG->encode and PORT->format->encoding, I don't know if someone with more experience with MMAL could shed some light on that point?
CAMERA_RX_CONFIG is setting up the receiver peripheral. format->encoding is the format of the output buffers. Yes, you can create wonderful mismatches here and nothing will stop you - here be dragons!
eg The receiver is told the stride as dictated by the port format. If that doesn't match the stride of the incoming data stream, then either you'll get uninitialised memory at the right hand edge of the image (if stride too large), or it will crop the right hand edge off the image (if stride too small. It shouldn't manage to overrun the buffer though as it is given an end address).
Likewise on height, if the incoming data continues once the receiver has hit the defined end of buffer, it will wrap to the top of the buffer and continue writing.
Lots of fun and games (which is one of the reasons that opening up the full camera stack is such a can of worms so it won't happen).

I have tested this with commit https://github.com/6by9/userland/commit ... ff8b651d21 in my userland/rawcam branch. At the top of the source is

Code: Select all

#define RAW_16
#ifdef RAW16
#define ENCODING MMAL_ENCODING_BAYER_SBGGR16
#define UNPACK MMAL_CAMERA_RX_CONFIG_UNPACK_10;
#define PACK MMAL_CAMERA_RX_CONFIG_PACK_16;
#else
#define ENCODING MMAL_ENCODING_BAYER_SBGGR10P
#define UNPACK MMAL_CAMERA_RX_CONFIG_UNPACK_NONE;
#define PACK MMAL_CAMERA_RX_CONFIG_PACK_NONE;
#endif
So we haven't changed the encoding coming off the camera at all - that is always Bayer RAW10.
What has been changed is that the receiver peripheral has been told to unpack the raw 10 data and output it as raw 16. MMAL also needs to be told that the output data is raw 16, otherwise it will allocate buffers and image strides based on the wrong image format.
(Oops that I left the default as unpacking to raw 16, but this is only test code!)
Memory says that if you ask for either unpack or pack, you must ask for the other as well. That may be wrong, but I probably safest to do it, and generally you need both anyway. (I seem to have misplaced my copy of the hardware spec sheet at the moment, so can't confirm it).

Encode and decode is all related to DPCM compressing the data. Some sensors allow you to compress the data, but that makes it harder to work with. The receiver will decompress on the fly, and write decompressed data out to memory. Or you can compress on the fly if you are short of memory and your processing stages can cope with DPCM.

For decoding to 8 bit data, try:

Code: Select all

#define ENCODING MMAL_ENCODING_BAYER_SBGGR8
#define UNPACK MMAL_CAMERA_RX_CONFIG_UNPACK_10;
#define PACK MMAL_CAMERA_RX_CONFIG_PACK_8;
greenarchon wrote:Also, on a slightly related note, how much of the repacking is done on a dedicated block on the GPU and how much of it uses the GPU's core QPU? (ie. is the CSI->RAM still done by DMA if repacking is involved?)
It is purely in the CSI-2 receiver hardware block before the data is DMAed to RAM. No involvement with the QPU. The VPU gets involved in the MMAL component for setting up the buffers to be written to by the receiver, but doesn't touch the image data at all.
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.

greenarchon
Posts: 5
Joined: Thu May 28, 2015 1:46 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Thu May 28, 2015 8:20 pm

6by9 wrote:For decoding to 8 bit data, try:

Code: Select all

#define ENCODING MMAL_ENCODING_BAYER_SBGGR8
#define UNPACK MMAL_CAMERA_RX_CONFIG_UNPACK_10;
#define PACK MMAL_CAMERA_RX_CONFIG_PACK_8;
Thanks for the reply, it definitively helped (especially with the pack/unpack, I wasn't sure which way was packing/unpacking). However, we're not quite there yet...

Looking at an (underexposed) ceiling/neon:
The default 10 bit picture (pack/unpack none) and the 10->8 bit conversion done in post-processing:
https://www.dropbox.com/s/lewdikod0g2chhn/raw0016.png
The 8 bit picture taken with the parameters you suggested:
https://www.dropbox.com/s/zjzv7c17zfrktqg/raw0031.png
Note that the camera did not move between the shots, so the neon is clearly misplaced in the second picture. Also, the second picture is definitively an 8 bit image, since converting it as if it was a 10 bit picture yields pretty much the same result, and it doesn't look like a 10 bit image in an hexdump (where, on 10 bit images, each fifth byte generally holds a high value)

Any ideas?
6by9 wrote:

Code: Select all

#define RAW_16
#ifdef RAW16
#define ENCODING MMAL_ENCODING_BAYER_SBGGR16
#define UNPACK MMAL_CAMERA_RX_CONFIG_UNPACK_10;
#define PACK MMAL_CAMERA_RX_CONFIG_PACK_16;
[...]
(Oops that I left the default as unpacking to raw 16, but this is only test code!)
Actually you haven't, you defined RAW_16 but the condition is on RAW16 ;)

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

Re: Raw sensor access / CSI-2 receiver peripheral

Thu May 28, 2015 10:03 pm

greenarchon wrote:Looking at an (underexposed) ceiling/neon:
The default 10 bit picture (pack/unpack none) and the 10->8 bit conversion done in post-processing:
https://www.dropbox.com/s/lewdikod0g2chhn/raw0016.png
The 8 bit picture taken with the parameters you suggested:
https://www.dropbox.com/s/zjzv7c17zfrktqg/raw0031.png
Note that the camera did not move between the shots, so the neon is clearly misplaced in the second picture. Also, the second picture is definitively an 8 bit image, since converting it as if it was a 10 bit picture yields pretty much the same result, and it doesn't look like a 10 bit image in an hexdump (where, on 10 bit images, each fifth byte generally holds a high value)

Any ideas?
I haven't got kit to hand to test with, but that does sound like something odd. Theory all looks right for that - I know I made typos in the first attempt and mismatched my enums, so it's quite possible I've made typos elsewhere.
How are you processing the images to produce your PNG files? It's possible something is being incorrectly processed there.

Just for info, raw 10 is an absolute pain to deal with. Have a look at the spec (unofficial copy at http://electronix.ru/forum/index.php?ac ... t&id=67362 page 92) it is sent as the MS 8bits for 4 pixels, and then the LS 2bits of each of those pixels packed into a 5th byte. That is why every fifth byte looks strange.
greenarchon wrote:
6by9 wrote: (Oops that I left the default as unpacking to raw 16, but this is only test code!)
Actually you haven't, you defined RAW_16 but the condition is on RAW16 ;)
:oops: I did a code tidy up after having proved it worked. I obviously didn't check it that carefully!
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.

greenarchon
Posts: 5
Joined: Thu May 28, 2015 1:46 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Thu May 28, 2015 11:43 pm

The images were obtained with ImageMagick:

Code: Select all

convert -size 2592x1952 gray:8bitimg.raw 8bitimg.png
Note that I have had similar result (albeit in color) with a modified version of your modified dcraw to process images as 8 bits instead

The 10 bit image taken from the sensor (the one that looks right) was converted to 8 bits by removing each fifth byte of the image.

Anyways, if I have the time I guess I'll try seeing what happens if I try other values for those enums, or I'll just post-process the removal of that fifth byte (and deal with all the unaligned access fun that goes along with that ^^).

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

Re: Raw sensor access / CSI-2 receiver peripheral

Fri May 29, 2015 2:02 pm

Something very odd going on. Hooking the VideoCore debugger on shows that the hardware has been programmed to do an unpack 6, pack 14?!
Then again I need to find my datasheet as with the RAW16 config it claims unpack 12 (enum 5), pack 14 (enum 4). That is what the component has been told too, including in the MMAL request from the ARM
...
Oh, I'm a numpty. Spot the deliberate error:

Code: Select all

	rx_cfg.unpack = PACK;
	rx_cfg.pack = UNPACK;
:oops:
unpack 10 is enum 4, pack 16 is enum 5. Correct those and it appears to do the right thing (though I've only looked at it as 8bit greyscale, not correctly demosaiced).
I'll punt up a corrective commit to my userland tree.
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.

greenarchon
Posts: 5
Joined: Thu May 28, 2015 1:46 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Fri May 29, 2015 2:43 pm

Yep, I can confirm that that works indeed ;)

Thank you for your time.

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

Re: Raw sensor access / CSI-2 receiver peripheral

Sat May 30, 2015 7:18 pm

Dom has done the magic, so sudo rpi-update should get you an official release with the rawcam support in. That should also allow you to modify the GPU memory allocation and the like.
I'll tidy things up a little and make a PR for the userland app when I get a chance.
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.

EpsiOne
Posts: 2
Joined: Tue Jun 02, 2015 7:37 am
Location: Malmö, Sweden

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Jun 02, 2015 3:04 pm

Hello 6by9 and everyone else who is doing all the hard work!

I found my way here after reading a discussion on DIY Drones (http://diydrones.com/forum/topics/3-km- ... y-hardware) where the Paspberry is used to stream video using a technique called "Wifibroadcast".

Me and a lot of other drone pilots would be more than happy to be able to use our GoPros and other HDMI cameras with this new low latency "Wifibroadcast", instead of the Raspberry Pi camera module.

Being a beginner I've tried to understand this very interesting thread without really understanding anything... So I'm just going to ask: Will this progress that is being done right know enable us to use an module like this, B100 HDMI to CSI-2 Bridge: http://www.auvidea.com/index.php/theme- ... i-2-bridge to connect an HDMI camera to our Raspberry any time soon?

If I'm completely lost, I'm sorry for taking your time. Keep up the good work!

rascol
Posts: 9
Joined: Sat May 30, 2015 1:48 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Jun 02, 2015 4:15 pm

At the moment the only i2c device on my RPi 2 is /dev/i2c-1 and so far no luck in getting a /dev/i2c-0 device working. Is it possible to get raw sensor access working on ic2-1 instead? Or do I have to first get ic2-0 going?

flu
Posts: 7
Joined: Sun May 31, 2015 8:10 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Jun 02, 2015 5:34 pm

Many thanks you for this effort 6by9, it seems to be very helpful to me.
Today I managed to run raspiraw, and in the resulting raw-files I found the 5-Byte patterns which I expecteded. So I think everything works fine.
Before this achievement, I spent some time to modify "raspistill", and was happy to identify the raw data on the fly, when I learned that I could not control analog gain at all. This fact killed the approach based on raspistill. I absolutely need control of analog gain. (By the way raspistill contains a huge amount of code, and so it was not a good starting point anyway)

I work on a project to create true random numbers out of shot noise, which I want to extract from uniform light shining on the camera. There is a very interesting paper, which describes this concept: "quantum random number generation on a mobile phone" (Bruno Sanguinetti,* Anthony Martin, Hugo Zbinden, and Nicolas Gisin Group of Applied Physics, University of Geneva). I spend my spare time on this project, because I think this gives a very useful application for the Raspberry Pi.

my questions:
  • you wrote "therefore you've got one fixed exposure time and analogue gain." I suppose to choose fixed exposure time and analogue gain means changing the appropriate entries of struct sensor_regs ov5647[] - do you know which ones / how to find out? I am looking for maximum analogue gain.
  • I found a spec from Omnivision which seems rather official (marked "preliminary Specification", november 2009, 140 pages). Is this the "copy floating around", or is there something better?
and my lessons learned before I managed to run raspiraw (little stones, but may be someone else struggles with them too):
  • it is not enough to clone the modified user land, one has to tell git to do a switch from master to branch "raw cam"
  • when wiringPi is installed, and /dev/i2c-0 is enabled, one may have to check the rights associated with /dev/i2c-0 and do a chmod

Return to “Camera board”