I'm not going to overly explain what is going on as you can all read but the stop and start GSM functions are specific to the GSM2 Click board which is based on the M95 GSM chip. Everything else should hopefully be quite generic.

A few things I know need improving which I would love some help on:

Puppies have probably died due to my poor use of callbacks. I'm not used to them but Gordon had suggested making some changes to utilise chaining.

The Send Command function currently sets a timeout to wait for a response, there are probably much better ways to do this.

The response I define within the Send Command function is given when I do the call, there may be cases where the response received is not the one expected. Once again probably much better ways to do this.

Currently using console.log to view what is going on when I run this code, which assumes you are using USB. Obviously I have to remove this when running on the espruino from battery without USB to laptop which is a bit of a pain. Any better ways to show status? Maybe the Led blinks?

Interesting post. I receive a FONA GSM board from Adafruit tomorrow. So I have been trying to figure out the same thing. I have been studying the npm modem code to try and understand the way to handle callbacks from a AT modem.

I am also trying same test. As well as serial setup I see a few other things that I dont quite understand. Does espruino have a blocking timeout command? when setting c0 high for 2 seconds using digitalPulse does not block I tried using setTimeout(function(){},2000); after digitalPulse, the code continues and sends AT commands before the GSM unit turns on.

I am struggling to understand how the responseCallback routine works.

I am finding it really interesting to read and try to debug code. It gives a much better understanding of the way that Javascript works.

I'm unsure on how the flora GSM board works @user7143 as the c0 high for 2 seconds is specific to the GSM2 click board I am using. It tells the board to turn on/off. This may not need to be the case in your instance (unsure but worth checking).

Fona also requires 2 second high pulse to turn on/off board. I have might not explained correctly but when I run Gordon's code the digitalPulse command does not seem to block. Hence the other AT commands to initialize the board are sent before the GSM board is powered on.

Thinking about his maybe the Send_Command in the start_GSM function needs to be fired from a SetTimeout command that waits for 2 seconds to allow for the GSM board to be powered on. That way the commands are sent and read rather than being lost.

I think most GSM boards are going to have the same command set so once the code is working it will be relevant to a number of GSM boards.

Odd.. Write has been perfect for me. I have some working code now but doesn't really look much like the stuff above. I'm trying to decide how best to receive the send command output and check its content still.

Took another look at the Serial.write cmd. I had the / \ mixed up. Now it seems to work.

On to the issue of reading and processing the send command output. Would a swicth statement in the serial.on("data") make sense?

if I send the command Serial.write("AT+CBC\n\r", 500, "+CBC",function(){}); to check the battery voltage I get +cbc: 0,94,3978 returned from the serial port. With a switch statement I could act on this by parsing the +cbc from the line and comparing it to the expected response from the Serial.write line (+CBC). If these agree I could then return an array for the 0,94,3878, that shows battery % charge left and the battery voltage.

I will try to code this later today if someone agrees this is a good way to proceed.

Typically you will take the response from the on.data, build up a buffer to get a complete command and then check the command to see if it has the required response.

I was part the way implementing that and got confused over how I wanted to go about it. You will see in my original code I had an answer variable which stored the expected response agains the sent command. Note. The answer is not always OK nor is it always the expected answer.

I was hoping to do the check agains the response buffer to see if I got what I wanted in return. If I didnt I would just raise and error and shutdown the module.

There is also the scenario where you have slow response or no initial response. This is why I had the timer implemented into the send command function. This meant that I could repeatedly run the command every few seconds if I didnt get an answer back from the module. There is also the scenario where the command times out, so how long do you want to keep sending a command or waiting for a response until you decide the module is either dead or unresponsive? You can potentially end up in a loop.

As you can see there are a few things to consider and I think I rushed in to it at first without splitting all of the problems down and building out the solution. In my confusion I created quite a mess which I'm now working on to fix. Would be good if you could share your code though might help me get a bit further on my work :)

Will work on the Switch code and share when I have a few minutes free. This should take care of the differing responses based on different commands. A if statement before the switch statement should be able to check the expected response vs actual response.

The Digital.write code that Gordon posted above still does not seem to work correctly. I think rather than using a delay time after the 2 second high turn on code is run, the right way to handle this is to read a pin on the modem that lights up the ready LED to make sure the modem is ready to read commands.

For me the timed sending of commands is enough to get things running and sending texts. I just need to add in my GPS code and I'll have a tracker that can sms coords to twilio. My JS skills arent up to doing anything better.

Now I guess we can do lots with the Parsed responses and I have added in an example of a SMS received which the console will pick up on.

You can add in some error handling and also wait for an OK from an AT send on startup. I think I'll work on the latter next so that I can then kick off the actual SMS sending via callbacks once I'm sure the module is running.

@user7143 I just fixed it for you. You need three backticks before and after the code. The simplest way is to just highlight the code you paste in and click the button that says </> code at the top of the edit window.