Close
0%
0%

Hacking Cellphones Overview Project

Cellphones have so many useful bits: it's a shame that they're hard to us in projects. Let's fix that!

elliot-williamsElliot Williams
Following
Liked Like project

Just one more thing

To make the experience fit your profile, pick a username and tell us what interests you.

Pick an awesome username
hackaday.io/
Your profile's URL: hackaday.io/username. Max 25 alphanumeric characters.
Pick a few interests
Projects that share your interests
People that share your interests

We found and based on your interests.

Choose more interests.

OK, I'm done! Skip
Similar projects worth following
1.5k views
4 comments
224 followers
View Gallery
Cellphones have a CPU, tons of storage, a touchscreen, GPS, an accelerometer, WiFi, an audio codec, and even cellular data. And they're dirt cheap on the used market. Why aren't we using them in our projects?

The consensus seems to be twofold.  The hardware side of things is too cumbersome -- there's no pins broken out anywhere.  And the software environment doesn't help either.  

We're spoiled for scripting languages (with hardware support libraries!) on the Raspberry Pi.  Not so on cellphones.

I wrote an Ask Hackaday column because I find this a horrible waste. And there were some great approaches suggested in the comments -- this project is basically a lit review. 

Go read the Logs for a summmary.  And hit me up if you want me to add an approach.  Or better yet, document it as a Hackaday.io project and submit it to the Cellphones for Brains list.

  • Cellphone to CANbus

    Elliot Williams • 10/19/2018 at 18:27 • 0 comments

    [nebk] wrote in with a project that used a CANbus dongle (originally a design by Hackaday's own Eric Evenchick!) to read the vitals of an experimental competition car. 

    CANbus is actually pretty versatile, and the transceiver chips take care of a lot of the hassle for you for very little money.  You probably don't want CANbus for a single sensor, but once you get past a few, it might make sense.  Of course, if you're doing automobile stuff, it's a good fit.

    "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)."

  • WiFi + Websockets + ESP

    Elliot Williams • 10/19/2018 at 15:33 • 0 comments

    [murilopolese718523034] suggested WiFi + Websockets + ESP32 running Micropython.  

    Websockets are great b/c you could code the app on the phone side as a webpage, which makes it more portable and relatively easy to hack together if you know HTML / JS.  It's also (relatively?) low latency, at least compared to HTTP.  Which is faster, Bluetooth/Serial or WiFi/Websockets?

    I also like this b/c the hardware side is pretty easy to handle.  Just an ESP32 and you're done.  Let its HW peripherals handle the SPI or I2C or ADC or whatever.

    What's missing is a protocol/API.  

    Micropython here or there, this is a promising approach to tacking fairly high quality GPIO onto a phone.

    Pros: cheap, readily available, super-flexible hardware

    Cons: battery drain from WiFi, flexible -- protocol implementation needed

    This is the angle I'm going to chase down.  I've got some ESP32 breakouts just asking to be used...

  • Bluetooth

    Elliot Williams • 10/19/2018 at 15:26 • 0 comments

    Bluetooth is obvious.  You can easily put out serial data to a cheapo BT modem, and pass that off to a microcontroller.  

    Pros: simple, portable, flexible, not a super power hog

    Cons: slow, high latency, flexible -- need to develop own protocol

    [Eric Mockler] says: I use Basic for Android and the BT for serial access.
    https://www.b4x.com/b4a.html

    See the bead-sorter project for another example (Droidscript + Arduino).

    [MartinR] says: 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.

    So many ways to go here, and a Bluetooth serial terminal is always handy...

  • FTDI 232H

    Elliot Williams • 10/19/2018 at 15:18 • 0 comments

    [scatterbrained2] suggests that some Android phones will recognize the FT232H chip, which has GPIO as well as the normal serial modes.  

    I have a 232H board with some onboard EEPROM, and it can be configured to do fast SPI / I2C / JTAG, passing all that over USB.  This would be a powerful/fast interface if it worked with a phone.  But I think it set me back $20.  More than a Pi Zero, less than a Pi 3B.

  • Android Open Accessory

    Elliot Williams • 10/19/2018 at 15:14 • 0 comments

    [jonsmirl] and others suggested AoA -- which mostly seems to be an Android-side API to interface with USB devices.  Not a bad idea, but what do we use for hardware?

    Well, there's the official dev kit which doesn't exist anymore.  Google/Android now wants you to tether the phone to a Raspberry Pi.  LOL, thanks.  The whole point of a cellphone/hardware interface was replacing the Pi.

    Arduino made an ADK board for a while.  Looks to be discontinued.

    It looks like you can still get the IOIO board from Sparkfun, so that's good news.  It's $40.  Bummer.

    So DIY? It looks like AOA needs a USB host attached to it.  So you'd better like coding up USB host firmware.  (I don't.)

    I haven't looked hard enough into AOA -- If I'm missing something here, please let me know!

  • Cellphone-powered Bead Sorter

    Elliot Williams • 10/19/2018 at 15:01 • 0 comments

    If you want to know what I'm talking about, it's this!

    [Aaron Christophel] took a project that was done with a RasPi and camera, and subbed in a cellphone, Bluetooth modems, and Arduino.  The vision is done on the phone, coded up in Droidscript (JS dialect targeting Android OS).  The phone talks serial via Bluetooth to an Arduino that drives the servos that make it go.

    [RÖB] and [Aaron] note that Droidscript is a friendly stepping-stone to Android-flavored Java, so learning it isn't a waste of your time if you want to start off quick on the phone side.  Now [Aaron] uses the SDK directly. 

