 Hello, everyone. Hello, Zafir people. My name is Pavel Hibner. I'm CEO and co-founder of Hard Video. Today I will introduce the Chester platform, which we have had already for a few years, and the platform is targeted for industrial IoT applications. In Hard Video, in general, we create open embedded platforms, and Chester is like our flagship product. Let's get started. So Chester started actually, it started a few years back, when we got a request from customer to create an NB IoT thermometer for the forest to correlate and monitor the occurrence of the bark beetle. Back then, we became partners with Vodafone and one of the first adopters of NB IoT technology in the Czech Republic. And yeah, on the picture, you can see my son. He's super excited with the running machine. But of course, what is more exciting is the yellow circle, which is Chester. We have installed together in the forest. And where we are today, Chester is like a general multi-purpose IoT platform that is used by partners all around the world. And this talk is targeting anybody who is enthusiastic about connected hardware, about firmware engineers, and there will be a demo, so anybody who wants to see things in action. So a little bit about Chester. We usually represent it as IoT hardware endpoint. You can see here in the picture that it consists of the yellow board, which is the main board. It is a low-power platform, so it can be powered from batteries for years, a bit more about it later. And it is very extensible. And we usually pick it in a rugged IP67 enclosure. And our target customers, they are partners. We are targeting B2B and we provide full sort of customization for that, UV, label printing and so on. And in the end, the process is like if you are creating or specifying your own car, you can tell us what kind of features you need, what kind of interfaces, and we make it tailored for your application. So the main board features, because this is the core, and it's just not about this board. We have lots of extensions, but let's fly through it. That is dynamic antenna system. There are two RF switches over here and here, which are multiplexing between the Lora 1 versus cellular modem, and another RF switch, which is multiplexing between internal and external antenna. That is the cellular module on its own. We use Nordic NRF 9160. There is Lora 1 module from Murata. We use some supercaps on the board. That is because usually here in the middle, we can have the battery holder and the supercaps are helping to survive the current spikes required for LTE. There is of course NAL SIM card holder, the 3 core LED, I2C terminal block. The terminal blocks, there are two of them mapped to the extension modules, speak about it later. And there is hardware one wire, bus master port, and on board I2C digital thermometer, and the Bluetooth module, which is the main one, we use again Nordic NRF 52840. This one is hosting Chester SDK, and this is what our customers are using to create and craft their applications. And 8 megabyte of Nord flash. Recently we made it work that we can flash the main application firmware from external SPI flash. The U-blocks GNSS module supporting GPS, GLONASS, Galileo, and Beidou, the push button, and again I2C peripheral, the 3-axis MEMS accelerometer. So that was the main board flyover. The main pillar of this platform is of course the connectivity. So for short range, we have Bluetooth that you can use for diagnostics, for reconfiguration, for firmware upgrades. I mentioned seller, so we support NBIOT and CATM. And for 868 megahertz or 915 for the U.S., we've got Lora1 module. And recently we added to the family of Chester Ecosystem, the satellite connectivity through AstroCast technology. That one communicates in L-Band, and it's amazing because we have a few customers in agricultural business, so Chester platform can now communicate from anywhere in the world. And I've already spoken about this GNSS connectivity supporting those four standards. You can see that there's a lot of radios on the board. But of course, in order to optimize the cost, we provide several main board variants. So yes, we have a fully-fledged one, but then we shrink it down to whatever the customers need. The second very important player is hardware extensibility. I have put a few pictures of the modules, but trust me, we have far more. We have like almost 20 modules now in the family. We have like three types. We call them the backside modules. Those are the guys, red guys on the right. And they define actually the functionality of the terminal blocks. If you remember, there were like two big terminal blocks. You can use two of these backside modules as the extension. And we provide interfaces like RS-45, precision analog inputs, all kinds of DC-DC converters. And we are usually adding the new additions to the family based on the application requirements. So these are the back sides. Then we have top cover modules. I've mentioned the satellite. It's one of the examples. But we also have recently added this display module, Chester D1, which offers the low-power LCD with capacitive touch buttons and many others. And the last, but not least, usually if out of the box, connectivity and mechanical constraints for this 130 by 180 millimeters enclosure is not sufficient. We are creating these green carrier boards with multiple interfaces, pluggable terminal blocks and so on. So still the base is clear. It's just the main board, which is certified and to which makes the whole ecosystem extremely versatile. The third pillar is low-power flexibility. We use 7.7 amp hour lithium-tionyl chloride batteries which can energize your application. Let's say we have a cellular application which sends data every half an hour. The typical question current is like 230 microamps, including Bluetooth beginning. This doesn't seem to be like the lowest ultra low-power number, but we have to also take into consideration there is overhead on the supercups, the leakage, some DC-DC converter, idle current and so on. But altogether, including NBIOT idle modes, it's like 230 and it will provide you with this battery of like three years of battery lifespan. And there is flexibility. So we have hardware logic which can prioritize if you have multiple available power sources, whichever goes first. Of course, the battery sources are prioritized. So anytime you connect solar photovoltaic cells or AC-DC converter, whatever, it's just used in the first place. So also we have a rechargeable module, we call it Chester Z, which is like one of the top cover modules. And that one provides like wide operating range and you can connect solar panels to it. It will charge the lithium ion battery and you can therefore use it in the night and day shift mode. So it has very low maintenance. However, if you go with primary battery and one is not enough, we also have solution. So we use carry boards to just connect multiple of these like in parallel. Of course, you're using shodky diodes to prevent any overcharging of the primary cells because that's the danger zone. And for example, this enclosure I have here on the slide, that one provides 112 amp hours. So we have a customer who actually asked that they want to send data, I don't know, every three minutes. I don't remember exactly, but they needed like five years of battery lifetime. So yeah, this was the answer. Each of those cells in this case, they have 17 amp hours. We have lots of real applications. We have been deploying this platform for a few years. This is like a famous application. This man in the forest became quite famous on the internet because we use it everywhere. And we cooperate with Vodafone in the UK. We monitor the environmental and impact of climate changes on the tree growth. So this trip you can see around this trunk of the tree, it's called dendrometer. And it provides proportional voltage as the trees are growing. And scientists are using all kinds of data that we are gathering like soil, moisture, temperature, environmental conditions to correlate like how this affects the tree growth. This is my favorite because we have a few partners that literally establish their business around Chester platform. We have a company called Stato Test and they are using Chester platform to monitor the inclination of bridges in very long term. And therefore they are sort of providing the predictive maintenance for bridges. And they have built all ecosystem like back ends, front ends and of course notification systems. And they basically reshape the product that is their own. Again, Chester is a platform to help the partners to build their own products. Also another partner, Adastra. Chester works well in retail for digitization. So we gather the real-time data from these so-called smart shelves and cooperate with some famous breweries to like monitor exactly how the cans or the beers are taken, which one are prioritized by the customers. And Chester monitors like 1000 pixels in the shelf and reports those data to the cloud platform where our partner Adastra creates their logic on top of it. Utility segment, this picture on the left, it's called cathodic protection monitoring. If you are distributing gas, you have to somehow protect these gas pipes against corrosion. And they do it the way that there are like negative voltage generators. And these have to be ensured that they are checked, that they generate that small like minus two volts negative voltage. And usually what they do, they send technician in the field, they measure the voltage by multimeter. Now and then they check it, they write it maybe with pen and paper. And of course this is something that can be improved. So we are working with one supplier for this utility segment and to use Chester again to using galvanic isolation module to monitor this voltage that it works. And things like cabinet environmental monitoring and similar. So in the world of IoT, you will find lots of overlaps. And we discovered that Chester is often used for similar use cases. This is why we have brought this concept of what we call catalogue applications. And we have like 10 of them today and it's growing. It uses the same ecosystem, the same Chester SDK running Zephyr. It's using this almost the same hardware foundation. And it's only about different application business logic implementation and different set of peripherals connected to it. I have an example here. This is called Chester Push. We use heavily in production for the so called unknown system. So for example if you want to reduce the reaction time when something goes wrong in the production line, you can have such a device that will change the state. We can label print some states for the requirements of the customer and they will immediately receive the notification and they can react to it. We have one installation in Chukor Auto where we have this bar LED strips in the hall like at the ceiling and they immediately know which station has some issue. That one was using Lora One. So we have all kinds of application for different purposes and we offer them like off the shelf and that implementation is open. So anybody and the developer that starts to create their own and something is similar, they can use this reference application as the boilerplate and start from there. We are coming up with a new one which is quite exciting because recently we have finished the implementation of the two-way communication and we are introducing the catalog application Chester control which will allow not just control of the relays but also quite advanced parametrics of the inputs and defining some logic between the inputs and outputs. And yeah this is what we are about to expand next to the developer's offering of the Chester. We have these ready-made products which are also immediately available in the stock. So next of course it's about ecosystem. We are like one puzzle but of course we built our foundation on top of the others as well. We cooperate with Nordic as I mentioned. It's our silicon vendor for Bluetooth and cellular and they created NRF Connect SDK which is the core foundation for Chester SDK and they inherit of course Zephyr which is I would say the best operating system ever for microcontrollers and we also have some technological partners such as Battery Check which is a vacant company, they have start-up and they are doing advanced battery analytics and using neural networks to analyze the state of the lithium battery, their state of health and they can again provide some predictive maintenance. They are now deploying systems which are related to safety critical applications for systems that are like sort of helping and preventing in fire emergency situations and Battery Check is using Chester to like observe the current from the battery, temperature, voltage and other conditions. And that is Sternum which is our new technological partners. Sternum is an Israeli startup which sort of provides very comprehensive software stack on the cloud and also for as an agent for the microcontroller and tooling which helps to basically adjust your application so and prevent cyber security threats before they happen. It's very advanced, they also provide traces, logging and the core idea is to make your devices in the field as robust and secure and safe as possible. Our connection to Zephyr and probably you know so it's more targeted now for anybody coming new to the Zephyr ecosystem. Zephyr was designed from the beginning for IoT devices with low power in mind, with security in mind and it integrates with vast ecosystem of projects and we jumped on it simply because we already used NRF or Nordic ecosystem before and Nordic has switched fully to Zephyr a few years back and we have followed and we like it because we realize that this is like another step, another ecosystem that encourages true portability and usability of your software components that you implement. Of course there is always some learning curve, it's not the easiest ecosystem to jump into but it improves quite a lot. There is always enhanced documentation and more and more resources are coming there and there are more and more use cases so there is way more inspiration than when we came to the ecosystem about three years ago and despite this still some leap to jump, I would say it is definitely worth and it's a good protection of your investments and true code in the future. How Chester looks from, it's called a firmware landscape. When you look at the board as an embedded programmer engineer you want to see like what are the core components that you care about. There are three, those two right, they are the Modems, Seller and Monata and they are connected with the application Bluetooth SOC through UART. There is traditional AT command style. For Seller Modem we are using reference implementation from Nordic called serial LTE Modem which always gets improved and on the board you will find three standard nine pin debug connectors and Chester SDK runs on the Bluetooth part. The software stack as you know the WEST workspace is composed of so many repositories. Luckily the WEST tool makes the management of these very easy and this is the like onion like structure but of course those folders are sitting next to each other. We start from Zephyr and RF Connect SDK inherits that as a sub module we inherit an RF Connect SDK log to some specific version and you can go on and on. And another great thing about Zephyr is hardware obstruction. So I always like to use this example maybe remember when I talked about those carrier boards sometimes we need to move this LED on the carrier board in a bigger enclosure to another spot. So this is where Device 3 really helps to abstract the hardware definition and the implementation and transferring the LED to a GPIO expander sitting somewhere else was as easy as changing a few words and applying the Device 3 overlay. We usually do it through the shield subsystem and I have changed just a few letters and magic happened. So this is why it's great. Modularity is another cool feature of Zephyr. It's Zephyr I would say it's like a framework which is almost like enforcing that of course you can always fight it back but why would you? And the goal is to guide you and keep true independence of the blocks and avoid cross-dependency. Here on the right you can see as the very minimalistic snippet of Kconfig that you can put in your application folder. You can introduce a symbol, state that it's a boolean, give it some default values and maybe when the symbol is selected enabled it can imply like the selection of some other symbols. And then you need to of course if you have Kconfig in your application structure you need to also instruct the Kconfig system that it should continue with Zephyr standard Kconfig processing. And in your PRJconf file which defines like how those options are used you can just use config underscore the symbol name and give it the selection. So that's one way like how you can embrace Modularity is to introduce these symbols and then use them later in CMake lists and apply the ad sub directory which is standard CMake command with underscore if that and reference that symbol. So this is the way like how you can have lots of modules in your project, in your subsystems and still keep it separate and minimalistic. Zephyr's philosophy is going always or being explicit. It starts from zero and you are adding new features, enabling new things on top of it. There is another nice neat thing that you can use Zephyr modules and that is like standard mechanism. You can add the modules folder in your application directory and the build system knows and you don't have to even alter the CMake file. You can keep things stick together. You can just add Kconfig CMake lists and your module implementation and this will be automatically included in your project. Next is coherence. This is another great thing because I was talking about avoiding cross dependencies. I talk about it here like what is the cross dependence if you have some let's say main.c and you are including lots of header files, every of those modules have some init function and they are calling one after the other. So Zephyr has mechanisms how it can save you from that. Of course, you will not reach 100% cross dependency avoidance probably. It's like holy grail. On the other hand, you can go with the sub modules and subsystems as much as possible thanks to, for example, sys init mechanism. So if you have an init function, you can implement it like you are normally used to and now there is this red circle. Does anybody know why I'm circling the void parameters of the init function? Okay, I'll tell you. In the past, this init function, it has to have the pointer reference to a device structure. This is like the same overlap if you are implementing Zephyr driver. The parameter has to be there. With the latest release 3.4.0, they have made enhancement because it didn't make sense to enforce the developers to use a reference to devices. You can now avoid that because it will also match this like unit implementation and you can use like this format without this written on parameter. And you can just use this macros in it, give it the name of the function, tell what is the Zephyr boot stage, what is the boot priority, which is number 0299. 0 is the highest priority, 99 is the lowest. And that's it. You just include it in the build and Zephyr puts the reference to this function to a table and based on the priority, it will be automatically called for you. Great, you don't have to be explicit about calling init. And of course, you can use the build time constraints like build assert to actually make sure that if you are referencing something in your init function, that that particular module will be initialized before you. So usually the practice is that at the end you insert build assert and you define the constraint that the priority of your module is lower than the other one you are referencing. Also we have apart from init other things that are really helping this coherence which is logging. You can see here on this line this log module register where you define the logger module name and what is the minimum level. So on each of those modules in your application you can define individual log levels. There is also shell. Maybe you have already worked with it. I will show it in a bit is that you can create your own custom commands and again they can be coherent to the given C file implementation. And settings very often you need to store some parameters, some data. So as I said, again it's ready to keep it in the same place related to the module all together. So let's do a bit of demo. I will switch now to the terminal. And I will show here on my table I've got just the main board. It's a special variant, the dev kit because here from the bottom we have the spring terminals and you can swap and replace those extension modules which are defining the functionality for the terminal box. And I have connected segre jailing and power profiler kit from Nordic. Raise your hand. Who uses power profiler kit? Is there anybody? Okay, one, two, three, yeah. Well, guys, if you are a developer this is like really an available tool. It costs like $100 approximately. And we will start from there because the purpose of the power profiler kit is to energize your application and you can also use it to trace the power profile of your software. So when you connect to it, using this power profiler which works for all the systems, you can set your target voltage. Now I'm emitting the battery so I have 3.6 volts. I can switch it off. I can start like tracing the power profile and I switch it on. You see that something is going on in my application and it's powered. I can stop it. I can zoom it. I can analyze what is the average power consumption and what we usually do and we create some new implementation. We let it run for a few hours including all the new bands or whatever transmissions and we calculate the average current over the long course of time and therefore by simple division we can estimate by capacity of the battery what would be the approximate typical lifetime of the given implementation. So that's the power profiler kit. We actually distribute it as part of the Chester development kit including the J-Link. And now let's build an application. We will not build it like compile it but we will flash something we have prepared. Let's prepare application that is transmitting one wire thermometer temperature and sends it over a cellular over NB IoT network of Vodafone in the Czech Republic and we will see it, see the data in the cloud. Now I have moved my cable so it probably is connected. It will still work. So I have to reconnect PPK. Program now. So let's start it again. Yeah. Okay. Let's flash the firmware. The J-Link is connected and it's not just about hardware in hardware. We invest a lot into tooling and we have created the PiPay package, Python package called hardware. It has many modules. One of them is Chester and it allows you to do all kinds of things like flashing firmware, uploading firmware to hardware cloud, opening console. And now I'm flashing firmware with this weird set of hex characters that is actually like the secret that is generated for you in hardware cloud when you upload the built artifacts. And this is something that for catalog applications you can find in our documentation. So we have docs.hardware.com and if you go to Chester section and catalog applications and scroll down a little bit we have the overview of the catalog sets and then there is the list of firmware variants that are there for these applications. So there is a version, there is this identifier that I'm using right now in the shell and I'll just trigger the command low voltage. Maybe it's again connected. Maybe the target. Maybe the cable between PPK. Oh thank you. Yeah. That was it. So let's go back and try to flash it again. So now it's erasing the flash. Of course if the firmware is not downloaded locally in my cache it will download it and later it doesn't have to. Now it's flashing the memory and after verification we will start another sub command of this hardware package which is called console. So when I start it I will see this two panel terminal friendly app which on the right side provides the device logs. We have color differentiation for all kinds of local levels. There is four in Zephyr, it's info, warning, debug and error. And on the right side I've got this interactive shell. So I can use standard Zephyr shell commands that are built in there but also we have introduced a few. From standard Zephyr commands you can for example ask the kernel for time or you can do things like kernel reboot called and reboot the application. So on the right side you will see it starts from beginning. And you can easily introduce your own. So for example in our Chester SDK we have this config command. So let's check what it offers. So config allows you to for example show the current configuration of your project. And in command line style it dumps all the parameters that are there. You can copy paste it, you can share it and somebody somewhere else with the same set of commands can replicate the same settings for the given firmware build. You can also change it. However if you are changing now these parameters nothing is actually applied until you use config safe which is like a commit. It will write all the parameters to flash and it will start fresh. So you don't have to manage or implement the change management. For this IoT application you rarely change their configuration. So let's keep things simple. Just it's more important to have things atomic. So you keep changing the parameters as much as you like once you are the config safe and it will reboot. Alternatively you can do config reset which will trigger the factory default reset. Okay there is another command which is called info. It provides this command info show. Sorry info show. And here you can see the vendor information like serial number, the claim token for registration to the cloud, Bluetooth address, what is the hardware variant, hardware division and so on. And on the right side you can see already some things going on in the application. Actually the message was just sent and we will use that serial number 7984 to find it in hardware cloud and see the messages from it. So let's switch to the browser and open hardware cloud. This is the left one. Is it? This one looks like it's the button application. Yeah. So yeah this is 984. So a few words about hardware cloud. It's like our SAS which is optional. We don't enforce anybody using it but it's so much easy for our partners, for integrators to jump into it and focus on the added value of the data on the JSONs. It's not application platform today so we don't do dashboards, widgets, nothing like that. But the main purpose is to actually integrate and allow access through REST API or you can configure web hooks to immediately push the data as soon as they arrive from devices to your own services. And I can see that there is a message 1155, I assume we have to refresh it. Yeah. And there is 1243. We can see and explore the JSON structure. And you will see some envelope that is quite common for all those applications which are adding some diagnostic information. You can see some same stuff I just shown in a console from Info section. You can see uptime, you can see network parameters, the main number of the modem, IMSE number of the same IMSE, some network parameters, some onboard data, thermometer, accelerometer, and the useful data that you care about. There is this one wire thermometer and you can see the measurements which come as array with timestamp and aggregated values of minimum maximum average and median. So you can process it and push it to your time series database and below JSON, you will see the raw data. From this raw data, we have processed this JSON. Of course, we are talking about low power devices with optimization over NBOT and UDP and stuff like that. So we don't transfer JSON, we transfer seabor and we upload the so-called codec where we have like a binding between the integers and the dictionaries and also some metadata like how shall we process the values that are coming after the keys like division, multiplication, whether there is an arm and so on. And this way, we don't have to alter our backend processing pipeline, we can have a generic and device can push any arbitrary structure and if it uploads the codec, the hardware cloud can render JSON in any way the developer desires. So this is hardware cloud and I think that's the main part of the demo. I should have also mentioned that we've got Bluetooth application, hardware manager that is available for iOS and Google Play. And that one allows you to flash firmware to the units or open the console that I'm just showing you on the left side, this interactive shell and do it through Bluetooth. We don't have enough time to show all the tooling that we have, it's just to mention that this is the part of the ecosystem. Okay, let's jump back. So we are trying to be also active, proactive in Zephyr development and I've connected SDK, we have done ourselves a few contributions. I would like to also raise a special thanks to Tomas Strenger and Kaspar Friedrich who have contributed a lot to Onewire ecosystem. We were pushing this quite a bit and we have lots of applications in the field. Now, using this Onewire, it is well tested, it is fairly new, it's been around for about a year, merged in the main and I encourage you to test it. And Kaspar has also made drivers for the hardware Onewire bus masters. We have one implemented on the Chester main board and that is like a bridge from I square C to Onewire. The advantage for hardware Onewire bus masters is that you have the so-called active pull up. So you can reach much longer distances, communication distances than if you do just GPI autoglink. I know that one is I'll say more cost effective but it is I would say a trade off for many aspects. In the future, because we use a lot of shields, you have seen that we have many catalog applications. Each of the catalog applications, it's using some variants, depends what you connect to it. So we are using shields. It's a well established ecosystem in Zephyr but it has some limitations and recently Zephyr introduced the so-called snippets which is I would say a good replacement for the shields. It gives you a bit more flexibility and you can do like PRG overlays. Whereas with the shields you have to like the only with Kconfig files and that has some I'll say limitations because as we know Kconfig is one pass-through and it can get you to situations where you will have to explore what is the ultimately the output of the Kconfig if things don't get enabled as you requested. Also we really like the addition of Zeebus. Zeebus is very interesting subsystem to Zephyr because it allows you to do PubSub messaging and again it will allow you to decouple the components even better. So we are about to start testing this and implementing to some of our subsystems. Chester SDK from this Sunday I mean last what happened is open source it's on GitHub that is this Chester SDK repository with a few hundreds of commits and we are actively working on it enhancing it and now it is available to everybody under hardware of five close license which is very pervasive you can share it modify distribute it but of course like Nordic does it under the conditions that you use it with hardware related products but it can be a great source of inspiration because we are using some some corners of Zephyr which are only in the documentation and you don't find like examples references to it anywhere else so we hope that this will help also to others on how to use various things in Zephyr. So everybody can start with Chester Devkit it's got Sega J-Link this special mainboard version for developers a few a few extension modules that are attached to it using magnets like DC-DC converter RS485 extension module and the configurable 4 channel analog digital input module also there is this power profile kit and this is like I would say for any integrator the gray starting point of course it doesn't have to be exactly the Chester Devkit it can be any of our application but Devkit has advantage that it doesn't have super caps because super caps if you have it on table you want to do some power cycling and so on it's it's a burden yeah this is why we have even on the latest revision implemented the white LED from the bottom that this is activated by the push button that is just to make your life in the field a little bit easier because it's quite annoying if you have to wait like 20 minutes when you buy commands activate all LEDs from the from the front side you are waiting like 15 minutes before the LEDs discharged the super caps otherwise you can wait for the whole day long so this power LED will discharge it within like 20 seconds yeah so there's the difference no super caps on Devkit version because also super caps make it a little bit more difficult to tracing down like what your power current profile is currently doing in the software because it's filtering that out all those spikes yeah okay so thank you thank you for your attention we have a boot down there would number 33 so you are welcome to see us and discuss we have a few more gadgets on the table and yeah are there any questions please hello well I'd like to ask how you how do you perform the firmware update for the devices that are already in the field yes today we do it only through Bluetooth but as I was talking about the two-way communication that is like the first stage before we do it remotely this is very desired features you can imagine from all our partners and we have however taken some steps now we have in our chester tree a sample which allows you to build firmware with bootloader that allows for flashing from this 8 megabyte SPI nor flash so that's the first step and we will soon make a breaking change for all our catalogue applications that they will essentially have to be refreshed to using J-Link to change the bootloader to support that and there are multiple steps to coordinate to bring this but technically it should we shouldn't be that far from the goal because as we already have STP API interfaces to push some data from the cloud to the unit and we support bulk transfers so it's basically a few I would say long longer weeks before we deliver this functionality in Chester SDK and my second question is you saw you saw that some firmware that are stored in the cloud how do you use them oh yes okay so I was talking about this hard video Python tool so I'll go to console oh no I have just swapped some of the screens so I'll try to get it back mirror yeah Martin F10 doesn't work control F10 it's right no yeah okay so hard video and if he if he look actually in the Chester commands and we explore the app section there is another subsection called firmware it's a little bit nested now right and that one allows you to upload the artifacts so when you finish there's a fair build this command will actually look into your build folder and depends whether it's built with the bootloader so that is matched dot hex and update dot bin it will like sanitize them create the zip file and using this command you are enforced to use hardware or cloud API token so if you provide this together it will upload the artifacts and it will generate for you this this excellent small token and you will also receive email notification with the build with this so called Chester firmware page where you will also see the QR code and you can use the QR code with a mobile application hardware manager to scan it and flash it so it's like a file less firmware management and our partners are using that because it's simplifying the whole deployment the process so you can like deploy many times a day without hassle sharing attachments emails and so on thank you I want to ask how many devices you have in the field it's actually quite difficult to answer it's I would say between two and three thousand I didn't count exactly because some of them are clear we have them connected to hardware cloud and they are constantly streaming some data some of them are Laura one devices this is the second generation of Chester so I'm talking about this quantity but also we had the previous one which was not open source and we also have quite a bunch of them in the field so generally I think hardware cloud today is has registered like four or five K of devices so any more questions oh yeah we're talking like 50 minutes Jennifer we have time okay good so yeah thank you so much and enjoy the rest of the event