Raw sensor access / CSI-2 receiver peripheral

[6by9]

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.

Fine for triggering the captures, but can I suggest you read up on semaphores as the correct way to signal back and forth.

The other thing you could do is have a MMAL_QUEUE_T between the threads.
In callback(), if the flag is set then mmal_queue_put(queue, buffer) and do NOT return it to the rawcam component with mmal_port_send_buffer. In your other thread, wait with mmal_queue_wait(queue). Once the buffer is delivered your thread will be unblocked and you'll get the buffer. Do whatever processing/network sending/whatever on it, and then return it yourself to the component with mmal_port_send_buffer. It saves memcpying data around the place as you're doing.
Do check that output->buffer_num is large >=6 so that you still have double buffering available on the component itself and won't stall it.

But when I get images out the other end they look something like this:

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.

A slight nasty in that you don't check that the buffer->length of the buffer that triggers the malloc is the same as the length of subsequent buffers.

Without knowing how your processing is detecting the start of frames it's difficult to say.
From previous posts you're using the OV5467 V1 camera module. Your webp (why?!) file appears to be 1293x974, so a slight munge on 1296x972? Are you sure you're running mode 4 and not mode 5? The buffers are likely to be adjacent in memory, so copying too far would result in reading off the end of one into the start of the next. What length are the buffers being reported as?

[fooforever]

I'll look into the semaphores and mmal ques thanks 6by9.
The file must have been converted by google drive, is comes out a a 2592x1952 image, or at least I get frame buffers of 10119168 at 16 bits.
I am using a V1 camera set in mode 3.

[6by9]

I'll look into the semaphores and mmal ques thanks 6by9.
The file must have been converted by google drive, is comes out a a 2592x1952 image, or at least I get frame buffers of 10119168 at 16 bits.
I am using a V1 camera set in mode 3.

Check it with mode 2 instead. I'm not aware of anything strange in there over timings, and your image doesn't appear to have corruption in it, but it is possible to end up dropping lines. That wouldn't result in a duplicate of the top part of the frame though, and typically throws off the Bayer order for amusing results.

[fooforever]

Switching to mode 2 sorted it Managed to get a mmal queue working to send the data over the network too rather than doing it from the callback, with a bit of fudging for the 74 bytes of null data at the start of each buffer, not sure what that is about.

If I want to change settings like exposure and gain whilst the program is running should I just be able to call the update_regs function with the new parameters or do I need to do something more?

[6by9]

Switching to mode 2 sorted it Managed to get a mmal queue working to send the data over the network too rather than doing it from the callback, with a bit of fudging for the 74 bytes of null data at the start of each buffer, not sure what that is about.

A 74 byte offset at the start of the buffer to the start of the image? That does sound most odd, but I'm afraid I haven't got the time to investigate it at the moment.

If I want to change settings like exposure and gain whilst the program is running should I just be able to call the update_regs function with the new parameters or do I need to do something more?

update_regs only amends the mode array. Resending the entire array will stop and restart the sensor streaming and is totally unnecessary.

The better approach is probably to refactor the code to either send the configurable parameters directly (flips can typically only be done when not streaming), or separate out those relevant settings into a common-per-sensor block that can easily be resent.

[fooforever]

A 74 byte offset at the start of the buffer to the start of the image? That does sound most odd, but I'm afraid I haven't got the time to investigate it at the moment.

Yeah thats right, then 8 full lines at the end.

Thanks for your help so far. Can I ask why you suggested I switch modes to fix the 'banding' of different images a few posts ago? I've run into a problem when trying to change the gain and exposure at runtime. Using the code below I can change both values fine when I run in mode 3, but then the 'banding' is still there. But in mode 2 which fixes the 'banding' problem I only seem to be able to adjust the gain, not the exposure time. I get the messages printed out to say that registers have been set, but I don't see any change in the output image.

Code: Select all