View all 6 project logs

Enjoy this project?

Share

Discussions

dackdel wrote 10/22/2018 at 13:53 • point

https://hackaday.io/project/161985-tramontana Can I add this project to this list? I think the project fits in very well.

  Are you sure? yes | no

zoobab wrote 10/20/2018 at 16:25 • point

On the GPIO over USB topic, I am trying out if an stm32 bluepill would not be the perfect companion to hook to a USB port in OTG. Trying to plug one of them with USB-CDC serial port to see if they are recognised.

  Are you sure? yes | no

Hacker404 wrote 10/20/2018 at 00:41 • point

Some thoughts -


ESP32 does both Bluetooth and BLE as well as Wi-Fi so you're not limited to using the more complex and power hungry Wi-Fi.


The only protocol used for Bluetooth or BLE is the "AT command set" to establish the link parameters and in most cases this is handled by the development platform you are using on the phone and is a once only setting on the remote end as it's often stored in FLASH. Most often the manufacturer (default) setting in the remote end (like HC-05) will work fine. The link itself is only a serial link so it doesn't matter what protocol you send over it. For example you could send G-Code. There are also a multitude of IoT protocols out there if you desperately need a "standard". 


If you want to use Wi-Fi then the best standard is HTTP.


It would take a year to read all the RFC's for HTTP so I will cut it down to the bare essentials -

Line terminators can have some special meaning so I will sort them out first.

There are four common ways to visually represent line terminators as text so I will explain those so the rest makes sense.

1) They are written as descriptions of their function - example "carriage return"

2) The coders way - They are shown in decimal or hexadecimal preceded with "0x" and the ASCII number.

3) The "Windows way - they are show as letters within square brackets "[xx]".

4) The *nix way - they are shown as and escape character "\" followed by a letter.

Here is the co-relation of the two we need to understand in the above order -

"Carrage Return", 13 0x0D, [CR], \r

"Line Feed" or "New Line", 10 0x0A, [LF], \n

I will use the *nix version - \r \n

You make a request to the server and the server returns a response. Both are simply long strings.

Both have the same line termination format. They both consist of a header and a body (not to be confused with the HTML <HEAD> and <BODY>) these are completely different. The body is omitted in a request unless you are using the POST method to upload data or variables.

The character sequence that separates the header and body are \r\n\r\n.

For lines within the header or the body the normal line terminator is \r\n

You can use a different line terminator in the body from the server if you are writing server code but not for the header.

In fact you can use anything in the body that you want even raw binary.

The only thing you can't use in a header is \r\n\r\n obviously as it would per-maturely terminate the header.

OK - for HTTP 1.0 or 1.1 (also compatible with HTTP 2.0 servers)

The following is all you need in a request (GET method) -

GET \pathtofile\filename.ext HTTP/1.1

Host: www.mydomain.com

Including line terminators, this looks like -

GET \pathtofile\filename.ext HTTP/1.1\r\n

Host: mydomain.com\r\n\r\n

The response will be a whole lot of lines terminated with \r\n

The last line of the header will be terminated with \r\n\r\n

And the rest of the string is the data you application wants.

The most important line in the response header is like this -

HTTP/1.1 200 OK\r\n

If there is a problem you will get a different status code like

HTTP/1.1 403 Forbidden\r\n

or

HTTP/1.1 404 Not Found\r\n

or one of many others. These are called "HTTP Status Codes".

HTTP 2.0 is just and extension to HTTP 1.1 so HTTP 1.0 or HTTP 1.1 requests to a HTTP 2.0 server will still work exactly the same.

  Are you sure? yes | no

jamesdanielv wrote 10/19/2018 at 20:57 • point

have you ever thought about using bluetooth with mit app inventor.? it runs on android tablets and cellphones. there are also usb to micro usb connectors that allow sending info to serial on Arduino or similar using serial communication.i used it years ago for 3d printer initialization using bluetooth serial. As for programming, it is cumbersome, but easy for beginners to lego block things together. the only issues i had with it is you could not program in features, you had to add each one by snap clicking. for example i wanted to program in 10 different buttons, i had to add each one manually to gui click at a time. 

  Are you sure? yes | no

Similar Projects

Flipper is a portable multi-tool for pentesters and geeks in a toy-like body.
Project Owner Contributor

Flipper Zero— Multi-tool Device for Hackers

pavel-zhovnerPavel Zhovner

Heavily inspired by the Pi-Hole, this project aims to bring network wide ad-blocking to the ESP32
Project Owner Contributor

Esper: ad-blocking with the ESP32

zacharymorrzacharymorr

One mans quest to spend less time in the basement
Project Owner Contributor

Monitoring washing machines

lars-knudsenLars Knudsen

USB-less WiFi for the PiZero (and others)
Project Owner Contributor

Yet Another (PiZero) Wi-Fi 'Hat'

jarocksjarocks

Does this project spark your interest?

Become a member to follow this project and never miss any updates

Going up?

About Us Contact Hackaday.io Give Feedback Terms of Use Privacy Policy Hackaday API

© 2024 Hackaday

Yes, delete it Cancel

Report project as inappropriate

You are about to report the project "Hacking Cellphones Overview Project", please tell us the reason.

Send message

Your application has been submitted.

Remove Member

Are you sure you want to remove yourself as a member for this project?

Project owner will be notified upon removal.