Serious question, why doesn't Google build its own bluetooth & BLE chips? Please put some competition on Broadcoam and the like and either push them entirely out of the market (good riddance), or force them to step up their game.
Android has never been about driving the hardware narrative -- it's always been about building a phone with mostly open contributions and driving the start of a wedge to open up the phone industry a bit. It's always been a software answer to a hardware problem, even today. Prior to Android, all we had were closed source low powered feature phones and Blackberries.
That being said, building silicon is non trivial work, and building a BLE stack and controller is even more so. Will a solid BLE stack sell phones? Hard to say how it could drive that narrative, realistically, and even harder to say if such a controller could be made cost effectively. Given Android's archetype (software solution to closed hardware), this puts such a project into a much more difficult position politically and financially.
I can't see this kind of thing having much in the way of legs in a large corp. That being said, I do think if a startup could challenge this landscape, it is a HUGE opportunity.
The Android org generally isn't the right org to build hardware, let alone do chip design. Maybe the camera team got closest when I worked there?
Source: worked on Pixel Buds @ Google & was one of several engineers responsible for selecting the chip vendor. We got source access to the entire stack/OS except for the microcode & some parts of the stack they hid. I found BES a way better partner to work with than the BCOM/QCOM mess.
a) they frequently flip flop between at least two BT profiles, leading to a lackluster listening experience b) they lose connection to each other (leading to intermittend profile switches during reconnects, possibly due to lack of available bandwidth) c) they have severe signal quality issues, leading to limited range and audio interruptions
All these issues only happen with the 2nd Gen Pixel Buds, but not with a random sample of various other true wireless earbuds (I tested Sony WF-1000XM3, 1More True Wireless ANC, Airpods Pro) leading me to believe that this must be a hardware issue on Google's side, especially because the amount of people with the same issues is pretty high.
No other pair of true wireless earbuds hat any issues with music playback while I'm on a road bike, with my phone being on my back, only the Pixel Buds do - and I'm on my 2nd replacement already.
Symbian was open source, ran on millions of smartphones - most of which had app stores and web browsers. Some of which had touchscreens, GPS, augmented reality features etc.
Don't get me wrong - Android has been brilliant. But let's not completely rewrite history, eh?
Symbian was far more popular in Europe than it ever was Stateside, so bear that in mind. I had to import my Nokia E70 gullwing phone before I received my sooner, and what functionality it had was okay, but the browser was hardly more than a WAP browser in a feature phone. The app store was barely there as well, including only a handful of very simple apps at the time.
Prior to Android, all we had were closed source low
powered feature phones and Blackberries.
The rest of your comment makes sense, but the cognitive dissonance of that sentence was so extreme I had to respond.
Fun fact: the first Android phone was the sooner, and it looked and behaved much like a blackberry. Still have mine, in fact.
Apple has been building its own hardware from the beginning, but still also uses Broadcom chips.
do you mean designing? I'm not familiar with any point in time where Apple was building phones, but maybe i'm mistaken.
A quick google search indicates that even the first generation phones were built by Hon Hai.
There is a lot of overlap between WiFi and Bluetooth & BLE such that you just have a Wireless chip that does both. In fact I think with Bluetooth 4 the file transfer profile just establishes an adhoc WiFi network. You don't have separate Bluetooth and WiFi chips anymore.
Furthering that, in the mobile space the Wireless capabilities are usually integrated into the mobile SoC. So you don't even have separate chips for CPU and Wireless.
About the only time you see a separate Wireless chip is when a new technology is emerging like 5G and it's usually only an external chip for a generation or two until it can be integrated into the SoC.
So, if you were to design your own Bluetooth chip today you would also be designing a WiFi chip and then you'd probably just roll all that into a SoC with a CPU. No small feat.
This was a feature of Bluetooth 3.0, but almost nothing ever used it. I was once at a big BT testing company and asked about it, and they had like one device that could do it (a crazy feature-packed HTC WinMo device I think).
And then Bluetooth 4.0 added BLE, and it seems like there hasn't been much development of classic BT since then.
The radio frontend is typically a downmixer and then straight into digital.
Some of the typically "software" bits like FFT's, various encodings, checksums, clock recovery etc. are frequently done in digital hardware acceleration blocks for performance, and saving power. If you were writing the firmware of the device, you needn't use them though.
With enough human years of effort, you could take almost any radio hardware for sale today and repurpose it to speak nearly any other radio protocol in similar frequency bands. Performance will probably be terrible though!
It's rare people do this though - all the chips don't have their firmware documented (again mostly to avoid publishing documentation that proves they are violating someone elses patents), and many have various cryptographic elements that makes reverse engineering hard.
The one exception to this is WiFi chips used in the Nexus 5 by Broadcom, which has had a reasonable amount of reverse engineering because Broadcom accidentally published the source code because the firmware code was in part shared with published Linux kernel driver source code.
:O
Enlightenment moment :(
Companies already in the industry typically have cross-licensing agreements - ie. I can use your patents if you can use mine. Either that or they just violate each others patents knowing that a patent war would be mutual destruction and in neither companies interests.
But a newcomer has nothing to offer - the minute they release any product, every incumbent company will go through their patent portfolio and sue them out of the water.
I thought only the hardware could be patented, not the software, and so SDR would level the playing field, but that's perhaps too naive?
Distraction might not be the right word but I can't conjure up the right one.
Hardware is one of the end goals for Apple, for example. For Google, Android hardware is not. It's just there to serve their goal of selling ads.
I tried it and it can do a few basic things, though it’s in the early stages, apparently.