Raw sensor access / CSI-2 receiver peripheral

[6by9]

Not much difference between "-fps 60" and "-fps 90" I2C sequences compared to 1000 lines in total:

Code: Select all

$ wc --lines 60_.csv 90_.csv 
 1003 60_.csv
  991 90_.csv
 1994 total
$ diff 60_.csv 90_.csv | wc --lines
136
$ 

At a guess the longer log was the first camera command since boot, and so included the probing of the cameras before it started actually using them.

If you can switch to printing out hex instead of ASCII then you'll be better off, and should see significant overlap with raspiraw.

'l' = 0x6C, which is address 0x36 shifted left by 1, and the read/write bit set to 0 for write.
'm' = 0x6D, which is address 0x36 shifted left by 1, and the read/write bit set to 1 for read.

Code: Select all

1.21549542	I2C	Setup	Write	to	[l]	+	ACK
1.21558542	I2C	0	+	ACK			
1.21567542	I2C	\n	+	ACK			
1.21578542	I2C	Setup	Read	to	[m]	+	ACK
1.21587542	I2C	V	+	ACK			
1.21596542	I2C	G	+	NAK			

- Write 0x30 0x0A (0 \n)
- Read 0x56 0x47 (V G).
https://github.com/6by9/userland/blob/r ... des.h#L860

[HermannSW]

Thanks for the help.

> At a guess the longer log was the first camera command since boot,
> and so included the probing of the cameras before it started actually using them.
>
No, even if I do two captures one after the other with exact same command line, the probing is always there:

Code: Select all

...
I2C,Setup Write to [0x6C] + ACK         I2C,Setup Write to [0x6C] + ACK
I2C,0x30 + ACK                          I2C,0x30 + ACK
I2C,0x0A + ACK                          I2C,0x0A + ACK
I2C,Setup Read to [0x6D] + ACK          I2C,Setup Read to [0x6D] + ACK
I2C,0x56 + ACK                          I2C,0x56 + ACK
I2C,0x47 + NAK                          I2C,0x47 + NAK
...

> If you can switch to printing out hex instead of ASCII then you'll be better off,
>
I did change to hex in Salea preferences.

> and should see significant overlap with raspiraw.
>
I did not analyze raspiraw yet ...


These are the two commands I measured:

Code: Select all

$ time raspivid -w 640 -h 480 -ss 1000 -ex off -fps 60 -t 3000 -o foo.h264
$ time raspivid -w 640 -h 480 -ss 1000 -ex off -fps 90 -t 3000 -o foo.h264

In attached i2c.zip there are two i2c decoded traces for 60fps and one for 90fps, as well as side-by-side diff between 60a.csv and 90a.csv discarding timestamp column.

I2C frequency is 100KHz:


Both command lines take slightly more than 3 seconds of the 6 seconds captured. The final signal after 3 seconds terminates the camera transmission:


This shows that both 60fps i2c sequences are identical if ignoring the 1st(timestamp) column. And that both 60fps runs have different timestamps:

Code: Select all

$ diff <(cut -f2- -d, 60a.csv) <(cut -f2- -d, 60b.csv) 
$ 
$ head --lines 3 60a.csv 60b.csv 
==> 60a.csv <==
Time [s], Analyzer Name, Decoded Protocol Result
1.043579550000000,I2C,Setup Write to [0x6C] + NAK
1.043689550000000,I2C,Setup Read to [0x6D] + NAK

==> 60b.csv <==
Time [s], Analyzer Name, Decoded Protocol Result
1.069103410000000,I2C,Setup Write to [0x6C] + NAK
1.069213410000000,I2C,Setup Read to [0x6D] + NAK
$ 

This shows that the i2c decoded files fit into 49 columns, and how I did setup the side-by-side diff in attached .zip:

Code: Select all

$ diff <(cut -b-49 60a.csv) 60a.csv 
$ diff <(cut -b-49 90a.csv) 90a.csv 
$ tail -1 60a.csv | cut -f1 -d, | wc --bytes
18
$ diff --side-by-side -W 74 <(cut -f2- -d, 60a.csv) <(cut -f2- -d, 90a.csv) > diff.txt
$ 

I was not able to get side-by-side diff with timestamps, but files with timestamps are in .zip as well.
(differences are marked with '<', '|' or '>' in the middle)

[HermannSW]

I did capture and i2c decode this raspiraw run as well (-md 7 is 640x480 with 60-90fps), into file md7.csv:

Code: Select all

$ raspiraw -hd -md 7 -t 3000 -o out.%03d.raw

And I compared against 60a.csv from yesterday (raspivid with -fps 60), because "-md 7" always shows (only) 60fps with raspiraw.
The line count difference is really big, raspiraw does much less i2c commands:

Code: Select all

$ wc --lines 60a.csv md7.csv 
 1003 60a.csv
  379 md7.csv
 1382 total
$ 

6by9 previous comment:
> and should see significant overlap with raspiraw.
>
diff command was smart enough to do a good match between both files.
Finally I created side-by-side diff between 60a.csv and md7.csv:

Code: Select all

$ diff --side-by-side -W 74 <(cut -f2- -d, 60a.csv) <(cut -f2- -d, md7.csv) > diff_.txt
$

A really good match, only 47 lines different on the right side (md7.csv), although 60a.csv has 1003 lines!

Code: Select all

$ grep ">" diff_.txt | wc --lines
29
$ grep "|" diff_.txt | wc --lines
18
$ 

These i2c writes in md7.csv are start and stop commands for taking frames from camera:

Code: Select all

...
1.373255370000000,I2C,Setup Write to [0x6C] + ACK
1.373345370000000,I2C,0x01 + ACK
1.373435370000000,I2C,0x00 + ACK
1.373525370000000,I2C,0x01 + ACK
4.373996910000000,I2C,Setup Write to [0x6C] + ACK
4.374086910000000,I2C,0x01 + ACK
4.374176910000000,I2C,0x00 + ACK
4.374266900000000,I2C,0x00 + ACK
 

All new files attached in i2c_,zip, next step is to identify in raspiraw source code where the md7.csv i2c commands are prepared/sent. Then look for differences between 60a.csv and 90a.csv from yesterday on what i2c commands to send differently, which should result in "raspiraw -md 7 ..." run with 90fps ... or better add new "-md 8" that does 640x480 @90fps.

[HermannSW]

OK, raspiraw i2c command code is really tidy.

From "ov5647_modes.h":

Code: Select all

