views:

719

answers:

7

hi. my apologized right away if it is not really programming related question.

I have a (crazy?) idea of using cellphone voice channel as remote control channel for RC models/drones. in principle if it is doable, it should increase the range a lot. Data data channels on most cell phone companies are more expensive than pure voice channels, moreover many US providers allow unlimited voice communication at night or on weekends. So hacking the voice channel might be cheaper from operational standpoint. Using cellphone on RC models also gives benefit of bidirectional communication, so that the model can transmit back, for example coordinates/occasional images.

The questions are:

  • is it remotely possible? (barring legal issues)
  • which is easier to hack, CDMA or GSM phones?
  • a particular phone model which is amenable to hacking?
  • how much knowledge is required to pull this off?
  • how much money is required to pull this off (IC, micro?)
  • how to go about interfacing to onboard Linux? USB, particular protocol?
  • tutorials, resources which may help?

Thanks a lot.

let me clarify "barring legal issues". I am not interested in using/abusing the channel for any significant length of time, I would do however want to tinker with hardware. EE students do have somewhat autonomous helicopter (i assume it has been cleared), using WiFi which has limited range, however i do not know any local telephone hackers.

by hacking I am meant hardware interface and modulation to carry commands rather than the pure voice over a regular phone call. Hence attraction of free weekends/nights

+1  A: 

It is illegal to fly an RC plane past visual range, so a Line of Sight receiver would work fine for your UAV project.

Edit: Any model RC aircraft, not just a plane, past visual range. Sorry for poor language choice.

Crowe T. Robot
hi, actually did have helicopter in mind. But do not care so much about flying, more interested in trying to pull this off.
aaa
+1  A: 

It sounds to me like you want two phones, one on the ground and one on the UAV. A standard voice call will be placed between them, and the ground controller sends commands to the UAV using modulated signals over the call. This is just me thinking out loud about the project:

First off, we need a hackable phone, perferably cheap and lightweight. The OpenMoko project has a fully open source set of software and hardware, and sounds more or less ideal for this project. Unfortunately you will have to buy the hardware secondhand, on eBay perhaps, for about $150 per handset. Then we get to the output functions of the phone, so we can control the UAV. The only outputs are probably sound and WiFi. Neither seems ideal for controlling the flight functions.

Then we need some kind of mechanism to encode commands over the voice channel. Unfortunately, GSM codec is extremely low quality and also designed to be specifically clear for human voice only. We get either 6.5 or 13 Kbit/s, which is perhaps enough to run a 4800 bps modem scheme over? You're probably not going to be able to get images back from the UAV, and definitely not at anything approaching realtime.

So all in all, this is doable as a cheap, long-range way of sending controls to a UAV, and perhaps getting telemetry data back from it. It will require a decent amount of research into how modems work on Linux and how you can use the voice channel for your raw "bleeps and bloops", and at the end while you may be able to leverage some existing software or protocols you will also have to write a lot of stuff yourself. Getting output from the phone on the plane seems like the hardest task and may need custom hardware.

Coxy
thanks, i did think of Google phone (I aware it is less hacker friendly). The price is a bit high. I thought one of older handsets might have been hacker friendly.
aaa
+1  A: 

What you're trying to do is send data over a cellular voice channel. There are two methods I can think of. First, you can use a modulated audio signal for data transmission. This will require little hacking of the phones themselves (just connecting to the audio signals). This method is unsuitable for high bit rates because the audio data is compressed using a codec (called a vocoder) designed for compressing human speech. You will end up with data transmission rates much lower than the digital bit rate of the channel. The patent here discusses some of the difficulties associated with this method (used by OnStar, I believe).

The second method would require hacking the phone firmware. You would need to replace where the vocoded data gets placed on the channel to feed your own data in instead. On the other end you would have to extract the data from the channel prior to it being decompressed. This will allow you the full bit rate of the channel, but it will likely be complicated to implement.

