6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7021
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 Oct 06, 2017 3:01 pm

fooforever wrote:
Fri Oct 06, 2017 2:39 pm
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.
fooforever wrote:But when I get images out the other end they look something like this:
Image
I seem to be getting either a repeated top bit of the frame at the bottom or the top of the next frame. Any idea what's going wrong? Obviously this doesn't happen with the saved images, but as far as I'm aware im kinda handling everything in the same way.
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?
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.

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

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Oct 06, 2017 3:23 pm

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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7021
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 Oct 06, 2017 3:32 pm

fooforever wrote:
Fri Oct 06, 2017 3:23 pm
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.
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.

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

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Oct 10, 2017 9:40 am

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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7021
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 Oct 10, 2017 10:10 am

fooforever wrote:
Tue Oct 10, 2017 9:40 am
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.
fooforever wrote: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.
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.

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

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Oct 10, 2017 2:26 pm

6by9 wrote:
Tue Oct 10, 2017 10:10 am
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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7021
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raw sensor access / CSI-2 receiver peripheral

Wed Oct 18, 2017 11:16 am

fooforever wrote:
Tue Oct 10, 2017 2:26 pm
6by9 wrote:
Tue Oct 10, 2017 10:10 am
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.
fooforever wrote: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.
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.

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

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Oct 20, 2017 1:34 pm

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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7021
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 Oct 20, 2017 2:22 pm

fooforever wrote:
Fri Oct 20, 2017 1:34 pm
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.
fooforever wrote: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.
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.

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

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Oct 20, 2017 2:31 pm

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 :/

User avatar
HermannSW
Posts: 1317
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Nov 17, 2017 1:47 am

> 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

[email protected]:~/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
[email protected]:~/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
[email protected]:~/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
[email protected]:~/userland-rawcam $ 
But last written frame with default saferate of 20 is 281 indicating 300 frames captured, which is 60fps for 5s.
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7021
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 Nov 17, 2017 11:03 am

HermannSW wrote:
Fri Nov 17, 2017 1:47 am
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".
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.

User avatar
HermannSW
Posts: 1317
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: Raw sensor access / CSI-2 receiver peripheral

Sat Nov 18, 2017 5:21 pm

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

[email protected]:~ $ raspivid -md 7 -ss 1000 -ex off -fps 60 -o foo.h264
Too many macroblocks/s: Increasing H264 Level to 4.2
[email protected]:~ $ 
[email protected]:~ $ raspivid -md 7 -ss 1000 -ex off -fps 90 -o foo.h264
mmal: Too many macroblocks/s requested
Segmentation fault
[email protected]:~ $ 
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

[email protected]:~ $ raspivid -w 640 -h 480 -ss 1000 -ex off -fps 60 -o foo.h264 
[email protected]:~ $ raspivid -w 640 -h 480 -ss 1000 -ex off -fps 90 -o foo.h264 
[email protected]:~ $ 
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.
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

User avatar
HermannSW
Posts: 1317
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: Raw sensor access / CSI-2 receiver peripheral

Sat Nov 18, 2017 8:03 pm

> 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

[email protected]:~/userland-rawcam $ gpio readall | grep S[DC][AL].0
 |   0 |  30 |   SDA.0 | ALT0 | 1 | 27 || 28 | 1 | ALT0 | SCL.0   | 31  | 1   |
[email protected]:~/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
[email protected]:~/userland-rawcam $ gpio readall | grep S[DC][AL].0
 |   0 |  30 |   SDA.0 |   IN | 1 | 27 || 28 | 1 | IN   | SCL.0   | 31  | 1   |
[email protected]:~/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

[email protected]:~/userland-rawcam $ gpio readall | grep "GPIO. [01]"
 |  17 |   0 | GPIO. 0 |   IN | 0 | 11 || 12 | 0 | IN   | GPIO. 1 | 1   | 18  |
[email protected]:~/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

[email protected]:~/userland-rawcam $ grep Rev /proc/cpuinfo 
Revision	: 9000c1
[email protected]:~/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
;;
[email protected]:~/userland-rawcam $ 
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7021
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 Nov 18, 2017 10:02 pm

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.
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.

User avatar
HermannSW
Posts: 1317
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: Raw sensor access / CSI-2 receiver peripheral

Sun Nov 19, 2017 1:59 am

> 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:
Image

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):
Image

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?
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7021
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 Nov 19, 2017 10:11 am

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.
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.

User avatar
HermannSW
Posts: 1317
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: Raw sensor access / CSI-2 receiver peripheral

Sun Nov 19, 2017 2:11 pm

> 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.

Image
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7021
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 Nov 19, 2017 4:44 pm

HermannSW wrote:
Sun Nov 19, 2017 2:11 pm
> 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.
HermannSW wrote:> 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.
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.

User avatar
HermannSW
Posts: 1317
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: Raw sensor access / CSI-2 receiver peripheral

Sun Nov 19, 2017 11:29 pm

> 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?
Image

Thanks for the pointer to the schematics, I will try with camera connector pins 13+14.
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

User avatar
Gavinmc42
Posts: 3455
Joined: Wed Aug 28, 2013 3:31 am

Re: Raw sensor access / CSI-2 receiver peripheral

Mon Nov 20, 2017 6:32 am

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.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7021
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 Nov 20, 2017 7:26 am

HermannSW wrote:
Sun Nov 19, 2017 11:29 pm

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?
Image

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.
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.

User avatar
HermannSW
Posts: 1317
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: Raw sensor access / CSI-2 receiver peripheral

Mon Nov 20, 2017 11:15 am

> 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.]

Image
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

User avatar
HermannSW
Posts: 1317
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: Raw sensor access / CSI-2 receiver peripheral

Mon Nov 20, 2017 3:20 pm

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
Image
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

User avatar
HermannSW
Posts: 1317
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany
Contact: Website Twitter YouTube

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Nov 21, 2017 10:15 pm

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:
Image

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

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
$ 
Last edited by HermannSW on Sat Mar 03, 2018 12:31 am, edited 1 time in total.
⇨https://stamm-wilbrandt.de/en/Raspberry_camera.html

https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://gitlab.freedesktop.org/HermannSW/gst-template
https://github.com/Hermann-SW/fork-raspiraw
https://twitter.com/HermannSW

Return to “Camera board”