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.
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.