Notes IoT provider. LoRaWAN and RS-485

Hello, dear lovers of the Internet of Things. I continue my series of articles.

So, we have learned to work with a pulse output of counters and have mastered encryption. What is the next step? The answer is obvious. RS-485.

A little bit of theory. RS-485 (Recommended Standard) is an asynchronous physical layer interface. Received huge popularity in the Industrial Internet, beginning from housing and communal services and finishing with various plants and the enterprises.

In principle, almost any meter that wants to transmit not one, but several parameters to us will most likely be supplied with RS-485. Less commonly, RS-232 or M-Bus, but for the time being we will leave them aside and analyze the most illustrative example. More precisely, the problems in working with him.

Speed ​​problem

RS-485 is a wired standard. LoRa - wireless. It is logical that there should be some device that can make them friends.

That's right. Almost every manufacturer of the endings in the line has a radio module with RS-485 support. Works on the principle of a transparent channel. All packages that go over the wire are packaged as payloads of LoRaWAN packets and are being transmitted. Or accepted and converted into electrical impulses.

And here is the first problem. RS-485 is a very fast interface. Packages on it go at speeds of several kilobits / sec or even several dozen. For example, one of the typical Modbus speeds is 9.6 kbps.

LoRa, even with the best SF = 7 (125 kHz, 4/5), will squeeze 5.5 kbit / s. With higher SF will be even less.

This means that a survey of the values ​​of an electric meter will take not seconds, or even tens of seconds. The score will go on for minutes. And this is with a properly adjusted waiting time. If you leave the default settings, then your survey is likely to end with a timeout error. I am silent about the restrictions on the length of LoRaWAN packages. There is just trouble.

Polling problem

With pulse outputs, everything is simple. We count the pulses, multiply them by the price of division and get the meter readings. Any simple interface can handle this. And such an interface, in addition to simplicity, will also be universal.

With RS-485 everything is much worse. Surprisingly, many do not understand one important thing.
RS-485 is NOT a PROTOCOL EXCHANGE! He does not specify the format of the packages that run within him. In essence, it’s just a transmission medium. Only the electrical and temporal characteristics of the interface are specified. Everything! Everything above should be disassembled separately.

And there is something to disassemble! On top of our environment, each manufacturer can wind what your heart desires. Well, or what was convenient to him personally. For example, VKT-7 heat meter will communicate with us through ModBus. And Energomera - through GOST R IEC 61107-2001.

These are all protocols that are superimposed on the medium above and have a higher level. Each protocol has its own frame composition, requires its own teams to perform certain actions, provides for a different storage (and therefore polling) of values. Therefore, each device requires its own polling script. Moreover, even within the framework of one protocol (the same ModBus), this script will differ from device to device.

The protocols themselves are not secret and, for the most part, open. Moreover, the site of each manufacturer often contains a free utility with which you can query devices. But these utilities are not universal and sharpened by a single manufacturer. And we remember that we almost always have a zoo of devices. And putting several programs on the computer to the client at the same time ... well, this is not very convenient.

Exit two. Or write something of their own. Or take a program that has already compiled scripts for polling the most popular devices. There are a lot of ready-made solutions on the market, say “LERS-accounting” or “YaEnergetik”. But they are paid and cost good money. As the development of its software.

In addition, if we are talking about Industrial Internet (that is, going beyond utilities), ready-made universal solutions will no longer help you. How to be?

No

If you still plan on polling through LoRa via a transparent channel, you will still end up with speed limits and timeouts. Maybe not immediately and not with the first device, but it will happen.

Standard problem

Besides all the troubles, we have one more. Because RS-485 implies that we can turn to the device at any time, the LoRa radio module with its support should be class C. That is, always listen to the broadcast and be ready to respond.

Let me remind you that class C does not imply battery power, but then the trouble is not so serious. Usually, RS-485 is where external power can be obtained.

Worse is another.

By law, we can work in two frequency bands. Remember the limit is 864-865 MHz? Not more than 0.1% of the time on the air? This means that each separately taken device can be on the air, for example, no longer than 3.6 seconds per hour. But during this time, at SF = 12, we will not even get three packages.

You can try to get the most out of the channels 868.7-869.2. However, another limitation of the regional standards of the LoRaWAN specification comes into force - no more than 1 percent of the time on air for each terminal device (duty cycle). OK, it's easier, 36 seconds. But I’m still not really confusing.

At some point, we can say - oh their, these nonsense! I will sit on the air as long as necessary! But here appears:

Air Capacity Problem

LoRa knowingly exchanges short and infrequent packages. In fact, around this is built the whole standard. It is necessary that each device takes as little time as possible on the air. Then we will reduce the risk of collisions and will be able to achieve that fantastic density of several thousand radimodules per BS. What will happen if one radio module scribbles packets like a machine gun? Its frequency is busy at the time of transmission. And at the time of the answer all the frequencies are busy at all, since The base station hears nothing when it transmits itself.

Of course, no one has canceled the groundwork to increase capacity. Those. if there are two BSs in the coverage area of ​​one radio module, one will still respond, and the second one can hear some other packet. However, the air is not rubber. If each radio module takes a minute to exchange packets, then per hour we will be able to hang no more than 60 terminal devices per BS, this is subject to the absence of collisions. Very little, especially if we recall that the range of each base station in the city is about 2 km, and maybe more.

So no?

It turns out that our LoRaWAN network is limited only to devices with a pulse output and guard systems, where the fact of drawdown is recorded?

Not.

We just tried to use the concept of Internet People where you can not do it. Agree, we are accustomed to overuse the use of a stable Internet channel. For example, open the video, taking stock in the buffer, and not watch it. Those. traffic will pass, but in fact will not be used.

However, everything is different here. We have little speed, time on the air, too. You need to use it sparingly. What can you think of?

The answer is on the surface. Do not drive a lot of protocol traffic over RS-485 over LoRa.

The survey script can be downloaded to the radio itself. He will interrogate the meter on site with a certain frequency and send us only dry, predetermined values.

This method has two minuses:

• Such a radio module requires certain computational resources. This is not a big problem at the current level of technology development.
• Such a radio module consumes more power. But in the case of a transparent channel, we are forced to use class C, which also does not live on batteries. That is what comes out.

But we get all the information we need in 2-3 packages. And then in one all fits, if you need literally several parameters. After all, it often happens that we do not need to transmit ALL, a rather limited set of values.

A radimodule can transmit data, say, once an hour. And on the server side we will add them to the storage. If you need to access the archive, then the server does not even have to poll the device.

Of course, you need to have some kind of universal radio module, which loads various scripts. And an interface capable of receiving such information. This is not an easy way, but only it meets all the requirements and limitations.

At the moment, more and more manufacturers are coming to this decision. Similar devices are being prepared by Vega, icbcom, ORION M2M and others already have.

Because we use a self-written interface, then we have similar developments. At some point it became clear that if we do not go deeper, we simply cannot work.

In addition to the tricks of saving traffic, we still need a good network in which devices operate at minimum SF and maximum speed. I emphasize - not such a network in which all devices with SF = 7. You still will not achieve this.

Such a network that tends to SF = 7. This means good planning and ADR.

At the output, we obtain sufficient speeds for walking the packets, still a large number of radio modules per BS and the ability to work with interfaces a level above the pulse output. As required.

PS Colleagues, I am grateful to everyone for their feedback. Tell me, what else would you like to know about LoRaWAN or the Internet of Things? Answers can write to me in a personal or in the comments. According to the most interesting or massive requests will be published articles.