I would like to be able to build an Arduino based system that has the ability to send textual data (via SMS?) to a 'Droid cell phone. The system gathers data from several sensors, computes the results from the data and formats the results in standard text packets (i.e. “hhhhh, ddd, sss, ”). Individual packets would never exceed 30 bytes. The data would need to be sent every 15 or 30 seconds for approximately 10 minutes. Might it be possible to send the all the data in a burst of packets by accumulating them until the end of collection then sending them all?
Is such an application feasible from the communications viewpoint? What sort of hardware would I need to look at for the communications aspects?
Is this compatible with all carriers? I remember reading something about a cell add-on that was only compatible with AT&T or T-Mobile. Can’t remember the details of if it was even in regards to this shield. I need something compatible with Verizon.
victorf:
I would like to be able to build an Arduino based system that has the ability to send textual data (via SMS?) to a 'Droid cell phone. The system gathers data from several sensors, computes the results from the data and formats the results in standard text packets (i.e. “hhhhh, ddd, sss, ”). Individual packets would never exceed 30 bytes. The data would need to be sent every 15 or 30 seconds for approximately 10 minutes. Might it be possible to send the all the data in a burst of packets by accumulating them until the end of collection then sending them all?
Is such an application feasible from the communications viewpoint? What sort of hardware would I need to look at for the communications aspects?
Any enlightenment will be appreciated.
Vic
Seems like it would be simpler and less costly if the Arduino can access the Internet via wired cat5 or WiFi. Then it can send SMS to a dumb phone or SMS/email to a any smart phone. This presumes the Arduino system is not on wheels.
victorf:
I would like to be able to build an Arduino based system that has the ability to send textual data (via SMS?) to a 'Droid cell phone. The system gathers data from several sensors, computes the results from the data and formats the results in standard text packets (i.e. “hhhhh, ddd, sss, ”). Individual packets would never exceed 30 bytes. The data would need to be sent every 15 or 30 seconds for approximately 10 minutes. Might it be possible to send the all the data in a burst of packets by accumulating them until the end of collection then sending them all?
Is such an application feasible from the communications viewpoint? What sort of hardware would I need to look at for the communications aspects?
Any enlightenment will be appreciated.
Vic
Seems like it would be simpler and less costly if the Arduino can access the Internet via wired cat5 or WiFi. Then it can send SMS to a dumb phone or SMS/email to a any smart phone. This presumes the Arduino system is not on wheels.
Is this compatible with all carriers? I remember reading something about a cell add-on that was only compatible with AT&T or T-Mobile. Can’t remember the details of if it was even in regards to this shield. I need something compatible with Verizon.
I don’t own or have used one. I would think it would work with any carrier that uses GSM (or sim cards), but I don’t really have too much info on that… Sorry…
Yep…From what I can tell Verizon is not on GSM. I guess the most economical way to implement this would be to buy an AT&T SIM with prepaid data. If anyone has implemented this shield, what did you find was the most economical way?
stevech:
In the US, Verizon and Sprint are CDMA (IS95B). For data, its 1XRTT on the cheap.
AT&T’s old systems are a mix of GSM and TDMA. For data, its GPRS on the cheap.
GSM No. America is quite different than the rest of the world
Unanswered question: Is the Ardino a mobile device? If not, just hook it to the Internet.
I’ve just started with the Arduino, but yes, the Arduino can be easily made mobile…or stationary. The application I envision involves a GPS sensor and a cell interface. This would be a mobile device with no access to the internet. If the device were within range of a WiFi hot spot, then the WiFly shield should work, although I’m not sure how easy it would be to text to a mobile phone that way. There are web pages that allow you the text so it’s possible.
I’m coming to the conclusion that the cellular shield wasn’t really designed for use in the US. Is it even feasible to try and implement this on the US cell networks?
This thread seems like a random walk unrelated to goals This thread seems like a random walk unrelated to goals
As the OP I must disagree with you. I am looking for a solution to a problem that I have been grappling with for several years. One of the major stumbling blocks is how to communicate data to the deployer of my data collector on a as needed basis. It was suggested that I look into the cellphone solution as they have become almost ubiquitous worldwide. This would allow the user to get data at a time that was his to pick. The solution would need to be applicable to the standard US service providers, Verizon, AT&T and perhaps T-Mobile. I would like a solution that is independent of where the user is in the world, but perhaps this is asking too much.
For all of you that took the time to answer my post, Thank You! If anyone has an idea that might make my idea universal I would be interested about it.
In my profession, I use Cradlepoint CTR500 travel routers with a Verizon EV-DO modem. That connects to Verizon’s excellent US coverage. The router’s ethernet port connects to the sensor management device by cat5.
The router also has WiFi.
But the title of this thread is “talking to a 'droid phone” so some of thought the sensors were immobile and the phone was receiving reports. Hence, the confusion on why the sensor micro needs to be cellular based.
But the title of this thread is “talking to a 'droid phone” so some of thought the sensors were immobile and the phone was receiving reports. Hence, the confusion on why the sensor micro needs to be cellular based.
Perhaps there is a misunderstanding. The sensor is gathering data at some remote location and can be relocated and will not have access to the internet other than via cell phone networks. The consumer of the data would like to query the data collector from time to time throughout the day and get a data dump. Since phone apps for the ‘droid’ phone are relatively easy to develop it was natural for me to say ‘droid’, but it would be desirable that any text enabled cell phone could call the collector. It is doubtful that the range from collector to cell phone would be more than 10 miles or so.
Let’s assume that the sensor data collector can use a cat5 ethernet connection.
Perhaps that can be within 100m of a wired switch/router leading to the Internet for email/SMS.
If this isn’t viable, perhaps a WiFi bridge link up to a mile will work, to reach the Internet.
If the collector and user/observer are a few miles apart and there is no terrain obstruction, then a pair of 900MHz 100mW data radios such as from Digi will work.
None of the above?
Then the simplest way is to connect the sensor processor via cat5 ethernet to a Cradlepoint CTR500 router equipped with a 3G cellular modem.
This isn’t the cheapest way but it is easy. And you pay for a cellular account.
Otherwise, you have the mess of using a module level cellular modem, permitted by then intended cellular carrier, interface protocol running on your sensor collector, blah blah.
A comment on the cell shield page points to this website to purchase a card Bu so far no one is stepping up and saying “Yes it works and here’s how I did it”.
I think a cell interface would be easier, but I see no indication that it actually works. In my application, internet is not an option because the sensors are mobile and need to send a text message when an out-of-range condition occurs. If I can buy a card for around $100/year, that’s a workable solution. I guess I just need to buy one and try it.
http://www.sparkfun.com/products/9607 works fine in the US. AT&T and T-Mobile both use GSM bands, the SM5100B is Quadband, and will work in the US and most everywhere else. It’s capable of making calls, sending texts, and GPRS connectivity. Details on anything other than the very basic pass through sketch provided by SF are sparse, however, there are libraries written for other hardware that can be re-purposed.
http://code.google.com/p/gsm-playground/updates/list is a library written for the GSM Playground, http://www.hwkitchen.com/products/gsm-playground/, but if you replace Serial with Serial1, ensure the library doesn’t change the baud rates, put it on an Arduino Mega, and place jumper wires from Serial1 to pins 2 and 3, most of its functions will work without modification. It does use commands for a telit gsm unit that aren’t compatible with the SM5100B but all you need to do is go through the respective AT command sets and find equivalents.
http://code.google.com/p/sserial2mobile/ is a library written to communicate with cheap go-phone type phones that use a serial connection. Some phones are capable of communicating via the headphone jack. The command set is more limited than hwkitchen’s but it also mostly works.
You will need to provide your own SIM card, T-Mobile will give you one for free if you buy $30 of airtime. $30 will last for many messages, or 3 months, whichever happens first. AT&T has a deal where you pay $1-$2/day that you use the phone, with unlimited usage. So if you only use it for 10 days in the month, you only pay for 10 days.
mikecyber:
You will need to provide your own SIM card, T-Mobile will give you one for free if you buy $30 of airtime. $30 will last for many messages, or 3 months, whichever happens first. AT&T has a deal where you pay $1-$2/day that you use the phone, with unlimited usage. So if you only use it for 10 days in the month, you only pay for 10 days.
The AT&T deal is by far the better choice, as you can use GPRS with your prepaid account. They charge $0.01 per KB. T-Mobile has discontinued this option, in favor of charging $2 per day for “unlimited” internet access, on top of your prepaid amount.