if (n > 0) {
	cfg.exposure_us = atoi(buffer);
	cfg.exposure = (int)(cfg.exposure_us * 1000 / sensor_mode->line_time_ns);
	printf("Setting exposure to %d\n", cfg.exposure_us);
}
stop_camera_streaming(sensor);
update_regs(sensor, sensor_mode, cfg.hflip, cfg.vflip, cfg.exposure, cfg.gain);
start_camera_streaming(sensor, sensor_mode);

[6by9]

A 74 byte offset at the start of the buffer to the start of the image? That does sound most odd, but I'm afraid I haven't got the time to investigate it at the moment.

Yeah thats right, then 8 full lines at the end.

What resolution are you treating the image as? The buffer will always have the stride as a multiple of 16 pixels, and the height as a multiple of 16 for GPU optimisations. That is what is defined in the format->es->video.[width|height] of the MMAL format. The ACTIVE part of the buffer is what is described in format->es->video.crop.[width|height]. Having said that, 2592 is a multiple of 32.

Thanks for your help so far. Can I ask why you suggested I switch modes to fix the 'banding' of different images a few posts ago? I've run into a problem when trying to change the gain and exposure at runtime. Using the code below I can change both values fine when I run in mode 3, but then the 'banding' is still there. But in mode 2 which fixes the 'banding' problem I only seem to be able to adjust the gain, not the exposure time. I get the messages printed out to say that registers have been set, but I don't see any change in the output image.

Code: Select all

if (n > 0) {
	cfg.exposure_us = atoi(buffer);
	cfg.exposure = (int)(cfg.exposure_us * 1000 / sensor_mode->line_time_ns);
	printf("Setting exposure to %d\n", cfg.exposure_us);
}
stop_camera_streaming(sensor);
update_regs(sensor, sensor_mode, cfg.hflip, cfg.vflip, cfg.exposure, cfg.gain);
start_camera_streaming(sensor, sensor_mode);

I suggested it to try and confirm if it were a register issue or hardware. Modes 2 & 3 are the same resolution but have different PLL and frame/line length setups so that mode 3 gives significantly longer frame and exposure times. The CSI2 receiver has to lock on to the incoming clock signal, so if there was something timing/hardware related running almost the same thing but with different timings is useful.

Actually I think your calculation is incorrect. Note https://github.com/6by9/userland/blob/r ... raw.c#L679

Code: Select all

cfg.exposure = ((int64_t)cfg.exposure_us * 1000) / sensor_mode->line_time_ns;

Note the casting and extra brackets. This is all integer maths so 1000/(value > 1000) = 0. You don't say what value your printf is reporting for cfg.exposure_us.

[fooforever]

I'm treating the image as 2592x1944 and 16 bit, but I get sent a 10119168 byte buffer which means the buffer is 41472 bytes larger than the image.

Looks like I was using an old version of your repo for some reason, updated that and changed that line. But I still get the same behaviour. With a small code change to this:

Code: Select all

if (n > 0) {
	cfg.exposure_us = atoi(buffer);
	cfg.exposure = ((int64_t)cfg.exposure_us * 1000) / sensor_mode->line_time_ns;
	printf("Setting exposure us to %d and exposure to %d\n", cfg.exposure_us, cfg.exposure);
}
stop_camera_streaming(sensor);
update_regs(sensor, sensor_mode, cfg.hflip, cfg.vflip, cfg.exposure, cfg.gain);
start_camera_streaming(sensor, sensor_mode);

I can see the values are being set correctly from the printf readout. For example in mode 3 sending 1000us I get:

Code: Select all

Setting exposure us to 10000 and exposure to 54
mmal: Set exposure 3500 to 00
mmal: Set exposure 3501 to 00
mmal: Set exposure 3502 to 36
mmal: Set gain 350A to 02
mmal: Set gain 350B to 00

Which adds up when looking at line times. And Below when in mode 2:

Code: Select all

Setting exposure us to 1000 and exposure to 5
mmal: Set exposure 3500 to 00
mmal: Set exposure 3501 to 00
mmal: Set exposure 3502 to 05
mmal: Set gain 350A to 02
mmal: Set gain 350B to 00