...
struct sensor_regs ov5647_mode7[] =
{
      addreg(0x0100, 0x00),
      addreg(0x0103, 0x01),
      addreg(0x3034, 0x1A),
      addreg(0x3035, 0x21),
      addreg(0x3036, 0x69),
      addreg(0x303C, 0x11),
      addreg(0x3106, 0xF5),
      addreg(0x3827, 0xEC),
      addreg(0x370C, 0x0F),
      addreg(0x3612, 0x59),
      addreg(0x3618, 0x00),
      addreg(0x5000, 0x06),
      addreg(0x5002, 0x40),
      addreg(0x5003, 0x08),
      addreg(0x5A00, 0x08),
      addreg(0x3000, 0x00),
      addreg(0x3001, 0x00),
      addreg(0x3002, 0x00),
      addreg(0x3016, 0x08),
      addreg(0x3017, 0xE0),
      addreg(0x3018, 0x44),
      addreg(0x301C, 0xF8),
      addreg(0x301D, 0xF0),
      addreg(0x3A18, 0x00),
      addreg(0x3A19, 0xF8),
      addreg(0x3C01, 0x80),
      addreg(0x3B07, 0x0C),
      addreg(0x380C, 0x07),
      addreg(0x380D, 0x3C),
      addreg(0x3814, 0x71),
      addreg(0x3815, 0x35),
      addreg(0x3708, 0x64),
      addreg(0x3709, 0x52),
      addreg(0x3808, 0x02),
      addreg(0x3809, 0x80),
      addreg(0x380A, 0x01),
      addreg(0x380B, 0xE0),
      addreg(0x3800, 0x00),
      addreg(0x3801, 0x10),
      addreg(0x3802, 0x00),
      addreg(0x3803, 0x00),
      addreg(0x3804, 0x0A),
      addreg(0x3805, 0x2F),
      addreg(0x3806, 0x07),
      addreg(0x3807, 0x9F),
      addreg(0x3630, 0x2E),
      addreg(0x3632, 0xE2),
      addreg(0x3633, 0x23),
      addreg(0x3634, 0x44),
      addreg(0x3636, 0x06),
      addreg(0x3620, 0x64),
      addreg(0x3621, 0xE0),
      addreg(0x3600, 0x37),
      addreg(0x3704, 0xA0),
      addreg(0x3703, 0x5A),
      addreg(0x3715, 0x78),
      addreg(0x3717, 0x01),
      addreg(0x3731, 0x02),
      addreg(0x370B, 0x60),
      addreg(0x3705, 0x1A),
      addreg(0x3F05, 0x02),
      addreg(0x3F06, 0x10),
      addreg(0x3F01, 0x0A),
      addreg(0x3A08, 0x01),
      addreg(0x3A09, 0x2E),
      addreg(0x3A0A, 0x00),
      addreg(0x3A0B, 0xFB),
      addreg(0x3A0D, 0x02),
      addreg(0x3A0E, 0x01),
      addreg(0x3A0F, 0x58),
      addreg(0x3A10, 0x50),
      addreg(0x3A1B, 0x58),
      addreg(0x3A1E, 0x50),
      addreg(0x3A11, 0x60),
      addreg(0x3A1F, 0x28),
      addreg(0x4001, 0x02),
      addreg(0x4004, 0x02),
      addreg(0x4000, 0x09),
      addreg(0x4837, 0x17),
      addreg(0x4800, 0x34),
      addreg(0x3503, 0x03),
      addreg(0x3820, 0x41),
      addreg(0x3821, 0x03),
      addreg(0x380E, 0x03),
      addreg(0x380F, 0x12),
      addreg(0x350A, 0x00),
      addreg(0x350B, 0x10),
      addreg(0x3500, 0x00),
      addreg(0x3501, 0x1D),
      addreg(0x3502, 0x80),
      addreg(0x3212, 0xA0),
      addreg(0x0100, 0x01),
};
...

I did split out the pure bytes from md7.csv and from above "sensor_regs ov5647_mode7" (mod.txt). As you can see the diff is device probing (finding OV4647) and the final termination of camera frame capturing!

Code: Select all

$ for x in `cut -b14-25 mod.txt | sed "s/\(..\),/ 0x\1/g"`; do echo $x ; done > mod.bytes
$ cut -b23-26 md7.csv | grep ^0x  > md7.bytes
$ diff md7.bytes mod.bytes 
1,4d0
< 0x30
< 0x0A
< 0x56
< 0x47
281,283d276
< 0x01
< 0x00
< 0x00
$ 

So just adding new "sensor_regs ov5647_mode8" for new "-md 8" raspiraw mode with the needed values for 90fps (to be looked up from 60a.csv to 90a.csv diff) is all that is needed ...

[HermannSW]

Done!

I just added a new "mode8" to "ov5647_modes.h", and that was all that was needed.

I simply took all relevant i2c writes from 90a.csv starting in the middle of the file with these writes

Code: Select all

...
1.668625340000000,I2C,Setup Write to [0x6C] + ACK
1.668715340000000,I2C,0x01 + ACK
1.668805340000000,I2C,0x00 + ACK
1.668895340000000,I2C,0x00 + ACK
1.670090340000000,I2C,Setup Write to [0x6C] + ACK
1.670180330000000,I2C,0x01 + ACK
1.670270330000000,I2C,0x03 + ACK
1.670360330000000,I2C,0x01 + ACK
...

and created

Code: Select all

      addreg(0x0100, 0x00),
      addreg(0x0103, 0x01),
...

from them. I was not sure about the "int line_time_ns" last column value.
But 31749/21165=1.5 and 60fps/42fps=1.43.
Therefore I chose 21165/(90/60)=14110 for the new 90fps 640x480 mode:

$ tail -7 patch.txt
{ ov5647_mode5, NUM_ELEMENTS(ov5647_mode5), 1296, 730, 0, BAYER_ORDER_GBRG, 10, 0x2B, 2, 870, 31390 },
{ ov5647_mode6, NUM_ELEMENTS(ov5647_mode6), 640, 480, 0, BAYER_ORDER_GBRG, 10, 0x2B, 2, 484, 31749 },
{ ov5647_mode7, NUM_ELEMENTS(ov5647_mode7), 640, 480, 0, BAYER_ORDER_GBRG, 10, 0x2B, 2, 484, 21165 },
+ { ov5647_mode8, NUM_ELEMENTS(ov5647_mode8), 640, 480, 0, BAYER_ORDER_GBRG, 10, 0x2B, 2, 484, 14110 },
};

