I've used modules like this before (including the SIM908, which is like the SIM900, but with GPS too). The biggest pain is that they only support AT commands as a protocol. It's very difficult to work with reliably, especially in a memory-constrained device. Whenever you issue a command, you need to check the next line to see whether it succeeded or failed, but the next line might be the response, or it might be an entirely unrelated unsolicited response (an asynchronous notification). You end up with either a complicated state machine or having to treat every command specially.
Even synchronizing the commands and responses is tricky, because you have to send an 'AT' and wait for an 'OK', or if you didn't get one, send an 'AT' again. Then when you get an 'OK', is it from the first AT or the second one? So you have to spend a second eating all the data comes in before you can start sending commands for real. It's all so... ugh.
I'd love for someone to implement a well-thought-out binary protocol as an alternative.
I see the example code give here just cheats and waits 100ms for each command to happen, then assumes it was successful and moves on to the next.
The problem is that there are very few companies making baseband chips, and to say that they do not care, at all, about hobbyist applications, would be the understatement of the year.
As it turns out, even your smartphone is probably right now talking AT to its baseband processor. If you get one of these mobile surf sticks, it's probably a virtual COM port and the software on your computer is giving AT commands. As horrible as that sounds, it is the standard they use.
I always had this secret hope that the AT interface was a translation layer on top of their sensible protocol (kind of like, say, x86 on top of microcode), and that one day someone would have the bright idea to just expose the underlying one.
Right now I think it just supports SMS and phone calls, but I'm hoping it eventually handles all the AT command nastiness for TCP/UDP connections and such.
One thing you can do is get a microcontroller that does USB host, get a cheapie android phone online, and wire it up that way using ADB.
I wrote a library to let a Parallax Propeller do this (it will be more power hungry than, say, an IOIO board, but it can give your phone 8 serial ports rather than just one). http://obex.parallax.com/object/116
Economies of scale mean that a low end android phone costs about as much as this shield.
I always forget these kind of solutions made possible by cheap phones. The other day someone suggested that a cheap phone is a great alternative to GPS car tracking systems.
So for those who may have seen the BTTN post (100 dollar cell network enabled button) you now know the dirty secret. You are this shield, and arduino and 60c away from building your own.
They just copy/pasted the wiki engine, it's even showing "Wikipedia, the free encyclopedia". Looks like a really bad job. However, the Shield looks really neat and worth it.
Er, what? That page doesn't say "Wikipedia" anywhere on it. It is running Mediawiki, like Wikipedia, but that's free software; it's supposed to be used by other sites!
He's not crazy. On my phone, I see the stock wikipedia template - branding and all (including the globe logo top-left). On desktop, I see the same content but with seeed's theme.
So it looks like a straight rip (on mobile), but more likely someone's just skipped a step or two with the branding.
Even synchronizing the commands and responses is tricky, because you have to send an 'AT' and wait for an 'OK', or if you didn't get one, send an 'AT' again. Then when you get an 'OK', is it from the first AT or the second one? So you have to spend a second eating all the data comes in before you can start sending commands for real. It's all so... ugh.
I'd love for someone to implement a well-thought-out binary protocol as an alternative.
I see the example code give here just cheats and waits 100ms for each command to happen, then assumes it was successful and moves on to the next.