When a project has outgrown using a small microcontroller, almost everyone reaches for a single-board computer — with the Raspberry Pi being the poster child. But doing so leaves you stuck with essentially a headless Linux server: a brain in a jar when what you want is a Swiss Army knife.
It would be a lot more fun if it had a screen attached, and of course the market is filled with options on that front. Then there’s the issue of designing a human interface: touch screens are all the rage these days, so why not buy a screen with a touch interface too? Audio in and out would be great, as would other random peripherals like accelerometers, WiFi, and maybe even a cellular radio when out of WiFi range. Maybe Bluetooth? Oh heck, let’s throw in a video camera and high-powered LED just for fun. Sounds like a Raspberry Pi killer!
And this development platform should be cheap, or better yet, free. Free like any one of the old cell phones that sit piled up in my “hack me” box in the closet, instead of getting put to work in projects. While I cobble together projects out of Pi Zeros and lame TFT LCD screens, the advanced functionality of these phones sits gathering dust. And I’m not alone.
Why is this? Why don’t we see a lot more projects based around the use of old cellphones? They’re abundant, cheap, feature-rich, and powerful. For me, there’s two giant hurdles to overcome: the hardware and the software. I’m going to run down what I see as the problems with using cell phones as hacker tools, but I’d love to be proven wrong. Hence the “Ask Hackaday”: why don’t we see more projects that re-use smartphones?
Hardware Encounters Smartphone
It’s absolutely impossible to beat the convenience of simply hooking up some wires to the pins of a robust microcontroller. I’ll admit that even today, in this era of low-voltage logic, I like to keep a number of chips on hand that have five-volt tolerant GPIOs. And it’s super handy to have a microcontroller that’ll source 20 mA on a pin (per the datasheet, and maybe more in practice). It’s already a tiny hassle to migrate some projects to a Raspberry Pi, where you have to be careful with 3.3 V inputs and a slightly weaker output buffer. But it’s not that big of a deal: connecting directly to anything that speaks I2C or SPI, or just needs a logic-level signal on a wire, is child’s play. Just wire pin to pin, and you’re set.
And then I look at my cell phone. Where do I even plug my motor controller into this thing? There’s the audio jack and the USB, and that’s it. I’m not sticking my Hello World LED into either of those ports and expecting success.
One solution is to throw money at the problem and buy a USB breakout board. For the price of a Raspberry Pi and SD card, you can buy an IOIO dev kit that seems to support nearly everything you’d want. Numato Labs has an eight-pin GPIO expander that sidesteps the whole Java API mess — more on that later — by presenting itself to the phone as a serial device. This means that you need to learn its command language, though. A while back, Motorola even toyed with releasing super-expensive “Mods Development Kit“, but beyond the press release, I haven’t heard anything more of that. Does Android or iOS have support for the FT232H chip? If so, you could press one of those into service pretty readily.
But if the point was to get by on the cheap by re-using an old cell phone, these options don’t make financial sense. Can we DIY something cheaper? WiFi and Bluetooth spring to mind, and indeed you can buy modules that use either for just a few of your local monetary units. For instance, a HC-05 style Bluetooth module makes a cheap and cheerful USART-to-cellphone bridge. All you have to do then is tie the microcontroller of your choice to the HC-05 and then write the firmware. Or go WiFi and do the same with an ESP8266 or ESP32. Again, you’re stuck writing the WiFi-to-GPIO end of the code, but that should be a one-time cost. So I looked around to find these obvious projects somewhere on the net, and came up empty. Anyone?
But what about that audio jack? You could encode your data in audio like we did in the dial-up-modem days of yore. This can be done on small microcontrollers easily enough that a full ATtiny85 audio bootloader can fit in 1 kB, for instance. Now you just add the GPIO-driving firmware.
At the end of the day, these alternatives are all doable, but they all require doing. That is, tacking physical GPIOs onto a cell phone is a project in and of itself. Before you even get to thinking about programming the phone to do your bidding, you have to figure out your hardware-side API. And because it’s a project in itself, you’ve got to really value the additional capabilities that the smartphone brings to the table to warrant getting up and over the hardware hurdle.
Software Needs to Make It All Work
But let’s assume that you’re committed to buying or building a GPIO adapter, how do you start development on your project, given that the software needs to run on the cellphone? Our own Adam Fabio looked at the lay of the land back in 2015 for Android. (Apple folks, what’s the situation like for you?)
Suffice it to say that app development for Android is non-trivial, but at least there’s a ton of documentation to get you started. Even if you’re a Java master, which I’m not, you’ll still want to make sure that the rest of the software components that you’d like to integrate into your own are available on Android. This is where the picture actually gets a little bit brighter. For instance, if you intend to make use of the camera and abundant processing power for computer vision, you’ll be glad to know that OpenCV has been ported to Android, as has CMU’s PocketSphinx voice recognizer.
But Java isn’t my cup of tea. A few years back, I wrote some simple cellphone apps using SL4A — scripting languages for Android. It was pretty pleasant, and I was able to cobble together a Python script that uploaded photos to Imgur and then pasted the resulting URL into the system clipboard in an afternoon. It was actually really great to have Python up and running on the phone — it almost felt like a little computer. Now, SL4A seems to be no longer supported. What’s the new hotness?
As with the hardware hurdles, taking advantage of the processing power inside a cellphone looks like I’m going to have to put in the hours to learn Java and the Android OS way of doing things. And when I compare this with the ease of getting similar things done on a Raspberry Pi, it’s a show stopper.
Giving Up?
Faced with these hardware and software hurdles, you might just retreat back to the friendly environment of the Raspberry Pi or download one of the myriad apps that turn your cell phone into a glorified remote control. With shame, I’ll admit that’s what I’ve done, but I’d honestly like to change. If you’ve hacked a cell phone into a project, let us know! And if, like me, you’ve tried and failed, tell us where you got stuck.
Here is my kind of hacked android phone.
It uses the camera as color detection and communicates with an arduino via bluetooth.
https://youtu.be/Oyp8Vp9MA38
So Droidscript on the phone, Bluetooth to serial (?), and then serial to Arduino to control the motors?
Toss us a link for the phone-side code? Let’s see what this Droidscript looks like.
Correct.
Deoidscript is kind of Javascript but inside of a custom android app.
Here is an example of Android Bluetooth to serial: https://wiki.droidscript.me.uk/doku.php?id=built_in:bluetoothserial
It is also possible to connect an arduino directly to the usb and the phone as host device but then it is not possible to charge the phone at the same time thats why i choose bluetooth at that point.
The Javascript (Droidscript) code for bluetooth looks like it’s one to one with the Android SDK (Java) version but cut down to remove some of the protocol requirements and has less features – seems to be missing blootooth 4.0 (BLE). There will be a BLE library somewhere – no doubt.
So it looks like an excellent entry level to Android app development that would make it easier to make the next step to Java.
After i made some apps with droidscript i was trying out to make real android apps with the SDk and i found so many known commands and it was kind of easy. so you are right and i can say it too droidscript makes an easy learning curve.
Know i dont use droidscript anymore because the Android SDK is running faster and you have more possibilitys.
Like Arduino or direct C Programming :D
I have been saying this for years. So many thing could just be apps. I think this every time I see one of those badges that I know will just wind up in a junk drawer.
Our next badge shall be a clear plastic cellphone holder and a lanyard that attaches to two corners of it.
I actually think building the custom hardware badges is easier that writing an app that will work across platforms, manufacturers, and models (and getting everyone at the conference to install it). Ha!
how is the plastic cellphone holder ever going to support the shitty add-on spec?
BLE
You’re likely right!
Samsung announced few months ago their “upcycling” project to give a extend life to old smartphones up to the Galaxy SIII is still quite powerful but not for a IA/tracker/Spying OS, for sure.
Unfortunately, it doesn’t seem to have moved a lot, still no repository AFAIK.
https://galaxyupcycling.github.io/
Like Linux on Galaxy.
Announced with a lot of hoopla and 8 months later still “coming soon”.
https://seap.samsung.com/linux-on-galaxy
Samsung site likes to float their balloons.
Sorry I meant to say Samsung sure likes to float their balloons and then let them whither away :( can’t edit my post and the mobile interface of hackaday leaves a lot to be desired.
My “Why Not” list:
1 – Closed hardware/locked-down software. On most Android platforms, you can’t get root, you can’t replace the bootloader, and you can’t flash a hacker-friendly OS on it. Some Android installs even come with vendor adware or spyware that you can’t remove (especially the ones made by Amazon). You’re stuck using the Android install that’s on it.
2 – Lack of GPIO. Not much more to say, the article covers this one.
3 – Moving target. The hardware changes constantly from generation to generation. While a reused phone may be a sensible idea for an interface to a web app running on a separate server, if you want to interface to the hardware, you’re basically stuck using USB. The internal chips may have usable GPIO (if you can get past the software layer), but each different model will be different and incompatible.
Yep, #3 is my biggest – If I build it for a RPI, I can pick up another identical board to make or replace it very cheaply, with the exact same hardware for the reasonably foreseeable future. Phones on the otherhand are so one-off – I might have a spare one around, but if it breaks or I need to make another, unless I (likely not cheaply) try to obtain an identical outdated model, there are more moving targets to test and make sure everything works that make it more of a headache than it’s worth.
Depending on application, they might not be bad for one-off’s, especially if you need a nice display. If you don’t need a gui though, for the price of an i/o board for a phone, you could have bough a pi (or similar), and have easily available quantities of identical hardware at a good price to scale out or replace. My 2c anyway…
Points noted, although the whole cellphone market is broad enough, old and new, that a near-suitable phone can be found.
4) latency. If you have to push your gpio toggles over usb to serial or worse Bluetooth or wifi your minumum latency to respond to an input change with an output change will be high and, even worse, variable…
Yes. This is why many RPi projects include 8-bit microcontrollers: to get deterministic timing, which is nearly impossible on multitasking platforms.
That’s IMHO not that huge a problem in the general case, high frequency or ultra low latency interfacing is hard though. Don’t know if common USB stacks give the level of control that would be required however it’s possible to have a 2ms input-response loop even with USB 1.x hardware.
OTOH leaving the precise timing to dedicated hardware and doing the heavy processing on the phone is probably easiest.
And by the time you add a micro-controller, you begin to think why you needed the phone in the first place.
Volume buttons are gpio and can be remapped if kernel source is available. Documentation on the hardware is the real stumbling block as far as I am concerned. Not sure why you’d want a different bootloader; after all, android is Linux. What else would you be running on a rpi?
The point is to get around the chain of trust that keeps you from having root on your own system. There are many points you can attack. The bootloader isn’t the most convenient, but it is the first. There was a time when you could simply modify or overwrite it with jtag, to let you boot a custom kernel or change kernel command-line parameters. Vendors got wise and e-fused off the jtag port on most devices.
With a locked-down bootloader, you’re stuck with the default kernel. That generally means that your only resort is to use a local privilege escalation attack on the running kernel. Possible, sure, but now you rely on specific versions and what worked in the past may no longer work in the future. A newer device, or an accidentally (or automatically) upgraded firmware, and you may be locked out again.
If the application you want to run on the Android device doesn’t need any special permissions, or only requires the permissions that the user can grant, then they’re a cheap way to get a touchscreen interface. If your application needs more than that, or if you want to tear own the Android stack and just work on Linux? You need root.
I’m just now back to owning a smartphone(android). Couple years ago I rooted and loaded custom roms on multiple different devices between phones and tablets. Has it changed that much, or am I just not understanding.
I thought some of the Motorola smart phones were designed for hacking. Right down to just slapping an official back panel onto the phone that gave access to GPIO.
Yeah, here it is
https://developer.motorola.com/documentation/mdk-overview
Yeah. I linked/referenced that in the article. I have yet to see a single hack, done by someone not working for Motorola, using that system. Anyone?
While neat and compact, this is just connecting an stm32f7 (which you have to write firmware for) to the phone. Which could just as easily be done with any number of microcontroller dwv boards.
The port, if I understand correctly, gives you a USB, spi, and dsi interface. Nice.. but the cost is also an issue.
Check out the Umidigi A1. It is $116 on Amazon, $99 from China. It is 4G LTE with US and EU bands. Quad core A53 with 3GB memory and stock Android 8.1. Android has AoA (Android Open Accessory). AoA lets you plug in any USB peripheral and trigger an app to run. You can do almost anything you want to the peripheral using AoA. AoA has been in Android for at least the last five years, maybe longer.
Note that the way AoA works it is possible to keep charging your phone while the AoA peripheral is plugged in. The AoA peripheral is what supplies the power to the phone. This sounds like a hassle but it isn’t. You want it to work this way so that you can keep charging the phone. So wall wart send micro USB power to the AoA peripheral which picks off what it needs and then sends the rest to the phone over the USB connection.
Most any microcontroller that supports USB host mode can be used to build an AoA peripheral. You can get microcontrollers with USB host for as little as $3.
You say “AoA lets you lug in *ANY* USB peripheral” (emphasis mine), and that’s not true. The peripheral has to support AoA and not very many do.
The USB peripheral has to support USB host mode. If it supports host mode it is not much effort to implement the AoA protocol.
If your peripheral does not support USB host mode, ie it is USB device mode, then it can not run AoA and you have to rely on whatever drivers are present in Android.
AoA does not work like a normal USB device (ie USB thumbdrive) it is something different. Your peripheral has to support USB host mode. The reason it works that way is so that you can supply power to the phone.
Can you, maybe, share some examples or links? This is the first time I hear about something like this…
Example would be, you plug your android device into your desktop and MediaFoo runs, you plug it into your laptop and App RemoteWorkBar runs. “Host mode” means it isn’t for devices, it is for connecting full systems. And they have to provide power, this is the opposite of OTG. That’s probably why it isn’t popular; the device needs its own battery, and the phone WILL try to charge off that. The Accessory in the name appears to be the phone, not the thing being plugged in. If you’re making a battery powered accessory that runs android, this could simplify making it communicate with a desktop application. And assuming the thing running in host mode is a regular computer, the charging will be going in the more useful direction that way.
Personally, I would rather use OTG and a custom setup for an accessory. Also, AoA is my favorite k-pop group, so a technology would have to be as awesome as Hyejeong before overloading the acronym. :P
It could be useful for various work situations where you want to plug the phone into different computers and have different apps open.
I guess you didn’t try to make a USB host stack work on a $3 micro. Is it possible? Sure. Easy or quick? Heck no! And that assumes you find a stack that will actually support the peripheral that you need and that runs on your chosen micro. A highly non-trivial issue – almost no USB stacks for MCUs (even paid ones) have drivers for AoA peripherals because it is so obscure use case that almost nobody needs. So you are stuck writing your own. Gee, thanks, writing USB drivers is so much fun …
Not everything in life is fun and there are worse things – for instance bit banging USB while trying to be as standards compliant as possible on a non-overclocked AVR.
Definitely depends on the micro. Don’t grab a random out of the bag when you need a specific peripheral, though. Or at least, choose two $1 micros and have one of them only doing USB.
>AoA lets you plug in any USB peripheral and trigger an app to run.
>Most any microcontroller that supports USB host mode can be used to build an AoA peripheral.
If it supports *any USB peripherals*, then you wouldn’t actually need a microcontroller with USB host. Microcontrollers with USB device are easier to work as the device only stack is a lot easier than a host stack.
I was not clear, any peripheral implement AoA mode will work. AoA is a universal interface and not limited to a specific class of peripheral. There is good documentation for AoA at Google’s Android doc site.
What about the Accessory Development Kit and the few boards that comes along:
ADK, last spec of 2012: https://stuff.mit.edu/afs/sipb/project/android/docs/tools/adk/index.html
Arduino ADK: https://www.arduino.cc/en/Main/ArduinoBoardMegaADK?from=Main.ArduinoBoardADK
It’s basically IOIO with software support.
Looked good. Then I went to “Pricing” and got “Retired”. These seem to be done.
If the code is still kicking around, there’s nothing stopping someone from revamping it.
AoA support is in every Android phone. It is that old demo hardware that is retired.
What is the new demo hardware?
The USB Host Shield Library 2.0 supports ADK which is another name for AoA. Most of the ADK examples are rusty (broken links, etc.) but perhaps someone can revive them. The Arduino Mega ADK board has been retired which was another hardware demo for ADK.
WRT to FTDI you can plug a FTDI chip in to *some* android devices and get it to work. Phones seem to be better than tablets in this regard. The Android needs to be new enough that USB host support was added (ver. 5 I think) and the people who packaged Android need to have the support turned on (here’s looking at you el-cheapo Chinese mediatek tablet vendors). FTDI has a java version of the D2XX library that does not require a rooted phone. I didn’t play with it as I just needed a serial port and could use their test app to make sure stuff was working enough to pass on software guys.
Be interesting to see what you can get working. I used regular mice and keyboards on many a tablet/phone.
Got one of these kicking around … https://www.amazon.com/VELLEMAN-K8055RS-EXPERIMENT-INTERFACE-Velleman/dp/B00M75LY4W I might get around to trying sometime, but klunky though, could probably respin it a third the size if you needed to.
Also got a USB laptop dock with serial parallel etc on it, which would be interesting… par port eeprom programmer on a phone LOL
Concerning the lack of GPIO, I have come across a couple projects breaking some GPIO out through micro-sd card slots so that might be a possibility if the phone has one.
Hmm, I wonder if that could work for micro-sd card slots…..IF it isn’t in an awkward spot like under the battery.
Were those projects on this site or somewhere else?
Now I’m wondering if it might be possible to add a GPIO port using the connector for the smartphones camera…..hmm, while the input might have some decent bandwidth the output would probably be pretty slow if not perhaps non-existent. Have to see if I can find any information on that.
Could only re-find the one at https://forum.pine64.org/showthread.php?tid=5055 , the other I seem to have lost track of.
Keyword: SDIO cards. There are quite a few peripherals (wifi, camera, gpio,…) that you could connect to PDA using SD card slot.
I’ve found the Termux app to be a great tool here. It’s a terminal emulator, and Linux environment with a full package manager. Once you can install gcc and python, the sky is the limit. I believe it allows installing web server on the phone, which can be used as the interface.
We *are* hacking phones.
See postmarketOS
The article was about hardware hacking, not alternative ROMs. Those obviously exist since ages ago.
No it´s not an “alternative ROM” at least, not Android-based, which is a pain. When all you want is a basic Linux to run your code on, you got to love postmarketOS !
postmarketOS even tries to address the closed-source firmware problem:
https://wiki.postmarketos.org/wiki/Firmware
esp32+http server. you’re welcome. that is if you can get a real time executive on the esp32. if its not a real time app youre after, why not python or forth on esp(x)? i’m gonna do it. i already have a pi zero w set up with novnc to give me an arduino dev environment if i need it.
Yes, this jumped to mind for me. It’s what I’ve seen the most of, but that’s not really any kind of measurement of what’s being done. I have seen some that work really well, and some that have connection problems. But if the ESP is the gatekeeper, WiFi the connection protocol, and HTML the interface it gets around the majority of platform/device-age problems when trying to connect custom hardware to cellphones.
Yeah, for me the reason I don’t try to hack an old phone is they’re locked down, and the result kinda sucks compared to using an esp8266 or esp32. If it really needs its own screen it is easy to use an OLED.
And the AT command interface over UART means it is quick and easy to add wifi that way to anything, even without programming the esp.
Issue with doing anything with a phone for me:
Price.
I need some CPU power and an LCD for output?
Let’s grab my iPhone 7. Oh wait – it’s a locked down OS. Okay let me grab my last phone that I have in my drawer. Damn – a Nokia 3310.
The point is: Usually you flip your phones. You sell them used or vendors take the old phone back and subsidize for a new one. So there is no point in doing anything with a phone because they are locked down like alcatraz and they don’t offer ANY convenience. Setting up a webinterface from a Pi takes 10 minutes for stuff you need. And half of the projects I do, suffices with SSH access that the pi has out of the box. The pi costs me 10 bucks – or 30 if I’m fancy and buy a Pi 3.
But even an old LG phone from 2012 costs around 120 bucks. And that is real crap hardware that takes 8 minutes to boot.
So this is the major problem. Not a single use case scenario for me where I wish I used a phone instead of a Pi or Arduino.
Sure – the whole package is sweet. 3G / LTE, Bluetooth, a Screen, a backup battery… but you can only reliably use old hardware and that hardware is usually so dated that you just leave it.
And because if the nature of a phone you won’t do projects where you snap your phone in while using your project, then disconnecting it and living your day with your phone in the pocket – because projects usually are “always on” or “constantly in use”.
Noted, although for SBCs multiple boards (shields) may be required to getting the same functionality. e.g. sensors, GPS, etc.
I don’t know that price is the best reason not to buy a phone for a project. You can get a used Motorola e5 for $50-60 on ebay, and that is a 5.7″ touchscreen, 2GB RAM, 1.4Ghz quad core processor for not very much money.
Just for your info – 8core 1.5GHz phone chip, 5.5″ fullHD IPS display, 3GB RAM, 32GB storage, dualSIM 4G network for $89.99 on Aliexpress.
Try to buy just fullHD IPS touch screen (so it’s visible from angles) for this price…
Oh, I forgot to mention 2 cameras, of course ;)
Thats all nice and good, but how about documentation? If you want to do serious hardware-hacking you need datasheets and stuff.
I have pretty comprehensive documentation about Android itself, it’s just the problem of HOW to connect peripherals :(
IOIO is too expansive from my perspective and some alternative would be very welcomed. So far I am using ESP8266 with wifi connection, but that’s not my preferred way, to be honest.
I always struggle with keeping the device powered while using it. Use USB OTG and your support for charging at the same time is iffy. That means you can’t really rely on using the USB port for GPIO because eventually the phone battery will die. I’ve tried hacking into the device to replace the battery with a power supply, but that’s challenging for other reasons. And most devices don’t have separate ports for charging and for IO. So I end up with a plugged in phone to keep it charged, plus wireless communication for the data part.
The USB OTG specification covers this in the “Battery Charging v1.2 Adopters Agreement”. Just hook up a 124k restistor between the ID pin and ground.
I had great success with 3D printing “fake battery” with contacts, pulling them out using removed back-cover of the phone and simply powering with 4V source.
However, in the end I’ve got back to the battery and used external pin on the board to turn on/off charging. If I charged constantly, I ruined the battery quite quickly. So I only turned the charging on when the battery was below 30%.
Works still now.
I came here to mention power. Phone power supplies are designed for a model where the phone may be used heavily but off the charger for much of the day, alternating with quality time with the charger. Deviate from this model and strange things happen to the charging circuitry and batteries, which do not expect to be externally powered all the time.
It’s an good reason why DIY’ers are slow to adapt, the companies are too selfish to look beyond atheir own timeframe of profit. Why are the articlewriter whining instead of just doing it?
“Shut up and hack” is my mantra. :)
My biggest issue with iOS is that it’s a closed platform, so one have to think more careful of playing in their field. e.g. a commercial goal instead of “just doing it for fun”. I wished that the display mobilephones has could be more widespread, they’re really nice with their high resolution.
Something catchy at 4-5″ would be great to program with arduino or blue pill.
https://www.seeedstudio.com/RePhone-Kit-Create-p-2552.html
Accessory boards, and programmable via the Ardunio IDE
One option is to use the Microbit card: it is (relatively) cheap, it has Bluetooth communication and (aprox) 20 I/O pins with I2C, SPI, PWM, ADC. It is not the best option but for some projects it may be enough (e.g. if you are building something relatively simple, that kids can modify and experiment with by themselves).
Moto Mods Development Kit
http://cdn.electronics-eetimes.com/electronics-eetimes.com/sites/default/files/images/01-picture-library/GrahamProphet/160729edne-moto-e14-2.jpg
http://www.eenewseurope.com/news/moto-mods-kit-aids-smartphone-accessory-development-distribution-announced
https://www.youtube.com/watch?v=A0YFmMEjXP0
Yeah but only works for a very specific phone and at £100 investment for a single old phone project (to replace a £35 Pi) the price is a bit steep … however I love that it exits, and would love to see what it can do in the right hands! https://uk.farnell.com/moto-mods/sjyn1622a/moto-mods-development-kit/dp/2581422
That’s the one I linked in the story. Anyone ever use one? I’ve never seen a moto-mod hack, and I read hackaday every day. :)
Some of the answer is… popular phones retain more value, when you’ve got ppl willing to pay $100 for a few year old one they don’t tend to collect in junkboxes. These tend to get fully working cyanogen mod or other 3rd party firmware. Second and third tier phones only get hit and run firmware versions where you may variously lose the wireless, camera, bluetooth etc, because the chips used have data sheets only available under NDA, if they work at all they’re binary blobbed, etc etc.
So yah, you think “OMG all these advanced platforms practically free!!!” but in the end by the time you try to stick updated software on them and use them, you’re dealing with Tommy the Pinball wizard, the deaf, dumb and blind kid, only the brain is still working,
However, off, off, off brand phones and tablets might fare better if they have the cheaper allwinner chips in and likewise ubiquitous peripheral chips, then you can maybe get http://linux-sunxi.org on them and do great stuff.
Android boxes are probably a good thing to pick up for cheap also, but you may also have issues finding an OS/firmware to put on them that lets you do much and has everything working.
I would also agree that it’s probably a good plan to use the cheapy cheap ‘duinos and other low power boards for handling I/O and utility sites like https://www.blynk.cc/ can help a lot with talking to them.
as for software you could always use the ionic, corodva or the new capacitor framework,this is mostly cross platform and you get very rich access to the I/O of the phone. Use bluetooth to get your phone to talk to an arduino or something for I/O
Thought about Cordova. They don’t have native hardware support for much other than camera, GPS, and accelerometer. I don’t know what it would take to add on an external device.
Which means, as you’re suggesting, a Bluetooth-serial link. For a lot of applications, this’ would be the right way to go!
I just tried Droidscript mentioned earlier in the posts and it is quite easy to use, though I have the advantage of knowing Javascript.
It has USB OTG serial built in.
In the past I have used phones as a user interface and for FLASHing code via BT/BLE (HC-05). Protocols get you abstracted away from the hardware just enough that your code will still work on the next model.
Anyway – Droidscript is definitely worth a look. You code from you PC that has a webpage from the phone open (via Wi-Fi) and then click run on the PC and off it goes – dead easy. You can run lots of examples direct from the browser and in many cases the reference has example code that runs the same way.
The only gripe I have is that the code editor doesn’t have text highlighting to distinguish between user functions, Javascript keywords and Droidscript keywords and that is going to be a right pin for newcomers.
I should mention that only the premium version offers things like in-app purchases.
@Elliot Williams
There is a a plugin for cordova called cordovarduino. I made a few fixes to it and it works pretty well. It’s basically an addon to give you a com port in your app. It supports pretty much any flavor, be it CH340, FTDI or native USB with virtual cdc as found on the SAMD arduinos/feathers.
https://github.com/meso-unimpressed/cordovarduino
Next up:
ASK HACKADAY: WHERE’S WALDO?
They’re usually too good at being vehicles for app commerce. Vendors don’t benefit from giving low-level control of the hardware to users, the developer community is walled off.
Recently I pulled my old Handspring Visor out of a box and got it running again. Figured out how to sync applications to it (the only solution was on Linux, of course). Then I kind of looked at it for a bit…the dev environment isn’t that hard. The device isn’t locked down in any way. It has pretty easy way to get direct hardware access (the Springboard slot). It has an LCD screen, CPU, lots of RAM, physical and touch buttons. It’s probably the easiest possible handheld smart device to start hacking. Yet…I didn’t. It’s a dead end, because I’d have to expend some effort getting a dev environment and hardware interface worked out for this specific device, and then it’s unlikely I’d ever be able use that work for anything else. I can’t duplicate the hardware, and the original hardware is fast disappearing.
More modern phones have the same problem, except that the manufacturers and carriers are actively trying to prevent you from doing whatever you want with the hardware.
A smartphone is good at being a remote interface that you carry around with you at all times. If your application can work through a web browser or other easily portable protocol, then I don’t think there’s shame in using the phone as a fancy remote control. An ESP8266 with websockets makes this a solved problem.
I love handsprings and other palm PDAs! The M68k in those is such a pleasure to work with, they are not for anything mission critical and the security is nonexistant, but they speak serial and IR, have a decent display, a fairly open dev environment, and a beautiful graphics library for the hardware. If anybody has one lying around, please put it in a project! They were my first dev platform, and have a special place in my heart!
ah palms yes, fairly trivial to use them as dumbish terminals, though you don’t get many rows/columns. There’s a palm keyboard project around you can grab a 3D printable connector from to mess with them.
Been trying to think of a tricorderish project that would make sense for anything other than a novelty, arduino or ESP stuck on the bottom for sensor input, wave around get data deally…. maybe that square inch laser scanning project …
I set up a Palm V to monitor a solar system once. It’s a nice enough system to program for using the UART to interface with a microcontroller. The displays on the older devices are not great by modern standards though.
Which solar system?
It seems we are relearning why certain computing architectures and platforms became widespread, why some have a lot of diversity, why some dominated for a little while then fizzed out, etc.
Cell phones are engineered to be devices, not platforms. The Pi is based on a lot of the same tech as cell phones but it was designed to be a platform.
Read “hacking”, was expecting OsmocomBB and Motorola C123. GPIOs on Android instead. Oh, well ;-)
Sorry.
Nexmon? https://hackaday.com/2016/09/08/nexmon-turns-nexus-5-and-rpi3-into-wifi-toolkit/
Don’t get me wrong Elliot, the article is great and I frequently wonder myself on how to repurpose my ever-growing collection of used Android phones. It’s just that with all those amazing hacks popping up on this site it’s easy to forget that for some part of HaD audience blinking LED or running a web server on a consumer device meant for something else is much cooler than setting up own BTS.
I use Basic for Android and the BT for serial access.
https://www.b4x.com/b4a.html
Like others have said, it’s just too much effort to gain access to hardware and get a good tool chain going on a phone which is hard to get hold of the same brand and type so you can reuse the tool chain in other projects. With Arduinos and PIs, or even plain microcontrollers you can just plug it in and start coding the actual fun stuff, without having to worry about gaining access, writing obscure harware drivers and glue firmware/software etc.
Of course there are those who like the challenge, like MikesElectricStuff who reverse engineered an apple iPod display for his own projects. It’s way beyond my skill and quite frankly interest.
I’ve found it far more rewarding to hack a remote control from a articulating massaging chair that was powered by a PIC18 mcu and had an LC display and make it play Christmas tunes than transplanting the brain of a mobile phone. I’d just ruin it. It’s far better IMO to turn an old smartphone into an IP camera or something.
MicroPython’s WebREPL on ESP8266 and ESP32 is doing the job for me. While not exclusive to cellphones, it allows most browsers to get a Python REPL and file transfer over websocket. Communication is fast enough to make “remote controls” and get data streams (in contrast to HTTP servers) but also good if you want to integrate it with IDEs as you will probably find a websocket library for your favourite language.
You can get a straight forward terminal on http://micropython.org/webrepl/ but as I started to use it a lot, I ended up creating a very simple editor mostly to run code from a text editor after using a lot the “paste mode” of MicroPython’s WebREPL. It’s naive and full of problems but I believe it hold good intentions.
http://flying-circus-ide.herokuapp.com/
https://github.com/murilopolese/webrepl-client
There is also Espruino’s headphone jack communication that is just awesome if you prefer wires over wifi (and javascript over python): http://www.espruino.com/Headphone
Since last time I opened an old Android phone to try getting some GPIO action it never turned on again, I believe I will stick with the cellphones as the fancy serial terminal for my lo-fi Python computers for a while (and that is pretty much what I’m doing for a commercial project too: https://github.com/murilopolese/kano-pixel-kit-pixel32).
Websockets + WiFi + ESP makes a lot of sense! You’ll get a lot more responsiveness over doing the same with UART/serial, at maybe the cost of lower battery life. But heck, you’re charging your phone up daily anyway…
This also has the advantage that you can code the apps using a JS/browser platform, which makes the GUI design “easy” and it will work across most phones.
It’s still a project to get the ESP side of things configured, and you’ll need a websockets/GPIO API, but these should all be within reach, and a one-time cost.
I like this a lot.
Oh! I’m really glad you like it!
Yes, it will definitely drain more battery than over USB serial but it’s surprisingly less terrible than I expected, even using motors or bright LEDs.
Regarding the ESP side of things, you mean flash it with MicroPython? Because I believe that is the thing that could definitely be improved… But assuming you have at least Python 2 installed on your computer it should be pretty straight forward to do it. I still hope to see (or make) a good cross platform esptool gui, though.
MicroPython gives you a pretty nice GPIO API (machine or pyb modules) and the binaries for the ESP boards come with WebREPL already. The one for ESP8266 even starts WebREPL for you on a AP network automatically. But it’s still not very much “hacking” the phone hardware but extending it on the budget.
My heart still says “no” when I see python code wrapped in strings inside javascript but then it gets quiet very quickly when I think about how much easier is to develop and distribute web apps that interact with hardware almost without requirements other than a browser.
I actually wrote a bit about this journey here: http://murilopolese.com/buildlog/2018-09-webrepljs.html
I want a law that forces manufaturers to release sources and documentation or alternatively a nice refund for working phones after they stop updating. I can dream, right?
Yes, but even if one phone is EOL’d, the mfgr/carrier will claim that significant IP from the old product is contained in their current range of products and therefore they can only release a (broken) subset.
For making Android apps take a look at MIT App Inventor 2 http://ai2.appinventor.mit.edu Totally insane GUI programming but gives access to Bluetooth and BLE.
What about purchasing the individual cell phone displays and could they be operated by an ARM32 or PIC32?
Need a lot of I/Os I think or a lvds interface chip like a FPGA that was on here. I’d start messing with a beaglebone black for it’s easy LVDS interoperability until I got some notches in the belt.
About all I have in mind for my old phone when I replace it is to serve as a display in my Kerbal Space Program instrument/control panel project, or to run JMRI whenever I finally get to building a model railroad layout. For KSP, it would provide a nice auxiliary display that I can feed telemetry data to over WiFi… Basically, anything else that doesn’t get an actual LED display or analog meter readout of. With eh model railroad idea… It would just serve as a wireless DCC controller.
I find the idea of reusing phones as displays and interface devices to larger projects to be a very reasonable reuse. Honestly, I wouldn’t bother with it if I needed I/O though… I’d just get a Pi. Acting as a wireless interface to the Pi… That, yes.
I don’t know what you guys are doing. But I’ve done plenty with hacking phones. Here’s just one I found on a quick Google search. You can look up more because it’s what I do. https://youtu.be/VvIr0Sa9q8s
Want to know why people don’t use Android phones? It’s not easy, it’s not cheap, it’s not the best use of a mobile device to pin it to a project. There’s a lot of overhead from other apps. You never know when an update will pwn your build.
However, I did a video on Bluetooth and that should be awesome. You want to stay away from the device though and stick with intended operation for stability purposes
That ADK Arduino board _was_ expensive and appears to be discontinued. :( And my instinct is that it fell away b/c not many people were using it.
As you say “not easy and not cheap” may sum it up. That’s the part I’d love to change.
Once Android phones got USB OTG, the Arduino Mega ADK became much less relevant. Because early Android phones were USB device-only, the peripheral needed to act as the USB host. On a modern phone, talking to a regular Arduino over serial is probably easier to code.
An old phone does not need to be mobile anyway and without a SIM card you will not get unexpected updates. I would remove the other apps for such an application. Root access is probably mandatory anyway. Don’t forget: It’s not used as a phone anymore.
The first Android phone, HTC G1/Dream, had a serial port:
https://www.instructables.com/id/Android-G1-Serial-Cable/
The first and last cellphone to have have an easy to use I/O port.
Instead of trying to “hack” a smartphone we should try to figure out how to properly reuse their components .
Poperly and thoroughly.
Properly
Or, like we call it back home, “hacking”.
The components work best on their original PCB and most of them are too fine pitched or BGA, so that a component reuse is really difficult.
I use old cellphones (with LineageOS) all over the house as Squeezebox Players.
Not exactly a hack, but still better than the overpriced Sonos crap, that phones home and locks you out of your streaming account after an update.
LineageOS still gets updates every week, even on old Moto G phones, that you can get on Ebay at ~$20.
And as Lineage supports USB sound cards, you can even connect some 64bit gold plated esoteric high-end DACs made by elves.
I really need to dig into LineageOS. My actual-use phone still runs a year-old (or older?) version of Cyanogen…
I was going to mention that. Bring up some version of CyanogenMod on your phone then you can hack that into anything. The Cyanogen project died, but the code is still out there and works on those older phones.
I’m really sad that the Fernly/Fernvale work by Bunnie and Xobs doesn’t seem to have turned into something usable yet. (Apropos using cellphones, this is a cellphone-class CPU)
nice article – here’s some thoughts I had about this too >
https://eprint.ncl.ac.uk/file_store/production/238612/ABC20DD7-D483-4716-92F6-9298D8BE2820.pdf
In the section “THE MOBILE PHONE AS A NETWORKED MATERIAL” I give lots of examples of projects with the Telephony, Audio, Displays, Multi-touch, Magnetometer, Computation, Network and the Camera being worked to a wide variety of effect. I also talk about my own work later in the paper. If you’re making a list of such project I think these would be good aditions.
There has to be some GPIOs on those CPUs thare aren’t being used. If you can find them and if you can attach to them.
Maybe a strategy with slightly more chance of success… how about I2C? Even if you can’t get the CPU spec or there is no way to solder to it I bet it has at least one I2C bus. Somewhere maybe another chip on the phone, one which is easier to solder to and easier to get specs for might connect to that I2C bus. That might make an interesting way to interface an old phone that doesn’t rely on the USB port which is also the charging port or some hokey setup using the headphone jack.
Besides, you might want the phone’s audio capabilities for actual audio.
Of course you are going to need root.
Almost certainly it’ll have several I2C busses. The touchscreen controller, display controller, PMIC and cameras all tend to sit on I2C buses for control purposes. The biggest downside is that it’ll be low voltage (1.8v?) logic. If you’re lucky, the dev tree might even allow you to read/write directly without rooting.
These peripherals can also easily sit on SPI buses. logic level conversion is not difficult. For I2C 2 MOSFETS and two extra pull ups to your (higher) supply are enough. The sources are connected to the low voltage signals, the drains to the higher voltage signals and the gates to the lower supply voltage.
It seems that I am a bit late to the party here, but I will just put in what my Schools Shell Eco Marathon team did for connecting a tablet (Nexus 7) to the rest of our car’s electronics. The team uses a tablet because it has built in GPS and 3G data both of which we use to send telemetry and sensor data back to a server on campus. To connect the tablet to the rest of the car, we had tried a Bluetooth to serial adapter in the past, but kept having problems with interference. (This was before my time on the team, so details are fuzzy.)
My freshman year we moved to a CAN interface based (http://canable.io/), we had to recompile the Linux kernel in order to get CAN to work with the tablet, but since the tablet was a Nexus 7, it wasn’t too bad as far as I know. From there the team wrote a custom QT app to display the sensor data in a dashboard and stream it back to the server (https://github.com/HEEV).
I just started up a list on Hackaday.io for projects that use cellphones for more than glorified remotes. If you’ve done any projects, or have pointers to some, feel free to make a quickie project on IO and let me know — I’ll include it.
https://hackaday.io/list/161966-cellphones-for-brains
I’m going to write up an overview project that summarizes the approaches posted up here in the comments, too.
And if you’re super-interested, let me know and I’ll pull you in as a list curator.
The Espruino IDE actually does have support for serial communication via the audio jack. RX is the microphone, TX is the speaker:
https://www.espruino.com/Headphone
That hack is using the (DC) voltage levels to convey the data?
That’s asking for issues with portability, b/c really all you can count on out of audio jacks is an AC signal. Some audio jacks have decoupling caps, others don’t. Some have pulldown resistors, others don’t.
At least this is what the Blinkenrocket folks (https://github.com/blinkenrocket/firmware) told me.
It seems like the problem is that we are letting vendors sell us phones that are closed.
Locked OS that has to be rooted.
Undocumented chips that can’t be programmed for.
Undocumented hardware that can’t be modified.
Why do we buy them? Because there are no other choices, or what choices there are are not as good as we want.
Could we start some sort of Open Phone Initiative with requirements for non-locked bootloaders, open-source documented software all the way, and published schematics and board layouts? Would anybody bite on that? Maybe the larger players wouldn’t, but it seems like it would be a great way for a smaller company to differentiate themselves. But are we enough of a market to make it work? And would such a device not be an underpowered device available at a tremendous price?
I think there have been some partial efforts in this area, but they had those problems.
How else do you incentivize a viable solution?
Instead of starting yet another “open” smartphone, why not take and or support one of the many that are out there? Openmoko and Librem5 being the most promising ones. Or use one of the many “alternate OS” projects like replicant for android
> Instead of starting yet another “open” smartphone
I agree with the premise..
> Openmoko and Librem5 being the most promising ones.
Yep but the idea is to reuse the existing EoL and again quite powerful mobile devices. This is the purpose of hacking, is not it?
Even though Librem5 would take off, it will still be confidential and won’t get that much influence or impact. Look, the Nokia n900 was supposed to be the favorite Linux mobile device for years but then, you check its matrix capability for instance on postmarketOS wiki and you see that 2/3 of the features are not available, why is it not portable?
Sure, you won’t be able to do this for all the shitty smartphones – even though powerful from an IoT point of view – released by Samsung and LG but at least, focusing on the mid-range/high-end of their era would be already a good starting point.
I never say it is easy or my comment is original.
Nokia, Symbian, PyS60. Back in the days when people didn’t want to recharge their ‘smart’ phone twice a day.
I have my old Samsung Epic 4g (Sprint Galaxy S version with slide out keyboard) set up as a mobile wifi pentesting platform. Cyanogenmod, wifi monitor mode and packet injection, reaver, mdk3, aircrack-ng, etc. The keyboard makes working in the terminal so much easier. Sprint’s Galaxy S was the only version to have it.
TLDR;
Mobile phones don’t have expansion options – you are expected to buy a bigger, better phone. Even SD Card slots are becoming rare.
So unless you salvage parts and have your own PCB design, you’re not going to have a lot of fun.
Most has been said (closed hardware, lack of GPIO, moving target, unknown latency). What we are left with are Audio, Bluetoth and USB OTG.
The the USB OTG on Android may be our best bet. One may use the libusb on Android, if one is willing to jump through some hoops, see the end of
https://github.com/martinmarinov/rtl_tcp_andro-/tree/master/libusb/src/main/jni
With libusb, and the vusb library one may extend the GPIO for a kiss reproducibly, and with a reasonable latency.
https://www.obdev.at/products/vusb/index.html
Pondering over the Espruino’s serial over Audio idea: I implemented a similar approach for the Pocket PC platform in 2007
http://www.kufr.cz/~ok1iak/HAM/ATS3a-digital/index.php3
with the main difference, that the asynchronous serial data stream was Manchester encoded to remove the DC component of audio to remove the influence of the DC blocking capacitor in the audio path. On the receiving side (MSP430 micro controller), I used capture timers and interrupts on raising / falling edge to decode the Manchester modulation by the firmware. It worked very reliable and it allowed me to produce synchronous command stream with precise timing. I would not be sure about the reliability of the Espruino’s way of modulating the asynchronous serial line over audio directly, as the asynchronous serial line low level protocol carries a non-zero DC component, which would likely not work reliably with a fixed threshold decoder on the micro controller side.
In general, the Android platform is affordable, powerful, the APIs are well documented, the development environment is free. On the other side, when a phone is used as a single purpose device, the use is encumbered by all the Google applications and services which you cannot remove, and which are cumbersome to disable, and the development is complicated by the sand boxing of the apps and the APIs you have to learn to negotiate the access rights (see the libusb reference on Android above).
There is also an issue of various quality and latency of the vendor implementations. For example, a round trip Audio latency on Android 5/6 varies between 50ms on Nexus 4 and 250ms on some cheap Samsung, and this is not documented. I have to yet measure the kernel scheduler properties as I was not able to find anything I can draw conclusion from in regard to real time processing on Android.
For hobbyists, I thing it would be worth to prepare a minimal libusb example application together with a minimal attiny VUSB as a starting point for experiments. For myself as a primarily a C++ programmer, I find the Qt on Android quite workable, and I am very slowly hacking a libusb solution for the Omnia SDR transceiver as time allows.
https://github.com/bubnikv/omniasdrbasicfirmware
If audio latency isn’t driver blob related, then I’m wondering if Frequency-shift keying and “translator” HW is the solution for a extra serial link.
The Manchester modulation works reliably over audio and it is much easier to decode by the micro controller than FSK.
I’m not intending to use it purely with a microcontroller programmed for that specific use case, rather as a generic UART converter that works with a standardized baud rate with any bog standard TTL level serial device without doing any magic on the devices.
It’d also make it more flexible and “only” require SW trickery on the phone(s).
Also, since that’s how old modems did it reliably over noisy copper with fair bit of success means it should not be too hard to implement HW wise.
With digital audio devices, DC bias can be overcome by using clamping diodes on the receiver side. Standard serial encoding (1 start bit, 8 data bits, 1 stop bit) guarantees at least one high and one low per character. But there’s another issue to deal with: there is no guarantee of the POLARITY of the signal, or even that the output side uses the same polarity as the input.
All of this can be dealt with, though, by using software edge detection, to determine the polarity and to make DC bias unimportant.
Would you please give details of the circuit with the clamping diodes to remove the bias?
Well they make great little interfaces and display’s. have a Pi or esp run a web service and make a web app that controls what you need.
at least that’s my idea with them
That’s certainly the easiest solution, and doesn’t require any hacking of the phone at all.
It also means you don’t even need a discarded phone – you just use your current phone.
You Only need a 3 $ esp8266 D1 mini to run a webserver on your home WiFi.
I use one to transmit OSC messages wit quaternion data from a IMU to a VST to create a headtracker.
https://github.com/bossesand/OHTI-HT-osc-wifi
I think a phone makes more sense as a hub/server for controllers. I see people trying to OC an rpi to use it as a server when even a 5yo flagship you can buy for less can kick the rpi’s in benchmarks.
Also what about bypassing android? is there something like ubuntu for android still in development?
Just to clarify what I mean as a hub/server is for the phone to be the ‘brains’ of the operation and just control a bunch of arduinos, esp32 or even rpis through wifi, or ethernet using an OTG adapter
You could chroot a Linux distro on a rooted phone.
It’d still have android, but it can be scraped down to a minimum.
The question is IMHO wrong: ist should be “WHY AREN’T WE HACKING CELLPHONES ANY MORE?” There was a lively community doing that between 2007 and ca. 2015: OpenMoko.org and Tinkerphones.org. But ist has lost more and more enthusiasts. There are still some remaining activities but no freshman appear.
And Google’s Project Ara. And…
https://hackaday.io/project/161985-tramontana I think this project fits in well. Visit the website to learn more http://www.tramontana.xyz
I got OpenPLC working on a couple of smartphones. It has support for ESP8266.
One was on a Rooted phone using Debian Jessie through Linux Deploy, the other used Debian Stretch through Termux and didn’t require Rooting.