 Hello and welcome again. We are so happy you joined us today for this webinar from an Access Foundation, Access to Energy Institute, and OkraSola. We will today talk about CICADA, the Open Source IoT Communication Model, which was created for energy access organizations. Through this agenda today, we will have a short introduction about the three people on stage, which you can already see here. And then we will have a short intro about what the CICADA IoT module actually is and what it can and some of its technical specs and what it has been built for. And then we want to engage in an interesting discussion between us and Access as an initial supporter and funder of the module, then OkraSola as the initial developer, which developed it for their own needs. And A2EI as an organization currently looking into adapting and adopting the module and for which reasons and what potential they see and what challenges they see. Then after roughly 25 minutes or half an hour, we will get a live demo by Georg to see how to get started with CICADA when you want to use it. And after that, we will open the stage for questions. The questions will be posted during the whole webinar in the chat. So just write them down whenever you have a question. And we will make sure to cover as many as we can of those questions in the Q&A session at the end. So let's get started. Me, myself, I am Julien Barnier, the Chief Operating Officer of the N-Access Foundation. N-Access Foundation is a Dutch non-profit which engages in identifying, supporting, and promoting open source innovations for the energy access sector. And what does that mean in detail? So we reach out to the sector or the red sector reach out to us with particular challenges that they have, which can be technology, software, hardware, but also concepts, business models, and engage with us in a discussion if this is a solution that is possibly not only necessary for them, but can actually be leveraged and used by the whole sector. And we then co-design and agree on a shape and scope of the development that can actually be useful to more organizations and in this case to all organizations in the sector, but to as many organizations as possible. And that's also how we ended up in supporting the development of the CICADA IoT modules because we pretty much believed in the potential of these modules to be open source for the sector so that anybody in the sector can take them and treat them. We do this because we want the N-Access Foundation to focus on their core business and not spend their scare resources and time on reinventing the wheel and just developing baseline infrastructure which is required and needed, but which is needed by much more organizations in the sector and which does not make them outstanding in terms of their operating model or their technology from the others so that they can actually focus on developing their outstanding IP value developments, but baseline infrastructure should be open source and shared so that we can all profit in the sector. And I do this personally because I come from a private sector and I have seen these happening quite often and quite a lot in the sector in private companies just spending their resources and just doing things that have already been done and have already been developed instead of being able to actually leverage on the wisdom on the crowd. So that's what N-Access does and why I'm motivated about open source innovations for the energy access sector and I will hand over to Rainier von Kampenhout from A2EI to introduce himself. Thanks very much, Vivian, for the introduction and thanks for having me here today. My name is Rainier von Kampenhout from the Access to Energy Institute. We are also active in the energy access domain. We are located in Berlin, Germany and we have two main pillars. One is Prospect. There's an open source data platform for the whole energy access sector. Collects data flows from on-grid, mini-grid, off-grid sources and allows the users to process, customize and visualize the data. And the second project is what we'll be talking about today, the SKGS, a solar generator project. It's aimed at designing and producing solar systems in a range of about two to three kilowatts for small businesses. And systems consists of panels, batteries, inverter and our MCU, which is essentially monitoring device that collects data, transfers it to our backend. Here, next we can see one of our inverters recognizable by the pink color. And the systems are dimensioned so that they can replace petrol and diesel generators that are used to respond to grid blackouts. Countries such as Nigeria, South Africa and Honduras are experiencing. And we see that people there buy more and more generators. It's our mission to replace all of these by clean energy solutions. Thanks very much. Yeah, Georg Lipic, excuse me, from Okrasola, over to you to introduce yourself and tell us about you and Okrasola. Yeah, thanks everyone. Thanks for the introduction and for having me at this webinar. Actually, I'm really excited about this because the Cicada library is kind of my baby since I joined Okrasola in 2019. I was the first in the main developer in this library and it's a good opportunity to present it here. So let me quickly tell what Okra actually does. It creates power mesh grids in very remote areas where people currently don't have access to electricity. So our main markets are in currently Nigeria and in Southeast Asia, we have customers in Cambodia and the Philippines and Indonesia, for example. And basically how it works, the principle is quite simple. Basically, you get a solar panel on the roof. You have the central solar charger. You have a battery which is charged and all the households are also interconnected with a so-called mesh. Basically, they can share the power if one house has more battery power than the other one or if one house has, for example, someone is watching TV and needs to consume more power, then this can be shared between the houses. This is called a mesh grid. And we developed this solar controller ourselves. This is an IoT device which not only charges the battery and shares the power but also communicates all the data processes. It communicates it to the cloud and this is where we internally use Cicada. So we have a Cicada hardware which are basically different versions of communication modules and we have the Cicada library which actually does all the low level communication with the modules. Great. Thank you for that. So we already have heard a bit about what the Cicada IoT module or modules actually are by this intro and what we said so far. So let us go into a bit more of details to lead over to the discussion that I'm really looking forward to. The Cicada Wi-Fi, GSM and LTE modules. So you see these are different modules and IoT communication modules as it already says which enable energy access assets as Rania just said, for example, or Georg said to communicate with the cloud or and send the data to a backend which then can be processed by each company. And this is something that in the sector pretty much any company needs to do or is already doing or needs to do. And we as energy access foundation saw the great potential of this as a piece of work which is really essential to the operations of pretty much every energy access actor and having this part open source shared and supported and to further develop a community is a great potential because we don't need to spend each of us doing this basic required technology at our own. We need a working solution that can then be adapted and adopted to each particular case for each company. And that's where we believe that the open source power at this particular part and particularly looking into the transition from 2G networks to 4G networks so they're not longer supported 2G networks which in some countries already shut down and then the others they're under process to and the others are coming soon. So an easy change from a 2G to a 4G module by having actually open libraries and the open documentation would facilitate much more this transition. And that's the potential that an extra saw years back when we engage to support this project. So I would now hand over to Georg again to provide us a bit more of technical details on the CICADA modules and we'll then come in with some questions between me and Rainier that we have about this great project and to understand it better and to make it more understood by the audience that we have here today. Yeah, cool. Let me probably quickly start with the history how it was all developed. So basically we started developing it at Okra to fulfill our own needs. So we had this IoT device and when we originally started they were all connected with 2G but we already knew that 2G will not be the final solution so we probably will switch over to 4G in future of course and we also want to support Wi-Fi and we also want to probably even support like other protocols like what we're currently working on the sub gigahertz or there are a bunch of other IoT protocols. And the question was, is there like a way ecosystems where we can easily exchange all those modules without having to change too much on our main firmware and also of course at the hardware. And yeah, we did some research as usually but surprisingly turned out that there were not too many libraries fulfilling that needs. There are of course some there's for example, the old Android, not Android, sorry there. Arduino ecosystem has some ways to support these models and Embed has some things but they are also rather new that didn't exist in that way when we started with Cicada. But yeah, surprisingly turned out that there are not so many options available. So we thought of developing them ourselves and at the same time we got in contact with NXS who were actually happy to sponsor this as an open source project. And this is what we started. So we started basically with 4G and 2G support. Later we added Wi-Fi and currently this is very a stage of development but Kari we are working on Wi-Sun and Lore 1 support. Yeah, probably a bit to the library itself so it's a C++ embedded library which does not depend on many external libraries basically just the standard C++ library but otherwise no external dependencies. It's designed very modular with basically a clear separation between interfaces and actual implementation of the interfaces. So for example, when you want to add the new modem driver you would basically implement the interface of the common device to support your new device. Great, thank you Georg for this intro. I think very insightful. I have one question to start with. If now I'm using 2G Cicada what would it take me to change to 4G? So what is the, because in the country I'm operating the operators take down the 2G support and I need to change to the 4G? What is the work? I mean, if you can shortly describe what does the kind of work and how much time and effort it would take? Yeah, I mean, of course it depends not only on 2G or 4G but also on the vendor of the modems you use. But if you use the Cicada library ideally it wouldn't involve any work it also you have to check on a different module onto your device but the library also has an auto-detect feature so it will just detect that there is not 2G module collected anymore but instead a 4G module. Actually, I will demonstrate this later in the live demo and yeah, if you have used it with Cicada and already used Cicada's auto-detector then you wouldn't have to do anything it just detects different to us. Okay, thanks Rainier. Do you have any question? Otherwise I go on but I want to give the stage to you. Yeah, actually I thought it might be interesting to sketch our use case and why we got interested in Cicada in the first place and because we are using in our MCU Nordic chip it runs an operating system which is minute from Apache and which is not supported so far by Cicada and the chip that we have communicates with the cloud through Bluetooth low energy so we have an app that goes with it and the user connects with this Android app to the system and then we kind of utilize the data bundle of the user to transfer our data. It's a nice low cost solution. I mean, it doesn't have money costs that's a big advantage but for us the data volume and the frequency of the connections that we get depends on the behavior of the customer in the end. And now we have a new use case which is to electrify health centers and for that we need live data. So we want this data regardless if the customer connects with a smartphone to the system or not. That's why we are planning on extending our systems with 4G modeling or possibly also 2G for low cost but then we run in the same problem that Georg already described that it's phased out in some countries and we started to look around actually the same as Okra did back then for an open source driver and there are not so many that are available that are good, most are incomplete or badly written or maybe they're already tied into some other IoT ecosystem. And Ticada quickly identified as the best candidate especially because it's not tied into anything it's open source, it seems very well written and modular, so that's really nice and it already has support also for 4G but you can swap out with 2G. For us though there are some challenges because we need to include the library we will size up to a bigger chip to have more flash memory available but probably we would have to do that anyway. A more practical problem is that our code is in C so we need to glue in this C++ code from the Ticada library so there's some work there to kind of embed it in our compilation process and probably compile it as a static library first which is then tied into our C code but otherwise it looks very solid like I said the code is clearly tested there's unit tests available etc. And yeah, we are happy that Ticada is existing and we don't have to reinvent the wheel so that's exactly what your purpose was. And question to you Georg, we found the project on GitHub is that project actively supported? Can we ask questions there, file book reports and maybe even if we extend the library also do much requests to get our own code included in the library? Yeah, sure. Well, actually the Cicada library is actively developed for us still. At Okra we currently have two people working on it. Of course it's not our only project it's just part of our project but how it internally works, we develop it internally then we push it to the Okra GitHub page and then it usually goes to NXS. But yeah, there are definitely people maintaining it so if you create a merge request or if you open an issue tracker we are definitely happy to work on that and of course merge requests are always welcome, sure. Yeah, I imagine it was open source project so raising an issue is one thing and making a merge request is obviously more welcome and so yeah, to the developer community out there and feel invited to contribute. This is exactly what we are looking for and we hope this webinar contributes to that and helps to understand the potential of the project and later with the demo also how to get started. To add one question to Aynir, what of the Cicada, I mean you already mentioned a few things that it's well documented and so on. Are there any other particularities that you found special about this library or documentation of the IoT module which makes it more outstanding from the others? And like I said, very well organized, very complete. What's also interesting is that the communication with the modem is non-blocking so that seems nice feature for us to use with our operating system. Maybe Georg, you can comment a bit more on the philosophy what you had with communicating the modem. Yeah, the non-blocking philosophy, so this is a principle in programming when you do communication with some external devices, you can either implement it blocking or non-blocking. Blocking you basically mean you ask for something, for example, you ask the modem for new data, then you just wait until the data is here, this is blocking. And non-blocking means you basically ask for the modem, then you go on, can do other things in between and as soon as you receive those new data, you process them. And usually a non-blocking approach is a bit more difficult to understand. It's a bit more work to implement, especially on the driver side, but it has the advantage that's usually in the code, it's a very linear program flow you have. You don't interrupt your functions for any other threats and it's usually easier to debug if you have any problems. And our approach there was to make it a very strict non-blocking design, which means basically all the driver levels are designed, this non-blocking state machines and it's in microcontroller programming, this is a common pattern. You basically have the big loop which just loops around and calls the processing function again and again. And whenever there is something to do, the processing function gets active, probably changes its internal state and then returns back to the main event loop. And yeah, this is internally, we discovered that for some engineers, especially those who are not so familiar with embedded development, found it a bit difficult to understand this non-blocking design, but actually for microcontroller development, it's quite a common pattern. Okay, Rainier, do you have any? Because otherwise I would come in with a question, which is completely another scope, so if it's more technical. No, you can go ahead, please. Okay, and do you, I mean, you were mentioning like, mergers and contributions to your project. Have you, Gail, that's a question to you, and have you gotten like, requests of all, like collaboration or contributions to your repository so far, or do you know of others for many using the Sikara modules? So far, it's not too many, actually. There's one, actually I don't remember the name, but there's one organization, also in Germany, I think, which creates open source solar charge, also open source solar controllers. And they have explored and looked into the library. I think they also contributed some small MRs, but I didn't hear them back since a while. Yeah, other than that, it's mainly internal. So also internally, we have this process that every change which is made for someone, then it goes through a review and then MR and then it's internally merged. So the process is common to us, but the contributors are mainly internal, Isabelle. Okay, thank you. And following up on that, I mean, as at least the ones here in the room and looking at the quite high number of attendees, I believe it's a topic that is really relevant and important for the sector. And I mean, it's also what we identified the time back also by talking to other stakeholders in the sector. What do you believe is the reason that not so many, and there's a question to both of you, to Aynir and Georg, if you have any idea, what is the reason why you don't know about too many users? Do you think there are a lot of users and because it's open source, you just don't know it? Or do you believe actually, because when it's open source, whoever could come and just take it and use it without asking you anything or without contributing? Or do you believe there's another reason even though we all agree on the relevance and looking at, as I said, the number of attendees we have here, it's relevant? And yeah, do you have any ideas what could be a blocker so far or what could be reasons? And that's a very open question. Yeah, that's a good question, actually. I mean, the first thing is that we actually don't know. It could be that there are many more users from which we never heard of, but it could also be that there are not too many. I don't really know that. I mean, that's the nature of open source that you can just take it and don't really have to tell anyone about it. One other reason could be that this C++ library, I think right here, you mentioned it before, that's actually interesting because when we started with Cicada, also our internal firmware code is written in C++ and we kind of wanted to fill the gap that there are not so many C++ projects out there. So we made it C++, but it turned out that actually, most of the firmware developers still use plain C, so this could be a thing. Yeah, just a strictly non-blocking device approach could be another thing. So I just, when preparing for this webinar, I wrote a new example code, which does not use some of the internal Cicada macros and things we usually introduced, which are a bit uncommon. So hopefully this will make it a bit more clear how to use it. And yeah, of course, we hope that with this webinar, it also spreads the word. But yeah, we don't know, probably just more people will use it and not tell us, can never know. Yeah, and yet anything to add on that one, any idea? As you are somebody who is actually looking into using it, so what could be blockers? You should not forget there's also commercial solutions out there and they are not per se expensive, often they tie you into some ecosystem where you have to use their cloud also. I saw for instance also now that Amazon has their own, or I mean not their own, but offers hardware that can directly connect to their cloud. So if you're using that, yeah, you don't need to develop yourself. Could be that some companies don't have the time or expertise to develop this fully by themselves and they get some ready modules. There's also some modules you can buy that you just push data into it and it sends everything through your backend. So you don't have to do much development yourself because the disadvantage is these are black boxes that you are then using. You don't have control over what they do exactly. It would be harder to debug if you get any problems. And yeah, you don't have the source code. You can't modify it for your own purposes. Those were for us really important points to choose Cicada, but it might be that, yeah, some people don't have the development capacity or the time to do this or even if it's a ready-made library is of course some work to include it in your own firmware and your wider ecosystem of your connection to the cloud or to your backend, whatever. Okay, thank you. And I think it's a great handover to actually the demonstration by Georg so that people who actually want to get started and to have some capacity or maybe limited capacity and need some help on how to actually use the Cicada module and can now get a demo by Georg how to get started with it. So stages, Georg, we will leave you alone and you have some 20 minutes to show to the entities of this webinar on how to start using Cicada. Awesome, yeah, thanks everyone. So the second part of this webinar will be much more technical than the first one. So I will basically do a hands-on. I will first show you some of the Cicada modules and some of the hardware I have available. Then I will start a live demonstration running it on a STM nuclear microcontroller and forwarding the output to the computer. And then I will actually do a code walkthrough through this example code that I just showed before. And I just fall down, I have this Cicada modules here. I'll just show them into the camera. So this is basically the Wi-Fi module based on the Expressive 8266 microcontroller. Then we have 2G cellular module here. This is based on the quite popular SIM 800 module. And then there is this 4G module. It's based on the SIM 7600 module. And yeah, these small PCBs I just showed, they are also published in GitHub and available as open source hardware. So the hardware is actually rather simple. So it's basically just this module on a PCB with a power supply and some antenna networks depending on the module you use. So this is rather simple, but it's still very useful to use as a reference design. And basically you can just, you probably don't want to use the modules exactly as there are if you build a product, but it's still a very good reference. You can just copy and paste the hardware design into your own design and use that one. So basically the Wi-Fi module is just a power supply and the Expressive modules. The 2G and 4G modules are a bit more sophisticated. They also have an antenna network. They have obviously the SIM card reader. And what's also important there is to have a very stable power supply because one of the problems we have is there are some pre-made modules you can order on AliExpress or whatever, but the power supplies on them were actually too weak to support the current spikes the module use. So we had to create our own power supplies. So let me quickly show one more thing. This is basically at Okra. This is the main board of our solar controllers. And whenever you want to change your communications modules, it just plugs in here. And yeah, basically just plug-and-play solution. So when everybody wants to use it with a different module, we just chip the main board with a different module installed and we don't have to change anything in our firmware. So it's just the SIM card to transfer all of them. Yeah, that was a little introduction to the hardware. And the next thing is I will actually start with the live demonstration. Let me again first show the hardware. So I have a little SCM nuclear developer board here. So you can see the microcontrollers over here, this chip. And this has currently connected two modules. In that case, I don't use the C-Color PCBs. I just connected the modules directly with these wires over here. It has a Wi-Fi modem, which you see on the top here. And with these wires here, it has, again, a SIM 800 module connected to it. And yeah, now you've seen the hardware, I will start sharing my screen and show you some code. Just select the right screen over here. OK, yeah, you should now be able to see my VSCode with the example code. And yeah, so this around 200 lines file is basically the example I will walk you through now. On a high level, what it does basically is it initializes all the drivers. Then it detects the modem with that modem detector. Then it connects to a web server, sends a HTTP request, receives the website from a web server, and actually forwards it from the microcontroller to the terminal on my computer so that we can see the website. Let me quickly check which is enabled. So we will first start with the Wi-Fi module. So here I have two terminals. One is for flashing and compiling code. And here you actually have the serial UR part, which displays the output from the microcontroller. And we start with compiling. We use nasenet-minja as the build system. And then we actually flash. Now writes the binary to the microcontroller. And yeah, now you see here on the output that it actually detected the expressive module. It's happening faster than I can talk. So it detected the expressive Wi-Fi module. Then it connected to the web server, received HTTP header, and finally fetches this weather report on the website. Sorry to interrupt, but we still see in your code. We don't see the live demo screen. Oh, that's very weird, actually. I saw this share my screen. OK, just give me a second. OK, sorry for that. Probably just shared just one window instead of sharing my screen, so we just could have seen. But yeah, here it's basically still quickly repeat what I did. So I called ninja, which compiles the code. Then I flashed it to the microcontroller. And this is the output from everything where it detects. It says detected expressive Wi-Fi module. Then it connected, and then it fetches this weather report from the website. But yeah, I wanted to show it again anyway, because I want to do the same procedure now with 2G module. So as I said before, I have two modules connected to this. It's just another module on another UART port. So I comment out this part of the code, and instead I comment in this part of the code. So it's the same object which is created just with different pins, with a different UART port and different pins with the other module connected. So we do the same thing again. I'll flash. Now I see it live, what I just did before. And if you change terminal now, you see that it actually detects the 2G or 4G modem. It says 2G, 4G, because it's actually the different drivers, but they inherit one base instance. So we can just use the SIMCOM driver in this case. And again, it fetches the weather report from the website. So yeah, this was the live demonstration. And now I probably use around 10 more minutes to walk you through that code. So now you should be able to see the VS code again. So everything is happening in the main function over here. You have basically some initializations. You have the Zikata, the buffer initializations for all the drivers. So basically in Zikata, all buffers are user supplied. This is useful because there are different ways how you want to actually initialize your buffer. It could be in the heap. It could be in the stack. It could be on a local function stack, or it could be a global stack, whatever. So you just create your buffer wherever you want to create it. And then when you actually create one of the driver objects, you will hand in that user-created buffers over here. So these lines actually create this. There is also serial drivers included in the library. In this case, we used the SDM32 serial driver. We also create the serial driver for the Dblog UART, which we just used to connect to the PC. Then we create a serial driver here for the specific modules. And then we actually start creating the modem detector object, which has this auto-detect feature. So how the detector basically works is you create this modem detector object. Then you add it to the Cicada internal task handler. And then you have to go to the main loop and call its run method, which we do here. And basically what the modem detector does is it tries to send 80 comments to the modem to figure out which module is installed. And then it gives you back the correct C++ driver object of that specific modem you want to use. So that basically happens here. First, you start the detector, then you go to the main loop. And as soon as you have this flex set modem detected, you basically actually assign your common device to the actual modem driver object, which happened here. And then you can basically figure out which device you actually got. A common way to do this in C++ is with a dynamic cast. So you try to cast it to a SIMCOM device, which is for these 2G or 4G modems. If you have a SIMCOM device, you still have to set the APN, which we do here. If it's not the 2G or 4G modem, this dynamic cast will just return 0. And the function goes on. And the same thing we do for Wi-Fi. If it's a Wi-Fi module, we set some username and password. So this password is actually the one of our co-working space. It's not committed to GitHub. And depending on if you have some other modellers, you can do other casts. For example, you can cast the 2G modem to 4G modem or whatever. But this way, you can determine which model it actually has. This is, again, generic, which is valid for all the communication devices. You set host and port. And then you can actually call connect. So the next event here in this main loop is the actual connection app. So as soon as the modem is connected, you will have the COM device is connected. Method returning true. Within this method, what we do here is we print, obviously, the line to the debug yard. And then we actually build up the HTTP header, which we write to the COM device. And then we set this flag to true because we don't want to call this event ever again. And the next event is the actual receive event. So you have another method, COM device, but it's available, which basically tells you that there is new data and how much new data. So this is called whenever there's data available. And what it basically does is it just reads the data from the COM device and forwards it to the debug yard so we can see it on the computer's modem screen. And at the end, finally, so basically, as you see here, we have set the connection close flag in the HTTP header. So the remote host closes the connection as soon as it has sent all the data from the website. And this is basically the close event. So once the communication device is again back to idle state, we just print the debug message that we disconnected, and we exit the main event loop. So this was pretty much all you have to do for this example to detect the modem and fetch the website, probably some more words to this event loop. So how it basically works, this is, I think, quite a common pattern in microcontroller development. You basically have just one big main loop, which just runs over and over again. And within this main loop, you call different task methods and handle your events. So for Cicada, we have an internal task scheduler. It's a very simple scheduler. It's not like what you know from high-end operating system schedules. It basically just checks if all the tasks in the list are due to run. And if it's due to run, meaning it has a certain time out, then actually it runs the task. So basically, what you have to do is you have to create a Cicada scheduler. You have to add your tasks to the task list, which in our case is just a modem detector. And then within a main loop of your microcontroller, you call this Cicada task scheduler's run task method. You have to call it repeatedly. Yeah, that's basically how this works. I can quickly show you how an internal driver works. For example, if I open this sim800, the tppdriver, this is also only 400 lines. source code file, which is the implementation of the full sim800 driver. And basically, this run method is what I showed before, has to be called periodically from the main event loop. And all the internal tasks in Cicada, mainly the drivers, but also the detector, serial driver, whatever, those are implemented as state machines internally. So it basically means, for example, here you have the main state machine for sending out the comment. I'm sorry, this was for receiving your replies. So this is the state machine for actually sending the AT comments. So you have different states. You're first not connected. Then you handle your states. You usually send a bunch of AT comments. And then you go to your next state. So for example here, you send first the comment to not reply, to not echo the characters which go to the modem. Then you go to the next state. Then you send a bunch of configuration for those modems. In this case, it's the active or passive mode, basically, of the flow control of the modem. And then you actually set APN, then you actually set up your connection, which is over here. You first cellular connection, then the actual TCP or UDP connection. And then you finally are in the connected states, which is actually for handing incoming and outgoing data. Yeah, there are different states also for actually processing the data. And in the end, you basically just have to disconnect and finalize states again. Yeah, that was a quick introduction how a modem driver looks like. Let me probably finally go back to the main example. So I already went through the main loop. And everything that comes after is just boilerplate code to initialize your main MCU. This is just copied from this. There is this program where I can create boilerplate codes for STM for do micro-models. CubeMX is the name. So this is just auto-generated with CubeMX. Yeah, that's basically it. Let me quickly check in the chat. OK, I see that there is a bunch of questions in the chat. So I think it's a good opportunity to end this demonstration code walkthrough. And yeah, let's finally hand back to Vivian and go to the discussion. Yes, thank you, Georg, for this great intro and demo for anybody interested in using the Cicada modules and how to get started. I think very helpful. We have a few questions, which I would like to address here, which came into the chat. Also, others who want to make questions still, you have still some time, some 10 minutes to post them in the chat. And we will address them as good as we can in the time that we're remaining. If you're not able to manage it here, we will make sure to try to reach out to get you the answers. But let's get moving. The first one is about general IoT cost. I mean, we all know I'm making an asset IoT enabled cost money. And here the question is written as if the current IoT will increase the price of the whole product a lot, it is a big challenge for the end users. Yes, what are the most useful points of IoT module? Maybe very quick one. Who of you two, because you're both using IoT or looking into? Who wants to take it? Maybe Georg, I give it over to you. Yeah, let me read the question again. Current IoT, you mean if the IoT will increase in prices? Yeah, I think it's difficult to tell, of course, how prices will develop on the market. But actually, our experience is that the modules got cheaper. They rather decrease in price. Did they increase in price? Especially this, if you use a Sim800 module, which is already like 2G is quite outdated, but you can get them for I think around a dollar or something in high volumes. But yeah, I think the most useful idea of this CICADA library is also that these IoT modules, the communication modules specifically, are exchangeable. So for example, if one goes up in price, you could switch to another vendor, you could switch to another module from the same vendor, or you can just implement your own or whatever you think and you still have a flexible ecosystem, which makes it easier to interchange your supply chain if prices change. Great. Thank you. Let me just quickly add on that one. I mean, A3EI with their solar generator, it's a rather costly product. I mean, it's not costly compared on the market, but if you talk about a small solar light, you will probably not make an IoT CICADA module on it because it doubles or triples the price of the product. And there you would possibly use the Bluetooth solution, which I knew was mentioning earlier. And just to mention here, at an access, we have an open source solution for that as well, which is the AirLink. So go on our page, check out AirLink. If you want to, if you don't need real time data and can rely on an agent coming or a customer coming with a smartphone from time to time near your asset and it's a small asset, then you can rely on the Bluetooth communication and the smartphone would actually act as a data carrier. And yeah, we have another open source solution for that and then you don't have to go full IoT real time data, which makes it obviously more costly. I hope this question was answered well enough and I would move to the next one, which I believe already has been answered mainly. The question was that Patrick, is the GitHub project available as C implementation or only C++? Yeah, we have talked about that before. So basically the CataLibrary is fully C++. It does not yet have any plain C code. So if you want to use it in your C project, you have to mix C and C++. There are good online tutorials about how to do that. Yeah, probably not going into detail too much now, but the simplest way is just to use a C++ compiler. If you cannot do that, and if you want to strictly separate C and C++ code, you have to write C wrappers around your C++ methods, which is a bit more work. But yeah, if anyone is probably going to contribute a C wrapper for the C++ codes, that would be very welcome because then we support both. Yeah, that's exactly what we plan to do actually. We can't use a C++ compiler, so we're going to write a wrapping code and we hope to add it as a contribution to Cata project. So that is an example. That would be awesome. Yeah, great. Patrick, maybe we try to find here as well if you want to work together on that. I mean, that's what is open source and that's what we want to see. Let's move to the next question quickly from Jeff and let's try to make the answers as short as possible. How many different types of moderns and chips does Cata support? Yeah, I think we have a list and they read me. I'm not sure if it's up to date, but the main devices are currently sim 7604G, sim 802G, Expressive 8266 Wi-Fi, Express ESP32 Wi-Fi, and we currently working on, I think this is not yet publicly released, but we're just working on support for LoRaWAN. There is a Chinese LoRaWAN manufacturer, which provides AT modules which we support and we will support WISUN, Texas Instruments CC8256, I think WISUN, SoC from Texas Instruments. Great. Thank you, Georg. I hope your question has been properly answered, Jeff. Next question from Martin. Are you planning to support Sapphire Airtoes in the future? Embed operating system seems almost that as ARM has kind of abandoned it. Yeah, I want to repeat this again. Sorry if it wasn't clear before. So actually the Cata library itself is completely independent of the operating systems. It's even possible to use it as bare metal library. So you don't have to use any operating system at all. And if you want, I think there are some example codes in the Cata library on how to use it with embed. If for some reason you want to use it with in combination with embed threats or something. For example, like I showed in my demonstration, I had a simple event loop where I do everything, you could, for example, call the periodic run method from one thread and actually call the actual driver method from another thread. But then you have to synchronize them. So this is all possible. But again, it doesn't depend what operating system you use. Cata itself is not dependent on an operating system. But you can use it together with one. Great. Thanks. Then another question from Martin. It's actually as far as I see Martin from Libre Solar, the one that you mentioned earlier, Georg, is interested or an adopter of the Cata modules and also developer of the open source battery management system supported by an access. And so we have here the great open source community live. And the question is questions regarding the event loop. Is it possible for the MCU to go into low power sleep mode while waiting for the new input? And I would request you to answer as quick as possible as we have one more question, which I would like to address and then close the session. Okay. That's a good, that's a tricky question actually to be honest. It's not supported by the Cata library itself because the drivers don't support any energy mode. So you basically would have, I think what you would have to do is just to go into sleep. You have to wake up your event loop with an interrupt as soon as you have data from the UART. So you can go to sleep, but you just would have to wake up your main event loop as soon as UART arrives. Then you process the data and then you go to sleep again. But that's not part of the Cata, it's part of your operating system. Okay. Thanks. I hope this was enough for you, Martin. But yeah, you know how to find Georg and can follow up if you have more questions. And the last question, sorry if I didn't pronounce you and I'm well, is it a good idea to integrate Lora modules? If yes, no, some explanation, one minute to answer this question. Was a bit tricky question. I think what you basically, why you're asking this question is because Lora, one approach of Lora is very different than normal IP communications. You don't have a P addresses, you can't simply connect an internet host. So yeah, I think even though we have this Cata ecosystem, using a Lora one module would be quite different than using a normal internet module. But yeah, anyways, there already is a Lora one driver working process. We've all tested, but it's almost complete. And yeah, I think how actually useful it is to use Cata in that case, that really depends on the use case. It's very difficult to answer now. Yeah. Thank you, Georg. And you did a great job answering all these questions. And all the triggers. Thank you, Rainier for being here and sharing your interests for this Cata module and the value you see on it. We want to close the session with pointing out NXS does open source, promotes open source, but also helps adopting open source. So if you need help in adopting, reach out to us. We try to help you as much as we can. We can't promise that we solve all problems for you, but we will do our best. So help at NXS.org. If you want to reach out for funding or any other question on us, info at NXS.org. If you want to reach out to Okrasola, Georg, the developer of the Cata modules, info at okrasola.com and if you want to contact us at A2EI, info at A2EI.org. Thank you for attending today and thank you for this great and engaging discussion to Georg and Rainier and to all the attendees that joined us here today. Bye-bye and see you soon. Bye.