Which also makes sense, but I only see a change in the images in mode 3 where I also see the 'banding' or multiple images in one buffer or whatever.

[6by9]

I'm treating the image as 2592x1944 and 16 bit, but I get sent a 10119168 byte buffer which means the buffer is 41472 bytes larger than the image.

Look at https://github.com/6by9/userland/blob/r ... raw.c#L828
1944 is not a multiple of 16, hence output->format->es->video.height will be set to 1952.
2592 * 1952 * 2 = 10119168 as expected. That value is also going to be returned in rawcam->output[0]->buffer_size after the port_format_commit.

Looks like I was using an old version of your repo for some reason, updated that and changed that line. But I still get the same behaviour. With a small code change to this:

Code: Select all

if (n > 0) {
	cfg.exposure_us = atoi(buffer);
	cfg.exposure = ((int64_t)cfg.exposure_us * 1000) / sensor_mode->line_time_ns;
	printf("Setting exposure us to %d and exposure to %d\n", cfg.exposure_us, cfg.exposure);
}
stop_camera_streaming(sensor);
update_regs(sensor, sensor_mode, cfg.hflip, cfg.vflip, cfg.exposure, cfg.gain);
start_camera_streaming(sensor, sensor_mode);

I can see the values are being set correctly from the printf readout. For example in mode 3 sending 1000us I get:

Code: Select all

Setting exposure us to 10000 and exposure to 54
mmal: Set exposure 3500 to 00
mmal: Set exposure 3501 to 00
mmal: Set exposure 3502 to 36
mmal: Set gain 350A to 02
mmal: Set gain 350B to 00

Which adds up when looking at line times. And Below when in mode 2:

Code: Select all

Setting exposure us to 1000 and exposure to 5
mmal: Set exposure 3500 to 00
mmal: Set exposure 3501 to 00
mmal: Set exposure 3502 to 05
mmal: Set gain 350A to 02
mmal: Set gain 350B to 00

Which also makes sense, but I only see a change in the images in mode 3 where I also see the 'banding' or multiple images in one buffer or whatever.

Sorry, but for that I really have to refer you to https://github.com/6by9/userland/blob/r ... odes.h#L30 Due to NDAs I can't assist on register setup.
There's nothing stopping you putting an I2C analyser on the bus to see what the firmware is doing under these situations.

Hang on, those line timings at https://github.com/6by9/userland/blob/r ... des.h#L833 look wrong.
mode 1 (1080P) has a line time of 29584ns
mode 2 (5MP 1-15fps) is 32503ns
mode 3 (5MP 1/6-1 fps) is 183789ns
modes 4&5 (2x2 binned) are 23216ns
mode 6 (VGA 30-60fps) is 31749ns
mode 7 (VGA 60-90fps) is 21165ns.
They're all offset by 1 except modes 6&7, probably as the original register set for 5MPix is inserted as an extra table in the first row.

[fooforever]

I remember making that change but I think it matched the data I had at the time. I'll try changing the values to what you've just said and see if thats the problem.

EDIT:
No change in the behaviour. I know you can't tell us thing under NDA, I'm just trying to work out where the problem is ? Is it my code or something not working in the rawcam stuff :/

[HermannSW]

> mode 7 (VGA 60-90fps) is 21165ns
>
If I run raspiraw with mode 7, then the framerate is always 60fps (which is fine).

If I want to increase framerate (in direction 90fps), what is needed to be changed?
I read that exposure has to be reduced for higher framerates.
Does it make a difference on whether setting exposure via -e or -eus?
What about -g gain setting?

I did set exposure by "-eus 100" to 100us, which translates to exposure 4 being set:

Code: Select all

pi@raspberrypifb:~/userland-rawcam $ time ( raspiraw -md 7 -t 5000 -eus 100 -o out.%03d.raw 2>err )

