Hacker News Reader

Comment by icelancer | Hacker News Reader

Of course. Still no ability to go above 120FPS. I have tons of comments on this in my history about trying to extract raw frames from the RPi camera modules and go faster if anyone cares to help.

So ridiculous these sensors and data lanes on everything embedded can't get us 240FPS at even VGA resolution.

View on HN

It is possible!

This article been on the HN frontpage at least twice: "A Guide to Recording 660FPS Video On A $6 Raspberry Pi Camera" - https://blog.robertelder.org/recording-660-fps-on-raspberry-...

- Aug 6, 2019 | 103 comments | https://news.ycombinator.com/item?id=20627574

- Dec 27, 2021 | 64 comments | https://news.ycombinator.com/item?id=29703293

Obviously, the resolution is really low (640x64) but for the price, the quality seems quite nice.

Your solution lies here: https://github.com/raspberrypi/raspiraw You can use any camera with it and set parameters whatever you like.

Edit: Raspberry Pi compute module 4 has all 4 CSI-2 data lanes exposed. So you can get full bandwidth of this interface and could use high resolution sensors.

> Supported sensors: adv7282m, imx219, ov5647

The new sensor is IMX708 and probably not supported yet.

Write your own header and you’re good to go. I did it as electrical engineer generalist and it worked fine. Their support forum is also very helpful.

Could you give a bit more detail where to get the information that we need to put into the header?

Looking at https://github.com/raspberrypi/raspiraw/blob/master/imx477_m... it's not immediately obvious where to get the all the values from.

Fiddling with "struct mode_def imx477_modes[]" when you already have the rest of the header file would be the obvious thing to do and would probably work out fine but that is mostly trial-and-error and not a proper method.

Well you need a datasheet from your sensor’s vendor. There are whole description of the register and initialization sequence. Few hundred values. And from these values you can construct your own register map for the sensor in the way as it was done for supported sensors. For popular sensors datasheets can be obtained just by searching.

AFAIK the normal RPi boards only provide 2 MIPI lanes while 4 MIPI lanes would be possible by most camera modules and the processor. Therefore we only have half of the possible the bandwidth available. For higher resolutions the bandwidth is a limiting factor. There are some boards and camera modules that use 4 lanes. Those boards use different connectors and therefore are not compatible with the default RPi camera cables this is probably the reason why the 4 lane option is not offered by default.

In order to enable higher framerates you need to set up additional "modes" in some configuration file. I assume that by default only "relatively reliable modes" are configured. That's where the limitation to 120 FPS comes from. Calculating other modes requires some special tool that is specific to the camera chip. Also you need some luck that those modes actually work for you.

It’s so frustrating that the entire CSI camera module ecosystem has been completely handicapped by the choice of connector for the camera module.

The V1 camera module (OV5647) only supported two lanes, so it was a fair enough decision then, but they had a chance to change it when they changed connector on the PiZero.

The connector even had the 4 extra pins specifically to support 4 lane CSI, but it was as if it was forgotten about. The V2 camera came out not long after so the combination would have made for a massive upgrade.

I think they ended up back peddling from the new connector due to the horrific combination of a too thin custom flat flex cable with a connector that could barely meet its 10 mating cycle rating.

It didn’t have to be that way, a standard 0.5mm FFC with decent swing down latch connector is 10x more robust.

I think this is a typical case of nice-to-have but not-important-enough for >90% of customers. The decision is not optimal but the want-to-change is not big enough to overcome the existing installation base. The new camera reinforces this. We could have a new connector with more lanes and a cheap little adapter PCB to adapt to the old connector and cables. But even that seems too much right now.

I reverse-engineered the first Pi camera and you can make it record at all sorts of combinations of frame rate and resolution if you bypass the libraries provided.

The limiting factor is how long it takes to shift a row of pixels out of the CCD and into the ADC - wide-but-short videos can be recorded at 200+ fps pretty easily.

Reply on news.ycombinator.com