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

Blockchain

We've all become acquainted with cryptocurrencies like [Bitcoin](https://bitcoin.org/) and [Ethereum](https://ethereum.org/en/). Some of us have dived into the crypto market, exploring and investing in various digital currencies, familiarizing ourselves with the array of options available. Crypto investors are often drawn to volatile cryptocurrencies with fluctuating values, but ultimately, many end up converting their funds into stablecoins via pools on decentralized exchanges (DEXs). 

*Have you ever wondered how stablecoins maintain their equal value to the dollar on a distributed ledger?* USDT and USDC are two of the most talked-about stablecoins. These coins are not fully decentralized or algorithm-based, but they play a significant role in the cryptocurrency market. They are considered centralized because they are issued by specific authorities who ensure each coin is backed one-to-one by dollars, for which they charge a fee.

USDT, for example, claims to always be worth exactly one US dollar. However, there are some doubts about the actual cash reserves backing each USDT, as the issuer, Tether, sometimes lacks transparency in this area. On the other hand, USDC is known for its openness and regular audits of its dollar reserves. It's issued by Circle and Coinbase and also maintains a one-to-one value with the US dollar. Despite this transparency, the control over issuing and managing USDC remains centralized.

Now that we've briefly examined how centralized stablecoins operate, let's delve deeper into our topic.

## What are Decentralized Stablecoins?

Unlike centralized stablecoins backed by assets like fiat, gold, oil, or real estate, decentralized stablecoins are algorithmic. No central authority backs or controls them.

Blockchain technology operates on a decentralized ledger, creating a natural demand for decentralized stablecoins. These coins offer an innovative solution in the cryptocurrency world. They combine the stability of traditional currencies with blockchain benefits. Decentralized stablecoins use algorithms and smart contracts to keep their value stable, no matter the external influences. Let's explore how these principles work and how they ensure stability.

## Understanding MakerDAO: The Backbone of Decentralized Finance

In the vast landscape of decentralized finance (DeFi), MakerDAO stands tall as a pioneer, offering a unique solution to the volatility conundrum inherent in cryptocurrency markets. At the heart of MakerDAO lies a symbiotic relationship between two tokens: MKR and DAI. MKR, the governance token, empowers holders with voting rights, allowing them to actively participate in shaping the future of the MakerDAO ecosystem. On the other hand, DAI serves as a stablecoin, meticulously pegged to the value of the US dollar. But what sets MakerDAO apart is not just these tokens; it's the ingenious mechanism behind them.

The core concept revolves around maintaining the value of DAI in relation to the USD through a decentralized framework, achieved with the assistance of collateral and vaults - smart contracts that oversee collateralization.

### Here's how it Works:

A user deposits ETH or ERC-20 tokens as collateral into a vault. Based on the collateral, the user can mint new DAI tokens. However, there's a catch - the system imposes a minimum collateralization ratio. For instance, if the minimum ratio is set at 150%, the user must have at least $150 worth of collateral for every $100 worth of DAI generated. If the collateralization ratio falls below the minimum (e.g., 150%), the user must either add more collateral or face liquidation.

### Let's Illustrate this with an Example:

Imagine a user possesses 5 ETH, each valued at $200, totaling $1000. Assuming a minimum collateralization ratio of 150%, the user can generate a maximum of 667 DAI. However, for safety, the user decides to mint only 500 DAI, maintaining a comfortable collateralization ratio of 200%. In this scenario, the user secures their position, safeguarding against potential market fluctuations.