real	0m5.139s
user	0m0.060s
sys	0m0.390s
pi@raspberrypifb:~/userland-rawcam $ ls -lst out\.*raw | head -3 
376 -rw-r--r-- 1 pi pi 384000 Nov 17 01:34 out.281.raw
376 -rw-r--r-- 1 pi pi 384000 Nov 17 01:34 out.261.raw
376 -rw-r--r-- 1 pi pi 384000 Nov 17 01:34 out.241.raw
pi@raspberrypifb:~/userland-rawcam $ grep exposure err
RaspiRaw: Setting exposure to 4 from time 100us
RaspiRaw: Set exposure 3500 to 00
RaspiRaw: Set exposure 3501 to 00
RaspiRaw: Set exposure 3502 to 04
pi@raspberrypifb:~/userland-rawcam $ 

But last written frame with default saferate of 20 is 281 indicating 300 frames captured, which is 60fps for 5s.

[6by9]

If I want to increase framerate (in direction 90fps), what is needed to be changed?

Same response as to fooforever above

Sorry, but for that I really have to refer you to https://github.com/6by9/userland/blob/r ... odes.h#L30 Due to NDAs I can't assist on register setup.
There's nothing stopping you putting an I2C analyser on the bus to see what the firmware is doing under these situations.

Either a Bus Pirate, Saleae analyser, or possibly even piscope (having loaded pigpiod with "-x -1" or otherwise enabling GPIOs 28&29), should give you the information you require 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".

[HermannSW]

Thx, I need to find a Raspbian without userland-rawcam built (that builds raspivid as well).
I tried on two with userland-rawcam already, and both segfault with fps 90:

Code: Select all

pi@raspberrypi03:~ $ raspivid -md 7 -ss 1000 -ex off -fps 60 -o foo.h264
Too many macroblocks/s: Increasing H264 Level to 4.2
pi@raspberrypi03:~ $ 
pi@raspberrypi03:~ $ raspivid -md 7 -ss 1000 -ex off -fps 90 -o foo.h264
mmal: Too many macroblocks/s requested
Segmentation fault
pi@raspberrypi03:~ $ 

P.S:
Tried on two SD cards without userland-rawcam, same crah for fps 90.
One SD card was fresh, I had to enable the camera via raspi-config first.
Latest Raspian Stretch.

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

Code: Select all

pi@raspberrypi05:~ $ raspivid -w 640 -h 480 -ss 1000 -ex off -fps 60 -o foo.h264 
pi@raspberrypi05:~ $ raspivid -w 640 -h 480 -ss 1000 -ex off -fps 90 -o foo.h264 
pi@raspberrypi05:~ $ 

The recordings are done with 60fps/90fps since the videos play 10s/15s in totem video player stating 30fps. So the difference must be in the i2c protocol.

Will connect my Salea Logic16 (100Msps) logic analyzer now, did never analyze i2c traffic before.

[HermannSW]

> Either a Bus Pirate, Saleae analyser, or possibly even piscope (having loaded pigpiod with "-x -1" or otherwise enabling GPIOs 28&29),
>
These are settigs for SDA.0 and SCL.0 after reboot, and after running camera_i2c:

Code: Select all

pi@raspberrypi02:~/userland-rawcam $ gpio readall | grep S[DC][AL].0
 |   0 |  30 |   SDA.0 | ALT0 | 1 | 27 || 28 | 1 | ALT0 | SCL.0   | 31  | 1   |
pi@raspberrypi02:~/userland-rawcam $ ./camera_i2c 
setting GPIO for board revsion: 9000c1
PiZero / PiZero W - I2C 0 on GPIO 28 & 29. GPIOs 40 & 44 for LED and power
pi@raspberrypi02:~/userland-rawcam $ gpio readall | grep S[DC][AL].0
 |   0 |  30 |   SDA.0 |   IN | 1 | 27 || 28 | 1 | IN   | SCL.0   | 31  | 1   |
pi@raspberrypi02:~/userland-rawcam $ 

I connected logic analyzer to pins 27+28 of Pi Zero, but can see nothing (contant 0 for both).
Then I connected to pins 11+12 because that is where GPIO0/GPIO1 are:

