 So this talk is about OSS-7, which is an open source implementation of the Dash 7 communication stack and I'm just gonna leave Glenn the floor. Okay. Thank you for the introduction. That's very nice being here I was here a lot of times before but comfortably sitting in the audience Now it's new for me standing here But anyway, I work at the IDLA research group of the University of Antwerp and IMEC and our part of the group is Doing low power communication and localization and it is in this context that we got into contact with the Dash 7 alliance Where we actively where we are an active member in the alliance and also driving the open source stack Which is the topic of today. So the Dash 7 spec is originating from ISO 18000 Dash 7 so hence the name and that was purely focused on active RFID in This new evolution of the spec We try to make it more generic for IoT use cases It's focused on sub gigahertz bands and it's using a star or three topology. So we're not using a machine Currently we're at version 1.1 of the spec published about one year ago So some key aspects without going too deep into the the specification itself it's focused on low power communication and asynchronous communication and There's a lot of functionality embedded in the stack as we will see see later Also basically in Dash 7 everything is a file. This is configuration of the stack itself, but also sensor values are stored in a file This is also the main application interface you would use from your application or from an external note You would do familiar operations like read file or write file To the to manage the the the stack in fact This is done using ALP commands, which is just a efficient binary representation of these operations What I have right here is an of the shell of DevKit from ST which is running a dash 7 modem on it It's connected with my laptop using USB and on this serial connection. We talk this ALP command sets on the laptop We have a Python framework called pyd7a and it basically does a translation to and from ALP So I'll I'll be doing a few demos Somewhere between the presentation, so I'll be switching over a few times If I can find it So the Python framework also has a small user interface which we which we use to manage the modem So now it's connected with this this module here and here for instance You can browse some system files which are defined there and you can view here for instance. This contains a UID There's a firmware version file There's an access profile which defines some channel bands and some data rate and stuff like that So this is just a view on the file system, which we now query using this ALP commands You can also execute a command Like this you can just say I read file I want to read file 0 and execute and you would get the UID file here I don't know if it's feasible Okay, so on the other hand I have Two notes here which are the same def kit, but they have a shield a shield on top of it containing sensors for instance a temperature sensor So the application running on this is very simple and this is basically everything this is this is on the application layer We just read the temperature value from the sensors And we write it in a file on the dash seven file system in a specific file for for this temperature value And then we reschedule it again to do this periodically every 10 seconds So this is everything there is at the application layer and the rest is managed by the stack And we will be using this application throughout the demo So if I go back to this UI I can now instead of using the host interface Which is the the local module connected over the serial I can execute the same commands through through the dash seven interface I forward it to the dash seven interface I specify this takes some configuration for instance how to access the notes and then then it will Execute the same command, which was the read UID on this other on this other interface I started it Yeah, so as you can see we now have two responses which are from these nodes So that's that's fully transparent you execute the same commands to a local note as to a remote note Also, I mentioned that We were writing the temperature file. It's just in another file So if I take file 64 and I happen to know it's two bytes long I can just read out the temperature data just as I would read out the UID of the note So you see the two bytes coming in These are the raw bytes. We don't parse it here because it's not a System-defined file. It's something it's user specific So I'll show later how you can can visualize it, but here are the other the temperature of the two nodes Okay So what happens here is This is our sensor node the application is basically writing the sensor file Continuously or periodically it writes a sensor file and the rest is managed by the dash seven stack So here we have the interrogator, which was this note here It just executes a command to read sensor file. The stack will receive it We'll read the sensor file and we'll retransmit or we'll Answer the the data. So the application doesn't know the application is totally unaware of this happening This is what we call the the full communication scheme and it's useful if you want to request the data only when we need it So for instance on an external event like A door closes and you want to query all the notes inside or a user pressing a button on the UI Then pull communication makes sense You can also interrogate multiple responders at once Sorry now. How does this happen? As I said, it's used for low power and asynchronous networking So the the nodes there can't be continuously listening because they would consume too much power and they're not synchronized as well So what we do is an ad hoc synchronization? I can show this like this. I I hope it is visible But it's a screenshot of logic analyzer where you have the top two rows of the requester and The top one is the transmission and then we have the reception to Rx and then the same thing for for two responders And here we can see that the responders will Go into RX mode periodically. They will chat scan the channel for Background frames and the other one does that as well and you can see it happens as synchronously compared to the other one So there's cam for background frame. What is a background frame? It basically contains an estimated time of arrival of the foreground frame, which will follow So it's used for synchronization So they go into receive mode They check if the the energy on the channel is above the noise floor or not if it isn't they go Asleep as soon as possible if it is they they try to decode the background frame And when they receive that they go back asleep until this time out So if you want to transmit the query as a Requestor you would basically here and it happens here float the channel with background frames for a period Which is the same amount of time or a bit bigger than the scan and scanning interval So during one seconds this background the requester will send these background frames and it will basically count down And you will see here. I don't know if it's visible, but this this Here is a bit wider than the other one because here it actually receives the background frame So at this point in time this node knows that the request will be sent here And the same thing happens here and now basically they are synchronized So the request will be transmitted here They will both be in in receive mode here and then they will respond here using CSMA CA will respond to the to the requester So this is a talk synchronization or low power listening what we also support is push communication Push communication is useful for when your techniques to talk first for instance here We measure the temperature every 10 seconds imagine that we would require to capture all these measurements It wouldn't make sense to go query them every 10 seconds We can just as well let the note sent them to us and push them push it to us every 10 seconds Now you can you can code this in the application layer Of course, but there's seven provides a more generic way to do this without touching the application That's called the action protocol So this is the same diagram where the application writes the sensor file But now we configure the sensor file to trigger the action protocol when written So an action protocol takes two more files It takes an action file and an interface file an action file is the action which will be executed and Interface file is specifies where the output of the action should go to So if we now before we had our query here saying read sensor file data if we now We are not sending this right now because we're doing push communication But we're storing it inside of the action file So when the file is written the stack will execute the read file command So it will return 21 degrees and it will be transmitted over the interface with the specified here Where you can say it's transmitted on this channel using a security or whatever and it will transmit the file So basically what we did is we we removed this one But we pre-registered it in the notes and it will be triggered because it's configured that way So I can demo this I will not be using the UI to configure this now But I will using the API so I have some some script What should do this? I will make it a big big here Okay, so I use this script to choose the Python API and you can see it reconfigured two notes So I can also show this in a dashboard. This is a Things board which we use for dashboarding so you now you can see data coming in from from two more notes So it's 21 degrees depending on the notes here 21 or 23 Things board is an op-source platform. We use for dashboarding and for managing our Devices so all our devices are here and also a digital twin as mentioned before But I'm not going to into much details about this, okay now ALP has some more operations except from read and write you can also do queries for instance you can do an arithmetic comparison between a Value in a file and a value you provide and you can you can chain ALP actions and the Result of this query operation will determine if further actions are being executed or not So I'll give an example later But you can use this for for some smart addressing instead of addressing a node by ID you would say I want all nodes of type a or all nodes where Humidity is below this and the temperature is below that for instance We could also use this to extend our demo a bit further So now we're transmitting the temperature every 10 seconds, but imagine that 23 degrees is considered normal and we also want only want an alarm when it's above 25 degrees for instance Then all these messages would be a waste of energy right now. So if we could just have this this condition Restored in the query Like this so we will prepent the the query Before the read action and the read action will only be executed when the query is yields through so Okay, I'll show this now. I Use the same script that I can provide it with a with a parameter now. I'm going to check. What's the temperature is? So it's 23 degrees. So let's say 23.5 And it changes again It just changes the configuration over the air of the of the files the application isn't to wear But you see no new data is coming in now right now Now of course to prove that it will I need to increase its temperature Which I hope it does now Here you go Okay, it's even off-scale So back to the presentation So yeah, what we did was we just modified this file and again the application wasn't wasn't aware that we do in it and still we modified the behavior of our network Okay, so to recap we have two main communication schemes where you push when you have periodic data or sensor trigger data and pull if you Want to do want to trigger or want to query on some external event basically In practice you would use a combination of both you would enable pull to to to configure the note and you would push most data which is Triggered by the sensor. There are also some other options with I didn't mention a lot or which I didn't go into detail But for instance, you can have dormant sessions for non-urgent downlink or you could have Configure your gateway to do scandal channeling very fast on a few channels And then your note would pick a random channel and would do a very small advertising frame to lock your gateway Which would give you some some frequency agility and increase throughputs for instance So I only I only mentioned a very small part of the stack but here you can see per layer a few concepts Which are there? So for instance, you have quality of service power out of scaling one of routing network layers as encryption We have three different data rates at three different bands. So giga's bands There's also Laura in gray. Why is it in gray? It's in part of the the spec by itself. So But we use it Just to test the Laura five beneath it and it doesn't change anything above the spec So I talked a lot in general about that seven always as a seven is basically the open source Implementation of this. So the goal is to be a reference implementation for the spec and we want to generate interest in the spec And have people testing it and then contributing It's also don't get up. It's a patch license to so it's very useful for commercial products as well And without going too much into detail the architecture is a bit like this where you have a harder abstraction layer Which has some APIs and you have different drivers for MCU peripherals and for radios and they're glued together basically by something called a platform where you can specify a combination of drivers and you Specify the wiring on the physical board. So the platform is more or less your physical board and they have a framework Components which contains logging and scheduling for instance And then the modules contains the network stacks who have the dash seven stack there We also read it recently added the Laura one stack to test with multi modality And then in terms of hardware we focus now mainly on the Murata module, which is also the module which is Used here. So it's an STM 32 L zero microcontroller using and a Semtech chip on One module, which is very easy to integrate. You need a minimal amount of external components. You just put it on the on the board Especially if you have an existing board where your application is running on one microcontroller, you can add this Murata module And use it as a dash seven modem And then it's very easy to integrate since your application does not interfere with the stack timings and vice versa and also it could Make it easier to to do certification because your modem can be certified separately So that was the the firmware parts We also have some related tools that by D7 a framework already mentioned so parsers and generator for alp frames Alp or frames, sorry, but also contains a modem API which is used to to interact with with the modem There's some examples and tools and a basic web UI And then we also have the the things board gateway, which was used for injecting the data in things board So in that also uses by D7 a to talk with the modem, but on the other hand implements MQ2t API of things board and it allows you to Yeah to transmit your telemetry data and to Manage your your devices also for the things board gateway You can provide very simple plugins to parse your sensor data Which is why here we show the temperature data and not the two bytes you saw before they're just parsed before entering the things board platform And it enters the errors temperature data And then finally we have a test suite Which is running on physical modem So we we attach it to a to a PC and We execute some tests which are written in Python and also using the Python framework And that's driven by by Jenkins. The goal there is to test the full behavior of the of the spec You know the stack But we're not quite there yet, but it's still useful already the next steps We're not feature complete yet to the the current version of the spec We're working on it But we're now at the point where a lot of pieces of the puzzles are actually Available and you could do a lot of things with the current implementation already But still we need to progress this further. In the meantime, we're also discussing version 1.2 of the specification So this needs to be implemented as well, of course Then what you want to provide next also is to make it easier to interface from an application microcontroller with the modem So we want to provide a C modem library And also enable over-the-air updates Which is one one big advantage of that seven that you have a Low latency downlink to to do this actually Then finally you want to enable porting to other operating systems. So OSS 7 Was there for historical reasons, but we're not very interested in developing the operating system by ourselves So maintaining the scheduler or the outer abstraction layer is not our goal So ideally we want to to to port this to another Operating system and we're looking into that. We also we did some first step steps with riot So maybe in the future we will be using riot. We'll see So that's about it. I have a few links here To the documentation to get you started to the code to the mailing list and Twitter And also you can download the spec for free from the Alliance website So That was it Questions It's not specified so It's not that it's not possible, but it's not the way how to do routing for instance It's not specified in the spec. So what we do is in each star or three So using one hop at most is in in the handled in the specification But if you want to do more complex routing or missing then it will need to be handled by an by an upper layer So it's not something we we support for now Also because the due to the fact that we're using sub gigas you can do cover quite a lot of range with only one hop so Mishing is not that necessary anymore. And yeah, it would require more synchronization of course. So And the files you were writing to reconfigure the device are you storing them permanently on a device or is this just in Yeah My question for the video record, okay So the question was if the files we're writing where are they stored? Are they stored in RAM or are they stored more permanently? The answer is right now. They're stored in RAM But they should be stored in a more permanent Setting depending on the file you could configure you have transient files, which which which changed which Yeah, for instance Something coming from a sensor you could just as well Keep in RAM because you will just read it again, but configuration files of course needs to be stored in Rom but that's some some things which is on our to do list which is not there yet for the moment So right now it's in RAM. Everything is in RAM. And how do you define who is allowed to write which file? there's the concept of a Remote note is always a guest by defaults and you have you have access Permissions of a guest user and route. So remote user is a guest Then the local user is is the root by default and a serial over the serial link is the user So we have some permissions there