Yes the iOS Tinker app just frozen as well as my own iOS app (Swift). The curl return ‘false’ and ‘timeout’.
This looks really cool. Thank you for posting this. I was planning on implementing my own SMS capability using AT commands. I got stuck on trying to figure out what library the Cellular class can be found. Looking t your code on GitHub I see no includes for a library that reference Cellular.
I can’t get your code to compile since it can’t find “Cellular”. What library are your including? Or how are you able to compile your code without referencing the library in which Cellular is defined?
hi @shiv
With any of the cloud compiler paths, you need to make sure your target is an Electron since Photon etc. don’t have the cellular class.
How are you compiling your code?
1 Like
@bko,
Thank you for the reply. Yes, my target is the Electron. I’m compiling the code online and then downloading the *.bin file and flashing it locally. Of course in this case, I can’t compile. I tried add an include for Cellular.h but that didn’t work either.
If you could use this to wake up the Electron, that would be awesome. I asked that question yesterday so I’m definitely going to be watching your post. Best of luck Krvarma!
[My Post][1]
[1]: Waking up an Electron remotely
1 Like
Hi @shiv
I still think you are not targeting an Electron since nothing else make sense to me. In the web IDE, the device that you are targeting must have the yellow star to left of its name.
I tried the followed test code (non-functional but compiles and based on @krvarma code above) in the web IDE and do not get any compile time errors with zero include files.
Can you try this (cut-and-paste into a new .ino file in the web IDE):
// TEST CODE DO NOT USE
char szPhoneNumber[] = "5551212";
#define MAX_PHONE_NUMBER 14
#define CTRL_Z 0x1A
#define TIMEOUT 10000
int callback(int type, const char* buf, int len, char* param){
Serial.print("Return: ");
Serial.write((const uint8_t*)buf, len);
Serial.println();
return WAIT;
}
void setup() {
}
void loop() {
sendMessage("testing");
}
int sendMessage(char* pMessage){
char szCmd[64];
sprintf(szCmd, "AT+CMGS=\"+%s\",145\r\n", szPhoneNumber);
Serial.print("Sending command ");
Serial.print(szCmd);
Serial.println();
char szReturn[32] = "";
Cellular.command(callback, szReturn, TIMEOUT, "AT+CMGF=1\r\n");
Cellular.command(callback, szReturn, TIMEOUT, szCmd);
Cellular.command(callback, szReturn, TIMEOUT, pMessage);
sprintf(szCmd, "%c", CTRL_Z);
int retVal = Cellular.command(callback, szReturn, TIMEOUT, szCmd);
if(RESP_OK == retVal){
Serial.println("+OK, Message Send");
}
else{
Serial.println("+ERROR, error sending message");
}
return retVal;
}
@bko,
Thanks for persisting! Yes, you’re correct. I didn’t realize that I had to click on the star to make the device “active”. Once I clicked on the star and it turned yellow I realized my error. Thank you!
Ok, I was able to compile and flash my Electron. Changed the szPhone to my cell phone number. At some point I see the “+OK, Message Sent” in my terminal program. But no SMS is received. FYI - I’m not using the Particle provided SIM but another SIM I use for a different device from which I am able send SMS messages.
@shiv, can you look at the serial output for any possible errors after sending the AT command? May be it will provide some clue.
1 Like
hey,
I’m new to electron but farly familiar to ARM and arduinos… I wanted to make some sort of access tool that checks if a CallerID is in a certain list and perform than a certain action…
Can anyone help me figuring out how I can get the caller ID and how to enable a Interrupt that is triggered when a call comes in?
Is there already a similar thread about this? This seems to me to be the best place working out AT commands… 
Is PB12 settable as a Interrupt pin?
Me too! 
1 Like
Here is the serial output
Sending command AT+CMGS="5555555555",145
Return: OK
Return: >
Return:
Return: +CMGS: 8
Return: OK
+OK, Message Sent
I don’t know the protocol well but from whatever reading I have done it looks good. Most other AT commands for SMS don’t require the “,145” at the end. But I’ve not tried without that.
Ok, I sorted the problem out. I didn’t realize I had to put a +1 in front of the phone number. Other service I use don’t require this. Once I put that in, it worked.
Thank you.
2 Likes
I do not know if it will be helpful I found this implementation of receiving SMS for SIM800.
There is an example of receiving a call with ID:
Isn't that sending out tons of sms? or am I missing something here?
If you read the comments, this was just test code to prove to @shiv that it would compile.
As the comment say, do not use this code!
@developer_bt, I am sure about that because Adafruit FONA is connected using Serial and the module sends reply through Serial. I don’t know whether electron sends console outputs, I found one debug build that sends debug outputs. But not sure this is in production, need to check.
the ublox is also connected to a serial. But not the one that is brought out to the pins. The STM32 has about 4 different UART lines…
Anyway I was able to communicate with a stock firmware through the normal UART line… (can’t remember if it was OTG or my FTDI board…)
I issues first
AT+V
AT+VERSION
then a { occurred, I waited a few seconds, then some unformatted output came and a formatted output about the ICCID and IMEI but with blank input… At least it responded…
But due to the fact that nothing was recognized it might be in the blue blink mode… aaah… I hate so many if’s but wanted to share my experience… I’m gonna analyse the cellular.command() on github… maybe this can help us?
The actual naming of the Pin is RI_UC ....Found out that all Names listed on the block schematics like RI_UC RXD_UC are mapped correspondly
So listening to the serial of the ublox ofer another Serial or SoftwareSerial might be possible too! 
2 Likes
When using an SMS enabled SIM, if you send an SMS message to the electron, the RI may not indicate an SMS arrival unless configured to do so. RI will normally indicate an incoming voice call.
The incoming SMS will be received and stored in the SMS list within the modem. You can always poll for new SMS messages if you don’t want to figure out how to configure RI for SMS arrival (or if it’s not possible). You will need a function to read new SMS messages anyway 
For me, to use a non-particle SIM would eliminate the real value of the Electron, it’s connectivity plan. I’ve been using the cell network in embedded projects since the early 90’s, I used Rim and Motorola pager tech before that, and wired modems before that The hardware has never been a problem, it’s always the connectivity cost that kills the project or limits it’s scope/market. $36/year is a whole lot different than $600/year, per device!
Please carry on with your learning, it is well worth the effort! We just added SMS notifications to our systems monitoring at work with a USB GSM stick. Basically the exact same thing you are doing with your electron. I’ll stick with Twillo and the other SMS services so I can keep my $36 plan 
If I wanted to see the modem output, I would simply have my callback that gets the modem response, send it out the normal serial channel before doing it’s response processing.
I hear you about the cost. There are other SIM vendors that are very reasonable (pay as you go, and this landscape will continue to change/improve) and so having the option to send SMS and other call options is key (in the library). After that, folks can decide to use or not use as they choose.
I don’t think having the option to make/receive calls and send/receive SMS diminishes the value of the Electron, in fact on the contrary.