Code: Select all

pi@raspberrypi02:~/userland-rawcam $ gpio readall | grep "GPIO. [01]"
 |  17 |   0 | GPIO. 0 |   IN | 0 | 11 || 12 | 0 | IN   | GPIO. 1 | 1   | 18  |
pi@raspberrypi02:~/userland-rawcam $ 

Also nothing shows up on logic analyzer. I tested on other pins and manually flipped from 0 o 1 to 0, and see that on logic analyzer. So logic analyzer is OK.

Where/how can I measue the i2c traffic of Raspberry camera?

Code: Select all

pi@raspberrypi02:~/userland-rawcam $ grep Rev /proc/cpuinfo 
Revision	: 9000c1
pi@raspberrypi02:~/userland-rawcam $ sed -n "/9000c1/,/;;/p" camera_i2c 
'900093'|'920093'|'9000c1')
echo "PiZero / PiZero W - I2C 0 on GPIO 28 & 29. GPIOs 40 & 44 for LED and power"
# i2c can be on pins 0 and 1, so make sure they are not set to alt0
gpio -g mode 0 in
gpio -g mode 1 in
# i2c on these pins
gpio -g mode 28 in
gpio -g mode 28 alt0
gpio -g mode 29 in
gpio -g mode 29 alt0
# shutdown
gpio -g write 44 1
# LED
gpio -g write 40 1
;;
pi@raspberrypi02:~/userland-rawcam $ 

[6by9]

GPIOs 28&29 off the SoC(*), not 0&1 (presented as pins 27&28 on the 40 pin header)

I've just pushed a new branch rawcam_rebase which takes all the changes from the main userland repo with raspiraw changes on top. I don't see anything that would cause a seg fault or is significantly different from the main repo. If you want to not install raspivid then edit buildme to remove the "sudo make install" lines, or host_applications/linux/apps/raspicam/CMakeLists.txt to remove raspivid from the "install" line.

(*) 44&45 on a Pi3.

[HermannSW]

> GPIOs 28&29 off the SoC(*), not 0&1 (presented as pins 27&28 on the 40 pin header)
> ...
> (*) 44&45 on a Pi3.
>
Does that mean I cannot measure camera i2c traffic on Pi Zero(W)?
Or can pins 44 and 45 be mapped into 1-40 on Zero for measuring?

I have 6 working Zeros, only non Zero is Pi 2B from my son.
That has 40 pins only as the Zero (W).

I just looked for Pi3 pinout, and that does have pins 1-40 only as well.

I do have shielded cable fly line connectors from 400 M logic analyzer.
But for measuring i2c traffic the connectors on both sides seem to be a bit too tiny for me.

So I did measurement again, with pins 27+28 and 34(GND) connected:


But logic analyzer shows nothing (I did execute "raspivid -w 640 -h 480 -ss 1000 -ex off -fps 60 -t 3000 -o foo.h264" during that 6 seconds):


According to
http://ozzmaker.com/testing-points-raspberry-pi/

Code: Select all

...
PP39 SCL0
PP40 SDA0

Would measuring at PP39/PP40 make a difference over testing on pins 27/28?

[6by9]

I will state again - GPIOs 28&29 FROM THE SoC (ie NOT on the 40 pin header which only has GPIOs 0-27 on it).
GPIOs 28&29 are routed to the camera and display connectors ONLY. If you change the pinmuxing to route the signals elsewhere (eg GPIOs 0&1 on pins 27&28 of the 40 pin header) then the I2C will not work and the GPU will not see the camera.

You have a logic analyser so forget piscope. You need to connect it to the camera connector or the camera board (pinout is available from the schematics in the documentation section). Soldering small fly leads off the relevant pins is the normal approach.
If you trust that test point list then PP39 and PP40 look plausible seeing as 38&38 are the camera GPIOs, but I don't have information to confirm.

[HermannSW]

