React

Development

Design

In the ever-evolving landscape of smart building management solutions, we are consistently committed to innovation and excellence. In this case study, we’ll explore one of our most remarkable projects – the Smart Sensor, a cutting-edge multi-sensor designed for ideal room climate monitoring. Today, we visit this groundbreaking technology to dive deeper into its capabilities and the impressive results it continues to deliver for our Swiss-based client, a leading building automation solutions provider.

![Mask group.png](https://strapi.suprabit.eu/uploads/Mask_group_017e145b33.png)

The Smart Sensor project was born out of the need to address the complex challenge of room climate and environment monitoring. This IoT system integrates an array of sensors, including those for temperature, humidity, volatile mixed gases, presence/motion, brightness (light intensity), and noise level. The real magic happens through sensor fusion, where data from these sensors is intelligently combined to provide precise information about the room's state. Mounted discreetly on the ceiling, the Smart Sensor captures critical environmental data and also communicates room status to users through an LED ring, where each color signifies different aspects of room occupancy, air quality, or cleaning requirements.

![Frame 10.png](https://strapi.suprabit.eu/uploads/Frame_10_24c5bbe3b7.png)


In this case study, we will explore the firmware, mobile application, and dashboard that make this technology a game-changer in smart building management.


## Holistic Approach
For this project, it was crucial to take a holistic approach. We needed to synchronize the embedded and IoT teams with our product designer and mobile app development team. From the project kickoff until the final bug fixes, the entire team worked collaboratively to create the perfect solution. We held team meetings with our client to discuss their needs, and then our teams planned together to ensure smooth coordination. The client’s product development team would provide the requirements, our designer would create the UI for the mobile app feature, and the IoT team would develop the firmware. At the same time, the mobile team would begin implementing the feature. This iterative approach allowed us to address any issues promptly, eliminating long waiting periods between different teams.

## Academic research
As we ventured deeper into the project, leveraging cutting-edge technology, we encountered a significant challenge with our sensors, specifically in obtaining accurate noise level measurements. Recognizing the critical need for precision, we decided it was time to elevate our approach. To achieve the highest level of accuracy possible, we visited a local university. There, we gained access to their quiet room—a space so tranquil that even the sound of a heartbeat can be heard.

![silentroom.png](https://strapi.suprabit.eu/uploads/silentroom_2acc2ccd92.png)

In this controlled acoustic environment, we diligently fine-tuned and calibrated our microphone sensors, ensuring they delivered the most reliable and precise results. This collaborative effort with academia underscored our commitment to excellence and demonstrated our readiness to go above and beyond to guarantee the Smart Sensor's exceptional performance in real room conditions.

## IoT Development
In the realm of IoT development, the Smart Sensor project represented a significant milestone for us. The primary goal of the Smart Sensor was to monitor room climate and environmental conditions, and to achieve this, we integrated a range of sensors, including temperature, humidity, volatile mixed gases, presence/motion, brightness (light intensity), and noise level detectors. These sensors were meticulously designed to work in concert, enabling sensor fusion to provide highly accurate information about the room's state.
![senzori.gif](https://strapi.suprabit.eu/uploads/senzori_2d6699f3ec.gif)

Our IoT-ready approach was a key element of this development, as the Smart Sensor implemented MQTT communication via IP/Ethernet. Additionally, we leveraged Bluetooth Mesh for seamless networking of sensors, enabling efficient communication between up to 16 nodes and a gateway device. This wireless networking capability allowed for real-time data exchange between devices through node-to-node communication. Bluetooth Beacon technology was employed to enhance interaction with the mobile application, providing precise device localization within the room.
![case study.png](https://strapi.suprabit.eu/uploads/case_study_b65d97440b.png)

Our work extended to the firmware, where we crafted a robust solution in C/C++ for the ESP32 with dual-core processing, ensuring the efficient operation of the Smart Sensor. This IoT development effort represents our commitment to innovation and excellence in delivering solutions that transform complex challenges into user-friendly, efficient, and highly functional IoT devices.


## Design
When developing the Smart Sensor mobile application, our design approach placed user experience (UX) at the forefront. Unlike many specialized applications that often neglect user-friendly design, we aimed to create an intuitive and enjoyable user journey from the very first interaction.

![App.png](https://strapi.suprabit.eu/uploads/App_4f1c2ef09c.png)

While prioritising UX over UI in the initial stages, we emphasized rapid iteration and user feedback to identify and resolve potential issues efficiently. Through constant communication among teams and a deep understanding of the possibilities and limitations of both sensor hardware and application, we crafted a seamless provisioning process for technicians, ensuring simplicity and error-proofing.

The design process involved some innovative solutions and out-of-the-box thinking, such as using unique colors and LED rings on sensors to aid technicians in precise sensor identification during provisioning. Thoughtful language choices, like replacing "Provision" with "Configure" and "Lock," were made to eliminate confusion and improve the user experience. This commitment to user-centric design not only resulted in a more intuitive application but also highlighted the profound impact of intentional language and iconography in creating a user-friendly interface.

![sensors.png](https://strapi.suprabit.eu/uploads/sensors_79eefbbaac.png)

Overall, our approach to design reflects our dedication to delivering high-quality, innovative, and user-centric applications that set new standards in the field of smart building management. You can read more about our design journey [here](https://suprabit.eu/article/smart-sensor-design).

## Mobile app development
The development of the mobile application for the Smart Sensor project was a crucial part of the solution. Our client required an app that would empower their technicians to efficiently provision the sensor, map out floor plans and networks, and configure settings effortlessly. Beyond the initial setup, the mobile app continued to play a pivotal role, enabling users to monitor and manage room conditions, as well as to update the sensors wirelessly. It acted as the essential link between users and the sensors. All of this added an extra layer of convenience to setting up and maintaining the whole system.

![Phone.png](https://strapi.suprabit.eu/uploads/Phone_3c26d79663.png)

Using the versatility of React Native with the convenience of Expo, our mobile team delivered a robust application that catered to both Android and iOS platforms. This cross-platform approach ensured that our clients had access to a wider user base, making it more accessible and user-friendly. The app seamlessly communicated with the sensor devices using Bluetooth Low Energy, providing technicians with real-time access to vital data. This capability was the key to the provisioning and setup of the Smart Sensor, making the commissioning process efficient and user-centric.

## Conclusion
In conclusion, the Smart Sensor project has provided us with valuable insights into smart building management solutions. Throughout the project, our teams worked together to develop software for an advanced IoT device that seamlessly monitors room climate and environmental conditions. We prioritized precision by consulting with academia to fine-tune sensor technology.

Our IoT development efforts, including MQTT communication, BLE Mesh networking, and iBeacon technology, set new benchmarks for real-time data exchange and device localization. Additionally, we created a user-centric mobile application that simplifies provisioning, configuration, monitoring, and updates for technicians.

The Smart Sensor project not only met the requirements of our client but also pushed the boundaries of sensor calibration, IoT development, and user-friendly mobile applications. As we look towards the future, our commitment to innovation and excellence remains, and we eagerly anticipate developing new smart building solutions.




large_case study-2.png

medium_case study-2.png

small_case study-2.png

thumbnail_case study-2.png

case study-2.png

Read all about how we reinvented the Smart Building Industry using our IOT, design and development expertise.

Smart Sensor - Case Study

Sauter introduced the[ Smart Sensor viaSens](https://www.sautersmartsensor.com/en) - an Internet of Things device that transcends conventional sensing capabilities and takes monitoring to the next level. By tracking key parameters such as temperature, humidity, air quality, motion, brightness and sound pressure level, the Smart Sensor provides invaluable data. This wealth of information is harnessed to empower automation and control systems, resulting in smarter and more responsive office spaces that cater to users' needs. This product is the result of a great collaboration with our Swiss-based partner [SAUTER](https://www.sauter-controls.com/en/), a premier Smart Building Automation manufacturer with a global presence. 

What sets this device apart is its incorporation of BLE Mesh technology, facilitating seamless communication among devices. The Smart Sensor isn't just a leap forward in sensor technology; it's a game-changer in creating interconnected, intelligent ecosystems for enhanced workplace experiences.


![smart-sensors.png](https://strapi.suprabit.eu/uploads/smart_sensors_f428a6fec2.png)

## BLE Mesh 

Bluetooth Low Energy (BLE) Mesh is a communication protocol crafted specifically for  Internet of Things (IoT) devices. This protocol extends the capabilities of traditional Bluetooth  Low Energy, paving the way for the creation of expansive, reliable, and secure networks.  Unlike traditional point-to-point Bluetooth connections, BLE Mesh allows devices to form a mesh network, enabling data to flow seamlessly through the network, extending both the range and the overall coverage. 

Key features of BLE Mesh include low power consumption, robust, mandatory security mechanisms, and strict adherence to Bluetooth SIG standards. These qualities collectively make BLE Mesh a powerful solution for constructing interconnected wireless networks, opening new possibilities for diverse IoT applications. 

Within this network topology, we employ a sophisticated structure featuring a primary node known as the gateway, alongside up to 15 interconnected nodes that communicate through  Mesh technology. The gateway plays a pivotal role as it acts as the bridge connecting the sensor nodes in the network to the vast realm of the Internet. It stands out with its MQTT  capabilities, assuming responsibility for the subsequent transfer of data. 

Each node in this intricate setup serves a unique purpose - collecting valuable data and establishing communication channels with the gateway. Direct communication occurs if nodes are within range, while a relay node facilitates communication when direct interaction is not feasible. This strategic architecture ensures efficient data flow and a robust network,  exemplifying the power and versatility of the BLE Mesh network design.

![network-topology.png](https://strapi.suprabit.eu/uploads/network_topology_c99f98c12e.png)

## Wireless (OTA) Update 

Over-the-air (OTA) update represents the wireless delivery of new firmware to embedded devices. This transformative technology empowers manufacturers and developers to enhance device functionality, address bugs, and fortify security - all without the need for physical access to the device. 

In a landscape where thousands of Smart Sensor devices adorn ceilings within a single building, the impracticality of manual physical updates is evident. The wireless update approach not only streamlines maintenance but also minimizes downtime, contributing to an enhanced overall user experience. 

However, implementing this feature posed a challenge as only the gateway had fast Ethernet connectivity, leaving other devices without direct access. The key question was how to initiate updates. Despite the nodes lacking Ethernet connectivity, a clever solution emerged - upon receiving a trigger, the BLE mesh nodes could activate their Wi-Fi capabilities. Leveraging their additional functionality of iBeacon advertising and scanning, we opted for a custom-made iBeacon packet as the trigger. A mobile app then became the initiator, serving as the primary source for the new firmware and orchestrating the entire OTA update process temporarily over WiFi.

![ota-update.png](https://strapi.suprabit.eu/uploads/ota_update_0571db4537.png)

## iBeacon

iBeacon is a location-based service pioneered by Apple that harnesses Bluetooth Low  Energy (BLE) for proximity sensing, indoor navigation, and context-aware applications. 

The iBeacon packet format usually consists of three integral components: UUID, Major and  Minor values. When combined, these components form a unique identifier for each iBeacon.  As a Bluetooth device enters the range of an iBeacon, it interprets the UUID, Major and  Minor values, enabling applications to trigger location-specific actions or provide context-aware information to the user, as SAUTER uses it for Mobile Building Services. 

The Smart Sensor also integrates iBeacon technology, allowing users to enable or disable iBeacon advertising. But regardless of the advertising status, iBeacon scanning on the device is always active to receive the initiating OTA updated trigger. 



## Mobile Application 

<video loop="loop" autoplay="autoplay" muted style="width: 100%;">
  <source src="https://strapi.suprabit.eu/uploads/mobile_app_5d75341fe8.mp4" type="video/mp4">
</video>

In collaboration with Sauter, we designated the mobile app as the central hub provisioning the sensor network and the primary initiator performing the OTA updates. Functioning as a server housing the latest firmware versions in binary files and also as a mobile hotspot with a predefined SSID and password, it allows sending triggers and facilitating the OTA process on the devices. 

Within the app, users first need to select the Mesh network for updating nodes and then choose the firmware version they would like the devices to update to. Users have the flexibility to choose any available version, with the caveat that updates will only occur when transitioning to higher firmware versions than those currently on the device. 

Upon making these selections, the app prompts users to enable the mobile hotspot with a predefined SSID and password. Clear instructions for enabling the hotspot are provided for both Android and iOS users. Once the hotspot is active, the app starts broadcasting the beacon packet. This signal triggers the OTA update on devices within range and of interest. Upon receiving the beacon signal, the Smart  Sensor undergoes a series of checks. The update will only proceed if the received network ID matches the one under which the device was provisioned, the firmware version is higher than the current one, and the hardware index aligns with the device's hardware index. Subsequently, the device activates WiFi, establishing a communication link with the server. After starting the OTA update the Smart Sensor will display appropriate animation and reboot. 

![orange.gif](https://strapi.suprabit.eu/uploads/orange_af53966f82.gif)

## Fallback Mechanism 
When the OTA update is initiated, the device temporarily halts all its regular functionalities to ensure a smooth and uninterrupted update process. In the rare event that an issue arises during the update, a safety mechanism is activated by triggering a safe reboot, effectively reverting the Smart Sensor to the previous firmware version. 

To provide users with visual feedback in case of an unsuccessful update, a distinctive animation would be displayed. This serves as a clear indicator, enabling users to promptly identify and address any issues that may have occurred during the update process. If everything goes smoothly, the Smart Sensor viaSens reboots with the new firmware.

![red.gif](https://strapi.suprabit.eu/uploads/red_10c9b9ee36.gif)


large_blog-cover.png

medium_blog-cover.png

small_blog-cover.png

thumbnail_blog-cover.png

blog-cover.png

The Smart Sensor viaSens, developed in collaboration with SAUTER, introduces a leap in IoT technology by incorporating BLE Mesh and iBeacon for seamless OTA updates via a mobile app, enhancing smart building automation with advanced sensing of environmental parameters. 

Effortless OTA Updates for BLE Mesh Devices  via Mobile App

## Introduction to ESP32 and ESP-IDF Framework

The ESP32 is a popular series of low-cost, low-power microcontrollers with integrated Wi-Fi and dual-mode Bluetooth. These microcontrollers have gained popularity in the IoT world due to their robustness and cost-effectiveness.

To complement the hardware, Espressif developed the ESP-IDF (Espressif IoT Development Framework), a software development framework for the ESP32. ESP-IDF offers tools and libraries to efficiently develop applications for the ESP32 hardware, but perhaps the most crucial aspect of ESP32 and ESP-IDF is their approach to memory management.

The ESP32 microcontrollers feature both internal and external memory options, with internal memory being limited and precious. Managing this limited resource efficiently is key to ensuring smooth and reliable operation of applications, particularly in embedded systems where memory constraints are always a concern.

## Memory Management Challenges in Embedded Firmware

Memory management in embedded systems like ESP32 is a complex task. A typical issue revolves around the allocation and use of Internal RAM (IRAM) and External RAM (SPIRAM -external flash memory).

### Case Study: Troubleshooting Reboot Issues

My journey into memory management challenges began with a peculiar case where a network of ESP32 devices in an office setup experienced repeated reboots. The network consisted of one gateway (GW) and three nodes. Despite various firmware updates and fixes, the GW began to experience reboots with various errors, mainly stack overflows in certain tasks. Other issues were reports of corrupted flash memory and sudden device resets caused by a Watchdog Timer (WDT):


#### Memory leak 
The biggest problem I was dealing with was a nasty memory leak. I discovered it in the first place by monitoring individual task CPU and memory usage. A certain task that the device uses to display custom LED animations was handling new animation data incorrectly. Freeing of memory allocated for animation data was not handled properly and this would eventually cause the system to reboot. I only became aware of this after executing longer tests which periodically sent animation data to this task. 

#### Internal RAM limitations
While monitoring memory usage on the system, we've also observed that the ESP32's internal RAM was nearly exhausted, with about 98% usage. This was particularly concerning since essential functions and interrupt service routines (ISRs) are typically stored in IRAM for faster access. (IRAM also stands for Instruction RAM and should not be mistaken for Internal RAM -see picture). However, by examining data statistics it showed that I have ample Data RAM (DRAM) to use and this hinted to a possible solution.

![](https://lh7-us.googleusercontent.com/A26ZobJLdyh33dpst1Y56hA_0jQF2iqgQ4-UH5RagsXKyfNTMl_KYgV_Tg1NCfAO-9jEjErj26VUxG1sMatoiElNQcdZsgY0D_QhDHdZ45giMx43Dr7FMkf_Ad6xGfrpjH4x98p9oNRIYjlnDBE7hZQ)

#### The Watchdog (WDT) Conundrum
What frustrated me the most were sudden system resets caused by WDT. The device would just reset itself without a crash and therefore without any clue where the bug originated from. I only knew upon reboot that a WDT triggered a reset on the PRO CPU core of the device.

The ESP32 features two watchdog timers (WDT) for each of its CPU cores to ensure the system resets in case of a failure. However, in this case, the WDT reset always occurred on the PRO CPU, indicating a potential issue with task scheduling or interrupt handling.

I deduced that the APP CPU was stuck in a cache error case. Reboots were caused by a "cache disabled" error. By doing some research on the web, I found that this issue occurs typically when there is some sort of concurrent flash memory access. By force printing of logs before the WDT reset occurred, I managed to get some backtrace showing that the BLE MESH stack (feature of esp-idf) was storing message replay parameters into Non-Volatile Storage (NVS -part of main flash memory). 

I could also see that a certain timer interrupt handler was invoking a function FreeRTOS function xQueueSendFromISR() that is supposed to be safe for calling within interrupts marked with IRAM_ATTR flag (stored in instruction memory for quick access and execution of interrupt handlers) but clearly in some way accesses the flash memory. My theory is that this leads to triggering the panic handler which disables all watchdogs except for the system watchdog and subsequently reboots the device.


#### The Corrupted Flash Issue
I had an issue where the flash memory of the device was getting corrupted rendering the device unusable until you performed erasure of flash memory. It occurred rarely and only on a few devices, but the issue was a serious risk in mass production. Some investigation led me to believe this was a somewhat known issue with a particular series of flash memory chips, produced by XMC, which came with some of ESP32 boards installed in devices. For some reason, even Espressif did not manage to find that the flash chip can unpredictably receive random commands with a chance of disabling the normal functioning of the chip.


### Lessons Learned and Solutions

**Stopping a memory leak**

To effectively resolve the issues with the task of handling LED animations, I had to fundamentally re-evaluate and refine its underlying logic. My primary objective was to establish a foolproof system where all dynamically allocated resources were meticulously tracked and appropriately freed upon task completion.

Originally, my approach to managing shared resources between two asynchronous tasks involved the use of static pointers. While this method provided a means of resource sharing, it inadvertently introduced vulnerabilities, particularly in the form of memory leaks. These leaks occurred due to the inadequate tracking and releasing of the allocated resources, leading to gradual accumulation and eventual system instability.

I shifted my strategy to leverage the FreeRTOS xQueue to address these shortcomings. This change represented a significant improvement in communication management and resource sharing between tasks. The xQueue, a robust queue management feature provided by FreeRTOS, offered us a more structured and reliable way to pass data between tasks. This method not only facilitated better control over shared resources but also helped in systematically tracking and releasing dynamically allocated memory.

By implementing the xQueue, I could ensure that every allocation was properly accounted for and deallocated at the appropriate time. This approach effectively sealed the memory leak, enhancing the stability and reliability of the task. T

**Reducing Internal RAM Usage**

I was already using the feature where memory for dynamic allocation with **malloc()** can be allocated from SPI RAM (Serial Peripheral Interface Random Access Memory). SPI RAM is an external memory module interfaced through the SPI bus, expanding the available memory beyond the ESP32’s internal capacity. This type of RAM is especially useful for handling larger or more memory-intensive applications that exceed the capabilities of the microcontroller's onboard memory.

To make effective use of this expanded memory resource, I had to adjust the maximum **malloc()** size for allocating memory in internal RAM. By doing so, I ensured that more memory allocations would utilize the abundant external SPI RAM instead of the limited internal memory.

Configuring ESP-IDF options to minimize IRAM (Instruction RAM, used primarily for storing executable code and critical functions) usage also proved to be an effective strategy. This approach helped in preserving the valuable IRAM space for essential executable code and ISR (Interrupt Service Routine) handling, while larger and less critical data could be stored in the expansive SPI RAM.

By implementing these changes, I increased the availability of Internal RAM and reduced the risk of exhausting internal memory resources. This adjustment has been crucial in maintaining system stability and efficiency, particularly in scenarios where memory demand is high.

![Diagram.png](https://strapi.suprabit.eu/uploads/Diagram_2e245b02ed.png)

**Escaping watchdog reboots**

In this scenario, I addressed the issue of unexpected system resets triggered by the Watchdog Timer (WDT) by implementing a strategic change in how the timer interrupt handler operates. The key to resolving this was preventing the timer interrupt handler from executing while the cache was disabled. This adjustment was crucial because the cache disabled errors were leading to system instability and triggering the WDT resets.

The solution involved modifying the interrupt flag associated with the timer interrupt handler. In the ESP-IDF framework, when you add an interrupt handler, you specify certain flags that define its behavior and priority. Initially, my interrupt handler was using the **ESP_INTR_FLAG_IRAM** flag. This flag indicates that the interrupt handler is located in IRAM (Instruction RAM) and is safe to execute when the flash cache is disabled. However, this setup contributed to the WDT reset issues I was experiencing, likely due to conflicts arising from cache disabling.

To mitigate this, I changed the interrupt flag from **ESP_INTR_FLAG_IRAM** to **ESP_INTR_FLAG_LOWMED**. This flag sets the priority of the interrupt to a level that is between low and medium. By doing so, I reduced the priority of the timer interrupt handler, ensuring that it does not interfere with critical operations or run when it's unsafe to do so - during periods when the cache is disabled.

**Flash Memory Stability**

To address the problem of XMC chips causing the flash memory to experience corruption, Espressif's support team provided a solution in the form of a firmware vendor patch. This patch locks the Status Register permanently or until power-cycle effectively preventing the setting of write protection, countering the source of the error. Even if the flash chip receives random commands in the future, it can no longer lock itself.

The XMC flash memory chip has three 8-bit wide status registers (SR1, SR2, and SR3) that can be set. I opted for disabling write protection until power-cycle by setting the bits SRP1 in status register 2 to "1" and SRP0 in status register 1 to "0".  These Status Register Protect bits are one-time programmable (OTP) bits. With this strategy, you prevent the memory chip from setting write protection during runtime, but still leave the option to write to the status registers if the need arises.

## Conclusion

Managing memory in embedded systems like ESP32 requires a careful balance between performance and resource utilization. The ESP-IDF framework provides the tools and flexibility to optimize memory usage, but it demands a thorough understanding of the underlying hardware and software interactions. My investigation into the reboot issues not only resolved specific problems but also provided valuable insights into effective memory management strategies in embedded firmware development.



medium_Neki cipovi.png

small_Neki cipovi.png

thumbnail_Neki cipovi.png

Neki cipovi.png

Explore IoT firmware development with a focus on ESP32 and ESP-IDF framework. Tackle memory management in embedded systems and resolve reboot issues, memory leaks, and flash memory stability in ESP32 devices. Key topics include IRAM, SPIRAM, FreeRTOS, and WDT handling.

Investigating Memory Management Challenges in Embedded Firmware: ESP32 and ESP-IDF Framework


Hey there!

Just a short note before the introduction: when I first started writing this blog post, I was going into great detail about each screen in the application. Then, I realized that might be a bit dull for you to read. After all, there are tons of case studies out there that cover similar topics. They probably do a better job than I could hope to so I decided to change my focus. As a result, I present to you the challenges we faced during the project.

In the end, I didn’t even talk about the application much. Maybe I’ll have to write another post. 🤷‍♂️ Nevertheless, hope you enjoy reading this one!

![different smart sensors](https://strapi.suprabit.eu/uploads/Smart_Sensors_d1277e86e2.png)

<br/><br/>

## The rise of smart sensors

In the era of rapid digital transformation, the integration of smart sensors in buildings has revolutionized various industries. These sensors enable real-time monitoring of occupancy, energy consumption, air quality, and security. They optimise resource utilization, enhancing comfort, and improving overall building efficiency.

These intelligent devices provide valuable data insights and automate processes, leading to better efficiency and decision-making. However, the seamless deployment and management of smart sensors require a well-designed provisioning* app that technicians use to set them up.

**For those who are not familiar - in the context of smart sensors, provisioning refers to the process of configuring and setting up a sensor for its intended purpose and network connectivity. In most cases, sensors can be edited or reconfigured after they have been provisioned.*

<br/>

## Collaboration and synergy

The embedded team at Suprabit was already working on the firmware for the Smart sensor. During this time, our client, a Swiss-based smart building premier solutions provider, recognized a need for a user-friendly provisioning app. This app would help their technicians deploy and manage smart sensors easily. As a result, they asked us to design and develop a mobile app.

![best IOT team](https://strapi.suprabit.eu/uploads/best_IOT_Team_b0b9846ec6.png)


We embraced the challenge and took a unique approach to the development process. We designed and developed both the application and the firmware in the same team. This is, unfortunately, often not possible with IoT devices, since oftentimes different agencies work on firmware, application and design. But, the ability to approach the design and development of the app alongside the firmware team proved great. We had a thoughtful and iterative design process by keeping apps and firmware teams in sync.

<br/>

## Team effort

Since we were already working on multiple projects before, our tight-knit team had excellent synergy, aiding frequent collaboration and problem-solving.

This allowed us to address technical questions about hardware or firmware quickly and efficiently. Either by turning to a team member or through a short Discord call if we were working remotely. During the design and development process, we used a highly iterative approach. To ensure a great provisioning experience for users, we needed to adjust the firmware code to incorporate design and application improvements. We also had to adjust the application and design to accommodate firmware improvements.

By working together so closely and having instant feedback, we were able to make the best design choices. In the end, we created a high-quality, user-friendly provisioning app that met our client’s needs and exceeded their expectations.

> Through this synergy of different fields, we were able to create a provisioning process that neither application developers, firmware developers nor designers could come up with on their own.

<br/>

## Don't ignore UX

There's this thing that infuriates me about applications that are highly specialized and made for a specific audience. More often than not, they completely overlook the importance of user experience. It is usually assumed that they can simply refer to some kind of manual or figure out how the process is working by trial and error - it’s not like they can switch and use some other application.

From the get-go, we believed that applications should always be easy and enjoyable to use, regardless of the user or number of users. The app's entire process should be understandable from the moment it is first opened. In fact, we aimed to make the app so intuitive that the process would be understandable from the first time you open the app.

![Smart Sensor Mobile App Screens](https://strapi.suprabit.eu/uploads/Smart_Sensor_Mobile_App_Screens_656920a924.png)


<br/>

## The early stages

In the early stages, we focused on iterating rapidly, emphasizing user experience (UX) over polishing the user interface (UI). This approach allowed us to identify potential issues early and make necessary adjustments. This turned out great because there were numerous changes during this process. By not spending time on UI, we were able to move faster and more efficiently.

Our approach to the development process was highly iterative. We mock-tested bad designs early on, which allowed us to identify and rectify potential issues before spending too much time polishing the UI. This approach proved to be highly effective, and we moved faster and more efficiently toward a user-friendly application.

Throughout this period, all teams communicated constantly about the possibilities and limitations of sensor hardware and application. This was a crucial step, as it allowed all the teams to work as one big team and understand the possibilities ahead of us.

With the goal of ensuring simplicity and error-proofing, we designed the provisioning process to be as seamless as possible. Our foremost objective was to prevent technicians from accidentally locking the sensor with the wrong configuration.

Unfortunately (or luckily, regarding who you ask), we couldn’t just “copy” a UX/UI design for provisioning from Behance or Dribble because no one had done anything similar before.

<br/>

## My Precious: The LED ring

The first step in designing the provisioning process was to determine the hardware's possibilities and limitations.

The first obstacle we encountered is that sensors are typically set up in two steps by two people. First, they mount and power them on, and then they provision them.

The issue here was identifying the sensors in the app during the second step. With multiple unprovisioned sensors on the same floor, the technician needs to make precise identification of the sensor they plan to provision.

After consideration and brainstorming, we came to the conclusion that sensors should advertise their unique ID in the wild until provisioning is over. The app catches the ID and assigns a color to each sensor. The, LED ring on the sensor displays the assigned color to the technician in real-time.

![Different LED sensors](https://strapi.suprabit.eu/uploads/Smart_Sensor_Design_4bddc7ff14.gif)



This makes identifying the sensor easy, showing the technicians where the sensors are located on the ceiling. This ensures that the states in the app and in the real world are consistent.

This solution seems obvious now, but it was a crucial step in designing a user-friendly provisioning experience.

<br/>

## The Locking Puzzle: The provisioning process

### The problem

The next issue we stumbled upon was the locking of the sensors. Instead of sending their data through Wi-Fi or Ethernet (eliminating the need to set up cables or access points throughout the building), the sensors create a Bluetooth mesh network that transmits data to the gateway sensor that's connected to the internet.

Since sensors are provisioned into a Bluetooth mesh, the app can only communicate with them via Bluetooth during provisioning. Once the process is complete, they begin using Bluetooth to communicate with other sensors in the same mesh network. 
If there's an incorrect configuration, someone has to manually hard reset the sensors by pressing a device button. This is never ideal, especially when sensors are mounted on a high ceiling in a commercial space.

Through this process, a backbone of the design was created: a four-step provisioning process.

<br/>

### The process

Once a project (such as a single building) has been created, technicians can create networks for sensors to communicate on. These networks can be created per floor, or according to the client's requirements.

![Designing smart sensor provisioning process](https://strapi.suprabit.eu/uploads/Smart_Sensor_Provisioning_39bba5183d.png)



1. The first step to provisioning sensors is selecting the one you wish to provision. The application displays all unprovisioned sensors in the surrounding area. Each sensor has a unique color to aid the technician in selecting the correct sensor based on real-world data.

2. The following step prompts the technician to stand beneath the sensor. This step is crucial to ensure the strongest possible connection with the sensor.

3. After confirming their position, an animation will begin that is visible both in the app and on the real-world sensor. This step is essential to ensure the provisioning of the correct sensor. While this may seem unnecessary, we want to empower technicians to be certain in their actions and minimize any potential for errors.

4. In the final step, the user can add configuration for the selected sensor.

<br/>

## Designing with intent

For the provisioning process, we designed an icon for the smart sensor that changes color based on the color of real-world sensors. In the initial designs, we were just using simple colored circles to represent sensors. At first glance, this “illustration” may seem over-complicated. However, in initial tests, we noticed it allowed first-time users to make a stronger mental connection between the physical sensor and its representation in the application.

![Designing different smart sensors](https://strapi.suprabit.eu/uploads/Designing_different_smart_sensors_476b729dd7.gif)



Sometimes we want to abstract real-world elements to their bare minimum, simplifying them to basic shapes or symbols. However, the experience we had with the smart sensor icon reminds us of the importance of designing with intent. It highlights the significance of considering the users' cognitive processes and their ability to make connections between physical objects and their digital representations. By intentionally designing icons or visual elements that align with users' mental models and facilitate comprehension, we enhance user experiences and foster a deeper understanding of the system or product. This emphasizes the value of purposeful design decisions that prioritize user engagement over mere visual aesthetics.

<br/>

## Language is also design?!

Once one or multiple sensors have been configured, they must be provisioned into a Bluetooth mesh. In this step, we learned a valuable lesson about thoughtful design and language's impact on user interactions. The irreversible nature of provisioning sensors into the network posed unique challenges which made careful consideration essential.

We firmly believe that good design goes beyond just aesthetics; it extends to the words we choose to communicate with users. The terminology used can profoundly impact how users perceive and navigate an application. Hence, we dedicated time to ponder the best way to name each action during the provisioning process.

For those not familiar with the context, provisioning refers to configuring and setting up a sensor for its intended purpose and network connectivity. 

Unlike most cases, our sensors couldn't be edited or reconfigured once provisioned, which led us to avoid using the term "Provision" altogether. We were mindful not to introduce any connotations that word might have with technicians and cause confusion. Instead, we adopted "Configure" to signify the initial setup of sensors, and "Lock" for the actual process of provisioning them into the network.

To remove any confusion, we even went a step further and displayed the word "Lock" only on the popup window informing the user about the consequences of the action they were about to perform, and used a lock icon on the button.

<br/>

## Rethinking Symbolism

However, we soon realized that our approach had unintended consequences. The term "Lock" and its icon on the button created confusion among our initial test group. The symbolism of the lock did not represent a clear action. It didn't align with the actions technicians were accustomed to, and many of them forgot to press it. This left the provisioning incomplete. Despite explanations, they frequently missed the step, making it clear that the process wasn't intuitive enough.

Recognizing the need for a different approach, we decided to revamp the buttons. Instead of the lock icon, we introduced a clear "Finalize Provision" button. By incorporating a term familiar to technicians, the significance of finishing the provisioning process became more evident, and as a result, their memory lapses ceased to be an issue.

![Locking nodes process BLE Mesh](https://strapi.suprabit.eu/uploads/Locking_nodes_BLE_mesh_78f479c5ad.gif)



This experience taught us the immense importance of user-centric design. By understanding the specific context and needs of our users, we were able to craft a more intuitive and seamless provisioning process. It reinforced our belief that language and design must work harmoniously to create a truly user-friendly application. Through constant iteration and a willingness to learn from feedback, we successfully transformed a potentially confusing experience into a smooth and efficient one for our users.

<br/>

## Conclusion

In conclusion, the process of designing a smart sensor provisioning app not only taught us the significance of collaboration and user-centric design but also highlighted the profound impact of intentional language and iconography. By addressing challenges proactively and focusing on delivering a seamless and enjoyable experience, we successfully crafted a high-quality, user-friendly app that surpassed expectations. As technology continues to evolve, the lessons from this journey will undoubtedly serve as a strong foundation for future endeavors in designing innovative and user-centric applications.

SmartSensorMobile.gif

Step into the journey of developing a smart sensor provisioning app, as we shed light on the intricate design process, the critical role of user-centric design, and how collaboration led to an app that exceeded client expectations. A compelling case study for tech enthusiasts, app designers, and IoT professionals alike.

A Journey Through Designing a Smart Sensor Provisioning process: Bluetooth mesh

At first, the transition seemed scary since the two fields appeared to be worlds apart. However, as I delved deeper, I realized that embedded and mobile development share more similarities than I initially thought. So, let's explore how these two fields intersect and the skills you can use to excel in both.

# Things in common:

## Hardware limitations

Embedded developers are accustomed to working in a resource-constrained environment where every byte of memory and every clock cycle counts. This not only helps in writing efficient and optimized code but also develops a valuable skill set that can be leveraged in mobile development. Similarly, mobile development also requires optimizing battery life and processing power, making the transition from embedded to mobile development easier.

## Debugging skills

Debugging skills are essential for any type of software development. While there are several debugging tools available, such as logic analyzers or JTAG, what separates the experts from the novices is their methodical and analytical way of thinking, combined with patience and focus. A great developer can navigate through the maze of code, identifying and resolving issues efficiently and effectively, regardless of the technology.

## Knowledge of hardware interfaces

As an embedded developer, understanding hardware components and configurations is necessary for dealing with real-time issues. Power optimization is a key objective, given that embedded devices often rely on battery power. Similarly, mobile developers need to understand hardware configuration to troubleshoot communication failures and connectivity issues. Also, battery-related issues can bring down mobile applications, and knowledge of power optimization is essential to help track and resolve battery-related issues, as it can be the difference between a successful or underperforming app. 

## Handling interrupts and callbacks

Handling interrupts is common in embedded development, where a single device can handle multiple events, such as timers, buttons, and sensors. Since every interrupt is important and any of them can happen at any time, it is essential to have strong knowledge and a deep understanding of how to handle them properly. In mobile development, user inputs are handled as interrupts. Therefore, experience in embedded development is useful in learning how to handle user events in the mobile app properly. 

Callbacks are another fundamental concept in embedded development, where they can be categorized as synchronous and asynchronous. Mastering callback handling enables developers to manage events more effectively. In mobile development, asynchronous programming is crucial since most of the user interrupts in the mobile app are event-based.

# Biggest differences:

## UI

The focus of embedded development is creating software that integrates with the system hardware. Usually, the user interface on the embedded device doesn't exist and the user can interact with the device through small screens or buttons. However, in mobile development, creating an intuitive and appealing user interface is a focused aspect of the development process. As mobile applications heavily rely on user interaction, designing a user-friendly interface is key to delivering an enjoyable user experience.

## Devices

Embedded development focuses on designing and creating software that runs on one specific device, usually having a resource-constrained environment. Most of the embedded devices are very different so the software can be used only on the device that it's made for. On the other hand, mobile development is focusing on creating software that can work on a range of devices with different hardware specifications. The user might have different devices with different screen sizes, resolutions, and processing power, so the software must be flexible enough to work on all of them. Mobile development requires more consideration of device compatibility, while embedded development can be more tailored to the specific device it's running on.

# Challenges I faced when learning mobile development

As an embedded developer, I started my career mainly using C and C++ programming languages. For mobile development, I used [JavaScript](https://www.javascript.com/) and [React Native](https://reactnative.dev/) which were unfamiliar territories. Learning a new language is always tricky at first, but as they say, practice makes perfect, and with every new task, I gained more experience and confidence in the language.

Another challenge was making an application that is working on both iOS and Android platforms. In the end, as an embedded developer, I was focused exclusively on hardware development, so there were a lot of interesting challenges with creating user interfaces. But hey, what's life without a little challenge, right? 

# Advice to embedded developers interested in learning mobile development

As always, start by focusing on the fundamentals of mobile development. Take a common framework like React Native and learn its syntax. Then, try your hand at developing a simple app like a memory game or notes app, where you can learn more about user interface and asynchronous programming. After that, give yourself a bigger challenge and make an app that uses multiple screens, databases or even a hardware integration like BLE. Remember, the best way to learn is through trial and error, so don't be afraid to make mistakes and learn from them.

In conclusion, don't let the differences between embedded and mobile development discourage you from exploring new horizons. Instead, see mobile development as an opportunity to expand your programming skills and add another layer of expertise to your repertoire. Many of the skills you've acquired as an embedded developer are transferable to mobile development, such as memory management, power optimization, and debugging techniques. Embrace this challenge and use your experience to your advantage. Good luck on your mobile development journey!

Learning JavaScript and React Native as an Embedded Developer

large_Embedded to Mobile.jpg

medium_Embedded to Mobile.jpg

small_Embedded to Mobile.jpg

thumbnail_Embedded to Mobile.jpg

Embedded to Mobile.jpg

Picture this: I'm an embedded developer who's used to working on exciting projects involving smart building management. But after some time, I decided to shake things up and venture into the world of mobile development. 

Embedded Developer's Guide To Transitioning To Mobile Development



<div style="width:70%; margin:auto;">
<h2> What are embedded systems? </h2>
Embedded systems are computer systems with a specific function within a larger system. This includes all computing systems, such as home appliances, digital watches, cameras, avionics, and medical devices, except for PCs and smartphones. When classifying embedded systems by their main computing component, two of the most common types are microcontroller (MCU) and a microprocessor (MPU/CPU) based systems. There are also DSP, FPGA and custom ASIC-based systems. 


Microcontroller-based embedded systems are typically programmed either without an operating system, known as "bare metal," or with a real-time operating system (RTOS). Microcontrollers are cost-effective, single-chip computers that include a CPU, memory, and input/output capabilities on a single integrated circuit (IC). However, their specifications are limited compared to standard PCs, with less than 1MB of RAM and less than 8MB of flash memory, and typically only one CPU core with a frequency of less than 500MHz. Many 32-bit microcontrollers today are based on ARM Cortex-M CPUs.

In contrast, microprocessor-based systems, which are based on more powerful CPUs such as ARM Cortex-A, run Linux and have specifications more similar to PCs or smartphones. These systems, known as single-board computers, feature RAM, eMMC (flash), and various peripheral chips on the board, rather than on a single IC.

![1.png](https://strapi.suprabit.eu/uploads/1_a622eb8f94.png)

While microcontroller-based systems are generally more affordable and energy-efficient than embedded Linux devices, they also have more limited computing capabilities and feature sets. This blog post will focus on the unique characteristics of microcontroller-based embedded systems. However, as part of the Internet of Things (IoT) ecosystem, modern embedded systems are expected to have a range of features such as wireless communication, internet connectivity, and advanced sensors and actuators, all while maintaining cost and power efficiency. Careful consideration of both hardware and software is crucial for the successful design and development of these devices.

<h3> Optimizing power consumption </h3>
When selecting components for a wireless embedded device, it is important to consider factors such as suitability for the intended application, software and community support, market availability and cost. The microcontroller, RF communication chip, and sensors/actuators are the main components to evaluate. Factors like deep sleep functionality, communication interfaces, security options, processing speed, and memory of the microcontroller should all be taken into account to ensure that the device's requirements are met in the most optimal way possible.

<h3>MCU</h3>
Low-power MCUs on the market can typically achieve current consumption below 1 μA in their sleep modes. Some of these include ST's STM32L0xx, Silicon Labs' C8051F98x, Microchip's SAM Lx and TI's MSP430.
In our recent project, we used STM32L051 MCU and in its Stop mode, we were able to achieve 1.3 μA with Low Power Timer and Watchdog running.



 ![Microchip.png](https://strapi.suprabit.eu/uploads/Microchip_a7739c6ed3.png)


<h3> RF communication chip </h3>
When choosing an RF communication chip, it's important to select an appropriate wireless communication protocol that takes into account factors such as power consumption, range, and throughput. Factors that will affect the power consumption of the device are protocol frequency (sub-GHz, 2.4 GHz, 5 GHz, etc.), data packet length, the number of messages being sent within a certain timeframe, and signal power. Operating frequency affects range, power consumption, and throughput. Lower frequencies (sub-GHz) have better range and lower power consumption, while higher frequencies have better throughput. It's essential to keep the number of messages sent within a certain timeframe as low as possible for battery-powered devices, usually 1-2 messages every 10+ minutes. Smaller data packet length increases the throughput and power efficiency of a protocol, as it takes less time to transmit information and keeps the RF transceiver in active mode. With greater power, the range is increased, but so is power consumption. Low-power RF chips on the market can typically achieve current consumption in the nA or few μA range in their sleep modes, making them a good choice for battery-powered devices. In our recent project, we used AX5243 sub-GHz RF chip at 868 MHz with a custom protocol. In its Powerdown mode, we were able to achieve 0.8 μA.

![2.png](https://strapi.suprabit.eu/uploads/2_d19cc36535.png)
When choosing sensors/actuators, their idle current consumption should also ideally be in nA or worst-case few μA range.

Besides hardware, software choices and optimizations can also greatly affect the power consumption of a device; choosing the appropriate sleep mode of the MCU and RF chip, minimizing time spent in running mode of the MCU and RF chip, using only the lowest-power MCU timer while the device is in idle mode, setting MCU peripherals in low-power mode, etc.



<h5>Here are some important takeaways from our recent project with STM32L051:</h5>
<div style="background-color: #1D3656; padding:10px; border-radius: 4px; width:70%; margin:auto;">

</div>

<div style="background-color: #1D3656; padding:10px; border-radius: 4px; width:70%; margin:auto;">
<ul style="font-size:16px;">
<li  style="color:#ffffff">setting all unused GPIOs as analog inputs has reduced average current consumption by a few μA</li>
<br/>
<li style="color:#ffffff">ADC needed to be powered off after each measurement, otherwise it would add ~35 μA to average current consumption in sleep mode </li>
<br/>
<li style="color:#ffffff">although Standby mode has the lowest current consumption, in this mode SRAM and register contents are lost and only certain GPIOs can wake up MCU, so we've used Stop mode</li>
<br/>
<li style="color:#ffffff">in Stop mode, LSI is the only oscillator that works (and only timers whose clock source is LSI can work</li>
<br/>
<li style="color:#ffffff">LSI is unprecise, but it can be calibrated using an internal MSI oscillator and more precise e.g. periodic interval measurements can be achieved</li>
</ul> 
</div>




Wireless embedded devices transmit data in periodic intervals and spend the rest of the time in sleep mode, which minimizes the amount of time the microcontroller and RF transceiver are running and consuming power. However, if the running time is too long, it can significantly impact the average power consumption and shorten the device's battery life. To optimize power consumption, it's important to keep the duration of running time to a minimum, whether due to a periodic interval or an interrupt.


<h5>Here are some methods that we've used to minimize the duration of running time: </h5>
<div style="background-color: #1D3656; padding:10px; border-radius: 4px; width:70%; margin:auto;">
<ul style="font-size:16px;">
<li  style="color:#ffffff">compiler optimizations</li>
<br/>
<li style="color:#ffffff"> removing printfs/serial outputs  </li>
<br/>
<li style="color:#ffffff">making sure there's no polling or register flag checking that keeps device in running mode</li>
<br/>
<li style="color:#ffffff">checking whether higher MCU frequency (with higher current consumption, but shorter processing time) is better for power consumption</li>
<br/>
<li style="color:#ffffff">using constants/hard coded values instead of calculations if possible</li>
</ul> 
</div>

It's important to select an RTOS mode that is optimized for low power consumption, especially as the number of features increases, as RTOS is often required in such cases.

Finally, tools that we've used to measure current consumption are Otii Arc and a multimeter (just to double-check Otii Arc measurements). Also, it's useful to have measurement ports on PCB for measuring the current consumption of certain components separately (MCU, RF transceiver, sensors).

![pic1.png](https://strapi.suprabit.eu/uploads/pic1_6e7794a3ee.png)


With whole PCB average current consumption being under 5 μA (idle mode consumption below 2.5 μA), these devices can ideally last on one e.g. CR2032 battery (~230 mAh) for more than 5 years.

<h2> Optimizing memory usage </h2>
As projects need to be profitable, prices of the components are very important. But with lower prices, MCUs usually also come with smaller amounts of RAM and Flash memory. For example, STM32L051 has 8 kB of RAM and 64 kB of Flash memory . As the complexity of the application increases and the feature set expands, optimizing memory usage becomes necessary for these microcontrollers.

<h5>Here are some methods of optimizing memory usage that we've used in our recent project: </h5>
<div style="background-color: #1D3656; padding:10px; border-radius: 4px; width:70%; margin:auto;">

</div>


<div style="background-color: #1D3656; padding:10px; border-radius: 4px; width:70%; margin:auto;">
<ul style="font-size:16px;">
<li  style="color:#ffffff">compiler flags</li>
<ul>

<li style="color:#ffffff; opacity: 70%;">we've used GCC's <span style="font-weight:bold">arm-none-eabi</span> toolchain: <span style="font-weight:bold">-ffunction-sections, -fdata-sections, -fno-exceptions, -fno-rtti, -Os, --specs=nano.specs</span> (for using nano version of newlib)</li>
</ul>
<br/>
<li style="color:#ffffff">check out functions with the highest memory usage and try to optimize them</li>
<ul>
<li style="color:#ffffff; opacity: 70%;">for <span style="font-weight:bold">arm-none-eabi</span> toolchain: <span style="font-weight:bold">arm-none-eabi-readelf -s elf_name.elf</span></li>
</ul>
<br/>
<li style="color:#ffffff"> disable unused RTOS features</li>
<br/>
<li style="color:#ffffff">remove unnecessary printfs</li>
<br/>
<li style="color:#ffffff">remove double and float arithmetic <span style="font-weight:bold">__aeabi_</span>functions if possible</li>
</ul> 
</div>



That wraps up this blog post on memory and power consumption optimization for microcontroller-based embedded systems. We hope it'll turn out to be helpful in your current and future embedded projects too!

</div>

large_IOT BLOG (2).png

medium_IOT BLOG (2).png

small_IOT BLOG (2).png

thumbnail_IOT BLOG (2).png

IOT BLOG (2).png

In this blog post, we'll explore various ways of optimizing power consumption and memory usage of wireless embedded devices with examples from one of our recent projects.

Optimizing power consumption and memory usage of wireless embedded devices

Blockchain


## Motivation
Modern Smart Building Management solutions are fairly complex, comprising of a number of software modules supporting a variety of, often proprietary, protocols. When you add in all the front and back-end devices, automation stations, sensors and gateways, it can all seem like a real pain in the neck. But there is a clear economic benefit as functional smart building solutions are able to optimize energy consumption, provide better living environments and better security for building occupants, bringing your business closer to achieving that net zero goal. However, there are new issues regarding data security popping up every day, due to complexity, Internet integration and, more often than usual, slow adaptation to the newest technology stack. Traditional solutions relied on private networks where security was not such a big deal, but now, as every smart building solution provider offers Internet connectivity, the security paradigm changed. That left most solutions vulnerable to inside and outside attacks as well as data breaches. On the other hand, with the advancement of the Internet, many new use cases emerged that have the potential to significantly improve the ROI of smart building management solutions and enable more building automation in favour of building occupants and investors.  

This presents an obvious need to introduce a new data infrastructure layer to your solutions that will guarantee data security and data availability within a smart building management market. 

## Lavsa
Lavsa is a decentralized storage solution for smart building management, developed using blockchain and IoT technology. Our solution is taking in a stream of data and then replicating that data to every node in a private blockchain network. The newly added data sets are hashed and the hash is published on permissionless public blockchains like Ethereum, Polygon etc. By using blockchain(s) as an additional layer of security, we are improving integrity, immutability and availability. This is a step up from the traditional database model because, in Lavsa, every piece of data is distributed across a number of nodes and additionally hashed on a public blockchain, making it virtually impossible to fake, change or delete the data. At the same time, smart contracts are used to improve data relevancy, white and black lists and support new use case scenarios.  




![blockchain.svg](https://strapi.suprabit.eu/uploads/blockchain_77fbf6c69c.svg)





## Lavsa Goals
- Put the building data security, integrity and availability at the forefront of the Smart Building and IoT initiatives
- Establish trust among stakeholders of the building automation projects
- Enable higher level of automation
- Support integration with third-party building automation and business solutions
- Enable new disruptive business models 
 

## Lavsa Use Cases

Lavsa puts the data produced by a variety of smart building devices at the forefront of the Smart Building economy enabling new disruptive business models like 
- Data monetization and data markets
- AI solutions based on relevant building data
- Regulatory compliance
- Support for ESG initiatives 
- M2M payments
- Building Automation Infrastructure As a Service

If you have any questions regarding Lavsa, or if you are interested in discussing various Smart Building use cases - feel free to [contact us](https://suprabit.eu/contact) and let's give it a thought together.



large_androfin-min.png

medium_androfin-min.png

small_androfin-min.png

thumbnail_androfin-min.png

androfin-min.png

Back in 2018., the blockchain hype started to gain traction outside of the crypto scene and a number of enthusiasts proposed using blockchain for different business use cases. We had a vision to provide every party with relevant and tamper-proof data delivered by smart building sensors and devices. That data has to be so good that somebody wants to pay for it. Once you bought it, you want to have it ready at your disposal for further processing. And you want to be sure of its integrity.

Smart Sensor - Case Study

Effortless OTA Updates for BLE Mesh Devices via Mobile App

Investigating Memory Management Challenges in Embedded Firmware: ESP32 and ESP-IDF Framework

A Journey Through Designing a Smart Sensor Provisioning process: Bluetooth mesh

Embedded Developer's Guide To Transitioning To Mobile Development

Optimizing power consumption and memory usage of wireless embedded devices

Lavsa - a new kid on the Block