Slashdot Mirror
Why Modular Smartphones Are Such a Nightmare To Develop
itwbennett writes: Last week Google postponed tests of its Project Ara until next year. Mikael Ricknäs has written about why developing such devices is particularly difficult. The biggest challenge, writes Ricknäs, 'is the underlying architecture, the structural frame and data backbone of the device, which makes it possible for all the modules to communicate with each other. It has to be so efficient that the overall performance doesn't take a hit and still be cheap and frugal with power consumption.' For more on Project Ara and its challenges, watch this Slashdot interview with the project's firmware lead Marti Bolivar.
Nobody who has done Android development is surprised to hear this.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
It is literally a circular network connected to one CPU and a bunch of dumb nodes.
Each node has a network ID. They can pass messages and only the nodes that are listening for it will get it.
High bandwidth data bus for it.
Why is that so complex? I'm really not seeing a problem from that angle.
This shits been done for decades.
Weak frame? Stop making shit thin phones then. Worst thing ever.
>70% of people put a damn frame around their phones anyway.
Just make the damn thing bigger already!
And maybe make it from something other that crappy plastic.
Who the hell are Google hiring these days? Children?
No one who has done any web development would be surprised either.
Shattered glass becomes the least of your worries when the whole phone falls to pieces. Now where did my 4G radio chip land?
I always find it funny when people complain about the so-called fragmentation.
Imagine if every phone maker and their own OS. And a limited number of phone models. In short, they would all be like Apple.
There would be no fragmentation, right? Developers would instead need to develop for 10-20 completely different OS, in different languages. Because you know, every manufacturer would claim that they are the only one using the one true best language.
I think it's much better to have a single OS to develop for, even if it means testing on many different devices, with occasional compatibility problems. I would even say that Android is less fragmented then having an OS for each manufacturer, and that the smartphone world as a whole would be even less fragmented if Apple switched to Android too. There would be less choice, but it would be less fragmented.
So either stop complaining about fragmentation, or support the idea that every manufacturer not using the dominant OS switch.
Google can't figure out a way to make sure their spyware stays on there no matter what in a plausibly deniable way.
Captcha: psyche
With these requirements MMC/SD/SDIO comes to mind first.
It can transport XX MB/s but also allows use with slow hosts/devices.
It allows negotiation of lower supply voltages.
It allows probing of connected devices.
Nobody who has done Android development is surprised to hear this.
I generally find the opposite, the ones crowing about fragmentation tend to be the ones who have no experience in development on Android (and indeed any non-iPhone platform) and handling perfectly pedestrian problems that we've been working with for all of programming history...
Different hardware and OS versions is standard standard, part of being a programmer...
I thought we'd just 3D print a phone and crowdsource the OS?
Sorry Ara team; but the whole concept is a fail.
I do lots of electronic product development, and this concept has so many problems
- Electromagnetic Compliance. Every time a new module is created, are you going to go through the expense & time of compliance testing.
- Where is consumer demand for such a device? Consumers are becoming dumber; they are flat out finding a power button, let alone selecting complex modules for a phone. This makes it a niche market device, thus low volume, thus expensive.
- Connectors in any design are one of the common fail points. In this design you have lots of them.
- There's a lot of effort just to reliably mechanically retain the modules.
- Having discrete modules makes layout inefficient, as you have to per-decide the size of a function.
- A lot of added complexity/power consumption, as each module needs a hardware/software interface layer common to all modules to abstract their native interface.
- plus all the other mentioned in the link
Now if Google has some spare cash lying around, I've got a lot great projects going on they could invest in!!!
46137
I want a modular device like this so bad.
I plan to buy five of them. Me, my wife, and each of my kids.
I'm hoping tablet and laptop versions soon follow so I can mix and match more modules over time. and I'll get multiples of them, too. it just makes sense to be able to repair them year after year, instead of buying another bloatware crap machine.
Even later I'm hoping I can use the modules for other projects. using the same standardized data bus for a huge variety of things. wearables, pet projects, maker movement stuff.
This is grownup LEGO.
AND a way to save money over time,
AND a way to escape the damned branding going on.
I'm not going to buy a phone until I can get something like this, and I don't really care if it's made by google or someone else.
Before any of this can really happen, manufacturers need to get together and develop a standard for each component:
* The touch-screen, lcd and backlight need standardized connectors.
* Speakers and microphones need an interface that supports sufficient current with minimal noise
* SOCs need a standardize pinout for common components so that sets of commonly un-included component groups can easily be set up off chip without a lot of circuitry while also functioning on chips with the kitchen sink.
--- GPU on one side
--- ram on another
--- power supply and peripheral I/O on another
--- radio comms on another
Or whatever, the important thing is that it can be the same, if you don't include a standard component, just leave off those "pins". There should be a standard interface that could be used for any components that are not on board (or even if the SOC can turn them on/off internally)
The whole concept smacks of being a "Rube Goldberg" contraption to me. While I could see a very small segment of the market liking the idea of replacing components and doing partial upgrades, I'm pretty sure that the mass market will stick with integrated one-piece units that don't fall into a pile of blocks when dropped.
I do not fail; I succeed at finding out what does not work.
And yet, the Fairphone 2 has been designed is currently pre-selling. The prototypes are working, they are just gathering money to ramp up production.
- Where is consumer demand for such a device? Consumers are becoming dumber; they are flat out finding a power button, let alone selecting complex modules for a phone. This makes it a niche market device, thus low volume, thus expensive.
Modular design, means easier to repair just by swapping modules. (And ease to repair is one of the main argument for FairPhone 1 & 2).
- Connectors in any design are one of the common fail points. In this design you have lots of them.
As opposed to the ribbon connector of which you're going to have plenty in modern smart phone ?
At least the interconnects of module phone currently being produced tend to be sturdy.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
There were 3 chips: baseband, RF, and PMIC. The baseband had 2 or 3 CPUs (earlier ones had an ARM 7 for I don't remember what, then they an ARM9 to run the phone and a more powerful ARM11/ARM13 to run BREW, then Android). The RF chip did the radio stuff, and the PMIC did all the power control (Power Management IC). Each baseband chip was optimized for a specific RF and PMIC chip. You could swap them out with what I understood was a lower level of efficiency. As I worked for Qualcomm I was never exposed to non-QC chips.
// Wish I'd stayed a couple more years
/// hell, wish I was still there, it was a great place to work. Although former co-workers say that changed 5-6 years ago.
//// retirement isn't what I thought it would be
The display, keypad, battery were generic, use whatever you want. QC didn't make displays, nor keypads, nor batteries.
They also had a single chip line (SC1x/SC2x if memory serves), they took 3 dies (baseband, RF, PMIC) and stacked the dies atop each other in a single package. The idea was to sell them for, I think, $6 each for low cost phones. Add a display, keypad, battery, and case and you've got a cell phone.
I retired when Snapdragon was showing up on my "upcoming stuff" memos.
/ this is greatly simplified at the chip level (e.g. the PMIC let the phone vibrate)
I'm hoping tablet and laptop versions soon follow so I can mix and match more modules over time. and I'll get multiples of them, too. it just makes sense to be able to repair them year after year, instead of buying another bloatware crap machine.
You should definitely check out the FairPhone 2.
Ease of repair has been one of the main argument for FairPhone 1 & 2.
For the second model, they are currently going to a a modular design to make it even more easy to fix, and to give the possibility to swap module in the future for added features.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I've been building and upgrading my own desktops since I was 14. I'm not touching a modular phone with a 10 foot pole.
Stop trying to make "modular smartphones" happen. It's not going to happen. Ever.
The market is too cramped.
Lots of new "standards" will segment the market to death.
The margins are too low.
The pace of development for new phones is too fast.
The market is too small.
By the time someone "successfully" develops a modular phone, it'll be too old, too under-powered, and still too expensive. All of the cool whiz-bang modules will have to wait until the phone is accepted before they're developed and the phone won't be accepted until all those cool modular doohickeys are available.
It's just NOT going to happen. Oh, they can build a few and even offer them for sale, but practically no one will buy them. Perfectly good, useable phones already exist at price points far lower than a modular phone would be priced at.
Just stop trying to make modular phones happen. They're not going to happen.
Just cruising through this digital world at 33 1/3 rpm...
Nobody who has done Android development is surprised to hear this.
I generally find the opposite, the ones crowing about fragmentation tend to be the ones who have no experience in development on Android (and indeed any non-iPhone platform) and handling perfectly pedestrian problems that we've been working with for all of programming history...
Different hardware and OS versions is standard standard, part of being a programmer...
This.
If you want to avoid version issues with Android, target the lower API levels. Sure you miss out all of the newer features, but you dont need those for a fart app. Android itself handles most (or all of, in most cases) of the backwards compatibility.
Besides this, we've seen the problems inherent in monocultures in IT. Remember I.E. 6... This is why aged web developers never complain about writing compatibility layers for Firefox, Chrome and Webkit browsers.
Calling someone a "hater" only means you can not rationally rebut their argument.
Can't wait to see how they (don't) sell. Cellphones are throw away commodities. And in this case, there are so many established awesome big brands to compete against.
My prediction is more people will change their iPhone or Galaxy every year than the total number of people who buy modular phones.
I'm with labnet, if you don't admit your mistakes, you can never learn from them.
Admit Ara was dumb and learn from it.
I'm pretty sure the interconnect bus is not the issue.
The thing that slows down most ARM devices is the memory controller, which is why iPhones are such a win: the PA Semi folks were able to speed up the memory controller considerable, but only for Apple's chips. The nVidia people have made some forward progress, but the bottleneck is still the memory bandwidth making the graphics (among other things) pretty crappy. They are almost an order of magnitude slower than the A9. If you had an A9 at the core of these things, yes, the interconnect would become the bottleneck, but good luck sourcing Apple's hard-won designs.
The secondary problem is that the parts are not uniform between models, meaning you can't depend on anything but the lowest common denominator, which translates to intentionally limiting feature so that this will run on everything. This include using older API sets because not all of the phones can run the latest (which is what you expect, since that's sunk cost, so you lose out on any of the modern features that would compete with integrated phones. A lot of this has to do with carrier certification for the combinations of components, which go up by a power of two for each ne possible module you can plug in.
The idea is pretty doomed due to the least common denominator alone, even ignoring that it's a s mid-mash, and they are using real software engineers of component isolation and interface contract. In other words, it's a mess of epic proportions;
Modular cell phones. It's only missing an AM/FM receiver and it's a tricorder.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Wow! Who would've thought? A dumb concept by a designer with no notion of engineering turns out to be nigh impossible to realize!
I guess that tells us something interesting about the power of bullshitting on kickstarter-like websites. I remember seeing this project a few years ago and it had this "social crowdfund" aspect to it, where it had to get a certain number of shares/likes to be "considered", or something.
I laughed a lot when Google aquired the project. I'm laughing even harder now.
Why aren't they trying to develop something similar to the ATX standard? I don't need the ability to swap out some modules at runtime. But it would be nice if I could open up my standard case, swap out the motherboard, put in a new CPU, get more RAM, attach a new monitor, camera, keyboard etc. We could finally go the way of the PC and have a device that is in our control. And other manufacturers would still be free to pre-assemble them in any way they see fit. I fear that this project will be a category of it's own and will never get support from other manufacturers, making it a niche product that will eventually die out.
Except if you do need the new features then you're screwed.
I've been working with BLE, which is strictly 4.3+ only. The 4.3 stack was so buggy that Samsung for example had to put in a bunch of bugfixes. Naturally since there's no spec, just API documentation, the samsung ones behave differently from the Google ones in subtle but important ways, from what I can tell, the difference comes from wanting to fix the bug without replacing much more.
Note: the samsung one isn't correct, it's that the API is underspecified.
Of course half of it broke when 4.4 came around so we needed two layers of hacks, one to deal with the buggy 4.3 AND samsung's fixes and one to deal with 4.4. Then 5 came out and it seemed to work, but then we found our code targeting 4.4 worked on 5 but not 4 because the identical API changed its behaviour its behaviour subtly from 4.4 to 5.1, and while both behaviours were reasonable reading of the very sparse documentation, they were quite different in practice.
When dealing with any obscure part of Android it's basically the same. The documentation is sparse and ambiguous and things break easily between versions.
SJW n. One who posts facts.
Separating out everything into modules is going to be hard. Even PCs which have no space/weight constraints are not fully modular. Much harder for a phone where things like the CPU and RAM are typically soldered on top of each other.
But you can take a more modest goal of making the major components replaceable, repairable and upgradable, for example, https://www.fairphone.com/2015...
Nobody who has done Android development is surprised to hear this.
Now imagine being a developer if every company decided to make their own OS instead of using Android.
I don't care if it's a pain to create new things. I want new, quality, innovative things - anything less and you can fuck off and take your business with you. I'll use whoever replaces you. Serve me, your customer, or I'm not going to bother with you.
Actually this is a reasonable point. Bluetooth has been a pain between versions - audio recording too. Basically anywhere they change the underlying OS implementation and try to cover it up in the API.
Well, either I'm an amazing programmer or I work with terrible iOS developers, but my experience (since Android 1.6, btw) has not been that. The teams have always been the same sort of size, and worked at roughly the same pace.
How complicated can this be to understand? It is the same problem home computer builders have had for years. You can buy a Dell, HP, or other mass market brand and know that everything works together. OR you can put together your own system and possibly find that the high end video card does not necessarily like the way the motherboard handles video requests. And it is as much a software issue (i.e. poor drivers) as a hardware one. I have had really great hardware that came with truly atrocious drivers that made that great hardware almost unusable (I don't buy from that company anymore). It is the same for any platform designed to use multiple components built by multiple manufacturers, every different manufacturer has their own interpretations of the standard. It is not just computers, look at all the problems that Boeing has had with the 787 (like mounting holes not lining up) because they decided to outsource it to like twenty different countries.
I don't understand the huge rush to switch to BLE. So the software stack still has rough edges? No shit! It's new! Meanwhile regular Bluetooth chips and modules are available for pennies by the pound! If you are just a geek looking for something to play with yourself then by all means.. shiny! If you are developing a product though.. well.. would you install a 1.0 something on a production server?
Just stick with regular Bluetooth for now. These issues will be worked out. Can you really tell me that the average customer is DEMANDING BLE in their products? Do they even know what it is? I'm really doubting it!
Yes, I get it that Apple has already polished their BLE implementation. Of course they did... they didn't even have Bluetooth serial support! They had a major feature gap and a need to compete. So.. they threw all their effort into it just to try to show they are different.
Ah a typical slashdot post. You have no idea about the subject at hand, what I'm doing or the history of it, yet you wade into the discussion and arrogently tell me that I'm doing it wrong and should be doing it some other way. Out of interest have you shaved your neck recently?
I don't understand the huge rush to switch to BLE.
Because my sensors will run at full whack for 160 hours off a CR2032 coin cell, and sit in standby mode for about 6 months.
No shit! It's new!
No, it's that Android was super late to the party. BLE was ratified in 2010 and TI had their chips available pretty much then: the CC2541 datasheet is from 2009. That's 5 years old! Shipping software 3 years late is not an excuse for it to be super buggy.
Just stick with regular Bluetooth for now.
It's far too high power.
Can you really tell me that the average customer is DEMANDING BLE in their products?
And Henry Ford's cusomers wanted a faster horse. But I'm pretty sure my customers will demand a reasonable battery life from the kit I'm building. I doubt they'd care if I'm doing ICMP/IP, with unicorn farts as the physical layer. However, since no major manufacgturers provide phones with unicorn fart tranceivers (never mind with the IP stack running on top), I'm more or less stuck with BLE.
Yes, I get it that Apple has already polished their BLE implementation.
Do they? I've not tried it, since I've never done any iOS or OSX development (except for occasionally porting pretty straightforwarf Linux userland prgrams).
SJW n. One who posts facts.
Imagine having a phone where you can update to the latest OS.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
Finally.. in order to get that nice, on-device IDE.. they would only have to NOT ban compilers from their store!
There are on-device IDEs for interpreted languages for iPad. Last time I checked they were called "Codea" and "Pythonista".
Now imagine being a developer if every company decided to make their own OS instead of using Android.
It already exists, and it's called video games on the TV.
A lot of this has to do with carrier certification
Why would an individual carrier, not the governing body of GSM, UMTS, and LTE, need to certify individual phones?
for the combinations of components, which go up by a power of two for each ne possible module you can plug in.
And why would they have to certify anything but the radio module?
... I would be very happy to be an early adopter here. If it is not 100 percent perfect is fine with me.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
Marti Bolivar? That's a real BadAss name
Slashdot ya no es que lo era!