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).
Related
I have been involved in the software industry for many years. I started working on a project as a beginner for connecting multiple sensors and eventually with Android mobile phone. I would like to send some data between sensors and send data to an android phone.
I know that json or xml is used as a data format between distributed applications, but these days json is widely used. But sensor is a little different from an application running on a server, because memory/space/cpu is limited.
Anyway I am wondering if there is any such thing or a certain industry format that is used as a data format to be exchanged between sensors.
I am just thinking of a plain text delimited by a certain character for simplicity which will be parsed in the Android and converted to a Java object.
I'd appreciated if someone who is familiar with this area can post a link or make comment.
If security is a concern, sending data from an arduino may not be the best implementation(they can't deal with any reasonable encryption). If security isn't a problem you could send your data as a GET request like they do on this tutorial.May not be the best way but it works.
Sample request:
/update?key=0000&field1=prettydata&field2=prettydata2"
Sounds a little bit strange to send some data from one sensor to another. Anyway if you are going to send some sensor readings to the android phone from Arduino you have to choose data traffic appliance, i mean use of serial or tcp. In serial arduino translate all raw output directly to a serial port, using tcp arduino can send packets to a some daemon in android phone. May be this link will help a bit https://arduino.stackexchange.com/questions/1167/tcp-communication-between-arduino-client-and-server
Let's say I have an Android device which supports GSM 800/900Mhz bands and I want to use it as a transmitter to remotely control a car or anything else.
Is it possible to program such a thing on Android ? Maybe using NDK ?
The purpose would be to send custom packets on these frequencies.
Thanks.
There are a lot of misunderstandings in this concept, however what you're thinking of quite nice, assuming it would be possible (which isn't :( ).
RF communication is handled EXCLUSIVELY by the modem software, which is included in the baseband binaries.
You cannot simply tap into it, and send whatever you like, since the protocol and its transport layer are very strict to comply with the GSM rules.
Also - since baseband binaries are under strict control there are very few, to none custom ones.
There are also WAY many other reasons why this is not actually possible, without lots of hackish work. Those devices are made strictly to perform on the GSM network. You could use another reciver to for example send WAP push messages (in raw form) as commands, however expect the delays to be HUMONGOUS (ie. 1second - 20 seconds) which is not viable for any kind of remote control. Same results as SMS communcation, just in an unrestricted form.
CAUTION: Using telecom broadband channel is BANNED for public use in most countries, so even if you get an external GSM bands transmitter (which actually can be done), you still would need to comply to your countries regulations.
Possibly related thread: https://electronics.stackexchange.com/questions/94668/longest-range-remote-control
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 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.
Does anyone know how to implement communication between 2 android devices over the internet without using App Engine? For example, I have 2 Android devices, and I want to send a stream of data from one to the second one over the internet. I would like to know, if someone could give me an idea, how could I identify the second device (or how to create a communication channel between two devices ), so I could initiate the transfer (this is not possible using IP addresses ?).If i were to have my own server, which is the best way to go to accomplish this? If someone could point me to some useful resources I would be grateful.I have some background on android programming.
One way I was thinking to accomplish this was to write an android application, and when the user enters it, it will start a service. This service will then listen for network events and registers on my own server with the username and the IP address of the device as available.When another device wants to send data, it will connect to the server, search for the target device (by username key), gets the IP address and sends the data. Could this work, or does anybody have other suggestions?
One way I thought about doing this is making
(excuse the spelling mistakes if any)
It would help if we knew what kind of data you were trying to transfer.
For small bits of information, like notifications, events, and the like, I would suggest doing an HTTP POST to a server that has C2DM capabilities, and using the server as an intermediary.
For larger data, the only way I can think of to do it is to set up a SyncAdapter, then upload the information to the server. The delay will be a bit longer, but you'll reliably get the information downloaded from the server to the phone. So less of a communication API and more of a dropbox for phones.
I haven't done much with NFC, but that may be something you want to look into.