Fairphone 6 wide camera experimental Linux support
nondescriptpointer.com
nondescriptpointer.com
Anyone with experience buying them in smaller quantities?
A part of it is just how involved the manufacturing of those camera modules is. The sensor chips ships as bare silicon dies. They're precisely placed, glued and wire bonded to the substrate PCB, then adorned with a focus/OIS voice coil frame and a lens assembly. Absolutely nothing about this process is hobbyist friendly.
The other part is that corporations are incredibly stupid about how "valuable" their precious proprietary data is, and would rather jump into a volcano than give a sensor datasheet to someone who doesn't look like they have at least 20 lawyers employed and can take a MOQ of 100000 units. And how would one use a sensor without a datasheet, or a bring-up register sequence, or anything at all?
Vendor buying agreements and NDAs often prevent hobbyist-grade sensor boards from even existing. Especially for cutting edge high performance sensors, like the ones found in flagship smartphones.
You'd buy instead an "industrial/automation/automotive" sensor - one that has a fraction of the raw resolution, but maybe spots some other perks. Like a global shutter with no rolling shutter distortions, a "no RGGB Bayer" option that lets you set up your own filters and pick what wavelengths you care about, a package that's amenable to low volume manufacturing, longevity guarantees, availability in quantities of tens instead of tens of thousands, or actual documentation that you can get without 3-6 months of salesman and lawyer negotiations.
Or you'd buy a ready-made "scientific instrument" camera from someone else. Which probably has another "industrial" sensor - maybe worse, maybe better than one you could get directly, depending on how up to date the catalog is and how good of a working relationship does the instrument company have with the sensor vendors. And a price tag in 4-5 digits range. Then you would integrate that thing as a subsystem into whatever science hardware you wanted to make.
But if you truly want the "flagship smartphone" mix of small sensor size, low cost and high resolution? There are no good options! Clearly, the tech just hasn't advanced far enough for that!
For example this one:
https://mm.digikey.com/Volume0/opasdata/d220001/medias/docus...
It's not CMOS. It doesn't even have a digital interface. It has basically nothing in common with the kind of image sensors you'd find in a flagship smartphone, like Samsung ISOCELL. It's a very specialized device made for a very short list of uses, none of which are in consumer electronics.
Most sensors you'll see there are similar. Not all of them are as hideously exotic as the one you linked, but very few of them are the SKUs you'd find in a smartphone. The closest thing to a smartphone camera sensor would probably be STMicroelectronics VD56G3, which is similar to VD56G0 that Apple uses in iPhone FaceID. And even that is a specialized structured light NIR piece.
The contact data is real, but you'd have to at least look like a decent sized company to get anywhere with it.
Google has set the bar high with their security features.
It's now probably the most modern well-supported pmOS phone.
Some parts that stood out to me: > A phone camera is not a single device. On Qualcomm SoCs, the capture path is a chain: > The bus register base moved from 0xa00 to 0x1800, and encapsulating that offset shift accounted for most of the work. > It gated the AHB register bus used by the whole camera complex, including the CCI. Without it, register accesses silently returned zero. > With the wrong numbering, CSIPHY programmed a lane mask with lane 0 missing, and the PHY never locked. > This was the main bug. Frames arrived at the right rate and size, and buf_done fired, but every pixel was zero. [...] The data path delivered frame timing, but not pixel data. > Changing the register value from PLAIN64 (0xa) to 0x0 turned the all-zero frames into real images: the maximum pixel value was 255, the full colour-bar pattern appeared, and the violations stopped.
Sorry if not, but it seems like so much uses AI nowadays.
Since this post has a lot of terms in bold and enumerates filenames, yes, it seems at least ai-assisted.
Modern LLMs kick ass, but they aren't magic.
Fully vibe coding a driver for things more complex than, perhaps, a well documented CMOS sensor (that's a small part of what's covered in the article) is still a no-no.
But an LLM does wonders at emitting boilerplate, "vibe checking" your implementations, suggesting how to implement certain things, helping debug some of the things, etc. You can get the LLM to do a lot, but you still need a lot of understanding, and a lot of applied handholding.
Obviously this work was mainly porting downstream code and information so the scope was fairly limited but the diagnostics it could do were very impressive.