> I will state again - GPIOs 28&29 FROM THE SoC (ie NOT on the 40 pin header which only has GPIOs 0-27 on it).
>
Thanks, now that is clear.

> GPIOs 28&29 are routed to the camera and display connectors ONLY.
> If you change the pinmuxing to route the signals elsewhere (eg GPIOs 0&1 on pins 27&28 of the 40 pin header)
> then the I2C will not work and the GPU will not see the camera.
>
OK.

> If you trust that test point list then PP39 and PP40 look plausible seeing as 38&38 are the camera GPIOs,
> but I don't have information to confirm.
>
I trusted it, as both showed up in several Pi Zero test point lists on the internet.
And I soldered connectors to them (see photo below).
Camera works fine after soldering, but I got the same "see nothing" with logic analyzer.
So I assume that PP39/PP40 is SCL0/SDA0, but it is connected to pin28/pin27.

> You have a logic analyser so forget piscope. You need to connect it to the camera connector or the camera board
> (pinout is available from the schematics in the documentation section).
>
On the camera page there is only mechanical drawing for v2 camera, no pinout information:
https://www.raspberrypi.org/documentati ... /README.md

From https://www.petervis.com/Raspberry_PI/R ... inout.html:

Code: Select all

...
13	SCL0	I²C Bus
14	SDA0
...

Can you please point to official documentation schematics?

> Soldering small fly leads off the relevant pins is the normal approach.
>
I will have to try that next.

[6by9]

> If you trust that test point list then PP39 and PP40 look plausible seeing as 38&38 are the camera GPIOs,
> but I don't have information to confirm.
>
I trusted it, as both showed up in several Pi Zero test point lists on the internet.
And I soldered connectors to them (see photo below).
Camera works fine after soldering, but I got the same "see nothing" with logic analyzer.
So I assume that PP39/PP40 is SCL0/SDA0, but it is connected to pin28/pin27.

Your link stated:

Below is a list of test points which can be found on Raspberry Pi 2, 3 and some are also on b+.

If you look at any of those then you'll see that PP37-40 are all clustered on the underside roughly where the camera connector is.
If your picture of a Zero is accurate then they are no where near the camera connector, which should have rung alarm bells that those test point references do not apply to a Zero.

> You have a logic analyser so forget piscope. You need to connect it to the camera connector or the camera board
> (pinout is available from the schematics in the documentation section).
>
On the camera page there is only mechanical drawing for v2 camera, no pinout information:
https://www.raspberrypi.org/documentati ... /README.md

From https://www.petervis.com/Raspberry_PI/R ... inout.html:

Code: Select all

...
13	SCL0	I²C Bus
14	SDA0
...

Can you please point to official documentation schematics?

It's a flat one to one ribbon cable, so look at the schematics of the Pi 1/2/3 which use the same connector.
https://www.raspberrypi.org/documentati ... matics.pdf. Yes, pins 13&14 are SCL and SDA respectively.

[HermannSW]

> If you look at any of those then you'll see that PP37-40 are all clustered on the underside
> roughly where the camera connector is. If your picture of a Zero is accurate then they are
> no where near the camera connector, which should have rung alarm bells that those test
> point references do not apply to a Zero.
>
Hi, it was difficult to create this photo, with 5MP Android camera through lense of +2.5 dpt. glasses I use for soldering.
I soldered where the labels stated PP40 and PP39, do you say the official test point labeling is wrong?


Thanks for the pointer to the schematics, I will try with camera connector pins 13+14.

[Gavinmc42]

Raspbian is now not the only way to use the cameras.
But I have gone about as far as I can and need new eyes to see what mistakes I have made.

https://ultibo.org/forum/viewtopic.php? ... 5950#p5950

Why Ultibo? Because it can boot and take a image in < 3secs.
For in field, battery/solar powered apps the time it needs to be on and the time it is powered off is the duty cycle.
Low duty cycle = long battery life and/or smaller solar panel.

Trying to make the equivalent of raspiraw in Pascal, but I have reached the end of my skill level.
If anyone can get this going it should be easy to dump the V2 registers I think.

