Interview with Hynek Syrovatka from IQRF Alliance and Ivona Spurna.
A nice day to all listeners, today I would like to welcome Hynek Syrovatka, who is, among other things, the technical director of the IQRF Alliance.
Hello.
Hynek, IQRF technology has got further improvements in recent months. Those who are interested have probably heard of beaming, local FRC, and so on. Can you explain these functions, so that even people who have not heard of IQRF yet understand what they are for, what practical applications they are suitable for?
Definitely. I think it can be summed up in one sentence that we have added new communication protocols, that open up possibilities of use of IQRF, IQMESH, in situations where we did not stand completely suitable before. Specifically, it is about asynchronous communication, from some controllers, control devices, to battery sensors with very low power consumption, that transmit measured data in offline mode, and we have prepared a whole set of protocols, thanks to which this data can be obtained from the network.
So maybe I would mention a local FRC first. This is a new protocol that allows us to control things asynchronously from some controllers - you can think of it as a button or a PIR sensor - so that we can control some actuators with this type of IQRF device. You can typically imagine lights when talking about actuators.
A typical scenario is - I have a button behind the door - an IQRF button, I come to it, press it, and the lights in the room light on. Previously, such asynchronous communication could also be done, but not in a completely standard way, and not very efficiently. In terms of both consumption and confirmation of that communication, etc.
And the local FRC is the news. What is special - it is transmitted from the node, from the device. Many of you know FRC and I believe that it is the majority, so you know that it is sent from the coordinator, and it is usually used to download some FRC values from the nodes, from devices. Here it is used a little bit vice versa, it is used in a mode where the device - the node - speaks to other nodes. Ie. the node, the device, the controller, sends the local FRC to some other nodes, these are the lights, the actuators, of course, sends them some user data, which contains a command to do, and the nodes respond back to it with the FRC value, as the coordinator would receive from nodes, and some useful data may be included in this FRC value, but basically it is mainly a way to confirm that those nodes have received the FRC command.
This FRC, in contrast to the usual network FRC, is very fast because it is not routed, it is just for one hop, there is not the aggregation phase we know from a normal FRC, where data is collected from the whole network and routed back to the coordinator. Here it is a very simplified ordinary FRC, where the controller sends a broadcast request to the nearest nodes, that, when heard and addressed, receive the FRC and process it in the Custom Handler, as we know.
Or it can be Embedded FRC, so it doesn't have to be solved in Handler at all. They process it, respond with a value, it happens in the so-called individual phase, the controller gets it, it can do something when some nodes he addressed did not answer for some reason, he can repeat it, ignore it, report a mistake, the options are different, and that's how the work was done. So typically the data to be sent by that FRC command is prepared in that controller, a bitmap of the nodes to be addressed is also prepared there, it is sent, the nodes process it and send back response.
We have simple examples of everything, as you are probably used to. For this, we have an example, a code that has all the parts in it, both the part for the controller and the part for the actuator. In this example, our normal control button and our LEDs for indication are used. Ie. with that controller you control, I guess, the red LEDs on the other nodes, and then with your green LED you indicate that everything was fine and vice versa.
It is very simple, and it is necessary that it cannot be misused so that it does not happen that you will send FRCs to that network, for example, with the command - unbond. In order not to be exploitable, the node must, on the other hand, validate that the local FRC is suitable for processing. I.e. before the local FRC is executed at all, it goes through a verification where it is necessary to explicitly say that it is OK and that it is possible to execute it. And the second thing is that the local FRC must be explicitly enabled in the configuration of those actuators. These two conditions must be met for the local FRC to be used.
I would like to recommend our DPA help, wherein the part where the local FRC is talked about, there is also a video with animation, with an explanation where you can see how it all works and how to use such controls.
Because the local FRC is simplified, much shorter and faster than the ordinary, large FRC, the reaction should be very fast, in such a time interval that is acceptable, for example, for us, for people, where when we click the switch, then we expect the lights to come on almost immediately. For this it is appropriate.
What is also important, the communication is confirmed. I.e. the controller has the possibility to find out if all or possibly which nodes did it and which did not.
There is help for DPA on the iqrf.org website, there is a DPA API prepared - DPA API local FRC. When you look there, everything is explained there, there is also a link to those examples and a video. This is everything about local FRC.
Another useful technology is something we internally call beaming. What is it good for? It is a style of communication where devices, typically sensors, send measured data from time to time, similarly to a lighthouse (that's why beaming), and no longer care about it, if I could simplify it. In this way, it is possible to achieve that such sensors reach a lifetime of 10, 15, even 20 years for relatively common batteries. Even though they will specifically transmit measured values every minute, typically temperature and relative humidity.
It is something we have confirmed, measured. Of course, we have not yet waited 10, 15 years, but we have measured the average consumption of such devices, and assumptions and theoretical calculations show that a device in this mode, measuring such quantities every minute, should operate for 15 years without battery consumption. This device is part of the network, but it is not working at all. It is not necessary. Basically, 99.9% of the time the device is in deep sleep or in sleep, wakes up from time to time, makes some measurements, and sends the measurement results in a simple, standard way, which we have again demonstrated in the example, sends data, the packet is in format according to our IQRF sensory standard.
The question is, what good is it if it just sends it, how it is processed further. These are the next news.
We call beaming the whole set of innovations where we currently support long-life battery sensors. But basically, the beaming is this phase, that the sensor sends the data. In order to receive the data, process it, and then be able to download it, here are other news.
The first is FRC aggregation. It works as follows. The beaming sensor sends data out of it. Maybe once a minute.
Before it sends it, it can do some listen-before-talk test, ie it will test whether there is any radio communication in the immediate neighborhood so that it does not cause a collision, and when it sends it, it goes to sleep again. Something we call an FRC aggregating repeater, a device that can do FRC aggregation, hears this packet.
It receives the packet with the data, stores it in a kind of database, which is typically a larger external RAM memory, it saves the data there for those individual sensors, nodes of whose data it successfully received. Ie. it has them stored (you can imagine that with a larger number of sensors it is already quite a lot of data, therefore the need for external memory). When we want to get the data, typically at the gateway, at the coordinator, it is obtained by a normal, common sensory FRC, as we are used to.
For example, I want to see the temperature value from all the sensors in the network, as I'm used to from the time before beaming existed. I read the values from online sensors using FRC, standard sensor FRC - please, all nodes, send me the measured temperature. The right question is, how can those nodes provide that temperature when they are asleep.
When the temperature they measured was sent by the beaming and someone heard it. The answer is - the so-called FRC aggregation is used. Those devices, typically routing devices in the network, that have received the beaming and have the data in their internal database, can use a new technique called FRC aggregation. They are able to insert the value of the temperature received from the node into the result that returns to the gateway so that the gateway thinks it was sent by the sensor, as it would be online.
Such virtualization.
Yes, it could be said that. The sensor is basically not present in the network at the moment, but because we ask for the value of its temperature, humidity, any standard quantity, whichever, the FRC will provide it, thanks to the aggregation, thanks to the fact that the FRC works on that repeater, the value is caught there. In Custom Handler, as we are used to, it is processed, it is found out, yes, someone wants a standard sensor value, temperature, for these or these nodes… The Handler looks in the database if it has the value in the database for those nodes for which the FRC wants the temperature. If so, it inserts it into the FRC result, and then when all the data is aggregated from all these devices and returns to the coordinator, to the gateway, the data appears there.
So, as you say, this is a kind of virtualization, where the devices, although connected to the network, but not communicating at all in the sense that they don't listen, still in this way provide data via FRC through these two techniques, as we are used to all the time using common FRC.
This FRC aggregation in the next version of DPA will be fully documented. Again, there are 2 examples, one very simple and one a little more complicated, which already works with sensory quantities, and all interested parties who are members of the alliance will be able to equip their routing devices with this feature, so they will be able to work with FRC beaming.
To make it even more efficient, another optimization is possible, namely the fact that if we have only beaming sensors in the network, sensors that are not online at all, then it is possible to completely omit the so-called individual phase. This is the middle phase of a conventional FRC, where individual devices send their data to their surroundings at very narrow time intervals to increase the redundancy of FRC communication.
But because our sensors, from which we want to read the values, do not communicate at all, they sleep, so it is possible to omit this second phase completely. And then it happens that the FRC has only two phases. The first, when the broadcast is sent only to routing devices and then immediately the data collection, no other.
If we have a network in which we have 30 beaming sensors and we have 1, 2 repeaters on that network, then the whole FRC consists only of routing to the two repeaters, that is two hops and then collection, aggregation, 2 hops back. Ie. now it's on 2 + 2 hops. In the past, when those sensors had to actively participate in that FRC, there were another 30 individual slots in the individual phase, which partially slowed down the entire FRC, and during that time there was radio communication that could cause a collision.
This so-called offline FRC is just a normal FRC, as we are used to, but we can omit the individual phase because all the data is prepared in advance in those aggregating repeaters. And I don't have to wait for the individual sensors to send me the measured data individually, because they're asleep.
In reality, this offline FRC on those 30, 60 sensors lasts several hundred milliseconds, compared to even a few seconds with the traditional FRC, where there is no beaming.
So here we have several advantages - a completely radical extension of the life of those battery cells, and at the same time a huge acceleration of the FRC communication.
I have a question that could be interesting for people, how to communicate with such sleeping sensors when I want to update/upgrade them.
This is, of course, a solution for each individual device. The sensors that I have worked with, those from the IQAROS system are sensors that have no control button, however, it is possible to control the sensor with a magnet via a reed contact. The sensor can be woken from the beaming mode to the online mode in a very robust way so that it does not happen by mistake. Ie. then they are in that network, they are also receiving communication. Then you can communicate with them, but it has one big disadvantage. Although in LP mode, the consumption is significantly higher than if they are sleeping and beaming.
And that's why our sensors in the IQAROS system have the feature that they stay in that online mode for a maximum of 2 minutes from the last time someone communicated with them. The sensor can be put into online mode, it is possible to communicate with it, perform some update or change the configuration, but the moment I do not speak with it for 2 minutes, then it immediately jumps to the beaming mode, ie the low power consumption, and in this particular case, measurement and transmission of data once a minute.
Sure, it's just up to the manufacturer to handle it.
Exactly. When someone decides to switch the device to online mode in some other way, such as regularly, etc., why not. In IQAROS, the battery life was important to us, no need to have the device on the network and do something with it, communicate with it. This device then plays a different role, in this case, measuring, transmitting, and lasting a long time. We don't need more.
To sum up, these were three new communication techniques that are behind what we internally refer to in one word as beaming.
Beaming as such involves the transmission of measured data as from a lighthouse.
The second thing is the aggregation of the measured data within the FRC on the routing devices that support the aggregation and are equipped with storage for storing the received, beamed data.
And the third news is the offline FRC, ie the optimized FRC sent from the gateway, from the coordinator, where the individual phase is completely omitted, and therefore it is very fast and very efficient. And then we can afford, without violating the duty-cycle in the sense of the regulation of the telecommunications office, if the sensor sends us data every minute, so we can run the FRC, for example, every two minutes. And we don't have to worry about collisions or breaking regulations in any way.
Are there any other improvements?
I would like to mention our IQRF IDE software, where are a few new features. The first thing is that the IDE alerts me there is a new version, it downloads the installer itself, it reinstalls itself, it runs itself. The second thing I enjoy is that we have very closely linked the IDE with the online help for DPA, with the online help for our standards that we have on the web (sensory, binary output, DALI...).
Today in the IDE, when you enter a command in a DPA terminal, a standard sensor command or FRC, the terminal immediately tells you which command it is and you have a direct link to help for that command. Let's say you read some sensory values from the sensor, and you see the packet that arrives in the Packet Inspector, which is linked to the online help. Let's say we read three quantities from a sensor - temperature, humidity, CO2.
Then I get names of those values, what we were used to, but the values are linked with the help of the relevant standard of the quantity and I can see what kind of quantity it is, what its properties are, what its range is, what its resolution, etc. This is very nice, you don't need to have an open browser with help, but the IDE easily finds all of it and you don't have to use searching, etc. So that's also something I enjoy a lot.
What we are preparing now is a wizard for the fast creation of projects in the IQRF IDE for creating Handlers. This wizard works by asking you which version of DPA you want the Handler to create for, whether it's for the node or the coordinator if you want the header files to go directly to that Handler, or to link, what should be the name of the Handler. We allow you to add plugins for the DPA of that particular version to the project for which the Handler is being prepared, so if you want to upload those plugins to your module, you just double-click and they are immediately loaded. There will also be an automatic notification that there is a new version of DPA, which is something that will make life easier for developers.
Maybe I would mention one more thing, we have better notifications of IQRF news, there is a link with social networks - Twitter, YouTube, etc. IQRF IDE has very useful and interesting features.
This tool is available free of charge to anyone who needs to develop their applications for IQRF.
I would like to return to the IQRF Interoperability certification process. Let me just briefly say that if a member of the IQRF Alliance wants to certify a device for IQRF interoperability, he should first look at the IQRF Alliance website, study the specifications of the IQRF standards, and then prepare software for his device that respects these standards. He then sends the device with this software to the IQRF Alliance headquarters, where it finally goes to you, and then some iterative steps follow to verify that everything is as it should be. The whole process is described in detail on the IQRF Alliance website.
Have you recently certified any IQRF interoperable device?
I wouldn't say it better, thanks for the description. I will just add that we have a number of examples, Handlers, for devices that are to behave according to our standards for IQRF interoperability. The most interesting standards are for sensors, we have prepared examples, those interested can start the development after some initial study of those standards. They simply copy the example and start enriching it with quantities from their sensors. I think the process should be very fast thanks to those examples.
What went through my hands recently? An interesting device that is used to turn on/off electrical appliances at 230 V in the power mains. It is a device that is intended for installation in an electrical installation box or in a soffit. A device that can not only turn on/off the connected device according to our standard for binary output but, what is interesting, it can also measure. Specifically, it can measure mains voltage, current consumption, active power, power factor, cumulative consumption, so I think it's a very interesting thing. So far, it just went through my hands, when it will be available, I can't say, especially me, because I don't know. This is something I liked a lot.
So as a result, such a device can be identified by some hardware profile ID that is on the IQRF repository?
At this point, this particular device is still in development, but as you say, HWPID - a unique identifier of the device type will identify it. This device supports our two standards, the binary output standard for controlling the device and the sensory standard, measuring 6 quantities, if I remember correctly, from low voltage, through current to the cumulative consumption. So a very useful thing for scenarios where I need not only to turn something on/off but also want to know something about the device, or the electrical network.
So if we summarize certification, it probably makes sense to follow the standards for sensors, binary output, lights, DALI. There are probably cases when it is not necessary to deal with certification.
Yes. Of course, there are such cases. The moment I have some very specific needs that go beyond these areas, then of course a user solution comes up. But I dare say that the moment I want to get data, measure something, I think our standard for sensors is the right choice. If I remember correctly, we currently have standardized 35 types of quantities.
Of course, we would also think of some exotic variables. We haven't gotten into the field of ionizing radiation yet, so the radioactivity may not be there yet, but those common things, physical quantities that make sense to measure in common scenarios, or our customers are already measuring, are already in that standard. In case you need to add a quantity to the standard, contact us, we will define it hand in hand together, so that it makes sense, and we will enrich the standard.
Perfect. You closed it with exactly what I wanted to ask.
I believe that it was interesting and useful for the listeners. Thanks.
Thanks and have a nice day.