Fairphone hasn't talked about GrapheneOS at all, instead opting to be in bed with Murena and /e/os, so I doubt they've even bothered to read the list of hardware requirements. They didn't bother with the Fairphone 6, which was released barely a year ago.
>GrapheneOS smearing Fairphone as not secure in 3..2..1..
GrapheneOS would love to support more devices, that "smearing" is explaining that a company doesn't make secure devices, which is completely correct criticism.
Fairphone for various reasons is not able to or willing to achieve the hardware requirements. It's not easy to create some of the worlds most secure devices.
Fairphone 6 does not fulfill the hardware requirements (secure enclave, MTE, etc.), nor software requirements (monthly firmware updates, etc.). So there is nothing that GrapheneOS can do at this point. The ball is in Fairphone's court if they want this, but Fairphone seems more interested to cooperate with /e/OS, whose CEO proclaims security hardening is for pedophiles and spies (thereby fueling the narratives that support chat control and such nonsense).
One of the underlying reasons is probably that the Fairphone hardware and software is developed/maintained by a Chinese ODM (T2Mobile), so the question is if Fairphone even has the know-how to make such a phone. Heck, they have failed to fix bugs that have been plaguing people for months (e.g. regular dropping of all connections when using IPv6 on certain routers).
Motorola is going to make devices that fulfill the requirements and GrapheneOS is cooperating with them.
> whose CEO proclaims security hardening is for pedophiles and spies
This is a direct quote from the graphenOS Twitter[1] (you can see it in the thread above) and this is a completely misleading reading of the interview of Murena's founder that is being quoted. The actual quote is instead: «il n'y a pas des trucs de sécu vraiment durcis qui pourraient être utiles, clairement, pour des dirigeants, dans les services secrets ou que sais-je. C'est pas notre but».
So you see, the quote says the opposite of how grapheneOS is framing it, it's not “just for pedophiles and spies”, it's “clearly useful” («utiles, clairement,») for some category of people, including security agencies but also executives or other activities, but it's not their goal to offer such a high level of security regardless of other implications (the goal being usable by the mass, having lower security guarantees is a tradeoff that allows running on more hardware).
The personal crusade from GraphenOS's lead against another open source project that simply have different goal is frankly off-putting.
This is actually not the only crusade Graphene is engaged in (see also NetGuard, MicroG). Agreed, this makes the project much less valuable in this commenter's eyes.
When someone says “features that are clearly valuable for executives and others” you can't claim he said it's “just for pedo and spies”, even he also said it'd also be useful for pedo and spies.
The quote Par contre, on a pas une approche "sécurité durcie", on développe pas un téléphone pour les pédo(bip) pour qu'ils puissent échapper à la justice. is literally in the linked video. I encourage everyone who does not speak French to put it in their favorite translator. He literally says However, we do not have a hardened security approach, we are not developing a phone for pedophiles so that they can escape justice.
It is very clear what he is implying here, namely what I said in my original message.
He has repeatedly done so in various publications. E.g.:
Mais surtout, il ne faut pas se tromper de combat : /e/OS permet à ses utilisateurs d’échapper à la collecte massive de données personnelles qui s’opère dans les smartphones du marché, pas d’aider les pédocriminels à passer sous les radars de la justice.
Translation:
But above all, we must not fight the wrong battle: /e/OS allows its users to escape the massive collection of personal data that takes place in smartphones on the market, not to help pedophiles to slip under the radar of justice.
He repeatedly implicaties that only sex offenders need a security-hardened phone.
If we wasn't trying to throw a shade at GrapheneOS and other more secure systems, why does he continuously associate device security with pedophiles?
> He repeatedly implicaties that only sex offenders need a security-hardened phone.
On he doesn't! You trying to read implicit things when there's an explicit rebuttal of your interpretation just a few seconds later in littetaly the same extract!
You can be upset that he talks about pedophiles at all, but you can't claim he said it's ONLY for pedo when he said right after that it's REALLY USEFUL FOR EXECUTIVES.
Listen, I, unlike you who seem deeply invested in GrapheneOS's crusade against this dude, have zero skin in this game, I didn't know this guy before a few hours ago when I stumbled on this thread. But here you're literally making things up from a short video that literally says the opposite of what you're arguing against, and it's painful to watch.
The whole point of his argument is “we're not addressing the most security sensitive segment”. And while I can understand that you don't like that he talks about pedophiles at all, I'm pretty sure talking about “our phone isn't for pedophiles” is mostly to avoid adverse customers reaction against how they “aren't criminal and don't need a device to go to the darknet”.
Can we please not resort to personal attacks? For the record, I am not deeply invested in the project, nor in any way related to the project.
As for the rest of your comment, thank you for giving your point of view. Although I don't agree, I appreciate that you took the time to explain how you came to your position.
Depends what you mean by open source phone, do you mean open hardware? If not, you cannot retroactively add MTE or a secure enclave. Even if it was open hardware, it is kinda hard to do small production runs.
Sure, but then you have to run a different OS. That's completely fine of course, between Graphene, Sailfish, etc. there is a lot of interesting stuff happening.
That's a pretty concrete list so it's unclear to me what you mean. They're also going to support some of the upcoming Motorola phones so it's not just pixels.
I think the short answer of what they'd need to do in a practical way is to release a phone that uses one of the latest Qualcomm processors (those have the required hardware security features), make sure they have at least 5 years of driver support and commit to keeping the phone up to date, allow for relocking the bootloater (they might already do that). And I think that's basically it, the Graphene project would be able to take things from there.
Realistically given that they tend to source older/weaker processors for reasons related to their goals it's unlikely they would source a processor with the required security features for their next model, but that's just a guess.
I don't have anything to do with GrapheneOS (only using it on a phone), but the security of Fairphone is not great, like many other Android phones it does not have a separate secure enclave to store secrets, but instead relies on a TrustZone-based TEE, which is often vulnerable to side-channel attacks (e.g. see the recent attack where a lot of MediaTek phones could be decrypted in seconds, even in BFU). Note: iPhone has had a secure enclave since iPhone 5s (2013), Pixel since 3 (Titan M, 2018), and Samsung flagships since S21 (I think? Knox Vault, 2021).
They also do firmware updates very irregularly even though Qualcomm does monthly bulletins and Fairphone's firmware is known to be full of CVEs. They also have a bad history of updating Linux kernels, e.g. Fairphone 4 is on an ancient Linux kernel. Fairphones also miss modern security mitigation techniques like MTE.
To be fair, this applies to many Android phones outside Google Pixel and Samsung flagships.
Aside from that, repairability is nice, but the most common early failures on the Fairphone 6 seem to be broken volume buttons, for which Fairphone does not offer a replacement and an issue where the logic board dies during charging, which is also not user-replaceable.
---
Ps. perhaps you could use substantive arguments the next time? E.g. which points of the GrapheneOS lists of requirements do you think are irrelevant and why are they irrelevant?
They're also pretty behind on major OS updates and even bug fixes last I've checked. The software story was very disappointing when I wanted to get one.
Yep. I was interested in more sovereignty and degoogling to some extend. So I got a Fairphone 6 with /e/OS. It was only until I dug a bit deeper into the OS image and the microG source code that I found worrying things:
- Old kernel versions with many known CVEs (applies to both stock an /e/OS).
- Old firmware bundles with many known CVEs (applies to both stock an /e/OS).
- Old major Android version, so missing fixes for vulnerabilities not marked high/critical (applies to both stock an /e/OS).
- Chinese firmware blobs, TCL image processing firmware (applies to both stock an /e/OS).
- When using the App Lounge, F-Droid installs go through a proxy (CleanAPK), that Murena does not want to reveal the purpose or owner of. Given Android's trust on first use policy, this could be used to intercept installs and install malicious packages. (/e/OS)
- Runs microG privileged. When an app does Google Play Integrity checks, Google's obfuscated DroidGuard blobs run privileged (/e/OS).
- Runs many Google apps (e.g. Google Maps) with higher privileges (/e/OS).
Different priorities. GrapheneOS prioritizes very strong security (inside a very specific model that includes treating the user as an attack vector to be protected against). Fairphone prioritizes repairable hardware (and actually makes their own hardware). On a finite budget (of both money and time and people), prioritizing either one of these will undermine the other.
Not everyone needs this level of security, mostly against rogue governments. I'd be happy with a GSI grade OS providing me with privacy tools to defend myself against the surveillance capitalists.
I saw this narrative before — right on the GOS discussion board, by coincidence :)
It actually depends on what are you about to protect yourself against. You don't need exceptional security preventing LE from unlocking your device if your adversary are commercial entities craving for your data to sell.
GrapheneOS believes it's nothing or everything, while the privacy is not binary.
If it's all-or-nothing then it's always going to be nothing with a phone, because the position and activity of your device are perfectly transparent to the phone carrier you're using, by mere design of being a mobile phone. They know when you're awake, when you sleep, where you are at all time, when you use a VPN and when you don't, etc, etc.
You can never hide everything, so the question is where you set the bar. GrapheneOS and /e/ have a different bar, making different trade-offs for different user base, and that's absolutely fine.
It would take extensive work to achieve the hardware requirements and the capability for an OEM that isn't able to develop their own chips with Memory tagging enforcement (mte) which the Snapdragon 8 Elite used in the upcoming Motorola phones will have. It won't be cheap and it won't be easy.
Google has set the bar high with their security features.
They support murena's /e/os (as in, you can buy a fairphone from their store with it installed) - my guess is that they probably wouldn't look into directly supporting GrapheneOS (sadly) because the number of people wanting a de-googled android, that wouldn't be happy with /e/os is too marginal for them to consider it worthwhile going down this route.
I don't have any insider info though, just speculating.
Does the article seem AI-written/assisted to anyone else?
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.
True, the article was written with LLM help. Although the most important takeaways are that 1) the camera driver for the FP6 has been fixed and 2) humans can help produce drivers in a fraction of the time cost thanks to LLM help. These are both remarkable enough to vote this article to first place on HackerNews :)
Before AI slop, I rarely saw humans make so many words bold and explicitly mention all affected filenames. On the latter point, humans try to convey the main ideas, while LLMs tend to enumerate the files they changed.
Since this post has a lot of terms in bold and enumerates filenames, yes, it seems at least ai-assisted.
I submitted this article, as the author of the blog article is my close friend and we’re trying to build an open phone stack together. He clearly wrote that he used Opus for helping him write the driver. He also used LLM to help him write the article, but everything in the post is correct. The fact is that 1) the driver has been fixed and the camera is working (most important accomplishment) and 2) humans are able to help make drivers in a fraction of the time cost that it used to take. Both points are remarkable and deserve HackerNews top 1 position. Vote up please! :)
Has anyone had any luck in writing drivers using LLMs?
It’s one of those areas of software that is very niche and no one wants to do it.
And it’s also relatively testable
Drivers live at a nasty intersection of kernel land code, hardware-coupled code, poorly documented interfaces and undocumented interactions that have to be trialed-and-errored on real HW.
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.
Yes this was done with Opus 4.8 and it was very effective. I ran a local harness on the phone itself so it could probe around and experiment. You do have to reboot into a newly compiled kernel occasionally if a module reload is not sufficient.
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.
They aren't intended to be available frankly. You either buy them as camera modules, smartphone type or IP camera type, or don't at all.
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!
Have you even looked at this datasheet? This is one of those "industrial" sensors I was talking about.
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 phrase "standing on the shoulders of giants" comes to mind. So what happened here? Shouldn't there be at minimum a framework for making a camera driver? Nope. They're gluing everything together and hoping it works.. Again. This is not standing on the shoulders of those that came before. It's the same issues year over year over year. It isn't trolling, it is calling out the highly non-optimal, "reinvent the wheel using these bits we have lying around" situation for getting things working.
noIdeaTheSecond | 21 hours ago
BraveOPotato | 21 hours ago
nondescriptp | an hour ago
tuutuP | 58 minutes ago
NooneAtAll3 | 19 hours ago
Telaneo | 19 hours ago
https://grapheneos.org/faq#future-devices
NooneAtAll3 | 19 hours ago
I'm asking for details
Telaneo | 19 hours ago
warrantisall | 16 hours ago
Cider9986 | 15 hours ago
GrapheneOS would love to support more devices, that "smearing" is explaining that a company doesn't make secure devices, which is completely correct criticism.
Fairphone for various reasons is not able to or willing to achieve the hardware requirements. It's not easy to create some of the worlds most secure devices.
microtonal | 14 hours ago
One of the underlying reasons is probably that the Fairphone hardware and software is developed/maintained by a Chinese ODM (T2Mobile), so the question is if Fairphone even has the know-how to make such a phone. Heck, they have failed to fix bugs that have been plaguing people for months (e.g. regular dropping of all connections when using IPv6 on certain routers).
Motorola is going to make devices that fulfill the requirements and GrapheneOS is cooperating with them.
stymaar | 10 hours ago
This is a direct quote from the graphenOS Twitter[1] (you can see it in the thread above) and this is a completely misleading reading of the interview of Murena's founder that is being quoted. The actual quote is instead: «il n'y a pas des trucs de sécu vraiment durcis qui pourraient être utiles, clairement, pour des dirigeants, dans les services secrets ou que sais-je. C'est pas notre but».
So you see, the quote says the opposite of how grapheneOS is framing it, it's not “just for pedophiles and spies”, it's “clearly useful” («utiles, clairement,») for some category of people, including security agencies but also executives or other activities, but it's not their goal to offer such a high level of security regardless of other implications (the goal being usable by the mass, having lower security guarantees is a tradeoff that allows running on more hardware).
The personal crusade from GraphenOS's lead against another open source project that simply have different goal is frankly off-putting.
[1]: https://nitter.net/GrapheneOS/status/2040887784253141142#m
bornfreddy | 9 hours ago
microtonal | 9 hours ago
"Par contre, on a pas une approche "sécurité durcie", on développe pas un téléphone pour les pédo(bip) pour qu'ils puissent échapper à la justice."
"However, we do not have a "hardened security" approach, we are not developing a phone for pedophiles so that they can escape justice."
Also see: https://infosec.exchange/@Xtreix/116356764298456420
UnreachableCode | 8 hours ago
stymaar | 8 hours ago
microtonal | 8 hours ago
stymaar | 7 hours ago
That's just plain bad faith.
microtonal | 4 hours ago
It is very clear what he is implying here, namely what I said in my original message.
He has repeatedly done so in various publications. E.g.:
https://www.clubic.com/actualite-604786-murena-e-os-intervie...
Mais surtout, il ne faut pas se tromper de combat : /e/OS permet à ses utilisateurs d’échapper à la collecte massive de données personnelles qui s’opère dans les smartphones du marché, pas d’aider les pédocriminels à passer sous les radars de la justice.
Translation:
But above all, we must not fight the wrong battle: /e/OS allows its users to escape the massive collection of personal data that takes place in smartphones on the market, not to help pedophiles to slip under the radar of justice.
He repeatedly implicaties that only sex offenders need a security-hardened phone.
If we wasn't trying to throw a shade at GrapheneOS and other more secure systems, why does he continuously associate device security with pedophiles?
stymaar | 41 minutes ago
On he doesn't! You trying to read implicit things when there's an explicit rebuttal of your interpretation just a few seconds later in littetaly the same extract!
You can be upset that he talks about pedophiles at all, but you can't claim he said it's ONLY for pedo when he said right after that it's REALLY USEFUL FOR EXECUTIVES.
Listen, I, unlike you who seem deeply invested in GrapheneOS's crusade against this dude, have zero skin in this game, I didn't know this guy before a few hours ago when I stumbled on this thread. But here you're literally making things up from a short video that literally says the opposite of what you're arguing against, and it's painful to watch.
The whole point of his argument is “we're not addressing the most security sensitive segment”. And while I can understand that you don't like that he talks about pedophiles at all, I'm pretty sure talking about “our phone isn't for pedophiles” is mostly to avoid adverse customers reaction against how they “aren't criminal and don't need a device to go to the darknet”.
microtonal | 10 minutes ago
As for the rest of your comment, thank you for giving your point of view. Although I don't agree, I appreciate that you took the time to explain how you came to your position.
Cheers.
inigyou | 8 hours ago
microtonal | 4 hours ago
inigyou | 2 hours ago
microtonal | 8 minutes ago
Telaneo | 11 hours ago
svpk | 18 hours ago
I think the short answer of what they'd need to do in a practical way is to release a phone that uses one of the latest Qualcomm processors (those have the required hardware security features), make sure they have at least 5 years of driver support and commit to keeping the phone up to date, allow for relocking the bootloater (they might already do that). And I think that's basically it, the Graphene project would be able to take things from there.
Realistically given that they tend to source older/weaker processors for reasons related to their goals it's unlikely they would source a processor with the required security features for their next model, but that's just a guess.
warrantisall | 17 hours ago
I wish all smartphones were as easily repairable as Fairphone. The entire battery care stack would become unnecessary.
microtonal | 14 hours ago
They also do firmware updates very irregularly even though Qualcomm does monthly bulletins and Fairphone's firmware is known to be full of CVEs. They also have a bad history of updating Linux kernels, e.g. Fairphone 4 is on an ancient Linux kernel. Fairphones also miss modern security mitigation techniques like MTE.
To be fair, this applies to many Android phones outside Google Pixel and Samsung flagships.
Aside from that, repairability is nice, but the most common early failures on the Fairphone 6 seem to be broken volume buttons, for which Fairphone does not offer a replacement and an issue where the logic board dies during charging, which is also not user-replaceable.
---
Ps. perhaps you could use substantive arguments the next time? E.g. which points of the GrapheneOS lists of requirements do you think are irrelevant and why are they irrelevant?
izacus | 12 hours ago
warrantisall | 12 hours ago
izacus | 11 hours ago
microtonal | 3 hours ago
- Old kernel versions with many known CVEs (applies to both stock an /e/OS).
- Old firmware bundles with many known CVEs (applies to both stock an /e/OS).
- Old major Android version, so missing fixes for vulnerabilities not marked high/critical (applies to both stock an /e/OS).
- Chinese firmware blobs, TCL image processing firmware (applies to both stock an /e/OS).
- When using the App Lounge, F-Droid installs go through a proxy (CleanAPK), that Murena does not want to reveal the purpose or owner of. Given Android's trust on first use policy, this could be used to intercept installs and install malicious packages. (/e/OS)
- Runs microG privileged. When an app does Google Play Integrity checks, Google's obfuscated DroidGuard blobs run privileged (/e/OS).
- Runs many Google apps (e.g. Google Maps) with higher privileges (/e/OS).
yjftsjthsd-h | 14 hours ago
microtonal | 13 hours ago
Fairphone hardware and software is developed/maintained by a Chinese ODM (T2Mobile).
warrantisall | 12 hours ago
preisschild | 11 hours ago
warrantisall | 11 hours ago
It actually depends on what are you about to protect yourself against. You don't need exceptional security preventing LE from unlocking your device if your adversary are commercial entities craving for your data to sell.
GrapheneOS believes it's nothing or everything, while the privacy is not binary.
stymaar | 10 hours ago
If it's all-or-nothing then it's always going to be nothing with a phone, because the position and activity of your device are perfectly transparent to the phone carrier you're using, by mere design of being a mobile phone. They know when you're awake, when you sleep, where you are at all time, when you use a VPN and when you don't, etc, etc.
You can never hide everything, so the question is where you set the bar. GrapheneOS and /e/ have a different bar, making different trade-offs for different user base, and that's absolutely fine.
Cider9986 | 15 hours ago
Google has set the bar high with their security features.
izacus | 12 hours ago
benrutter | 10 hours ago
I don't have any insider info though, just speculating.
Throwaway698514 | 17 hours ago
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.
flawn | 15 hours ago
[OP] helonaut | 11 hours ago
microtonal | 14 hours ago
Since this post has a lot of terms in bold and enumerates filenames, yes, it seems at least ai-assisted.
warrantisall | 13 hours ago
[OP] helonaut | 11 hours ago
ClumsyPilot | 12 hours ago
ACCount37 | 11 hours ago
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.
nondescriptp | 11 hours ago
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.
amelius | 10 hours ago
Anyone with experience buying them in smaller quantities?
immmmmm | 10 hours ago
ACCount37 | 10 hours ago
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.
amelius | 8 hours ago
ACCount37 | 8 hours ago
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!
amelius | 5 hours ago
For example this one:
https://mm.digikey.com/Volume0/opasdata/d220001/medias/docus...
ACCount37 | 2 hours ago
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.
amelius | an hour ago
https://semiconductor.samsung.com/image-sensor/
ACCount37 | 55 minutes ago
The contact data is real, but you'd have to at least look like a decent sized company to get anywhere with it.
pizzaiolo | 9 hours ago
It's now probably the most modern well-supported pmOS phone.
nondescriptp | 8 hours ago
1970-01-01 | 7 hours ago
prmoustache | 6 hours ago
1970-01-01 | 6 hours ago