Closed dustinkerstein closed 4 years ago
A related question, in trying to get this working, I added my d03114
to the list of ids in camera_i2c
in the https://github.com/Hermann-SW/raspiraw/tree/long_exposure branch, on this line:
'a02082'|'a22082'|'a020d3'|'9020e0'|'a03111'|'b03111'|'c03111'|'a03112'|'b03112'|'c03112')
echo "Raspberry Pi3B / Pi3B+ / 3A / 4B(1G/2G/4G)"
It didn't seem to change any behavior, or break raspistill
, but is it possible to revert any of those changes without knowing what they were set to before? Thanks!
Update - It appears as though the GPIO pins are reset after each reboot per https://raspberrypi.stackexchange.com/a/32641/126505, so I think my concern above is moot.
FYI, here is what I see with uname -a
:
Linux raspberrypi 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/Linux
And ls -l /dev/i2c-*
:
crw-rw---- 1 root i2c 89, 0 Nov 5 19:19 /dev/i2c-0
crw-rw---- 1 root i2c 89, 1 Nov 5 19:19 /dev/i2c-1
crw-rw---- 1 root i2c 89, 10 Nov 5 19:19 /dev/i2c-10
crw-rw---- 1 root i2c 89, 11 Nov 5 19:19 /dev/i2c-11
5.4 kernels and above you need to use -y 10
in the raspiraw command line.
The revision parsing in camera_i2c all needs totally reworking, as particularly with the CM4 coming in 32 variants there is no way that listing out all the revision codes is really feasible.
Here's what I see when I run that:
pi@raspberrypi:~/GitHub/raspiraw $ ./raspiraw -y 10
Using i2C device /dev/i2c-10
RaspiRaw: Probing sensor ov5647 on addr 36
RaspiRaw: Probing sensor imx219 on addr 10
RaspiRaw: Probing sensor adv7282 on addr 21
RaspiRaw: Probing sensor imx477 on addr 1A
RaspiRaw: No sensor found. Aborting
Anything else I should look into?
camera_i2c reworked to use the board type instead of the full revision code.
The fact that you're seeing Raspberry Pi3B / Pi3B+ / 3A / 4B(1G/2G/4G)
implies that you weren't running the latest code anyway, as Pi4 was split out from the others in August by https://github.com/6by9/raspiraw/commit/222cc9556f0d128aa7e50a0509e9809270750953
raspiraw will now default to i2c-10, and fall back to i2c-0 if that isn't found.
All GPIO setup is reverted on reboot. In the general case raspiraw will not interfere with raspistill etc, but you can't run them both simultaneously.
Awesome! After pulling your code from today it detects the sensor:
pi@raspberrypi:~/GitHub/raspiraw $ ./camera_i2c
setting GPIO for board revsion: d03114
4B(1G/2G/4G/8G)
Set state of 133 to 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- 64 -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
Use i2c-10 for the sensor (-y 10)
pi@raspberrypi:~/GitHub/raspiraw $ ./raspiraw -y 10
Using I2C device /dev/i2c-10
RaspiRaw: Probing sensor ov5647 on addr 36
RaspiRaw: Probing sensor imx219 on addr 10
RaspiRaw: Probing sensor adv7282 on addr 21
RaspiRaw: Probing sensor imx477 on addr 1A
RaspiRaw: Found sensor imx477 at address 1A
RaspiRaw: Encoding 32315270
No AWB
mmal: Set pack to 0, unpack to 0
mmal: Timing 6/2, 2/6/0, 0/0
mmal: Create pool of 6 buffers of size 18580480
mmal: Create pool of 6 buffers of size 18580480
mmal: Now streaming...
mmal: mmal_port_pool_destroy: port 0x1be9120, pool 0x1befd40 destroyed while port enabled
But when I run raspiraw -y 10 -eus 10000 -t 1 -f 1 -o ~/out.%04d.jpg
I get a zero byte file. Here's the log:
Using I2C device /dev/i2c-10
RaspiRaw: Probing sensor ov5647 on addr 36
RaspiRaw: Probing sensor imx219 on addr 10
RaspiRaw: Probing sensor adv7282 on addr 21
RaspiRaw: Probing sensor imx477 on addr 1A
RaspiRaw: Found sensor imx477 at address 1A
RaspiRaw: Setting exposure to 416 from time 10000us
RaspiRaw: Set exposure 0202 to 01
RaspiRaw: Set exposure 0203 to A0
RaspiRaw: Encoding 32315270
No AWB
mmal: Set pack to 0, unpack to 0
mmal: Timing 6/2, 2/6/0, 0/0
mmal: Create pool of 6 buffers of size 18580480
mmal: Create pool of 6 buffers of size 18580480
mmal: Now streaming...
Am I using the command incorrectly? Thanks again.
And using this command: raspiraw -y 10 -md 3 -eus 1000 -o ~/out.raw
I get a file ~1MB.
Damn, sorry about that. Looks like I need to set the width and height explicitly. Will test more now. Thanks!
So it seems something is still a little off with my setup. When I run raspiraw -y 10 -md 3 -eus 1000 -w 4056 -h 3040 -hd -o ~/out.raw
I get no bayer data (only the header).
But when I run raspiraw -y 10 -md 3 -eus 1000 -w 4000 -h 3000 -hd -o ~/out.raw
I get the attached non-empty file - out.raw.zip and when I convert it with your modified dcraw I get a corrupted ppm file - out.ppm.zip
Any idea on what could be causing that? Let me know if I can help. Thanks again.
FYI, removing -md 3
might have fixed that. Testing more now...
Yep, that seems to have fixed it. I figured that mode 3 would be required, but I guess that's wrong. Closing this issue. Thanks!
-w and -h are a hack that I probably should have rejected for trying to set up crops within the sensor. It only works for OV5647.
The parameter to -md is the table entry to be used from the mode table. They do not necessarily match the mode that is passed used by raspistill. -md 3 for imx477 is the 1012x760 10 bit mode. 101276010/8 = 961400 bytes (plus a header and padding). https://github.com/6by9/raspiraw/blob/master/imx477_modes.h#L816 0 = 4056x3040 1 = 2028x1520 2 = 2028x1080 (cropped) 3 = 1012x760 (10bit).
Thanks! FYI I posted my remaining question about triggering ad-hoc frames over at https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=290380 - Let me know if you have any thoughts on that. No worries if you don't have the time though.
When running
camera_i2c
:And when running
raspiraw
:I see similar behavior on @Hermann-SW PR's. Let me know if there's anything else I can get you.