Cellular Modem?

We have been working with a pico and original espruino on a project and I LOVE them. We have used pi, beaglebone, olimex, etc... and so far the espruino is my favorite.

For our project we need to connect to the internet via cellular. I am going to attempt to use the sim900 module with a sim900 board that I have but as you probably are aware 2g is being sunset by AT&T Jan 2017 and the other carriers will probably follow that lead.

Is there a module yet to communicate with a 3g/4g/lte modem? I know the tessle now has support for a usb Huawei E303 3g modem.

This is an area I'm not that sharp in. If we find a serial interfaced 3g modem.... is there a module that would allow us to leverage that modem to connect to the internet?

I was actually looking at these:
https://nimbelink.com/skywire-cellular-m­odem-lte/

They seem to have multiple modems 2g, 3g, 4g, and the one in the link has a TNAG which has fallback from lte all the way back to 2g. My problem is that I have no idea how I would actually communicate with this? Would I just open the serial port and send AT commands or would the sim900 library in theory work for this modem as well?

I think what you'd want to do is make a new module - maybe based on the SIM900 module ( http://www.espruino.com/modules/SIM900.j­s ), depending on how similar the command set is.

If I started to try to do this... is there a page somewhere that explains how to actually build a module and use it?

NVM: I found this: http://www.espruino.com/Writing+Modules

If you're not aware, the IDE has a feature where you can tell it to look for modules in a specific location on your harddrive, instead of having to have it hosted somewhere. I can't find the documentation on the website, but it's one of the settings options (maybe called sandbox? I'm not at a development computer right now to check)

Great! I don't have any non-2G modules I've tested so far I'm afraid. In theory a single AT command set would be shared between devices, but in practice it seems not.

You'd probably stand a fighting chance if you used another SIMCOM module though (SIM5320E?)

Looking at the skywire examples they've come up with their own socket implementation, so the SIM900 module's implementation wouldn't work at all.

But that's not the end of the world at all. Espruino implements the drivers for serial-based network devices in JavaScript, so it's actually not that painful to write your own version at all. For starters, you could look at the ESP8266 module and the SIM900 one.

You're basically just changing commands around, using their AT reference manual as your guide - it looks like as far as TCP/IP goes it's pretty much 1:1 - they've just renamed things. I'd be happy to help out with the changes if I can.

I need some help. I am trying to use the SIM900 right now with a neo aeris sim card. I was able to run the sample after a few tries and actually got the "Hello World" printed from the GET but now I keep getting errors.

Connecting to SIM900 module
Error in 0: ÿÿÿATE0
] "\nOK\r\n" <--- "\nOK\r\n"

What is weird is I am reading that I got "\nOK\r\n" back from the SIM900 modue in the init method... at least that is how i read it. But it looks like the code just compares against "OK" and I see that pattern alot where it compares against what appears to be a cleansed string.

Anybody got any pointers?

Also, what are those weird 'y' chars? I tried to just write a simple trim for the (r) that is used but that of course wont trim those.

Ok... looks like that funky char is charCode 255 which the code does check for but it seems sometimes I get them.. 1 or 2 or 3 in front of the ATEO response... weird.. I'll continue my debugging.

Ok I def need some help. In debugging this I am getting what seems like weird behavior and I can't identify why.

The SIM900 module issues AT commands with a 100ms timeout which is fine because it passes itself as a function and does a stepper pattern where it just keeps checking the response from the AT command and once it gets a good response it steps to the next command etc.

However, what I am seeing is that the SIM900 module does not account for getting 'undefined' back as a result from the AT callback. I am trying to step through that code as well to figure out what is going on. If I make the timeout larger (like 2000ms) for step 1 it will get a good response and move on to step 2. This of course is not ideal ... the current code should work because it just continues to call itself on the same step until it gets one of N number of results.

Here is the output of a session where the step 1 (AT+CPIN?\r\n) was set to a 2000ms timeout on the AT call. If I leave it at the 100ms timeout, I will get an undefined in that step... Really could use some help on this one!

Connecting to SIM900 module
] "ÿ" <--- "ÿ"
] "ÿÿ" <--- "ÿ"
] "ÿÿÿ" <--- "ÿ"
DEBUG: Starting
["ATE0\r\n"
] "ÿÿÿA" <--- "A"
] "ÿÿÿATE0" <--- "TE0"
] "ÿÿÿATE0\r\n\r\n" <--- "\r\n\r\n"
DEBUG:ÿÿÿATE0
] "OK\r\n" <--- "OK\r\n"
DEBUG:OK
["AT+CPIN?\rr\n"
] "\r" <--- "\r"
] "\n+CP" <--- "\n+CP"
] "+CPIN: " <--- "IN: "
] "+CPIN: READ" <--- "READ"
] "+CPIN: READY\r\n\r" <--- "Y\r\n\r"
DEBUG:+CPIN: READY
] "\nOK\r\n" <--- "\nOK\r\n"
DEBUG:OK
["AT+CGATT?\r\n"
DEBUG:undefined
] "\r" <--- "\r"
] "\n+CG" <--- "\n+CG"
] "+CGATT:" <--- "ATT:"
] "+CGATT: 0\r\n" <--- " 0\r\n"
] "\r\nOK\r\n" <--- "\r\nOK\r\n"

