I require a fast reliable method of sending control commands (simple data, possibly only a few dozen possible commands) to a remote system which is using a smartphone* as its onboard computer. I have deemed standard data packages used for mobile internet data transfer as too unreliable of control purposes, however I have noticed that once a voice call is initiated it is much more reliable. Has there been any development into sending data between phones across a connected call, and if not are there any known reasons a modified dialup modem in software form couldn't be used?
Furthermore, could this protocol be robust enough to send back low res video and other simple numeric data?
*Smartphone - A phone with significant processing power and ability to run custom programs (most likely with an Android based OS however am open to suggestions)
Have you tried SMS? while you won't get video data it may work for small chunks of data. Also if the small chunks are from the phone to a server, you may try sending DTMF down the line (however I've yet to see that working.
Other than that it's customised hardware.
Hmmm...this reminds me of those old TV games like Hugo...there you had a voice connection and I think the commands were given by the different tone of the key pressed from 0-9. Maybe you should try something similar.
Related
Context to understand my need: I moved to an area without good cellular data coverage but with good cellular voice coverage.
I want to send small amounts of digital data over voice. Preferably over Android phones.
I was trying a way to connect my phone acting as a dial-up modem, but actually I don't think that is possible to use Android as Dialup/FAX Modem
Anyway I don't need that because I have my own servers and I can configure a PBX to receive calls and translate "voice" (sounds) to digital data and send something in response.
Could be great to use all TCP-IP through voice in my phone, but my question accepts answers that just translate "voice" to small amounts of ASCII bytes (or less than ASCII) that my server could send to internet in a predefined way.
So my idea is to programming something for both (Android and server), but maybe exists another easier way to do it (with or without a PBX) or somebody knows of a ready-made library that I can base my invention on. I'm open to start from some good point.
Extra: Also this "feature" could be used in emergencies. And also is a good idea to encrypt data through voice (that is something that you can't do because GSM encryption is broken).
I'm working on an app to cipher the audio stream sent via a voice call. Not VoIP call, just regular GSM phone call.
I have put together all of the core Android code classes to recreate the whole process of making a phone call but I always hit a dead spot where I can follow no longer.
Essentially, what need to know is: Where does Android manager the data that is being sent through a phone call. I mean were the bytes sent are.
Thanks ahead.
In very (over..) simple terms an Android phones consists of a general purpose processor which runs the Android OS and is similar to a regular 'computer' and dedicated hardware including a 'baseband' processor that handles the Mobile Phone communications.
The interface between the Android world and the GSM/UMTS phone world is tightly defined and the Android side has only limited access to the 'phone' side. This is for security and reliability reasons - e.g. it avoids a 'bad' app being able to take the phone down, which could have very serious consequences in emergency call situations.
The normal interface into the telephony side from Android is:
http://developer.android.com/reference/android/telephony/TelephonyManager.html
I want to know if there is any way to communicate users without internet connection to a server.
I thought it might be possible through SMS and machine-readable encoding. However this question confirms that iOS apps allows sending but not reading SMS: iphone app reading sms
I've also read a lot about using USSD but it seems that mobile opened messages aren't possible in iOS (dial USSD code from iphone programatically) and while in Android is possible to call a code programatically there is no USSD API to, nor it's possible to send USSD messages silently.
Is there any way to transfer data between my app and my server with only basic voice-sms signal?
You are correct that SMS could be used to communicate with the server, if the server has access to a GSM modem. For large volumes of SMSes, you'd expect to have an internet connection between your server and an SMS gateway that connects directly to the messaging centre in the mobile network, instead of a modem.
This is the model of the SMS voting servers.
You can send/receive SMS as long as you have a GSM network, and you're right; no IP connection is needed.
The Android platform lets you send and receive SMSes - see here.
Disadvantages are that SMS can be expensive, and has no guaranteed delivery, and no guaranteed delivery time. It's not suitable for real time communication.
USSD is another form of communication between a mobile device and the network that's built directly into the GSM network, but USSD messages are owned or licenced by the network operators, and aren't free for customers to use, as SMS is.
EDIT: USSD isn't a native protocol in CDMA, but various implementations are available from different operators. For example, here's a patent application describing an idea for one such system, which does not appear to require an IP connection. Googling "USSD CDMA" also gives various news items about commercial implementations, technical details unknown. I think you just have to find out what your target operator(s) offer.
I haven't worked directly with WAP, but a glance at the WAP Protocol Stack shows that it can indeed run over CDMA, or GSM without an IP connection. There is also a very useful Wikipedia article. My experience testing MMS is that it usually doesn't work without an IP connection, even though it is supposed to (according to that Wiki article, with WAP/SMS). So I would question how far European operators or mobile devices are supporting or testing WAP. Whether WAP is a practical choice could come down to pricing/availability at the end of the day, rather than technical issues.
Well, there are yet other options, depending on the amount of data you need to transfer back and forth to the server.
Instead of sms, for short amount of data you could try to implement an Asterisk PBX, whith your mobile calling your server and then sending other DTMF digits as your data, which would be interpreted by your Asterisk PBX (like an interactive phone audio menu from your cable company). Asterisk is GPL open-source.
Another option (an expensive one and with heavy work to do), would be to generate an audio signal encoded with your data content, and dial a phone number linked with an attached fax/modem pci board on a server, sending that audio like a call. It would'nt need to be a long call, as you could fit lots of data in a short bursts of audio stream.
Your server could check that data by acessing the content on the receiving end. Simply recording the call from the attached fax/modem pci board, or you could use an Asterisk PBX server on a local computer to save the audio file and then process by your server software.
Anyway, you would need to create a new protocol and data encoding type, like you mentioned "machine-readable encoding".
So, for the data types you could just save a lot of short audio files on your mobile and play them as your datatypes, but it would be easier to just go for the DTMF already mentioned above. Or you could encode like this: get the sound spectrum allowed to use through the voice call (Wideband/Narrowband), and divide it by the amount of single characters or chunks needed (take a look at how to encode in base64, to have some ideas). Then create a function to just encode your data as a short audio stream (read about PCM encoding and also read more about Fast Fourier transforms, if you want to complicate (but speed up) even further.
Create a simple protocol like this: first audio packet is a sequence of tones that makes a request, authenticates, and waits for acknowledgement response from the server (which could be just by not dropping the call 1 second after that). The 2nd audio packet is the size of the first frame of data, then the 3d audio packet onwards is the data itself with the size shown before. And so on. Have a look at the ftp protocol description for simplicity. Then you need to refine it so that the time of every packet above is the least possible while mantaining confiability.
For costs saving on voice calling, you could also explore phone number options, like Google Voice, Skype or any Voip service.
I am building an app that converts text messages to speech and sends them to the destination. At the other end, the speech is converted back to text messages.
I imagine it may be easy with Twilio but I don't want to use internet connection. A simple call should be enough to transmit the data.
Any idea on how I should proceed with this?
I don't think this is really possible to do, your tasks would be pretty heavy ...
TTS- that's no problem android has a library for that TTS and recording it
Make a phone call and monitor state Make phone call monitor state
Send your synthesized message - can't quite find a way to do this, seems problematic sending recorded messages over phone network it has been suggested that you could play the recording over the speaker and the microphone might pick that up, seems like a good way to introduce even more errors into the system though
On the other end something must answer - Answering a phone call
Record incoming call - this seems to be highly problematic on a non-rooted phone Recording incoming calls? or Recording incoming calls
Take the recording and do reliable STT without the benefit of a server back end, also highly problematic since the translation errors even on high end server apps are sometimes quite comical
So without a rooted phone with a custom rom I don't think all of this is possible even if you could overcome the poor quality of a double translation TTS -> STT
Twillo seems to be about making calls over the net vs. the phones digital network not about sending text (in essence) over a phone connection
Seems like a whole lot of extra work just to avoid an internet connection charge (of about 2 seconds and few bytes!)
I'm currently working on an android project and I am trying to find the best way to go about setting up communication between two android phones.
One android phone will be docked on a mobile platform e.g. an R/C car. I want this phone to receive simple control signals ("forward", "backward", "left", "right", "gotoCoordinate") sent from another android phone. I also want the docked phone to be able to return status signals.
Preferably I want the communication to happen via GPRS. I'm aware of the difficulties concerning P2P-communications and I'm currently looking into "Android Cloud To Device Messaging." (http://code.google.com/android/c2dm/index.html)
I'd like to hear about your experience with Android C2DM (glad to hear about delay from transmit to receive) and your thoughts on utilizing it in my project. I'd appreciate other suggestions on how to go about this. I'm expecting to have to deal with relatively high latency using this method, but of course preferably lowest possible.
C2DM makes no guarantee about the "delivery or order" of the messages, and it is limited in the number of messages you can send (a high limit, but still a limit). It's not really for low-latency stuff like controlling an RC car. It's better for non-realtime events.
http://code.google.com/android/c2dm/
For lower latency stuff using GPRS you can setup a third party server on your own and have both phones communicate through it. I've done that for several Android apps using straight up TCP sockets and it works reasonably well (and it would be even faster/better if you went UDP). Using GPRS may still have too much latency, depending on your needs, but it's a tradeoff (it's very convenient, almost always there, other methods are not).
The ideal way to do this would be to combine whatever is available and fallback gracefully, and test the latency once connected to make sure the network is up to par, or bail out. For example, use the local WiFi network if it's available. That is to say, have both devices "register" with a third party server as they startup, then if they're both on the same WiFi just have them communicate directly (run a server on or both, and clients on one or both, get information about discovery and such from the registration). If they are not on WiFi then fall back to GPRS, but realize there will be more latency, of course. Finally, once any method has been established send some test messages to check latency.
I know this isn't really an "answer," it's more of a stream of consciousness about this, but it wouldn't fit in a comment, and I thought it might help ;).
(Full disclosure: I've worked on Android apps that connect multiple mobile devices and multiple TVs, some over GPRS, some Wifi, some directly. I work for a company (MOVL) that makes a platform for stuff like that, it's more focused on mobile-TV-mobile, but it supports mobile-mobile also. In all it's not too hard to do yourself with regular networking, the tricky part is getting the latency down and picking the correct method for each device.)