![im_1.png](https://strapi.suprabit.eu/uploads/img_1_1d36e38d5b.png)

If the value of the collateral increases, the user can generate additional DAI tokens. The system mints an over collateralization buffer of 500 DAI. In our example, if the price of ETH rises to 300 USD, the user can generate an additional 250 DAI tokens (if they wish to maintain a 200% ratio).

![img_2.png](https://strapi.suprabit.eu/uploads/img_2_6e2d1717dc.png)

On the other hand, if the value of the collateral falls to $500 (or below), the user can deposit additional collateral into the vault. The collateralization factor stands at 150%, allowing a maximum loan of 1,000 DAI, calculated by dividing 1,500 by 1.5. Another user, known as the keeper, can liquidate the contract. The actual loan amounts to 500 DAI, resulting in a collateralization ratio of 300%.

The keeper sells enough collateral to gather the DAI tokens needed to repay the vault. The keeper keeps a certain fee and returns the remaining collateral to the user's vault.

![im_3.png](https://strapi.suprabit.eu/uploads/img_3_197971a0fa.png)

Conversely, if the price of ETH drops to $150, with the collateral now valued at $750 and the ratio standing at 150%, the keeper will sell 3.33 ETH for 500 DAI and return it to the vault. They will retain 0.2 ETH as a fee, while the remaining 1.47 ETH will be returned to the user's vault.

![im_4.png](https://strapi.suprabit.eu/uploads/img_4_3a15ad08dd.png)

## Ensuring Stability and Sustainability in MakerDAO

As MakerDAO continues to revolutionize the landscape of decentralized finance (DeFi), it uses various mechanisms to maintain stability and foster sustainable growth within its ecosystem. Let's explore these mechanisms:

- **Stability Fee:** This fee has a variable interest rate applies to all vault users who generate DAI tokens. It serves to regulate the DAI supply and is crucial for keeping its value stable relative to the pegged currency (USD).
- **DAI Savings Rate (DSR):** On the flip side, the DAI Savings Rate offers a variable interest rate that DAI token holders receive. To earn DSR, holders must deposit their tokens into a specific smart contract. Note that the DSR remains lower than the stability fee, motivating users to borrow DAI instead of holding it.
-  **Debt Ceiling:** To prevent excessive expansion of the DAI supply, MakerDAO imposes a debt ceiling. This ceiling limits the maximum amount of DAI that one can generate in a particular vault, depending on the collateral type. This control helps keep the system within safe limits and protects against risks from too much issuance. If liquidation fails to cover the outstanding debt of DAI tokens, the system covers the shortfall using the collected stability fees. This mechanism keeps the system solvent even in adverse market conditions, bolstering confidence among users and investors alike.

## Governance and Initiatives within MakerDAO

At the core of MakerDAO's decentralized governance model lies the MKR token, serving as the mechanism through which stakeholders influence the protocol's parameters and direction. Let's explore the role of MKR token holders and other participants within MakerDAO.

### MKR Token Holders:

MKR token holders wield significant power within the Maker protocol. They actively participate in governance decisions, ranging from adjusting protocol parameters to voting on the distribution of surplus funds. In the event of a failure of debt repayment mechanisms, MKR token holders can mint new tokens and sell them to cover outstanding debts. However, this dilutes the ownership stake of existing MKR holders.

Additionally, in the event of system malfunctions or emergencies, MakerDAO has provisions for an emergency shutdown, ensuring the protection of user funds and the integrity of the protocol.

### Motivations and Initiatives:

MKR token holders are incentivized to manage the platform effectively, as the value of their holdings correlates with the success and stability of MakerDAO. They have a vested interest in maintaining the integrity of the protocol and making decisions that foster long-term sustainability.

Keepers, on the other hand, play a vital role in the ecosystem by executing liquidations and earning fees for their services. Users also play a crucial role by utilizing the platform for various purposes:

- Users may choose to collateralize their assets (such as ETH) rather than selling them, anticipating future appreciation in value.
- They may leverage the platform to access additional liquidity, either by minting DAI against their collateral or utilizing financial leverage to increase their exposure to assets.

###  Maintaining the DAI-USD Peg:

To ensure the stability of DAI's peg to the USD, MakerDAO implements various strategies:

- If the price of DAI exceeds $1, users can lock additional collateral to mint new DAI tokens, subsequently selling them on the market. This increases the supply of DAI, driving its price back towards $1.
- Conversely, if DAI's price falls below $1, existing users may buy DAI from the market and return it to the vault reducing the supply. MakerDAO may also increase the stability fee to incentivize users to return DAI to the vault, thereby stabilizing its price.

Through these mechanisms, MakerDAO endeavors to maintain the stability and integrity of the DAI stablecoin, ensuring its usability and reliability within the broader cryptocurrency ecosystem.

![im_5.png](https://strapi.suprabit.eu/uploads/img_5_3edbe10d03.png)

## Conclusion

In conclusion, MakerDAO pioneers decentralized finance (DeFi) with innovative stablecoin solutions and governance.
Through decentralized governance, empowered by MKR token holders, MakerDAO ensures protocol resilience. With collateralized debt positions and smart contracts, MakerDAO maintains DAI stability while fostering liquidity and risk management. Incentivizing responsible participation and upholding the DAI-USD peg, MakerDAO commits to stability and sustainability. Leading DeFi with collaboration and innovation, MakerDAO sets standards for decentralized governance and stablecoin mechanisms, shaping finance's future.

large_photo_2024-04-24_07-39-21.jpg

medium_photo_2024-04-24_07-39-21.jpg

small_photo_2024-04-24_07-39-21.jpg

thumbnail_photo_2024-04-24_07-39-21.jpg

photo_2024-04-24_07-39-21.jpg

Explore MakerDAO's impact on DeFi and stablecoins, ensuring DAI's stability and robust governance.

Decentralized Stable Coins

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

As we step into 2024 with new resolutions, our team has been reflecting on the technologies that are poised to make a significant impact in the coming year. Among various innovations, Artificial Intelligence (AI) and Blockchain have particularly captured our attention. Let's explore what the future may hold for these transformative technologies.

## **Blockchain: Paving the Way for a Decentralized Tomorrow**

Several team members are enthusiastically shifting their focus towards Blockchain technology. They recognize its potential beyond cryptocurrency and envision Blockchain as a key player in creating secure, efficient, and transparent systems across various sectors. In 2024, their dedicated efforts will be focused on enhancing their full-stack development skills, with a particular emphasis on mastering design patterns relevant to Blockchain and other emerging technologies.

![BlockchainAgency2024.png](https://strapi.suprabit.eu/uploads/Blockchain_Agency2024_545999260a.png)

## **AI: The Vast Realm of Possibilities**

When we asked one of our team members what he thinks, he simply replied with "AI stuff". The term "AI stuff" may sound simple, but it represents Artificial Intelligence's immense and mostly unexplored potential. Our team sees AI not just as a tech trend but as a game-changer in the making. From making everyday tasks easier to tackling complex challenges, AI is set to revolutionize our workplaces and daily lives. The real challenge and opportunity lie in turning theoretical AI concepts into practical and impactful business solutions. We're jumping on the bandwagon by providing our partners and clients with personalized AI experiences tailored to their business needs.

![AISolutionsAgency2024.png](https://strapi.suprabit.eu/uploads/AI_Solutions_Agency2024_02be6f5d17.png)

## **AI and Blockchain: The Dynamic Duo of 2024**

The merging of AI and Blockchain technology is something that really gets us excited. The amazing analytical capabilities of AI have the potential to greatly improve the security and efficiency of Blockchain networks. On the other hand, Blockchain can provide a strong and transparent foundation for applications driven by AI. With the growing regulation and popularity of cryptocurrencies, we think that 2024 could be a big year for the widespread use of these technologies, changing the way we interact digitally and the overall tech scene.

![BlockchainAISolutions.png](https://strapi.suprabit.eu/uploads/Blockchain_AI_Solutions_b0977e70e8.png)

As we welcome 2024, these insights not only showcase our excitement for the future but also demonstrate our dedication to remaining at the cutting edge of technological advancements. If you're looking to enhance your business with innovative AI or Blockchain solutions, don't hesitate to reach out. Send us a message through our [contact form](https://suprabit.eu/contact), and let's explore how we can propel your business into the future together.

large_Trends in 2024.png

medium_Trends in 2024.png

small_Trends in 2024.png

thumbnail_Trends in 2024.png

Trends in 2024.png

Discover the Future of AI and Blockchain in 2024! Our team shares insights on Blockchain's role in creating decentralized systems and AI's untapped potential in transforming businesses and daily life. We also explore the exciting synergy between AI and Blockchain and how this powerful duo can enhance digital security and efficiency.

AI & Blockchain in 2024: Embracing the Future

## 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

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

Internship


**First thing first: the team and the brainy stuff**

Before starting the internship, I wasn’t really feeling nervous as I felt I had a good understanding of the basics of both Solidity and blockchain. Also, my colleague shared some insider information with me regarding the atmosphere, so I wasn’t surprised by the openness of the team and their willingness to help me and the other interns.
Firstly, we slowly studied the stack and the task itself. Then we got familiar and learned to work with the new blockchain technology that enables easier management of smart contracts. We were excited to start developing our own solutions!

Since blockchain is still a quite new technology, you can learn something new about it every day, as long as you know what to search for. Us interns were involved in the whole development cycle starting from the very beginning. First, we went back and forth researching the technologies and deciding which ones would be the best for this project and the internship, before deciding on Scaffold-ETH.

**You’ve heard it several times already: tHErE aRe No STuPid qUEsTioNs!**


![mulan-mushu.gif](https://strapi.suprabit.eu/uploads/mulan_mushu_9349847d61.gif)

 

Well, I’m going to say it again, there really are no stupid questions in Suprabit. Around here, everybody is eager to help each other, be it solving a bug or replacing the coffee pod. Don’t waste your time asking yourself “What will they think of me asking many questions or the same question many times?” because nobody will turn their back or roll their eyes at you. They all know the common goal is gaining understanding and moving forward.
 
The atmosphere is chill and most enjoyable. Once you've had enough of the keyboard tapping, you can make your way to our local table tennis station situated inside the office. Ask away, someone will surely join you! (Beware of the boss, you have to let him win, otherwise...).
 
 
**Future opportunities**

The internship program was well planned and adapted to students with or without previous knowledge of blockchain technology. The people were great, and I enjoyed the entire experience. I'm grateful for the things that I’ve learned during the internship and I'm happy that I was able to stay at Suprabit as an employee after the internship had finished. I know that Suprabit will continue to support my growth and make me a better blockchain developer (and a better table tennis player)!
 
![DSC00401-min.jpg](https://strapi.suprabit.eu/uploads/DSC_00401_min_4b49f3e364.jpg)



large_WhatsApp Image 2022-10-26 at 13.44.46.jpeg

medium_WhatsApp Image 2022-10-26 at 13.44.46.jpeg

small_WhatsApp Image 2022-10-26 at 13.44.46.jpeg

thumbnail_WhatsApp Image 2022-10-26 at 13.44.46.jpeg

WhatsApp Image 2022-10-26 at 13.44.46.jpeg

This summer, I decided to spend my summer-break gaining as much knowledge on blockchain as possible. After a couple of hours of research, a few interviews and one solved solidity smart contract task, I landed my internship at Suprabit.

My Blockchain Internship at Suprabit!

## What and why? 👀

For starters, what exactly is Expo? Expo is a bundle of tools created around React Native to help you start an app very fast. It gives you the means to simplify the creation and testing of React Native App. With Expo, there is no need to directly use Xcode or Android Studio. That means you can finally develop for iOS even if you are not a Macbook lover.

What’s more, if you choose Expo, you will never have to touch any native Swift, Objective-C or Kotlin or Java code. This means you can rely on just your Javascript skills for developing a real-feel native app, ready to be used on both iOS and Android!
However, sometimes you still need to add some native code. We will go over the steps on how to do that as well!

## Setting up the project 💻

You can read all about getting started on [this link](https://docs.expo.dev/get-started/installation/), here we will do just a quick overview so you can get right into the important stuff.
The first step should be downloading the Expo Go app on your phone as well as installing the Expo CLI on your computer:
```bash
npm install --global expo-cli
```

Then you should enter the following command in the terminal and choose one out of four templates:
```bash
expo init-my-app
```

After installing the project, you can start the app by entering 
```bash
expo start
```

A QR code will now pop up on the screen, then you can scan the code from within the Expo Go app if you’re using Android, or directly from the phone's camera if you're using iOS.
Now you can see all the changes you’ve made within the app right as you make them.

## Adding native modules using plugins 📌

Sometimes during your development, you will need to use native modules not directly supported by React Native. Before switching to the bare workflow, you should check if there is a plugin available for the module you need. Expo uses plugins to generate and configure all the native code for a managed project. 

If there is a plugin available, you can easily add it to your project following these instructions.
First, you need to install the plugin of your choice. After installation finishes, edit the app.config.json or app.json file. Edit the expo key and put in the following code: 
```json
{
  "expo": {
    "plugins": ["@config-plugins/name-of-your-plugin"]
  }
}
```
Before being able to fully use the native module, you need to build the application in the development mode using EAS. You can read up more about building later in the article.
Now you can start your app with:
```bash
expo start –dev-client
```

## Permissions ☑️ 

Some native modules require the user to give his permission. With Expo, you don’t have to dig into the native code to handle permissions. It is again enough to just edit the app.config.json file. Here we will be adding [this Bluetooth plugin](https://github.com/dotintent/react-native-ble-plx), but the process is the same for any available plugin. 
For Android, you need to add a new permission field like this
```json
{
   "android": {
      "permissions": ['BLUETOOTH', 'BLUETOOTH_ADMIN'],
    },
}
```
For iOS, you need to do a bit more work. 
```json
{
"ios": {
      "bundleIdentifier": 'your.bundle.identifier',
      "infoPlist:" {
        "NSBluetoothAlwaysUsageDescription":
          'Our app uses bluetooth to find, connect and transfer data between different devices',
      },
    },
}
```
And that's it! Now your app will ask the user for his/hers permission on startup.

## Adding native modules with no plugins available 🖇️

Even though by using Expo we try to stay away from native coding, occasionally there is no other way to achieve some functionality. <br/> Up until recently, if you wanted to add native code, you needed to eject Expo altogether. That means that you wouldn't be able to use the Expo Go app anymore, but more importantly, you would need to remove all your plugins and add them to the native code by hand! Luckily, now there is a workaround and that is using Expo's new feature - the bare workflow!

If you want to use custom native code that isn't already in the Expo Go app, you will need to generate the native iOS and Android projects. To do that, first, you need to switch from managed to bare workflow. You do this by running
```bash
expo run:android
```
and
```
expo run:ios
```

Using the run commands will initially prebuild your project to generate all of the native code within your project directory. Keep in mind that you need to have both Xcode and Android Studio installed to do this. 
Now, you can test your native code on simulators, and continue to use the Expo Go for all other testing and development. You can’t access native code while using the Expo Go app, but you can still access and keep all of your plugins. 

After adding a plugin to the bare workflow, you need to run expo prebuild so Expo CLI adds required permissions to the Info.plist and AndroidManifest.xml. As before, anytime you add a new plugin, you need to build the app again.

## Building the app 🔨

To build the app, we will use [EAS Build](https://docs.expo.dev/build/introduction/). EAS Build allows you to build a ready-to-submit binary of your app for the Apple App Store or Google Play Store.
First, you will need an Expo Dev account. You can register [here](https://expo.dev/).

At the root of your project, you have eas.json, where you can find the four types of builds: dev-ios-simulator, development, preview, and production.
<ul>
<li>Development builds include developer tools, and they are never submitted to an app store.</li>
<li>️Dev-ios-simulator build is used to create the development build for the iOS simulator.</li>
<li>Preview builds don't include developer tools, they are intended to be installed by your team and other stakeholders, to test out the app in production-like circumstances.</li>
<li>️Production builds are submitted to the app store, they are meant for release to the general public or as part of a store-facilitated testing process such as TestFlight.</li>
</ul>


You can change the default value of the bundle identifier in the app.config.js file. By default, the build will be of production type. You can also specify the build type in your command.
```bash
eas build --profile development
```
After that, you can select the platform for which you want to build or you can skip that step by specifying the platform directly in the command.
```
eas build --profile development --platform all
```
The Android build will start immediately. If you chose iOS, log in to your Apple account.

When the build is over, go to the given link or scan the QR code and install the app.
Keep in mind that the app won't run with build types Development and Preview on iOS devices that are not registered on your Apple account.

In the development and preview build, the result for an Android build is the .apk file, while for the production build the result is the .aab file. If you want to change the type of build file, you will need to edit the eas.json file.
```json
{
  "build": {
    "preview": {
      "android": {
        "buildType": "apk"
      }
    },
    "preview2": {
      "android": {
        "gradleCommand": ":app:assembleRelease"
      }
    },
    "preview3": {
      "developmentClient": true
    },
    "production": {}
  }
}
```

You only need to make a new build if you add new native dependencies, or if you register a new Apple device in your provision profile and you want to run the build on it. 

## Conclusion 📝

With Expo's new features, you can finally use it for the whole development process. Adding plugins and native code has never been easier. Since the building process lasts only a few minutes, your clients can now get day-to-day updates on your progress! Other than that, definitely check out [the documentation](https://docs.expo.dev/) for other commonly used features.

Have fun and stay tuned for more! 📻 😊





large_expo.png

medium_expo.png

small_expo.png

thumbnail_expo.png

expo.png

See how Expo helps you in your development and takes care of native things for you.

Using Expo with React Native

# We needed a change

People say that the website is the face of the company, and that is indeed true. The website is often the first thing somebody sees about your company and if they see an IT company with a bad, ugly or non-functioning website, imagine what they will think about the company itself.

Our old website was kind of out of date and since Suprabit is a company working with cutting edge technologies and following modern trends, we had to update our website to better represent us - what we do and who we are.

# Choosing what we want

Before doing a project like this, we had to agree on what we want to show on our website, how to package it and how to put emphasis on things we think are the most important. After the agreement had been made, our designer had to make a design prototype and web development team had to design application architecture and select the technologies to work with.

# Development

Our designer used **Figma**, a vector graphics editor and prototyping tool, to create the design which our development team would have to follow. For content management, we selected **Strapi**. Strapi is one of the best headless Content Management Systems, it is open source, 100% built in JavaScript and very simple to set up. **Next.js** is an open-source development framework built on top of Node.js enabling **React** based web applications functionalities such as server-side rendering and generating static websites. Since we are already experienced in developing Next.js applications, it was an easy decision to select this technology for building our website.

Following the design in Figma, the development team built React components. Next.js was important here to render as much as possible on the server side, and then serve the client with components already populated with content from Strapi. This increases user experience as the client has much fewer requests per page and pages load much faster.

# Deployment

For deployment of our web application and even through the development process, we used **Docker** containers for both Strapi API and for Next.js app. **Docker Compose** came in handy for easier management of both containers with only few command lines in the terminal. **Digital Ocean** is our selected cloud service provider and during the development phase, we had set up a dev environment and deployed our application iteratively as it was being built and as new features were being added. To do that without connecting to the server and running several commands lines every time, we created a **GitHub Action** to do all of that for us, deploying the application version on the main branch.

Once the app was ready, we needed to make it run over HTTPS protocol, instead of HTTP, and finally update DNS servers to route www.suprabit.eu to our server. 

large_Suprabit-web-1440x810.jpg

medium_Suprabit-web-1440x810.jpg

small_Suprabit-web-1440x810.jpg

thumbnail_Suprabit-web-1440x810.jpg

Suprabit-web-1440x810.jpg

Designing a new look for our website. Selecting technologies and principles to build our website on, implementing them and finally deploying the website to cloud.