#undef addreg
$

Find in attatched "raspiraw.90fps.zip" a patch file ("patch -p0 < patch.txt") and for convenience the already modified "ov5647_modes.h".

Here is a simple demonstration that indeed 90fps capturing happens.
With saverate 10, 9 frames will be saved per second, or 27 in 3 seconds:

Code: Select all

$ rm out.*.raw
$ raspiraw -md 8 -t 3000 -sr 10 -o out.%03d.raw
RaspiRaw: Probing sensor ov5647 on addr 36
RaspiRaw: Found sensor ov5647 at address 36
...
$ ls -l out.*.raw | wc --lines
27
$ ll out.*.raw | tail -2
-rw-r--r-- 1 pi pi 384000 Nov 25 20:02 out.251.raw
-rw-r--r-- 1 pi pi 384000 Nov 25 20:02 out.261.raw
$ 

Thanks to 6by9 for the many tips that made it possible for me to get 90fps added to raspiraw.

[6by9]

I was expecting to find only one or two registers different between mode 7 at 60fps and mode 7 at 90fps (it's a register that is already manipulated in raspiraw).
Adding a full mode for it is excessive - unless I've missed something it should be relatively easy to add an fps option that works in all modes, and can be extended to work on the IMX219 as well.

[HermannSW]

> I was expecting to find only one or two registers different between mode 7 at 60fps and mode 7 at 90fps
> (it's a register that is already manipulated in raspiraw).
>
I would have awaited similar, but since you cannot give us details because of your NDA, all we can do is measuring and i2c decoding raspivid runs with changing parameters. I provided 60a.csv and 90a.csv for640x480 runs with 60/90 fps. And the differences are not small:

Code: Select all

$ diff --side-by-side -W 74 <(cut -f2- -d, 60a.csv) <(cut -f2- -d, 90a.csv) | grep "<" | wc --lines
48
$ diff --side-by-side -W 74 <(cut -f2- -d, 60a.csv) <(cut -f2- -d, 90a.csv) | grep "|" | wc --lines
12
$ diff --side-by-side -W 74 <(cut -f2- -d, 60a.csv) <(cut -f2- -d, 90a.csv) | grep ">" | wc --lines
36
$ 

> Adding a full mode for it is excessive
>
As a compromise for new mode 8 I did convert i2c decoding from raspivid 90fps run for 320x240. Because there is no mode for 320x240 yet, a new mode seems appropriate. But I need help on how to determine these values for 320x240 mode (the last should be deterninable by calculation, but I don't know how):

Code: Select all

pi@raspberrypi2B:~/userland-rawcam/host_applications/linux/apps/raspicam $ export PS1=$\ 
$ sed -n "/^struct mode_def/,/^};/p" raspiraw.c | tail -3
	unsigned int min_vts;
	int line_time_ns;
};
$ 

With wrong guesses for both raspiraw runs, but not a single frame callback happens.


I have another question on raspiraw. I just today realized the "-b" option to specify bitlevel 8/10/12/16 with 10 being the default. 10, 12 and 16 work fine for me, and the size for each frame matches width*height*b/8.

But "... -b 8 ..." fails for me on two PIs/SD cards with "mmal: Failed to create pool" in the middle:

Code: Select all

$ raspiraw -md 6 -b 8 -t 3000 -sr 10 -o out.%03d.raw
RaspiRaw: Probing sensor ov5647 on addr 36
RaspiRaw: Found sensor ov5647 at address 36
RaspiRaw: Encoding 47524247
mmal: mmal_port_alloc: component:vc.ril.rawcam type:1 extra:0
mmal: mmal_port_alloc: vc.ril.rawcam:ctr:0: created at 0x8c5500
mmal: mmal_vc_component_create: vc.ril.rawcam
mmal: mmal_vc_component_create: vc.ril.rawcam: handle 0x40 status 0 reply status 0
mmal: mmal_port_free: vc.ril.rawcam:ctr:0 at 0x8c5500
mmal: mmal_port_alloc: component:vc.ril.rawcam type:1 extra:384
mmal: mmal_port_alloc: vc.ril.rawcam:ctr:0: created at 0x8c58b0
mmal: mmal_port_alloc: component:vc.ril.rawcam type:3 extra:384
mmal: mmal_port_alloc: vc.ril.rawcam:out:0: created at 0x8c5bc0
mmal: mmal_vc_component_create:  handle 64
mmal: mmal_vc_port_info_get: get port info (1:0)
mmal: mmal_vc_port_info_get: get port info (3:0)
mmal: mmal_pool_create_with_allocator: allocating 48 + 24 + 472 * 4 bytes for pool
mmal: mmal_pool_initialise_buffer_headers: allocating 740 bytes for payload 0/4
mmal: mmal_pool_initialise_buffer_headers: allocating 740 bytes for payload 1/4
mmal: mmal_pool_initialise_buffer_headers: allocating 740 bytes for payload 2/4
mmal: mmal_pool_initialise_buffer_headers: allocating 740 bytes for payload 3/4
mmal: mmal_component_create_core: created 'vc.ril.rawcam' 0 0x8c5330
mmal: mmal_component_create: vc.ril.isp
mmal: mmal_port_alloc: component:vc.ril.isp type:1 extra:0
mmal: mmal_port_alloc: vc.ril.isp:ctr:0: created at 0x8c7570
mmal: mmal_vc_component_create: vc.ril.isp
mmal: mmal_vc_component_create: vc.ril.isp: handle 0x38 status 0 reply status 0
mmal: mmal_port_free: vc.ril.isp:ctr:0 at 0x8c7570
mmal: mmal_port_alloc: component:vc.ril.isp type:1 extra:384
mmal: mmal_port_alloc: vc.ril.isp:ctr:0: created at 0x8c7930
mmal: mmal_port_alloc: component:vc.ril.isp type:2 extra:384
mmal: mmal_port_alloc: vc.ril.isp:in:0: created at 0x8c7c40
mmal: mmal_port_alloc: component:vc.ril.isp type:3 extra:384
mmal: mmal_port_alloc: vc.ril.isp:out:0: created at 0x8c7f50
mmal: mmal_port_alloc: component:vc.ril.isp type:3 extra:384
mmal: mmal_port_alloc: vc.ril.isp:out:0: created at 0x8c8300
mmal: mmal_vc_component_create:  handle 56
mmal: mmal_vc_port_info_get: get port info (1:0)
mmal: mmal_vc_port_info_get: get port info (2:0)
mmal: mmal_vc_port_info_get: get port info (3:0)
mmal: mmal_vc_port_info_get: get port info (3:1)
mmal: mmal_pool_create_with_allocator: allocating 48 + 24 + 472 * 4 bytes for pool
mmal: mmal_pool_initialise_buffer_headers: allocating 740 bytes for payload 0/4
mmal: mmal_pool_initialise_buffer_headers: allocating 740 bytes for payload 1/4
mmal: mmal_pool_initialise_buffer_headers: allocating 740 bytes for payload 2/4
mmal: mmal_pool_initialise_buffer_headers: allocating 740 bytes for payload 3/4
mmal: mmal_component_create_core: created 'vc.ril.isp' 1 0x8c73b0
mmal: mmal_component_create: vc.ril.video_render
mmal: mmal_port_alloc: component:vc.ril.video_render type:1 extra:0
mmal: mmal_port_alloc: vc.ril.video_render:ctr:0: created at 0x8c9d70
mmal: mmal_vc_component_create: vc.ril.video_render
mmal: mmal_vc_component_create: vc.ril.video_render: handle 0x30 status 0 reply status 0
mmal: mmal_port_free: vc.ril.video_render:ctr:0 at 0x8c9d70
mmal: mmal_port_alloc: component:vc.ril.video_render type:1 extra:384
mmal: mmal_port_alloc: vc.ril.video_render:ctr:0: created at 0x8ca130
mmal: mmal_port_alloc: component:vc.ril.video_render type:2 extra:384
mmal: mmal_port_alloc: vc.ril.video_render:in:0: created at 0x8ca450
mmal: mmal_vc_component_create:  handle 48
mmal: mmal_vc_port_info_get: get port info (1:0)
mmal: mmal_vc_port_info_get: get port info (2:0)
mmal: mmal_pool_create_with_allocator: allocating 48 + 24 + 472 * 4 bytes for pool
mmal: mmal_pool_initialise_buffer_headers: allocating 740 bytes for payload 0/4
mmal: mmal_pool_initialise_buffer_headers: allocating 740 bytes for payload 1/4
mmal: mmal_pool_initialise_buffer_headers: allocating 740 bytes for payload 2/4
mmal: mmal_pool_initialise_buffer_headers: allocating 740 bytes for payload 3/4
mmal: mmal_component_create_core: created 'vc.ril.video_render' 2 0x8c9bb0
mmal: mmal_port_parameter_get: vc.ril.rawcam(3:0) port 0x8c5bc0, param 0x7e89c4fc (1004d,40)
mmal: Set pack to 4, unpack to 1
mmal: mmal_port_parameter_set: vc.ril.rawcam(3:0) port 0x8c5bc0, param 0x7e89c4fc (1004d,40)
mmal: mmal_component_enable: vc.ril.rawcam 0
mmal: mmal_component_enable: vc.ril.isp 1
mmal: mmal_component_enable: vc.ril.video_render 2
mmal: mmal_port_format_commit: vc.ril.rawcam(3:0) port 0x8c5bc0 format 3:GBRG
mmal: mmal_vc_port_info_set: set port info (3:0)
mmal: mmal_vc_port_info_get: get port info (3:0)
mmal: mmal_port_parameter_set: vc.ril.rawcam(3:0) port 0x8c5bc0, param 0x7e89c49c (4,12)
mmal: mmal_vc_port_parameter_set: enable zero copy on port 0x8c5bc0
mmal: Create pool of 4 buffers of size 72806400
mmal: mmal_port_pool_create: vc.ril.rawcam(3:0) port 0x8c5bc0, headers 4, size 72806400
mmal: mmal_pool_create_with_allocator: allocating 48 + 24 + 472 * 4 bytes for pool
mmal: mmal_pool_initialise_buffer_headers: allocating 72806400 bytes for payload 0/4
mmal: mmal_port_payload_alloc: vc.ril.rawcam(3:0) port 0x8c5bc0, size 72806400
mmal: mmal_vc_port_payload_alloc: vc.ril.rawcam:out:0: allocating 72806400 bytes, format <0>, is_zero_copy 1
mmal: mmal_vc_port_payload_alloc: vc.ril.rawcam:out:0: allocated at 0x6ee91000
mmal: mmal_port_acquire: port vc.ril.rawcam:out:0(0x8c5bc0), refcount 0
mmal: mmal_pool_initialise_buffer_headers: allocating 72806400 bytes for payload 1/4
mmal: mmal_port_payload_alloc: vc.ril.rawcam(3:0) port 0x8c5bc0, size 72806400
mmal: mmal_vc_port_payload_alloc: vc.ril.rawcam:out:0: allocating 72806400 bytes, format <0>, is_zero_copy 1
usrvcsm: [vcsm_malloc_cache]: [790] [mmal_vc_port buffer]: ioctl mem-alloc FAILED [-1] (hdl: 0)
usrvcsm: [vcsm_vc_hdl_from_hdl]: [790]: invalid device or handle!
usrvcsm: [vcsm_lock]: [790]: invalid device or invalid handle!
mmal: mmal_vc_shm_alloc: could not allocate 72806400 bytes of shared memory (handle 0)
mmal: mmal_vc_port_payload_alloc: vc.ril.rawcam:out:0: failed to allocate 72806400 bytes of shared memory
mmal: mmal_pool_initialise_buffer_headers: failed to allocate payload 1/4
mmal: mmal_port_payload_free: vc.ril.rawcam(3:0) port 0x8c5bc0, payload 0x6ee91000
mmal: mmal_port_release: port vc.ril.rawcam:out:0(0x8c5bc0), refcount 1
mmal: Failed to create pool
mmal: mmal_component_disable: vc.ril.video_render 2
mmal: mmal_component_disable: vc.ril.isp 1
mmal: mmal_component_disable: vc.ril.rawcam 0
mmal: mmal_component_destroy: vc.ril.rawcam 0
mmal: mmal_component_release_internal: vc.ril.rawcam 0 preparing for destruction
mmal: mmal_port_disconnect: vc.ril.rawcam:out:0(0x8c5bc0)
mmal: mmal_port_disconnect: vc.ril.rawcam:out:0(0x8c5bc0) is not connected
mmal: mmal_component_destroy_internal: vc.ril.rawcam 0
mmal: mmal_port_free: vc.ril.rawcam:out:0 at 0x8c5bc0
mmal: mmal_port_free: vc.ril.rawcam:ctr:0 at 0x8c58b0
mmal: mmal_component_destroy: vc.ril.isp 1
mmal: mmal_component_release_internal: vc.ril.isp 1 preparing for destruction
mmal: mmal_port_disconnect: vc.ril.isp:in:0(0x8c7c40)
mmal: mmal_port_disconnect: vc.ril.isp:in:0(0x8c7c40) is not connected
mmal: mmal_port_disconnect: vc.ril.isp:out:0(0x8c7f50)
mmal: mmal_port_disconnect: vc.ril.isp:out:0(0x8c7f50) is not connected
mmal: mmal_port_disconnect: vc.ril.isp:out:1(0x8c8300)
mmal: mmal_port_disconnect: vc.ril.isp:out:1(0x8c8300) is not connected
mmal: mmal_component_destroy_internal: vc.ril.isp 1
mmal: mmal_port_free: vc.ril.isp:in:0 at 0x8c7c40
mmal: mmal_port_free: vc.ril.isp:out:0 at 0x8c7f50
mmal: mmal_port_free: vc.ril.isp:out:1 at 0x8c8300
mmal: mmal_port_free: vc.ril.isp:ctr:0 at 0x8c7930
mmal: mmal_component_destroy: vc.ril.video_render 2
mmal: mmal_component_release_internal: vc.ril.video_render 2 preparing for destruction
mmal: mmal_port_disconnect: vc.ril.video_render:in:0(0x8ca450)
mmal: mmal_port_disconnect: vc.ril.video_render:in:0(0x8ca450) is not connected
mmal: mmal_component_destroy_internal: vc.ril.video_render 2
mmal: mmal_port_free: vc.ril.video_render:in:0 at 0x8ca450
mmal: mmal_port_free: vc.ril.video_render:ctr:0 at 0x8ca130
$ 

Is "-b 8" supposed to work?
If so, what can be wrong?
Do you have a working raspiraw commandline with "-b 8"?

That mode would be cool to have because it avoids raw10->1 byte per pixel conversion in callback.

[AlexEts]

Hello 6by9. First of all thank you for the efforts you've put into raspiraw development.

I've recently notice that rawcam MMAL_ENCODING_BAYER_SXXXX8 modes seems are not supported properly by the output port of the rawcam component.

I'm using IMX219 and when raw data is captured in 8 bits mode it looks like raw BGGRbggr data is converted to Bb, Gg, Gg, Rr 10/12/16? bits and then Bb, Gg, Rr get cast to 8 bits without being properly scaled down/clamped so very bright pixels becomes very dark because of 8 bits overflow.
I getting these images:
8 bits interpolated and raw:

8_bit_mix.jpg (246.74 KiB) Viewed 8160 times

10 bits interpolated and raw:

10_bit_mix.jpg (87.63 KiB) Viewed 8160 times

RAW+ISP+RENDER output 8 bits vs 10 bits:

isp_render_mix.jpg (150.4 KiB) Viewed 8160 times

Is there any extra options I should use for rawcam component to get 8 bit data properly scaled down/clamped?

[HermannSW]

... I'm using IMX219 and when raw data is captured in 8 bits mode ...

Which command line did you use?
As stated in my last posting "-b 8" errors for me, but I am running v1.3 camera.
This is where "-b 8" fails, "-b" works fine for 10, 12 and 16 ...

Code: Select all

...
mmal: mmal_vc_port_payload_alloc: vc.ril.rawcam:out:0: allocating 72806400 bytes, format <0>, is_zero_copy 1
usrvcsm: [vcsm_malloc_cache]: [790] [mmal_vc_port buffer]: ioctl mem-alloc FAILED [-1] (hdl: 0)
usrvcsm: [vcsm_vc_hdl_from_hdl]: [790]: invalid device or handle!
usrvcsm: [vcsm_lock]: [790]: invalid device or invalid handle!
mmal: mmal_vc_shm_alloc: could not allocate 72806400 bytes of shared memory (handle 0)
...

[AlexEts]

Which command line did you use?

raspiraw -b 8 -t 10000

Code: Select all

RaspiRaw: Probing sensor ov5647 on addr 36
RaspiRaw: Probing sensor imx219 on addr 10
RaspiRaw: Found sensor imx219 at address 10
RaspiRaw: Encoding 31384142
mmal: Set pack to 4, unpack to 1
mmal: Now streaming...

This is where "-b 8" fails, "-b" works fine for 10, 12 and 16 ...

Code: Select all

...
mmal: mmal_vc_port_payload_alloc: vc.ril.rawcam:out:0: allocating 72806400 bytes, format <0>, is_zero_copy 1
usrvcsm: [vcsm_malloc_cache]: [790] [mmal_vc_port buffer]: ioctl mem-alloc FAILED [-1] (hdl: 0)
usrvcsm: [vcsm_vc_hdl_from_hdl]: [790]: invalid device or handle!
usrvcsm: [vcsm_lock]: [790]: invalid device or invalid handle!
mmal: mmal_vc_shm_alloc: could not allocate 72806400 bytes of shared memory (handle 0)
...

Check sudo raspi-config 'Memory Split' option. May be you need to increase the memory available to GPU

[6by9]

This is where "-b 8" fails, "-b" works fine for 10, 12 and 16 ...

Code: Select all

...
mmal: mmal_vc_port_payload_alloc: vc.ril.rawcam:out:0: allocating 72806400 bytes, format <0>, is_zero_copy 1
usrvcsm: [vcsm_malloc_cache]: [790] [mmal_vc_port buffer]: ioctl mem-alloc FAILED [-1] (hdl: 0)
usrvcsm: [vcsm_vc_hdl_from_hdl]: [790]: invalid device or handle!
usrvcsm: [vcsm_lock]: [790]: invalid device or invalid handle!
mmal: mmal_vc_shm_alloc: could not allocate 72806400 bytes of shared memory (handle 0)
...

Check sudo raspi-config 'Memory Split' option. May be you need to increase the memory available to GPU

Well it shouldn't be allocating 72MB for one buffer, so something has gone wrong in the calcs. I couldn't say where without digging in to the code.

[6by9]

> I was expecting to find only one or two registers different between mode 7 at 60fps and mode 7 at 90fps
> (it's a register that is already manipulated in raspiraw).
>
I would have awaited similar, but since you cannot give us details because of your NDA, all we can do is measuring and i2c decoding raspivid runs with changing parameters. I provided 60a.csv and 90a.csv for640x480 runs with 60/90 fps. And the differences are not small:

OK I've cheated in logging the I2C transactions being sent by the GPU rather than the data off the I2C bus, but the difference I get between

Code: Select all

raspivid -t 5000 -md 7 -fps 60 -o /dev/null -w 640 -h 480 -ex off -ss 1000

and

Code: Select all

raspivid -t 5000 -md 7 -fps 90 -o /dev/null -w 640 -h 480 -ex off -ss 1000

is only one 16 bit register on OV5647. (On IMX219 it is 1 register although written 3 times).

As a compromise for new mode 8 I did convert i2c decoding from raspivid 90fps run for 320x240. Because there is no mode for 320x240 yet, a new mode seems appropriate. But I need help on how to determine these values for 320x240 mode (the last should be deterninable by calculation, but I don't know how):

You may be able to work it out from the datasheet, potentially with assistance from the existing mode lists as you'll probably be wanting to amend the skipping registers too. OV5647 is not a trivial sensor to deal with though, with some awkward interactions that often meant we referred back to Omnivision.

[6by9]

Hello 6by9. First of all thank you for the efforts you've put into raspiraw development.

I've recently notice that rawcam MMAL_ENCODING_BAYER_SXXXX8 modes seems are not supported properly by the output port of the rawcam component.

I'm using IMX219 and when raw data is captured in 8 bits mode it looks like raw BGGRbggr data is converted to Bb, Gg, Gg, Rr 10/12/16? bits and then Bb, Gg, Rr get cast to 8 bits without being properly scaled down/clamped so very bright pixels becomes very dark because of 8 bits overflow.
<snip>
Is there any extra options I should use for rawcam component to get 8 bit data properly scaled down/clamped?

I have no access to the Verliog to check how the packing and unpacking works, but having captured some of the raw frames I think those are OK and it's likely to be the ISP component mishandling 8 bit. Certainly it looks like the black level is incorrect so giving significant greys instead of blacks, and asking for -b 16 gives very dark images. If that's wrong then I can see various points in the processing pipe saturating and giving colourful artifacts.
I'll have a look when I get a chance, although things like digital gain are now available via MMAL so worth playing with.

[HermannSW]

OK I've cheated in logging the I2C transactions being sent by the GPU rather than the data off the I2C bus, but the difference I get between

Code: Select all

raspivid -t 5000 -md 7 -fps 60 -o /dev/null -w 640 -h 480 -ex off -ss 1000

and

Code: Select all

raspivid -t 5000 -md 7 -fps 90 -o /dev/null -w 640 -h 480 -ex off -ss 1000

is only one 16 bit register on OV5647. (On IMX219 it is 1 register although written 3 times).

You are right, this is the only difference I get for your (new) commands:

Code: Select all

...
I2C,0x00 + ACK                          I2C,0x00 + ACK
I2C,Setup Write to [0x6C] + ACK         I2C,Setup Write to [0x6C] + ACK
I2C,0x38 + ACK                          I2C,0x38 + ACK
I2C,0x0E + ACK                          I2C,0x0E + ACK
I2C,0x03 + ACK                      |   I2C,0x02 + ACK
I2C,0x12 + ACK                      |   I2C,0x0C + ACK
I2C,Setup Write to [0x6C] + ACK         I2C,Setup Write to [0x6C] + ACK
I2C,0x35 + ACK                          I2C,0x35 + ACK
...

I went back to the commands I used before in this thread to find out whether I saw ghosts. The same bigger difference measured today:

Code: Select all

$ diff <(cut -f2- -d, 60A.csv) <(cut -f2- -d, 90A.csv) | wc --lines
    136 
$ 

But you used a different command today, in addition to -w 640 and -h 480 you did put "-md 7" into the command today. That seems to be the reason for only a single register change between both modes.


I went further down the modes, did run raspiraw and determined the current fps from the reported timestamps. For modes 1/2/3 raspiraw already captures at highest possible framerate 30/15/1 fps. For modes 4/5/6/7 raspiraw showed 30/30/42/60 fps. I did similar measurements and found 2 byte differences resulting in 42/42/60/90 fps.

Here is proof that indeed 90/60/42/42 fps get recorded from raspiraw (#lines / t * sr ... 27/3*10=90):

Code: Select all

$ rm out.*.raw
$ raspiraw -md 7 -t 3000 -sr 10 -o out.%03d.raw 2>/dev/null >/dev/null
$ ll out*raw | wc --lines
27
$ rm out.*.raw
$ raspiraw -md 6 -t 3000 -sr 10 -o out.%03d.raw 2>/dev/null >/dev/null
$ ll out*raw | wc --lines
18
$ rm out.*.raw
$ raspiraw -md 5 -t 3000 -sr 7 -o out.%03d.raw 2>/dev/null >/dev/null
$ ll out*raw | wc --lines
18
$ rm out.*.raw
$ raspiraw -md 4 -t 3000 -sr 7 -o out.%03d.raw 2>/dev/null >/dev/null
$ ll out*raw | wc --lines
18
$ 

These are the small changes for mode4-mode7 I verified to work:

Code: Select all

$ diff ov5647_modes.h.orig ov5647_modes.h
535,536c535,536
<       addreg(0x380E, 0x05),
<       addreg(0x380F, 0x9B),
---
>       addreg(0x380E, 0x04),
>       addreg(0x380F, 0x01),
631,632c631,632
<       addreg(0x380E, 0x05),
<       addreg(0x380F, 0x9B),
---
>       addreg(0x380E, 0x04),
>       addreg(0x380F, 0x01),
726c726
<       addreg(0x380F, 0xEC),
---
>       addreg(0x380F, 0x0C),
821,822c821,822
<       addreg(0x380E, 0x03),
<       addreg(0x380F, 0x12),
---
>       addreg(0x380E, 0x02),
>       addreg(0x380F, 0x0C),
$ 

Would be nice to see them on github raspiraw, with some fps commandline switch ...

P.S:

... is only one 16 bit register on OV5647. (On IMX219 it is 1 register although written 3 times).

Just saw this in Omnivision datasheet:
TIMING_VTS
0x380E Bit[1:0] Total vertical size [9:8]
0x380F Bit[7:0] Total vertical size [7:0]

[6by9]

OK I've cheated in logging the I2C transactions being sent by the GPU rather than the data off the I2C bus, but the difference I get between

Code: Select all

raspivid -t 5000 -md 7 -fps 60 -o /dev/null -w 640 -h 480 -ex off -ss 1000

and

Code: Select all

raspivid -t 5000 -md 7 -fps 90 -o /dev/null -w 640 -h 480 -ex off -ss 1000

is only one 16 bit register on OV5647. (On IMX219 it is 1 register although written 3 times).

You are right, this is the only difference I get for your (new) commands:

Not really new - viewtopic.php?f=43&t=109137&start=250#p1236009

by comparing "raspivid -md 7 -ss 1000 -ex off -fps 60 -o foo.h264" and "raspivid -md 7 -ss 1000 -ex off -fps 90 -o foo.h264".

Yes I've inserted -w and -h to reduce the output resolution from the default 1920x1080, but the -md 7 was there all along.
You dropped the -md 7 in favour of -w and -h:

P.P.S: Replacing "-md 7" with "-w 640 -h 480" does not complain:

viewtopic.php?f=43&t=109137&start=250#p1236446

[6by9]

640x480 @ 60 fps would be mode 6, which explains your significant differences.

[6by9]

< addreg(0x380E, 0x03),
< addreg(0x380F, 0x12),
---
> addreg(0x380E, 0x02),
> addreg(0x380F, 0x0C),

https://github.com/6by9/userland/blob/r ... des.h#L840

Code: Select all

 { ov5647_mode7, NUM_ELEMENTS(ov5647_mode7), 640, 480, 0, BAYER_ORDER_GBRG, 10, 0x2B, 2, 484, 21165},

0x312 = 786. 786 * 21165 = 16635690
0x20c = 524. 524 * 21165 = 11090460
Hmm.

Do note that VTS is only a 10bit field, so that is what limits the lowest frame rate that can be supported in each mode, and obviously it can't be less than the number of active lines in the frame.

[6by9]

Rawcam branch rebased to top of the main userland, and the timings corrected for OV5647.

[6by9]

Hello 6by9. First of all thank you for the efforts you've put into raspiraw development.

I've recently notice that rawcam MMAL_ENCODING_BAYER_SXXXX8 modes seems are not supported properly by the output port of the rawcam component.

I'm using IMX219 and when raw data is captured in 8 bits mode it looks like raw BGGRbggr data is converted to Bb, Gg, Gg, Rr 10/12/16? bits and then Bb, Gg, Rr get cast to 8 bits without being properly scaled down/clamped so very bright pixels becomes very dark because of 8 bits overflow.
<snip>
Is there any extra options I should use for rawcam component to get 8 bit data properly scaled down/clamped?

I have no access to the Verliog to check how the packing and unpacking works, but having captured some of the raw frames I think those are OK and it's likely to be the ISP component mishandling 8 bit. Certainly it looks like the black level is incorrect so giving significant greys instead of blacks, and asking for -b 16 gives very dark images. If that's wrong then I can see various points in the processing pipe saturating and giving colourful artifacts.
I'll have a look when I get a chance, although things like digital gain are now available via MMAL so worth playing with.

Bad news.
Having discussed it with a colleague it appears that the unpacking and packing is solely with regard the packing and not the scale of the values within it. Packing 10 to 8 will therefore be clipping the top two bits of the 10 bit word rather than shifting it down.
As a test I ran rawcam repacking from 10 bit to 16 bit, and then the ISP taking the 16 bit packing but treating it as 10bit data. The result was the same as if it were 10 bit throughout.

To get 8 bit data through you need to either set the sensor to produce only 8 bits (and reset rawcam etc to expect the new data type value and packing), or you could run 10 bit and then set expsoure time and/or analogue gain to result in only the bottom 8 bits being used (likely to give worse image quality as all the analogue stages are then closer to the noise floor).

[6by9]

Keeping me busy - firmware bug found where only BGGR was handled for 8 bit data. Patch sorted and should be in the next rpi-update.
That's likely to be why you ended up with such a huge buffer size (although I would have expected the port_format_commit call to fail - strange)

[HermannSW]

640x480 @ 60 fps would be mode 6, which explains your significant differences.

You are right.


Today I broke the 90fps barrier for Raspberry (v1.3) camera, and not for 320x240 but for 640x480!! For proving this I temporarily commented out the lines in raspiraw.c that write the frame data to SD card. This results in empty files being written. And for not getting into trouble with SD card latencies I did store files under "/dev/shm" ramdisk. Below you can see proof for every mode that the claimed new framerate really gets reached by counting the generated (empty) files (all frames get written because of saverate being 1 "-sr 1").


According documentation mode 7 can do 90fps, but it can do 97fps!
"7 640x480 4:3 60.1-90fps Full 2x2 plus skip"

Code: Select all

pi@raspberrypi2B:~/userland-rawcam $ rm /dev/shm/out.*.raw
pi@raspberrypi2B:~/userland-rawcam $ time ( raspiraw -md 7 -t 100000 -sr 1 -o /dev/shm/out.%03d.raw )
...
...
real	1m40.111s
user	0m1.110s
sys	0m4.260s
pi@raspberrypi2B:~/userland-rawcam $ ll /dev/shm/out.*.raw | wc --lines
9700
pi@raspberrypi2B:~/userland-rawcam $

According documentation mode 5 can do 49fps, but it can 58fps!
"5 1296x730 16:9 1-49fps Full 2x2"

Code: Select all

pi@raspberrypi2B:~/userland-rawcam $ rm /dev/shm/out.*.raw
pi@raspberrypi2B:~/userland-rawcam $ time ( raspiraw -md 5 -t 3000 -sr 1 -o /dev/shm/out.%03d.raw )
...
...
real	0m3.110s
user	0m0.050s
sys	0m0.080s
pi@raspberrypi2B:~/userland-rawcam $ ll /dev/shm/out.*.raw | wc --lines
175
pi@raspberrypi2B:~/userland-rawcam $ 

According documentation mode 4 can do 42fps, but it can 55fps!
"4 1296x972 4:3 1-42fps Full 2x2"

Code: Select all

pi@raspberrypi2B:~/userland-rawcam $ rm /dev/shm/out.*.raw
pi@raspberrypi2B:~/userland-rawcam $ time ( raspiraw -md 4 -t 3000 -sr 1 -o /dev/shm/out.%03d.raw )
...
...
real	0m3.111s
user	0m0.050s
sys	0m0.060s
pi@raspberrypi2B:~/userland-rawcam $ ll /dev/shm/out.*.raw | wc --lines
166
pi@raspberrypi2B:~/userland-rawcam $ 

The values taken are the limits, either lower values don't capture anymore at all, or they capture with less framerate. These are the diffs:

Code: Select all

pi@raspberrypi2B:~/userland-rawcam $ diff host_applications/linux/apps/raspicam/ov5647_modes.h.orig host_applications/linux/apps/raspicam/ov5647_modes.h
535,536c535,536
<       addreg(0x380E, 0x05),
<       addreg(0x380F, 0x9B),
---
>       addreg(0x380E, 0x02),
>       addreg(0x380F, 0xEE),
631,632c631,632
<       addreg(0x380E, 0x05),
<       addreg(0x380F, 0x9B),
---
>       addreg(0x380E, 0x02),
>       addreg(0x380F, 0xDB),
725,726c725,726
<       addreg(0x380E, 0x02),
<       addreg(0x380F, 0xEC),
---
>       addreg(0x380E, 0x01),
>       addreg(0x380F, 0xE9),
821,822c821,822
<       addreg(0x380E, 0x03),
<       addreg(0x380F, 0x12),
---
>       addreg(0x380E, 0x01),
>       addreg(0x380F, 0xE7),
pi@raspberrypi2B:~/userland-rawcam $ 

I tested modes 1-3 again, but their value are the limits already, no higher framerates can be achieved there. For mode 6 the maximal framerate raised from 60fps to 63fps.

It would be nice if these values (definitely the 97fps value for 640x480) can go to official raspiraw on github, best with a "-highfps" or similar switch.

[6by9]

I'd suggest you have a look at some of your images, either by saving some of them, or running them through the ISP (omitting the -o option).

I've done the quick mod to the firmware driver to open up the fps range for mode 5 (1296x730), and going above 49 fps results in torn/flickery images. 49fps is steady. The timestamps are all as expected which is what you've been looking at.

[HermannSW]

I've done the quick mod to the firmware driver to open up the fps range for mode 5 (1296x730), and going above 49 fps results in torn/flickery images. 49fps is steady. The timestamps are all as expected which is what you've been looking at.

Can you please look at 90fps vs 97fps frames for 640x480 on your side?
I will do that here as well.

I'd suggest you have a look at some of your images, either by saving some of them, ,,,

I found a cool solution to store >10s of raw frames with saverate of 1 on Raspbian!
Highest framerate possible to date is 97fps(90fps), so 10s fit into less than 1000 frames.
384000 bytes is 375KB, and 1000 frames fit into /dev/shm easily:

Code: Select all

pi@raspberrypi2B:~/userland-rawcam $ df /dev/shm
Filesystem     1K-blocks   Used Available Use% Mounted on
tmpfs             448396 376000     72396  84% /dev/shm
pi@raspberrypi2B:~/userland-rawcam $ 

So all you have to do is start raspiraw with "-sr 1", I tested it, and it works reliably (because writing to ramdisk is fast):

Code: Select all

$ time ( raspiraw -md 7 -t 10000 -sr 1 -o /dev/shm/out.%03d.raw )

And there is another goody with storing in /dev/shm, file timestamps have microsecond resolution. This outputs Modification time of the first files:

Code: Select all

pi@raspberrypi2B:~/userland-rawcam $ stat --printf="%y %n\n" /dev/shm/out.00[0-5].raw
2017-11-29 17:24:04.284012541 +0000 /dev/shm/out.000.raw
2017-11-29 17:24:04.294013570 +0000 /dev/shm/out.001.raw
2017-11-29 17:24:04.304014600 +0000 /dev/shm/out.002.raw
2017-11-29 17:24:04.314015629 +0000 /dev/shm/out.003.raw
2017-11-29 17:24:04.324016658 +0000 /dev/shm/out.004.raw
2017-11-29 17:24:04.334017688 +0000 /dev/shm/out.005.raw
pi@raspberrypi2B:~/userland-rawcam $ 

Here you see 10s recording resulting in 969 stored frames (would be 900 with 90fps):

Code: Select all

$ rm /dev/shm/out.*.raw
$ time ( raspiraw -md 7 -t 10000 -sr 1 -o /dev/shm/out.%03d.raw )
...
real	0m10.094s
user	0m0.280s
sys	0m2.490s
$ 
$ ll /dev/shm/out.*.raw | wc --lines
969
$

P.S:
With this simple change

Code: Select all

$ diff host_applications/linux/apps/raspicam/raspiraw.c.orig host_applications/linux/apps/raspicam/raspiraw.c
344c344
< 	if (0 > asprintf(finalName, pattern, frame))
---
> 	if (0 > asprintf(finalName, pattern, frame%1000))
$ 

filenames are kept 3 digit, and old files will get overwritten when more than 1000 frames get recorded. You can record for a long time (eg. -t 100000) and press CTRL-C when something interesting happened. If you do so within 10s, then the interesting frames will be in /dev/shm.

And there is an easy way to find out the frame number of the first frame:

Code: Select all

$ time ( raspiraw -md 7 -t 15000 -sr 1 -o /dev/shm/out.%03d.raw )
...
mmal: mmal_port_free: vc.ril.video_render:ctr:0 at 0x12b6140

real	0m15.091s
user	0m0.430s
sys	0m4.090s
$ 
$ stat --printf="%y %n\n" /dev/shm/out.*.raw | sort | head -2
2017-11-29 17:59:42.672595098 +0000 /dev/shm/out.455.raw
2017-11-29 17:59:42.682594916 +0000 /dev/shm/out.456.raw
$ 

[6by9]

A very quick check before leaving the office says that 95fps is stable, but anything above that the bayer order goes wrong. I didn't verify the timestamps.

[HermannSW]

A very quick check before leaving the office says that 95fps is stable, but anything above that the bayer order goes wrong. I didn't verify the timestamps.

Thanks, I did verify on my side that even 96fps and 97 fps are stable (I dcraw converted 40 consecutive frames and watched fbi slideshow on HDMI monitor then by "sudo fbi -d /dev/fb0 -T 1 -t 1 -a /dev/shm/out.*.ppm").

But 96fps and 97fps frames look ugly as you said (I cannot see a difference between 90fps and 95fps frame). Here are the frames for comparison, right click for full resolution display:


The 0x380E/0x380F values are 0x02/0xC0(90fps), 0x01/0xF0(95fps), 0x01/0xEB(96fps) and 0x01/0xE7(97fps). Summary: use up to 95fps 640x480 raspiraw frames, not higher.