This is the output when I run it as it is where the step 1 AT command has a 100ms timeout. Notice how we get the 'undefined' in that step now.

Connecting to SIM900 module
] "ÿ" <--- "ÿ"
DEBUG: Starting
["ATE0\r\n"
] "ÿA" <--- "A"
] "ÿATE0" <--- "TE0"
] "ÿATE0\r\n\r\n" <--- "\r\n\r\n"
DEBUG:ÿATE0
] "OK\r\n" <--- "OK\r\n"
DEBUG:OK
["AT+CPIN?\r\n"
DEBUG:undefined
] "\r" <--- "\r"
] "\n+CP" <--- "\n+CP"
] "+CPIN: " <--- "IN: "
] "+CPIN: READ" <--- "READ"
] "+CPIN: READY\r\n\r" <--- "Y\r\n\r"
] "\nOK\r\n" <--- "\nOK\r\n"

I think the issue is actually in the AT module. Something is broken with its timeout logic. When I increase the timeout to 10s for each AT command in the SIM900 modules init function, it works. Going to dig in more on the AT module to see if I can see why it is passing undefined back to its callback.

The AT module passes undefined back if it times out while waiting for a response. The SIM900 module should really detect that where it can happen and throw an error though.

But... The charCode 255 looks a bit dodgy - could it be:

• that there's some baud rate mismatch on bootup
  
• that there's some bad connection on RX or TX wires
  
• the GSM module isn't sharing the same ground as the Espruino?
  
  

Also, I'm not sure how you're doing it, but is it possible that the GSM module needs a few seconds after power is applied for it to boot up correctly?

To @Gordon's list of things to check: What about the power stability? Some com modules tend to have at some times very high power demands. What is the stability of the power rails / connectivity?

@Gordon - The undefined doesn't seem to be an error condition though. If I increase the timeouts or just return the cb in the SIM900 module so that it takes another round it works. Also, I am giving the module 15 seconds before attempting the initial Serial connection. As for power, this board uses 5V (I have it connected to VBAT with a 5V DC power). It has a continuous draw of 500ma with a 2A spike.

What would be a safe way to proceed? If I increase the timeouts in the SIM900 for the init calls.. is that 'safe' as in reliable or is there something deeper wrong here that I need to wait for resolution on?

This is the board I am testing with: http://wiki.iteadstudio.com/RPI_SIM900_G­SM/GPRS_ADD-ON_V1.0

This wont be our final board as this was just an extra sim900 we had around and are having to plug into the pi connector to get back over to our espruino which is fine for our testing.

Just for some additional info: I have the module connected as described here: http://www.espruino.com/SIM900. Also I am using that sample code as well with some small changes like using 9600 baud vs the 115200 since the wiki page for the pi module says its 9600.

Have you tried it at 115200 just in case? The 255 chars are exactly what you'd expect if the module was trying to transmit something at 115200 initially and you were listening at 9600.

But yes, I don't think there's a problem increasing the timeouts at all - I just looked and a timeout of 100 is insanely short (that's not enough time for the data to get there and back at 9600 baud!).

As it looks like you've already got it to the point where you can hack around with it, please can you increase the timeouts and see how it goes? Maybe when it's working you could send me a pull request?

Looking deeper, that initialisation code works I guess, but it's not how I would have written it :)

When I get a GSM module hooked up I think I'll go over that and translate it into nested callbacks like we tend to do for esp8266

Those extra characters you are seeing seem very similar to the issues I had when I was using GSM modules. The root cause was power. The board needed 5v and also the correct current spikes which I think went up to about 1.4A, ensure your power supply can support this high spike otherwise you will keep getting these messed up chars. Once the power works correctly you often find all the old commands will run through the module also as if they are blocked up so always good to disconnect everything for a few seconds.

...there you go #8: when some RF devices do their calibration, they very lavishly spend power... just for a very brief period, but spiky enough to throw the system off.

Have there been any more developments on the 4G front? I'm really hoping there's a module or device with a common interface, that's ready-made and reliable for cellular modem use.

Personally I haven't used one, but any AT-command-based cellular modem should be pretty trivial to interface to.

Probably if you use a 4G module from SimCom (who make the SIM800/900) it'll 'just work' with the SIM800 Espruino module.