Simple SIM800L code (GSM)(read and write SMS)

[Ttelmah]

Yes.
My standard approach is to first identify the chip family by the peripherals
needed, then for development always start with the largest version from
this family. Once the code is working, and optimised, and every extra
feature I can think of has been included, then if the code will fit in a
smaller chip (with at least a 10% margin), specify this for the final product.
Saves a lot of problems...

[Omarfarouk]

Thank you guys for your awesome support, I have made up a simple board to test with the hardware Rx & Tx.

I have only faced a problem where when reading messages sent it does not read the text sent at all and sometimes it reads random text. I am thinking it's a bit slow reading text... maybe too fast ... can't figure it out really. but using software serial still works. So I am defiantly having troubles setting up the hardware Rx/Tx.

All I did with my code was change the pins I am using.

[Ttelmah]

Possibly not...
How are you buffering the RS232?.
If you are using the CCS ex_sisr.c, with this you _must_ use a binary
buffer size (8, 16, 32 bytes etc.), not a size like '14'.

[benoitstjean]

As Ttelmah indicated in an earlier message, go with the biggest PIC you can afford, even if takes-up a bit more realestate.

I started with the PIC24HJ128 and ended-up with the PIC24EP512 (both are same physical size) and I'm at 93% usage because I've added so many options over the years. The EP512 is like 14$ Canadian.

Also, you may want to use a faster speed on the UART.... 9600 is very slow. I use 115200 and the TX data is sent via a DMA channel. You'd be amazed to see what this 14$ PIC can do all at the same time when using DMA and interrupts.

I'm running the PIC using an external oscillator running at 29.4912 MHz overclocked internally at 129.024 MHz and the UART runs at a perfect 115.2 Kbps.

Good luck.

Ben

[Omarfarouk]

I will defiantly have to move to another chips for my projects moving on you are totally correct.

Thank you for the recommendation will look that chip up as well.
and btw I was really inspired with the SIM card codes made up by PrinceNai & Gabriel they should be many times more reliable than mine but I was just trying to figure it out with the simplest possible version I can make up with this tiny chip.

I will try to update this forum as I make up a full version of my code.

thanks
Omar

[Omarfarouk]

I had something in mind that I wanted to add. A timer or a clock, which will start counting after sending a certain message so when the timer is done it can send the message again maybe. So basically I want it to count in the background while checking Rx. After researching, I understand it will be by using something like Timer0 (correct me if I am wrong) but I have never used them and do not understand how to interface with them.

So, if you know how to do so please instruct me how to simply use them and if you have any links to tutorials or so.

[benoitstjean]

I don't know about the SIM800 but since it's a SIMCOM modem, they probably all work the same. So with SMS messages on the SIM5320 (3G) and SIM7600 (LTE), you cannot send more than one SMS or AT command at a time and you cannot use a timer to 'wait' for the responses. You must absolutely wait for the response to the command to be returned. And you must be aware that if the command fails, then an error message may be returned without an OK response. And you must also account for unsollicited result codes (e.g. modem-generated messages without you sending an AT command) and account for unsollicited result codes that are formatted exactly like the result code of an AT command (e.g. AT+CSQ will return +CSQ: value followed by OK but if the modem is configured to auto-CSQ, then randomly the modem will return +CSQ: value without OK). AT+CSQ is to get the signal strength.

For instance, if you send AT, almost immediately it will return OK.

But if you send AT+CMGSO to send an SMS, you must absolutely wait for the +CMGSO response before sending any other AT command (any AT command, not just an SMS). In other words, you cannot do this:

AT+CMGSO [send]
AT [send]
AT+CSQ [send]

You can only do this:

AT+CMGSO [send]
[...wait...]
[...wait...]
[...wait...]
+CMGSO OK -or- ERROR

AT [send]
[...wait...]
OK

AT+CSQ [send]
[...wait...]
OK

Sending more than one AT command before the response will lock-up the modem. This was confirmed to me by SIMCOM Field Application Engineer. You also must check if the command returns ERROR instead of OK. Many of the AT commands will return ERROR if the command failed.

All this to say that you cannot use timers to assume that the commands or SMS messages are sent. The +CMGSO response is the modem's way of telling you that the network has succeeded in sending the SMS to the recipient. This is the equivalent of the progress line on your mobile phone going from left to right on your screen ending with a swoosh sound; if the progress line is not completed, you cannot send another message.

Also, you need to be aware that each command you send and messages you monitor take-up a LOT of space considering the wide range of commands and possible responses.

And lastly, you need to figure a way to keep track of which command you sent because many commands return only OK, others return a '+' response with parameters (e.g. +CMGSO: 125), others will return a word or sentence (ERROR, SIM CARD: UNAVAILABLE) and so on. Therefore, when you send an AT command (any), it may return OK but then you may need to do something when OK is returned for that particular AT command (for instance, do something when OK is returned for AT+VTS but do something else when OK is returned for AT+CNSN).... so you need to figure a way to filter which OK response comes from which AT command so that your code state machine reacts accordingly.

Hope this helps, good luck.

Ben

[PrinceNai]

That one is simple. Create timer interrupt every x ms. Increment a counter inside it every time interrupt fires. When you send a message, reset that counter to 0 and than check if it reached some number you defined before you got a confirmation that SMS was sent. If yes, send again. It does add something to the robustness, but not that much. You might end up sending the message multiple times, but in worst case you could end up stuck in a loop sending commands to modem without realising there is some error present. But to explain counter: lets say 10ms interrupt, you count to 100 for every second. 1000 ten seconds and so on. You just define for how long you want to wait before taking some action and define number against which you will check based on that.