I'd recommend looking at GSM phones, as GSM implementations are publically available, where CDMA code is mostly proprietary, thanks to the Qualcomm monopoly.

Splat
+5  A: 

I think a standard RC PWM signal would transmit just fine over a voice call, so all you'd need is a transmitter that can output that (most can), a receiver or a device that will demux that onto the servo leads like this and some headset plugs to hook it all together with.

However, before you rush off and do that, you need to know that it won't work. The problem is, cellphone voice has a fairly long latency... long enough that an RC helicopter pilot is not going to be able to control the aircraft through a link with that much. You feel the difference between 40 ms latency and 22 ms, state of the art gear is down around 11 ms. Cell voice latency can be up to about 300 ms, which is just too slow to put in a helicopter's control loop. Using something very stable, like say one of these, which is the standard airplane for this purpose, you'd be OK.

Andrew McGregor
Latency was my first thought as well. Plus, you have to factor in the occasional drop-outs and blips of audible interference that cellular voice calls can have and design a way to recover from them. Cell phones also heavily filter the incoming audio (sometimes crudely) so you would have to make sure that the signal you were transmitting would make it through the audio filters (on both ends) unchanged. In theory it's quite doable, but in practice there are much, much easier ways of doing it.
bta
Especially when you're talking about an aircraft with such insanely sensitive controls... RC helis will do 5 revolutions a second on the yaw axis at full stick, so the phone's latency would be more than a full revolution. WiFi works, I've seen that done, but cellular won't.
Andrew McGregor
A: 

This sounds a lot like a FAX machine, no?

Esteban Araya
+5  A: 

This is definitely doable. Here's a few ideas off the top of my head:

UAV interface:

You need to tap into the phone at 4 points:

  • The earpiece
  • The microphone
  • The ringer
  • The send button

The control station will send encoded commands (simple in nature at first. You might need some good stabilizing AI to compensate for the slow command rate.) through the sound channel. Circuitry on the UAV will be tapping into the two speaker leads on the earpiece. It should be a simple matter to interpret the electrical impulses. This will have to digitalize the signal for the CPU of the UAV.

The UAV will send similar electrical pulses through the microphone leads in much the same way that they are received from the earpiece. Use this for telemetry and pinging.

The UAV will regularly ping the control station to let it know that the connection is still live. If a couple of scheduled pings are missing, the control station will redial the UAV.

The UAV will also be tapping into the ringer to sense incoming calls. When it does, it will short the send button for a while to pick up and restablish the connection. (If the ringer and the earpiece are the same thing then you could device a two-way ping so that the UAV also knows the signal has been lost and thus knows that a ring will be coming)

Further notes:

  • Go simple at first and test on the ground. If it pays off, devise a better encoding scheme for your next prototype (multitonal or whatever you can come up with)
  • This seems legal to me. You're using the channel within its operational parameters and are paying for it too. Its no different than using a modem over any phone connection. (no idea about UAVs and line of sight.)
  • This scheme is simple. You'll need to work on the control station interface but its really not a big deal. I bet you'll be able to use the same digitizer circuitry from the UAV to interface with the parallel port on your computer. No need for complex hacks on the control cellphone, you can even redial manually. Leave automation for the next prototype.

OFCOURSE, you can use a regular modem interface and avoid all this trouble. I'm just saying, if you have two cellphones lying around... why buy anything else? hehehe

I think its sad that people are debating the legality of this (no reason for this to be illegal) instead of helping a guy learn some new things.

EDIT: http://www.sparkfun.com/commerce/product_info.php?products_id=8700 You can try one of these (or something similar) I'm sure they have the features you'll need and then some.

CptAJ
A: 

Use the phone as a modem. It probably already supports this. The hack then comprises using the weird serial port connectors on phones. Older phones did this routinely; chuck a RS232-to-RC converter on and you're done. Add a embedded controller to make it better. I'm not suggesting an ardunio. (Ardunio fanboys will vote me so negative for this, but it's so fashion-driven)

Tim Williscroft