BlackPlastic Design · Sensor board
The image sensor in the Pocket Cinema Camera 6K Pro is a Sony IMX571BQR — a consumer stills sensor that Sony decline to warrant for anything else, windowed down to a cinema frame and run continuously for hours at a time. The die marking gave it away. What follows from the identification bears directly on the reconfiguration hang.
Sony's IMX571BQR is a back-illuminated Type 1.8 CMOS sensor in a 184-pin LGA package, with 3.76 µm square pixels and 6244 × 4168 active pixels. It is a catalogue part, sold openly, and better known outside cinema for its use in astrophotography cameras.
The identification rests on the die marking, and on nothing else. It is worth being explicit about that, because the obvious supporting argument turns out to be circular: the 6K Pro records 6144 × 3456, and multiplying any chosen window by the pixel pitch necessarily yields its physical size. That arithmetic cannot fail, so it corroborates nothing.
It does establish one real thing. Blackmagic publish the effective sensor size as 23.10 mm × 12.99 mm, and 23.10 divided by 6144 gives a pitch of 3.76 µm — the IMX571's exactly. That is genuine corroboration, but weak corroboration: Sony use 3.76 µm across a family of parts, the full-frame IMX455 among them. It narrows the field. It does not close it.
What the numbers do show is what Blackmagic chose to do with the sensor:
| Sensor active area | 6244 × 4168 |
| 6K Pro recording | 6144 × 3456 |
| Used | 98% of width, 83% of height |
Almost the full width, and a substantial crop of the height. A 3:2 stills sensor windowed down to a 16:9 cinema frame. M
The product brief carries an unusually blunt restriction:
"This sensor is designed for use in consumer use digital still camera. When using this for another application, Sony Semiconductor Solutions Corporation does not guarantee the quality and reliability of this product. Therefore, don't use this for applications other than consumer use digital still camera."
It is tempting to read that as an engineering verdict. It isn't. The same document advertises 12-bit output for high-speed 4K moving picture by window readout, a rolling-shutter movie mode, and a table of windowed modes running past a thousand frames per second. Sony built the video capability in deliberately. They simply won't stand behind it outside one product category.
What "consumer digital still camera" designates is a qualification tier: consumer-grade screening, no long-term availability commitment, characteristics quoted at a particular junction temperature. Sony maintain separate industrial and automotive lines with harder guarantees and prices to match. The restriction protects that segmentation and limits liability. I
Note also what the restriction does not exclude. Consumer stills cameras shoot video, so the 4K movie mode sits squarely inside the sanctioned application. What falls outside is not a resolution — it is the job. Continuous duty, sustained thermal load, and a warranted product that somebody shoots a paid day's work on.
None of which lands on Sony. Blackmagic characterise the part themselves, carry the qualification risk themselves, and own whatever follows. That is an ordinary thing for a manufacturer to do — but it does mean nobody upstream is standing behind a 6K cinema camera built on this silicon.
Sony's full datasheet is distributed under NDA and is not publicly available, so there are no official thermal limits to quote — no maximum junction temperature, no thermal resistance figures. The nearest thing the brief offers is that it quotes the sensor's characteristics at Tj = 60 °C, which at least tells you Sony expect the part to run warm.
The gap is filled from an unexpected direction. The astrophotography community characterise this sensor exhaustively, because they cool it with thermoelectric stages and need to know exactly what they are buying:
| Dark current at −20 °C | ~0.0005 e−/pixel/second |
| Read noise | 1.2 e− high gain, 3.6 e− low gain |
| Full well capacity | > 50,000 e− |
| Peak quantum efficiency | > 80% (green) |
Dark current in silicon roughly doubles every 6 to 7 °C — a rule of thumb rather than a specification. Run it from the measured −20 °C figure up to a 60 °C junction and you get about twelve doublings, landing somewhere near 2.5 e− per pixel per second. I
At 1/50th of a second, that is five hundredths of an electron per pixel, against a read noise floor of 1.2. Utterly negligible.
Which answers the question the Sony restriction raises. An astrophotographer integrating for ten minutes must hold the sensor at −20 °C or the frame fogs. A cinema camera exposing for a fiftieth of a second is not fighting that battle at all: the same leakage, at that exposure, simply never accumulates into anything visible. Same part, same physics, completely different regime.
Which is not to say the sensor goes uncooled. The 6K Pro carries a thermoelectric stage on it, and a shared single-fan airflow path that reaches the sensor last — the thermal architecture is examined in detail elsewhere. The point is what that cooling is buying, which is not what it is usually assumed to be.
The thermal concerns that survive are about outliers and longevity rather than the average:
So the active cooling in a 6K Pro is not there to hold back dark current. It is there to keep the outliers in check and the silicon alive. I
Eight differential pairs leave the sensor board for the mainboard. M The datasheet explains the number without ambiguity: the IMX571 has an 8-lane SLVS-EC output.
SLVS-EC is Sony's scalable low-voltage interface with an embedded clock — timing is recovered from the data stream itself rather than carried on a separate pair. So all eight pairs are data, and there is no ninth clock pair to go looking for. The pair count is fully accounted for.
The clock that does cross the flex runs the other way: the sensor takes a 72 MHz input clock. If that isn't arriving, nothing downstream can work, and it is trivially checkable with an ordinary scope — which makes it the cheapest first measurement on the whole board.
Rather little. The board carries the sensor, two Texas Instruments TPS7A87 dual low-noise LDOs, two unidentified eight-ball wafer-level CSPs, and their passives. M
The TPS7A87 is a deliberate choice rather than a generic one: 3.8 µV RMS of output noise is a specification you pay for only when supply noise would land visibly in the picture. Two of them gives four clean rails, which is about right for a sensor's analogue, digital, I/O and pixel supplies.
No FPGA, no processor, no large digital part. The IMX571 carries its own H and V drivers, its 16-bit ADC and its serial communication circuit on chip, so the board's entire job is to hold the sensor, feed it very clean power, and pass eight serial lanes and a handful of control lines out over the flex. All processing happens on the mainboard. I
The brief lists readout modes numbered 0 to 21, in 10-, 12- and 16-bit word lengths. The full active area runs in the tens of frames per second; the heavily windowed modes reach into the hundreds and past a thousand.
The obvious culprit would be the link, but the arithmetic acquits it. Six-K at 50 frames in 12-bit is about 12.7 Gbit/s, roughly 1.6 per lane — well inside what eight SLVS-EC lanes will carry. The bottleneck sits upstream of the interface, in the sensor's own conversion and readout rate. Frame rate is still bought with pixels or with bits, but it is the ADC setting the price, not the wire. I The full-resolution modes make the trade plainly:
| Mode | Active pixels | Max frame rate | Word length |
|---|---|---|---|
| 0 | 6244 × 4168 | 48.42 fps | 10-bit |
| 1 | 6244 × 4168 | 18.82 fps | 12-bit |
| 3 | 6244 × 4168 | 24.15 fps | 10-bit |
The 6K Pro reads 3456 rows of the available 4168, and fewer rows read faster — roughly a fifth quicker, though readout time does not scale purely with row count, so treat that as an estimate rather than a figure. I
Now put that against what Blackmagic advertise. They claim 6144 × 3456 at up to 50 frames per second:
| Source mode | Printed rate | Windowed estimate | Reaches 50 fps? |
|---|---|---|---|
| Mode 1 — 12-bit | 18.82 fps | ~23 fps | No |
| Mode 3 — 10-bit | 24.15 fps | ~29 fps | No |
| Mode 0 — 10-bit | 48.42 fps | ~58 fps | Yes |
Only the fastest readout mode reaches 50 frames, and it is the shortest word length on the list. The 12-bit mode falls short by more than a factor of two — a margin far too large for the roughness of the row-scaling estimate to rescue. The conclusion survives even if the brief's columns are misaligned, because every other full-area figure falls short too. I
Which implies the sensor's word length changes with the frame rate you select, whatever the recording format is called on the menu.
Blackmagic claim 13 stops of dynamic range. Ten bits of linear data cannot encode more than ten stops. Both cannot be true at once at 50 frames, so one of the following must hold: the fast readout mode is companded or piecewise-linear rather than linear, or the full 13 stops is not available at the highest frame rates. I
Neither would be dishonest — companding is ordinary practice, and headline specifications are routinely quoted at a camera's best setting. But it is a real, checkable question, and the answer would say something useful about what the camera is actually doing when you ask it for 6K50.
Every readout mode implies a different lane rate and a different data format arriving at the receiver. Something on the mainboard must deserialise eight multi-gigabit lanes and adapt to whichever mode was requested — work for an FPGA with SERDES transceivers, and a very strong reason to ship multiple bitstreams in one firmware image. That is precisely what the firmware format turned out to contain.
So "video-pipeline reconfiguration" most likely means: load the bitstream matching the requested readout mode, then bring up the SLVS-EC link. And links of this kind do not simply start — they train, locking and aligning each lane before any pixel data flows. I
That gives the fault a shape. A default boot never requests a readout mode, so it never loads a pipeline bitstream and never trains the link — which would account for it surviving untouched while the reconfiguration path is the thing that fails. See the fault investigation for what has been established there.
If the chain really runs menu option → bitstream → readout mode, it makes a falsifiable prediction. Enumerate every recording mode the camera offers — resolution, frame rate, sensor windowing — and map each onto a sensor readout mode from the table. Then count the distinct sensor configurations required.
If that count matches the number of bitstreams in the firmware image, the chain is joined end to end. If it doesn't, the model is wrong and worth abandoning early.
One obstacle to be aware of before starting. The camera's mode list includes 2880 × 1512, 5744 × 3024 and 3728 × 3104, none of which appear anywhere in the product brief — and the brief itself defers to the full datasheet for binning and subsampling details. The mapping cannot be done from the public summary. It needs the complete IMX571 datasheet, which is not openly published.