Experience of using GSM module in home automation
It is cold at the dacha, and you want to turn on the heater a few hours before your arrival there, or you are worried about the possibility of an emergency shutdown of the heating system of a country house in your absence. All these problems can be solved with the help of a GSM module that can send and receive SMS messages and respond to them by turning off the required load. In theory, everything is simple, in practice, there are many pitfalls in the way of implementing such a device.
My plan was to create a simple and cheap device equipped with two temperature sensors, a humidity sensor, a GSM module, as well as a solid-state relay and a socket for connecting the load. What happened in the end, you can see in the photo. The climate sensor BME280 was selected as a temperature and humidity sensor, its pressure channel is not used. In the photo you can see it under the transparent cap to the left of the main module. This arrangement reduces the effect of heat generation inside the housing on the sensor reading. The cap uses a Chinese plastic tube with two holes for ventilation. The second temperature sensor remote, made on the DS18B20. It is located inside the metal probe, and is connected to the case with a cable through a normal audio jack for headphones. The probe is designed to measure the temperature of the heating system itself. The main volume of the case is occupied by a solid-state relay (I chose more powerful) and a 220V to 5V converter for powering the circuit. The socket for connecting the load is mounted on the back of the case, it is not visible in the photo. OLED display based on the controller SH1106 displays the sensors, and also shows whether the load is turned on. To control the entire system, use the Arduino Pro Mini module in version 3.3V 8 MHz. I'm not a big fan of this platform, but the abundance of libraries, including those carefully thought out by the author, makes it the best choice when you need to quickly do something simple.
The SIM800L GSM module is housed in a separate metal case to reduce its interference to the rest of the circuit. As practice has shown, the interference from this is not greatly reduced. And they are radically reduced by the remote antenna connected by a shielded cable to the coaxial connector, in the photo above it is in the foreground. But we will talk about this in more detail later.
')
About the use of GSM modules, many articles have been written, including on the Habré, so I will avoid repetitions and tell you what I didn’t meet in publications on this topic, namely how to make a reliably working device based on this module.
In the garages, where I often go, I recently put a barrier at the entrance, which opens if I call a certain number. Apparently, it is made on a similar GSM module. I was surprised how difficult it is to call this number so that it opens. Now I know a lot of reasons for this. This knowledge cost me several months of experiments and an impressive amount of money spent on them. I hope that now this knowledge will serve someone else. Consider what is important to pay attention, moving from obvious hardware problems to less obvious software.
It seemed to me obvious that the SIM card is inserted into a beveled corner forward. For a week I tried to understand why the module does not want to register on the network, simultaneously learning the commands in the terminal. As a result, at some English-speaking forum, I found mention of the fact that you need to insert it with a beveled corner back. It is strange that it is generally inserted in this and that way.
The power requirements of the GSM module are quite specific. It is based on a chip designed for push-button mobile phones and is powered directly from a lithium battery. Therefore, 5V is a lot for it, and 3.3V is not enough. In addition, in the transmission mode at maximum power, it is able to consume current up to 2A. If the power supply is not able to provide the desired current, the GSM module can reboot when trying to register to the network and continue to reboot in an infinite loop. Periods of peak consumption usually last less than a second, so there is a temptation to use a low-current stabilizer with energy storage for periods of peak load. As such a drive you can use a lithium battery. At the same time, it is important to ensure the possibility of its disconnection and it is important not to forget to use it, otherwise disconnecting the device from the network will result in a deep discharge of the battery and its irreversible damage. Another option is to put an ionistor (supercapacitor) instead of a battery. He is not afraid of a deep discharge. But he also has problems with reliability. One cell of an ionistor is usually designed for voltages from 2.5 to 3V. Ionistors, designed for more voltage, consist of several cells (usually 2). In this case, however, the voltage imbalance on the cells may result in the breakdown of the cell. This imbalance is easy to obtain due to the difference in the capacitance of the cells or the difference in leakage current. You should also take into account the parameter of the internal resistance of the ionistor. Ionistors with high internal resistance at high currents are useless, and ionistors with low resistance are no cheaper than a battery. After my ionistor died suddenly due to an imbalance of cells, I simply applied a 220V to 5V converter of sufficient power. In order to lower the voltage to the required GSM module, I put a conventional silicon diode between the converter and the module. On such a diode, it usually drops to 0.7V, so the module gets the necessary 4.3V. After the diode it is useful to put a large-capacity electrolytic capacitor. It will smooth out voltage dips when the transmitter is suddenly turned on.
Even after I provided the required power supply to the GSM module, the reset symptom periodically appeared, but this time the Arduino rebooted. Observing her food with an oscilloscope showed that there was nothing to eat there. Apparently the interference was caused by the transmitter of the module, since the problem arose more often than the conditions of reception of the base station signal were worse. Such a radical effect of interference from the transmitting antenna is quite understandable if we recall that the transmitter of the module is capable of delivering 2 watts to the antenna. Such power can boil a milliliter of water in 5 minutes or heat your ear by a few degrees. Various methods have been tried to combat this problem. First, I connected an external antenna, which was located outside the case and connected to the module with a short coaxial cable. However, it did not give the expected effect. Then I placed the module in a separate metal case, to which the antenna was attached to the outside. It became better, but not much. Radically improved the situation only the removal of the antenna at some distance from the device due to its connection with a coaxial cable of sufficient length.
Why this happens is easy to understand from physical considerations. A typical antenna is a 'quarter-wave pin', i.e. a half from a dipole antenna. But to create an electric field, the halves of the dipole are not enough, the second half is needed, then an electric field will arise between the negative and positively charged elements of the antenna. In the right whip antenna, the second half is either the ground surface, or the instrument body, or special conductive counterweights. But for marketers, all this is too complicated, so we usually sell only half of the normal antenna. How does it work? Very simple - the second half is the cable that connects the antenna. The fact that it is screened does not change anything. The outer surface of its braid plays the role of the second half of the dipole antenna. In this case, the interference is easily induced on the wires passing in the neighborhood, despite the fact that the cable would appear to be shielded. Well, if there is no cable, for example, we hid the module in a metal screen from which the antenna sticks out? If the screen is large (compared to the wavelength), then it works like the second half of the radiator, and if it is small, then other wires that are connected to this module are emitted, it doesn’t matter which ones. The following figure illustrates the above (the pros and cons are shown for clarity, in reality, the charge of the antenna elements changes sign with the carrier frequency).
The 'correct' antenna is shown on the left, its supply cable does not emit interference. The middle picture shows the antenna you usually buy. Here the supply cable is part of the radiator and interferes with the wires passing nearby. The right shows the situation when the signal source is hidden in a compact, shielded case. Here, any wires connected to such an enclosure are part of the radiator.
The moral is that the only reliable way to protect against interference from a transmitting antenna is to carry it away from the rest of the electronics by connecting it with a coaxial cable of sufficient length. How long is enough? The distance is naturally commensurate with the wavelength, in this case it is a maximum of 30 cm. This is the minimum distance to which the antenna should be attributed, but the farther the better.
In simple AVR microcontrollers, which everyone normally uses, the hardware serial port is only one, and it is used to load the program. Therefore, software implementation of the serial port is a very popular solution. I am going to prove a statement that many people would find unexpected, - the software implementation of the serial port is not suitable for controlling the GSM module.
The essence of the problem is that the software implementation of the serial port prohibits interruptions for the duration of the transmission or reception of the next character. It would seem that in this bad, so many do. For example, the implementation of the 1-Wire protocol for reading Dallas Semiconductor thermometers also prohibits interruptions for the transmission time of one bit, that is, for 65 microseconds. This is of course not very good either. If there are other interrupt handlers in the system, they will not be able to provide an interrupt response time less than these 65 microseconds. If the interrupt request arrives when they are denied, it will be processed only after the interrupts are allowed again. For example, a hardware serial port uses interrupts to put another received character in the receiver's buffer. If the next character comes, until the interrupt from the previous one is processed, it will be lost. This means that the hardware serial port will not be able to operate at a speed of more than 115200 bps. In the case of software implementation of the serial port is getting worse. For its operation, it is necessary that the response time to an interrupt be less than the transmission time of one bit. This limits us to 9600 bits per second.
A more serious problem is that the software implementation of the serial port itself prohibits interrupts. Moreover, the time for which it prohibits them (the time of transmission or reception of one character) is always about 10 times longer than the maximum interrupt processing time required for the correct operation of the receiver of the same software serial port. That is, it always interferes with itself to such an extent that it cannot simultaneously receive and send data. Of course, in most cases this is not required. In most, but not in our case with the GSM module. He may unexpectedly for us, on his own initiative, begin to transmit data (for example, when receiving an SMS message). And in the case of a software implementation of a serial port, this can easily lead to a failure of the exchange protocol with the module. Therefore, I just used the same hardware serial port for both Arduino programming and for communicating with the GSM module. Uncomfortable of course, but this is the only way to make a reliable device.
An asynchronous protocol is a protocol in which one side of an exchange can begin to transmit information unexpectedly to the other side, that is, without any synchronization with its messages. This is the exchange protocol with the GSM module. He regularly responds to requests from the Arduino, but may begin to transmit something of his own, for example, to report on a received SMS message. And this creates a real problem, since none of the libraries I know to work with the module under the Arduino asynchrony of the protocol does not take into account at all. Imagine that Arduino sent a command to a module, and at that very moment the module transmitted information about a received SMS message. This information will be accepted instead of a response to the command. As a result, as a response to the command, the library will return an error (at best, at worst everything will 'hang'), and the message about the received SMS will be lost.
It's easy to fix - you just need to write your own, asynchronous protocol handler. An asynchronous handler makes only the minimum necessary requirements for the module responses to its commands. For each command, the module eventually responds with either OK or ERROR. And this is all that is needed in order to fix the answer. All other lines that come from the module are processed regardless of whether they came in response to a command or by themselves. The meaning of these lines can always be determined by their beginning. If the line starts with + CSQ, then it contains signal quality information. If it starts with + CMT, then this is information about the received SMS, and it contains the sender's address. The first line is sent as part of the response to the AT + CSQ command, the auto module is sent on its own initiative, but for us this difference is absolutely insignificant. The module sends the received SMS messages directly to the serial port. This avoids reading them from memory and subsequent deletion. In order for us to recognize SMS messages in the general message flow from the module, they must begin with the # character, otherwise the message is ignored.
The library created by the author, which implements the above approach, is here .
To get strings that start with a specific sequence of characters, the client creates a special object - a trap. He can create any number of such traps. Lines from the module, other than OK, ERROR, which did not fall into any of the traps, are simply ignored. Since such an architecture does not require a complete analysis of module responses to many different types of commands, the library code is several times more compact than any of the libraries I know.
The result was a device that works reliably in a zone with weak coverage, even better than the average telephone. Below is its complete diagram.
For those interested, a link to the githab is where you will find the source code of the project and a description of the commands that can be sent to the device in SMS messages.
github.com/olegv142/GsmMon
My plan was to create a simple and cheap device equipped with two temperature sensors, a humidity sensor, a GSM module, as well as a solid-state relay and a socket for connecting the load. What happened in the end, you can see in the photo. The climate sensor BME280 was selected as a temperature and humidity sensor, its pressure channel is not used. In the photo you can see it under the transparent cap to the left of the main module. This arrangement reduces the effect of heat generation inside the housing on the sensor reading. The cap uses a Chinese plastic tube with two holes for ventilation. The second temperature sensor remote, made on the DS18B20. It is located inside the metal probe, and is connected to the case with a cable through a normal audio jack for headphones. The probe is designed to measure the temperature of the heating system itself. The main volume of the case is occupied by a solid-state relay (I chose more powerful) and a 220V to 5V converter for powering the circuit. The socket for connecting the load is mounted on the back of the case, it is not visible in the photo. OLED display based on the controller SH1106 displays the sensors, and also shows whether the load is turned on. To control the entire system, use the Arduino Pro Mini module in version 3.3V 8 MHz. I'm not a big fan of this platform, but the abundance of libraries, including those carefully thought out by the author, makes it the best choice when you need to quickly do something simple.
The SIM800L GSM module is housed in a separate metal case to reduce its interference to the rest of the circuit. As practice has shown, the interference from this is not greatly reduced. And they are radically reduced by the remote antenna connected by a shielded cable to the coaxial connector, in the photo above it is in the foreground. But we will talk about this in more detail later.
')
About the use of GSM modules, many articles have been written, including on the Habré, so I will avoid repetitions and tell you what I didn’t meet in publications on this topic, namely how to make a reliably working device based on this module.
In the garages, where I often go, I recently put a barrier at the entrance, which opens if I call a certain number. Apparently, it is made on a similar GSM module. I was surprised how difficult it is to call this number so that it opens. Now I know a lot of reasons for this. This knowledge cost me several months of experiments and an impressive amount of money spent on them. I hope that now this knowledge will serve someone else. Consider what is important to pay attention, moving from obvious hardware problems to less obvious software.
The first thing that is important to do right is insert a SIM card.
It seemed to me obvious that the SIM card is inserted into a beveled corner forward. For a week I tried to understand why the module does not want to register on the network, simultaneously learning the commands in the terminal. As a result, at some English-speaking forum, I found mention of the fact that you need to insert it with a beveled corner back. It is strange that it is generally inserted in this and that way.
To work well, you need to eat well.
The power requirements of the GSM module are quite specific. It is based on a chip designed for push-button mobile phones and is powered directly from a lithium battery. Therefore, 5V is a lot for it, and 3.3V is not enough. In addition, in the transmission mode at maximum power, it is able to consume current up to 2A. If the power supply is not able to provide the desired current, the GSM module can reboot when trying to register to the network and continue to reboot in an infinite loop. Periods of peak consumption usually last less than a second, so there is a temptation to use a low-current stabilizer with energy storage for periods of peak load. As such a drive you can use a lithium battery. At the same time, it is important to ensure the possibility of its disconnection and it is important not to forget to use it, otherwise disconnecting the device from the network will result in a deep discharge of the battery and its irreversible damage. Another option is to put an ionistor (supercapacitor) instead of a battery. He is not afraid of a deep discharge. But he also has problems with reliability. One cell of an ionistor is usually designed for voltages from 2.5 to 3V. Ionistors, designed for more voltage, consist of several cells (usually 2). In this case, however, the voltage imbalance on the cells may result in the breakdown of the cell. This imbalance is easy to obtain due to the difference in the capacitance of the cells or the difference in leakage current. You should also take into account the parameter of the internal resistance of the ionistor. Ionistors with high internal resistance at high currents are useless, and ionistors with low resistance are no cheaper than a battery. After my ionistor died suddenly due to an imbalance of cells, I simply applied a 220V to 5V converter of sufficient power. In order to lower the voltage to the required GSM module, I put a conventional silicon diode between the converter and the module. On such a diode, it usually drops to 0.7V, so the module gets the necessary 4.3V. After the diode it is useful to put a large-capacity electrolytic capacitor. It will smooth out voltage dips when the transmitter is suddenly turned on.
From the transmitting antenna it is better to stay away
Even after I provided the required power supply to the GSM module, the reset symptom periodically appeared, but this time the Arduino rebooted. Observing her food with an oscilloscope showed that there was nothing to eat there. Apparently the interference was caused by the transmitter of the module, since the problem arose more often than the conditions of reception of the base station signal were worse. Such a radical effect of interference from the transmitting antenna is quite understandable if we recall that the transmitter of the module is capable of delivering 2 watts to the antenna. Such power can boil a milliliter of water in 5 minutes or heat your ear by a few degrees. Various methods have been tried to combat this problem. First, I connected an external antenna, which was located outside the case and connected to the module with a short coaxial cable. However, it did not give the expected effect. Then I placed the module in a separate metal case, to which the antenna was attached to the outside. It became better, but not much. Radically improved the situation only the removal of the antenna at some distance from the device due to its connection with a coaxial cable of sufficient length.
Why this happens is easy to understand from physical considerations. A typical antenna is a 'quarter-wave pin', i.e. a half from a dipole antenna. But to create an electric field, the halves of the dipole are not enough, the second half is needed, then an electric field will arise between the negative and positively charged elements of the antenna. In the right whip antenna, the second half is either the ground surface, or the instrument body, or special conductive counterweights. But for marketers, all this is too complicated, so we usually sell only half of the normal antenna. How does it work? Very simple - the second half is the cable that connects the antenna. The fact that it is screened does not change anything. The outer surface of its braid plays the role of the second half of the dipole antenna. In this case, the interference is easily induced on the wires passing in the neighborhood, despite the fact that the cable would appear to be shielded. Well, if there is no cable, for example, we hid the module in a metal screen from which the antenna sticks out? If the screen is large (compared to the wavelength), then it works like the second half of the radiator, and if it is small, then other wires that are connected to this module are emitted, it doesn’t matter which ones. The following figure illustrates the above (the pros and cons are shown for clarity, in reality, the charge of the antenna elements changes sign with the carrier frequency).
The 'correct' antenna is shown on the left, its supply cable does not emit interference. The middle picture shows the antenna you usually buy. Here the supply cable is part of the radiator and interferes with the wires passing nearby. The right shows the situation when the signal source is hidden in a compact, shielded case. Here, any wires connected to such an enclosure are part of the radiator.
The moral is that the only reliable way to protect against interference from a transmitting antenna is to carry it away from the rest of the electronics by connecting it with a coaxial cable of sufficient length. How long is enough? The distance is naturally commensurate with the wavelength, in this case it is a maximum of 30 cm. This is the minimum distance to which the antenna should be attributed, but the farther the better.
Not all serial ports are equally useful.
In simple AVR microcontrollers, which everyone normally uses, the hardware serial port is only one, and it is used to load the program. Therefore, software implementation of the serial port is a very popular solution. I am going to prove a statement that many people would find unexpected, - the software implementation of the serial port is not suitable for controlling the GSM module.
The essence of the problem is that the software implementation of the serial port prohibits interruptions for the duration of the transmission or reception of the next character. It would seem that in this bad, so many do. For example, the implementation of the 1-Wire protocol for reading Dallas Semiconductor thermometers also prohibits interruptions for the transmission time of one bit, that is, for 65 microseconds. This is of course not very good either. If there are other interrupt handlers in the system, they will not be able to provide an interrupt response time less than these 65 microseconds. If the interrupt request arrives when they are denied, it will be processed only after the interrupts are allowed again. For example, a hardware serial port uses interrupts to put another received character in the receiver's buffer. If the next character comes, until the interrupt from the previous one is processed, it will be lost. This means that the hardware serial port will not be able to operate at a speed of more than 115200 bps. In the case of software implementation of the serial port is getting worse. For its operation, it is necessary that the response time to an interrupt be less than the transmission time of one bit. This limits us to 9600 bits per second.
A more serious problem is that the software implementation of the serial port itself prohibits interrupts. Moreover, the time for which it prohibits them (the time of transmission or reception of one character) is always about 10 times longer than the maximum interrupt processing time required for the correct operation of the receiver of the same software serial port. That is, it always interferes with itself to such an extent that it cannot simultaneously receive and send data. Of course, in most cases this is not required. In most, but not in our case with the GSM module. He may unexpectedly for us, on his own initiative, begin to transmit data (for example, when receiving an SMS message). And in the case of a software implementation of a serial port, this can easily lead to a failure of the exchange protocol with the module. Therefore, I just used the same hardware serial port for both Arduino programming and for communicating with the GSM module. Uncomfortable of course, but this is the only way to make a reliable device.
Asynchronous protocol - asynchronous handler
An asynchronous protocol is a protocol in which one side of an exchange can begin to transmit information unexpectedly to the other side, that is, without any synchronization with its messages. This is the exchange protocol with the GSM module. He regularly responds to requests from the Arduino, but may begin to transmit something of his own, for example, to report on a received SMS message. And this creates a real problem, since none of the libraries I know to work with the module under the Arduino asynchrony of the protocol does not take into account at all. Imagine that Arduino sent a command to a module, and at that very moment the module transmitted information about a received SMS message. This information will be accepted instead of a response to the command. As a result, as a response to the command, the library will return an error (at best, at worst everything will 'hang'), and the message about the received SMS will be lost.
It's easy to fix - you just need to write your own, asynchronous protocol handler. An asynchronous handler makes only the minimum necessary requirements for the module responses to its commands. For each command, the module eventually responds with either OK or ERROR. And this is all that is needed in order to fix the answer. All other lines that come from the module are processed regardless of whether they came in response to a command or by themselves. The meaning of these lines can always be determined by their beginning. If the line starts with + CSQ, then it contains signal quality information. If it starts with + CMT, then this is information about the received SMS, and it contains the sender's address. The first line is sent as part of the response to the AT + CSQ command, the auto module is sent on its own initiative, but for us this difference is absolutely insignificant. The module sends the received SMS messages directly to the serial port. This avoids reading them from memory and subsequent deletion. In order for us to recognize SMS messages in the general message flow from the module, they must begin with the # character, otherwise the message is ignored.
The library created by the author, which implements the above approach, is here .
To get strings that start with a specific sequence of characters, the client creates a special object - a trap. He can create any number of such traps. Lines from the module, other than OK, ERROR, which did not fall into any of the traps, are simply ignored. Since such an architecture does not require a complete analysis of module responses to many different types of commands, the library code is several times more compact than any of the libraries I know.
What is the result?
The result was a device that works reliably in a zone with weak coverage, even better than the average telephone. Below is its complete diagram.
For those interested, a link to the githab is where you will find the source code of the project and a description of the commands that can be sent to the device in SMS messages.
github.com/olegv142/GsmMon
Source: https://habr.com/ru/post/460745/
All Articles