With deeluk getting other CSI sensors going, it is getting very close having Pi's usable for many CV apps on more than just two image sensors.
5 and 8MP rolling shutter sensors are not optimal for highspeed CV.
For night use there are better sensors, but even the current Pi cams could be tweaked more.

[6by9]

Hi, it was difficult to create this photo, with 5MP Android camera through lense of +2.5 dpt. glasses I use for soldering.
I soldered where the labels stated PP40 and PP39, do you say the official test point labeling is wrong?


Thanks for the pointer to the schematics, I will try with camera connector pins 13+14.

I am saying that that list of test points was made for the Pi2 and 3.
Do you think all connectors on a Ford focus are the same as on a Ford Sierra? They're both Ford's after all.

[HermannSW]

> I am saying that that list of test points was made for the Pi2 and 3.
> Do you think all connectors on a Ford focus are the same as on a Ford Sierra? They're both Ford's after all.
>
I got that, thanks.

The Schematics are good, and describe the camera port for all models. But they are bad for showing test points.

For the Pi 3B only 17 testpoints are shown, and the only one in 3x range is PP35:
https://www.raspberrypi.org/documentati ... matics.pdf

For Pi Zero only 8(!) are shown in schematic (search for PP in schematic), although I can count 20 on Pi Zero:
https://www.raspberrypi.org/documentati ... matics.pdf

But schematics made my day as I don't have to solder to a camera connector! Reason is schematic for Pi 2B:
https://www.raspberrypi.org/documentati ... matics.pdf

There only 19 testpoints (PPxy) are shown, and I can count 44 on the Pi 2B of my son. BUT the interesting ones for camera are present (see below)!

The test points are big and it should be easy to solder connector cables to PP39 and PP40 on the Pi 2B.
[Pi 2B was not used for years, and the SD card was bad. Formatted it, flashed latest Jessie lite, did "sudo touch /media/boot/ssh" for allowing headless access and it worked immediately. I connected one of my v1 cameras to it and "raspistill -t 0" showed nicely on HDMI monitor.]

[HermannSW]

Soldered PP39 and PP40, now logic analyzer works like a charm.
This is for:

Code: Select all

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

[HermannSW]

I had no problems in decoding the recordings as I2C and export.
But I had real problems with noise, I did save captures for executing the exactly same command, and got totally different I2C decodings.

I assumed that the cables (same as from photo before) were too long and tried to solder short pins, without success. Then I had the idea to just solder big balls of tin-solder onto PP39 and PP40, and that worked well:


Sharper view, picture detail, scaled down 4x, from viewtopic.php?f=43&t=45887&p=1280449#p1280449:


The connectors got clamped to the balls, and now two measurement I2C decodings for same raspivid command line are identical (after removing the timestamp column).

Now I have to understand the meaning of the decoded I2C (1002 lines for decoding "raspivid -w 640 -h 480 -ss 1000 -ex off -fps 60 -t 3000 -o foo.h264"):

Code: Select all

Time	[s]	Analyz.	Name	Decoded	Protocol	Result	
1.21379535	I2C	Setup	Write	to	[l]	+	NAK
1.21390535	I2C	Setup	Read	to	[m]	+	NAK
1.21402639	I2C	Setup	Write	to	[l]	+	NAK
1.21413639	I2C	Setup	Read	to	[m]	+	NAK
1.21425728	I2C	Setup	Write	to	[l]	+	NAK
1.21436727	I2C	Setup	Read	to	[m]	+	NAK
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			
1.21658899	I2C	Setup	Write	to	[l]	+	ACK
1.21667899	I2C	'1'	+	ACK			
1.21676899	I2C	'3'	+	ACK			
1.21685899	I2C	'1'	+	ACK			
1.21697899	I2C	Setup	Write	to	[l]	+	ACK
1.21706899	I2C	'1'	+	ACK			
1.21715899	I2C	'0'	+	ACK			
1.21724898	I2C	'0'	+	ACK			
...

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
$