Computing capabilities of a generic cell phone?
November 27, 2007 3:42 PM Subscribe
What are the computing capabilities of a generic cell phone?
With Verizon opening up their network to allow 3rd party devices access, I'm interested in finding out what the computing capabilities of a generic(not new but not ancient) cell phone are. How much computing power do they have packed in there?
Essentially, I'm thinking that rather than building custom devices to access Verizon's network, an entrepreneur might be able to order cheap cell phones wholesale, get rid of any pre-existing software on the phone, and write new functions that use its processor, mic, speaker, and possibly camera(if cheap camera phones exist) to.... well, do something. I'm still brainstorming potential functions, and knowing what sort of limits on processing power a cell phone CPU has would be a big help.
With Verizon opening up their network to allow 3rd party devices access, I'm interested in finding out what the computing capabilities of a generic(not new but not ancient) cell phone are. How much computing power do they have packed in there?
Essentially, I'm thinking that rather than building custom devices to access Verizon's network, an entrepreneur might be able to order cheap cell phones wholesale, get rid of any pre-existing software on the phone, and write new functions that use its processor, mic, speaker, and possibly camera(if cheap camera phones exist) to.... well, do something. I'm still brainstorming potential functions, and knowing what sort of limits on processing power a cell phone CPU has would be a big help.
This is just a rough guess, but most older-ish cell phones are going to have a main CPU that's an ARM of somewhere between 100-200 MHz and maybe 16 MB of RAM. As mentioned above, they'll also have some coprocessors for DSP and a variety of other things, but that varies extremely by manufacturer and model.
An entrepreneur might be able to order cheap cell phones wholesale, get rid of any pre-existing software on the phone, and write new functions that use its processor, mic, speaker, and possibly camera(if cheap camera phones exist) to.... well, do something.
This an extremely complicated task, you realize? That's almost exactly what Android is meant to do. There are very significant differences in phone hardware that make creating a universal phone firmware extremely difficult.
posted by Nelsormensch at 4:07 PM on November 27, 2007
An entrepreneur might be able to order cheap cell phones wholesale, get rid of any pre-existing software on the phone, and write new functions that use its processor, mic, speaker, and possibly camera(if cheap camera phones exist) to.... well, do something.
This an extremely complicated task, you realize? That's almost exactly what Android is meant to do. There are very significant differences in phone hardware that make creating a universal phone firmware extremely difficult.
posted by Nelsormensch at 4:07 PM on November 27, 2007
You'd be surprised. On the model of phones I worked on, the main CPU was an ARM 7 that ran just twelve MHz. These days they're a bit faster, but not that much more. High clock rates chew power, and the battery is very small.
There was also a DSP, but it had an even slower clock rate.
The biggest problem with your idea is that you aren't going to be downloading your own firmware. There's a kernel which is responsible for that kind of thing, but the download protocol requires passwords and has other kinds of sanity checks. All those things are secret. In fact, they were even secret inside our development team; I didn't know what they were, and don't to this day.
Nor are you going to be doing it with a hardware mod. The main CPU isn't a separate chip; it's a core which is included in an ASIC. All the ROM, Flash ROM, and RAM are in the ASIC, too. So is the vast majority of the customized hardware, and there is a lot of that. The only thing that isn't in that ASIC is the RF stuff, which is two separate chips based on a different IC technology. You can't access the Flash ROM physically; it's inside the ASIC.
And even if you did, you'd still be SOL. The memory is divided into sections and there's a checksum on each section. During the boot process, the kernel checks all the Flash memory to see if it's been corrupted by evil people like you. If there's any section of memory whose checksum fails during boot, it puts a nasty message on the display and locks up. That checksum algorithm is also a closely guarded secret; I didn't know what it was either.
I'm also not sure you really understand just how complicated it is to "access Verizon's Network". You do not want to try to duplicate that stuff for yourself. About half the firmware in the phone has to do with controlling the hardware and taking care of RF-link protocol handling. It is very non-trivial; you aren't going to be able to make the hardware work, even if you could get your own code in there and bypass all the security. Nor could you take advantage of the existing code to do that. Believe me, it isn't that straightforward.
You are wasting your time with this idea.
posted by Steven C. Den Beste at 4:26 PM on November 27, 2007
There was also a DSP, but it had an even slower clock rate.
The biggest problem with your idea is that you aren't going to be downloading your own firmware. There's a kernel which is responsible for that kind of thing, but the download protocol requires passwords and has other kinds of sanity checks. All those things are secret. In fact, they were even secret inside our development team; I didn't know what they were, and don't to this day.
Nor are you going to be doing it with a hardware mod. The main CPU isn't a separate chip; it's a core which is included in an ASIC. All the ROM, Flash ROM, and RAM are in the ASIC, too. So is the vast majority of the customized hardware, and there is a lot of that. The only thing that isn't in that ASIC is the RF stuff, which is two separate chips based on a different IC technology. You can't access the Flash ROM physically; it's inside the ASIC.
And even if you did, you'd still be SOL. The memory is divided into sections and there's a checksum on each section. During the boot process, the kernel checks all the Flash memory to see if it's been corrupted by evil people like you. If there's any section of memory whose checksum fails during boot, it puts a nasty message on the display and locks up. That checksum algorithm is also a closely guarded secret; I didn't know what it was either.
I'm also not sure you really understand just how complicated it is to "access Verizon's Network". You do not want to try to duplicate that stuff for yourself. About half the firmware in the phone has to do with controlling the hardware and taking care of RF-link protocol handling. It is very non-trivial; you aren't going to be able to make the hardware work, even if you could get your own code in there and bypass all the security. Nor could you take advantage of the existing code to do that. Believe me, it isn't that straightforward.
You are wasting your time with this idea.
posted by Steven C. Den Beste at 4:26 PM on November 27, 2007
I think there's a RF-link protocol on a chip available (about $100 or so); if that works with Verizon's network, you can cobble the rest together however you please from off-the-shelf parts. And yeah, likely you'd use an ARM processor. That's what (for instance) most iPods use. These guys will know a lot more.
posted by orthogonality at 4:36 PM on November 27, 2007
posted by orthogonality at 4:36 PM on November 27, 2007
I would be very surprised if they were selling CDMA2K chipsets that cheaply, especially in single units.
posted by Steven C. Den Beste at 4:45 PM on November 27, 2007
posted by Steven C. Den Beste at 4:45 PM on November 27, 2007
Orthogonality, the page you linked to is for a GSM-compatible unit. GSM (which is TDMA) is drastically easier to do in hardware than any kind of CDMA (i.e. IS-95, J-STD-008, CDMA2K, or UMTS). I would not be surprised if someone sold a GSM chipset for $100 -- but it won't work with Verizon. And there's no way a CDMA2K chipset sells for that kind of price.
posted by Steven C. Den Beste at 4:49 PM on November 27, 2007
posted by Steven C. Den Beste at 4:49 PM on November 27, 2007
I think I should make something clear: the people who design cell phones have done everything in their power to make it impossible for you to do what you are contemplating doing.
The reason is that if someone could alter the firmware of their phone, they could steal service. That happened to AMPS, and it happened to GSM. The people who did the designs for IS-95 and later CDMA2K wanted to make sure it wouldn't happen to their phones. So there's security up the wazoo for the sole purpose of making sure people like you cannot load custom code into the phone without making the phone lock up.
posted by Steven C. Den Beste at 5:06 PM on November 27, 2007
The reason is that if someone could alter the firmware of their phone, they could steal service. That happened to AMPS, and it happened to GSM. The people who did the designs for IS-95 and later CDMA2K wanted to make sure it wouldn't happen to their phones. So there's security up the wazoo for the sole purpose of making sure people like you cannot load custom code into the phone without making the phone lock up.
posted by Steven C. Den Beste at 5:06 PM on November 27, 2007
It's not insanely difficult to load custom firmware on a cellular, it's done all the time. It really depends on how far you want to go and what phone you want to do it to. These things will all be very manufacturer and phone specific. The tools for my particular phone (v3) are easily found on the net. For that matter, you could just order them wholesale from motorola/nokia/ect with whatever you want burned into them. The problem is that these phones are going to cost you a hell of a lot more than your average consumer pays because there won't be the carrier subsidy (they usually LOSE money on these phones when you first buy them and make it back with the service charges). Any particular reason it's verizon you want to use?
posted by IronLizard at 5:23 PM on November 27, 2007
posted by IronLizard at 5:23 PM on November 27, 2007
IL, those are all GSM phones.
posted by Steven C. Den Beste at 5:44 PM on November 27, 2007
posted by Steven C. Den Beste at 5:44 PM on November 27, 2007
Hence the why do you want to use Verizon question. If there isn't some particularly special feature they offer, there's no reason to stick with them and their cranky (bet they're still hackable) phones.
posted by IronLizard at 6:00 PM on November 27, 2007
posted by IronLizard at 6:00 PM on November 27, 2007
Response by poster: Awesome, excellent answers!
Steven, thanks in particular for informing me of some of the difficulties with kernel security. That does put the damper on re-using legacy cell phones, though there's the possibility that some of the phones being produced to use the Android OS might be available at a value price, and the possibility that applications built on Android could function as needed.
To clarify the issue of connecting to Verizon's network, they should be making the code available to do so. There seems to be some confusion about this, but as I posted in the original question, they're opening up their network to 3rd-party devices. My question's about the possibility of modifying cell phones to do non-cell phone stuff, instead of building a device from the ground up.
posted by ElfWord at 6:35 PM on November 27, 2007
Steven, thanks in particular for informing me of some of the difficulties with kernel security. That does put the damper on re-using legacy cell phones, though there's the possibility that some of the phones being produced to use the Android OS might be available at a value price, and the possibility that applications built on Android could function as needed.
To clarify the issue of connecting to Verizon's network, they should be making the code available to do so. There seems to be some confusion about this, but as I posted in the original question, they're opening up their network to 3rd-party devices. My question's about the possibility of modifying cell phones to do non-cell phone stuff, instead of building a device from the ground up.
posted by ElfWord at 6:35 PM on November 27, 2007
OK, I think maybe you have misunderstood what they are "opening up".
You're familiar with the ISO "7 layer" model? The concept of protocols at different levels?
The thing they're opening up is very high level. They aren't opening up what's below that, because they don't own it.
Layers 1 and 2 are proprietary. Layer 1 is the hardware, the actual chipset. Layer 2 is the low level software that drives that hardware. That's all chipset specific.
Layer 3 (and up to about 5; it doesn't really quite map into the ISO model) as a protocol is fully specified and distributed as a TIA document. Large parts of it are covered by patent. The specification tells you what you have to do, but if you do it without licensing the appropriate patents you can be (and will be) sued.
In essence, what Verizon is saying is, "These are the proprietary things we've put at the very top of the protocol stack." Everything below that is your problem; Verizon is unhelpful.
And what is below that for CDMA2K is very complex indeed. Believe me; it's a bitch. At Qualcomm it took a team of a hundred people about a decade to develop it. (I was one of them.)
To make an analogy for the web, this is like Google opening up its interface for "Maps". Which is fine, but it doesn't give you TCP/IP, or HTTP, or DNS, or... Those things you have to bring to the party yourself before you can even reach Google, and they're not easy.
The same thing is true here.
posted by Steven C. Den Beste at 7:01 PM on November 27, 2007 [1 favorite]
You're familiar with the ISO "7 layer" model? The concept of protocols at different levels?
The thing they're opening up is very high level. They aren't opening up what's below that, because they don't own it.
Layers 1 and 2 are proprietary. Layer 1 is the hardware, the actual chipset. Layer 2 is the low level software that drives that hardware. That's all chipset specific.
Layer 3 (and up to about 5; it doesn't really quite map into the ISO model) as a protocol is fully specified and distributed as a TIA document. Large parts of it are covered by patent. The specification tells you what you have to do, but if you do it without licensing the appropriate patents you can be (and will be) sued.
In essence, what Verizon is saying is, "These are the proprietary things we've put at the very top of the protocol stack." Everything below that is your problem; Verizon is unhelpful.
And what is below that for CDMA2K is very complex indeed. Believe me; it's a bitch. At Qualcomm it took a team of a hundred people about a decade to develop it. (I was one of them.)
To make an analogy for the web, this is like Google opening up its interface for "Maps". Which is fine, but it doesn't give you TCP/IP, or HTTP, or DNS, or... Those things you have to bring to the party yourself before you can even reach Google, and they're not easy.
The same thing is true here.
posted by Steven C. Den Beste at 7:01 PM on November 27, 2007 [1 favorite]
(Actually, Layer 1 in the sense of the details of the RF behavior that's required is also specified in the TIA document, but the hardware implementation details, including things like the layout of the control registers, is all proprietary. That was what I meant.)
posted by Steven C. Den Beste at 7:22 PM on November 27, 2007
posted by Steven C. Den Beste at 7:22 PM on November 27, 2007
I still feel dissatisfied here. I'm still not sure we have a meeting of the minds. You mentioned the Android OS. I think you don't understand what that is, either.
Qualcomm sells a chipset called the MSM7600. Included in it are an ARM 11 and an ARM 9. There are also two DSPs.
The ARM 9 and the slower of the two DSPs come with (a lot of) software written by Qualcomm. The DSP is the codec. The ARM 9 plus all the software which is provided with it takes care of controlling the hardware and doing all the things that are necessary to be a phone in a CDMA2K network. The interface between the ARM 9 and ARM 11 is specified, but the ARM 11 itself isn't involved in controlling the RF link or doing any of the CDMA2K protocol stuff. Instead, there's an API that permits the ARM 11 to tell the ARM 9 to do this like "open a call" or "hang up". (Actually, the interface is lower level than that, but not a lot lower.)
The idea here is to provide a building block that a phone manufacturer can use to create a "smart phone" without that manufacturer having to know the details of how CDMA2K works -- because it's really tough. The Manufacturer writes all the code for the ARM 11 and the faster DSP -- and what it does is the user interface, plus all kinds of high level features. It controls things like cameras, and the display, and touch screens, and MP3 playback. All of that is the phone manufacturer's problem. And they want to control that part, because it's their value-add. It's the main way they differentiate themselves from all the other manufacturers who are buying exactly the same chipset and using it in competing phones. (Unusual case designs can only get you so far.)
That is what the Android OS is for. It's a collaborative effort to develop the basics of the UI side of the phone -- but it doesn't do RF. It doesn't know how to handle 800 power control bits per second. It doesn't know how to tune a rake receiver. It doesn't know about soft handoff. It doesn't know how to do Viterbi encodes and decodes. It doesn't know how to synchronize the long code. It doesn't know what a Walsh code is. It doesn't know how to search for multipath energy spikes. It doesn't know about slotted sleep, and how to listen to the paging channel, and what the messages on that mean.
And it isn't going to, because some of that stuff is covered by patent, a lot of it is proprietary, and all of it is a royal pain in the ass.
The Android OS is going to sort-of be "open", but there's going to be a big empty hole in it that says "And here is where you plug in your chipset and all the drivers plus the protocol stack for whatever system you're trying to run under". They won't be providing that part, but without it you don't have a phone. That part you buy from Qualcomm or one of their competitors.
Again using the web as an analogy, the Android OS is going to be like Apache. Apache is "open" and it is a complete web server. But it doesn't have TCP/IP built in, or drivers for ethernet hardware. Those things have to be provided from other sources if you want to have a fully functional web server.
posted by Steven C. Den Beste at 9:18 PM on November 27, 2007 [2 favorites]
Qualcomm sells a chipset called the MSM7600. Included in it are an ARM 11 and an ARM 9. There are also two DSPs.
The ARM 9 and the slower of the two DSPs come with (a lot of) software written by Qualcomm. The DSP is the codec. The ARM 9 plus all the software which is provided with it takes care of controlling the hardware and doing all the things that are necessary to be a phone in a CDMA2K network. The interface between the ARM 9 and ARM 11 is specified, but the ARM 11 itself isn't involved in controlling the RF link or doing any of the CDMA2K protocol stuff. Instead, there's an API that permits the ARM 11 to tell the ARM 9 to do this like "open a call" or "hang up". (Actually, the interface is lower level than that, but not a lot lower.)
The idea here is to provide a building block that a phone manufacturer can use to create a "smart phone" without that manufacturer having to know the details of how CDMA2K works -- because it's really tough. The Manufacturer writes all the code for the ARM 11 and the faster DSP -- and what it does is the user interface, plus all kinds of high level features. It controls things like cameras, and the display, and touch screens, and MP3 playback. All of that is the phone manufacturer's problem. And they want to control that part, because it's their value-add. It's the main way they differentiate themselves from all the other manufacturers who are buying exactly the same chipset and using it in competing phones. (Unusual case designs can only get you so far.)
That is what the Android OS is for. It's a collaborative effort to develop the basics of the UI side of the phone -- but it doesn't do RF. It doesn't know how to handle 800 power control bits per second. It doesn't know how to tune a rake receiver. It doesn't know about soft handoff. It doesn't know how to do Viterbi encodes and decodes. It doesn't know how to synchronize the long code. It doesn't know what a Walsh code is. It doesn't know how to search for multipath energy spikes. It doesn't know about slotted sleep, and how to listen to the paging channel, and what the messages on that mean.
And it isn't going to, because some of that stuff is covered by patent, a lot of it is proprietary, and all of it is a royal pain in the ass.
The Android OS is going to sort-of be "open", but there's going to be a big empty hole in it that says "And here is where you plug in your chipset and all the drivers plus the protocol stack for whatever system you're trying to run under". They won't be providing that part, but without it you don't have a phone. That part you buy from Qualcomm or one of their competitors.
Again using the web as an analogy, the Android OS is going to be like Apache. Apache is "open" and it is a complete web server. But it doesn't have TCP/IP built in, or drivers for ethernet hardware. Those things have to be provided from other sources if you want to have a fully functional web server.
posted by Steven C. Den Beste at 9:18 PM on November 27, 2007 [2 favorites]
Hi,
I had question related somewhat to this thread. I found this thread on Google and joined metafilter. I guess I have to wait a week to start my own thread...but maybe I can get some guidance before that...not trying to hi-jack this thread or anything.
I have an idea for a new function that could be used on every cell phone. I would like to know how hard/expensive would it be to patient the idea...to protect myself from myself from all the telcos using my idea. I say this because my first version would be some sort of download...where anyone with cellphone could download this function to their cellphone and use it...but if takes off like I think it will...it would be very easy for all the cellphone makers to just included this new function(s) in every phone as a 'standard' function...then pretty much rendering my first version (having to do download it) useless.
This new function(s) is really pretty simple...I just know nothing about the tech asspects of this and if it would even be possible to create a download that could be used by most cellphones on the market.
I know this post is a 'bit' vague... but if someone could give me an idea of whats possible and not...that would be great.
I live in Long Beach, CA...maybe someone here lives close by or can recommend someone with some expertise in this area they know of that lives close to me.
Like i said, I did/do not want to take over this thread....but the members posting here seem like the right people to talk to.
Rather than filling this thread up with responses to my question...you could just email me if you want at: mainstreet {at} gmail {dot} com
Thanks for your consideration.
Best,
Dan
posted by companyone at 9:17 AM on December 7, 2007 [1 favorite]
I had question related somewhat to this thread. I found this thread on Google and joined metafilter. I guess I have to wait a week to start my own thread...but maybe I can get some guidance before that...not trying to hi-jack this thread or anything.
I have an idea for a new function that could be used on every cell phone. I would like to know how hard/expensive would it be to patient the idea...to protect myself from myself from all the telcos using my idea. I say this because my first version would be some sort of download...where anyone with cellphone could download this function to their cellphone and use it...but if takes off like I think it will...it would be very easy for all the cellphone makers to just included this new function(s) in every phone as a 'standard' function...then pretty much rendering my first version (having to do download it) useless.
This new function(s) is really pretty simple...I just know nothing about the tech asspects of this and if it would even be possible to create a download that could be used by most cellphones on the market.
I know this post is a 'bit' vague... but if someone could give me an idea of whats possible and not...that would be great.
I live in Long Beach, CA...maybe someone here lives close by or can recommend someone with some expertise in this area they know of that lives close to me.
Like i said, I did/do not want to take over this thread....but the members posting here seem like the right people to talk to.
Rather than filling this thread up with responses to my question...you could just email me if you want at: mainstreet {at} gmail {dot} com
Thanks for your consideration.
Best,
Dan
posted by companyone at 9:17 AM on December 7, 2007 [1 favorite]
« Older Help me take pictures of women in their underwear! | These songs all sounds the same!? Newer »
This thread is closed to new comments.
Really, what with all the DSPs and coprocessors, as well as the wide variance in capability between various embedded processor types, there's no simple answer to that question, especially not if you want it couched in "as fast as a Pentium, but slower than a Pentium Pro" terminology. You could also conceivably try and dig up some J2ME (embedded Java) benchmarks, but they wouldn't really be good for anything.
posted by TheNewWazoo at 3:53 PM on November 27, 2007