Preface: When I entered Tims Coffee, I immediately looked for that chubby figure. I didn’t expect to see Mingfei stand up, looking much slimmer and more energetic. It seems that the environment in Xi’an suits him better than Beijing, which is conducive to his deep engagement with LoRa!

Upon meeting again, two cups of Americano opened our conversation, as we listened to his twelve-year journey with LoRa and LoRaWAN from 2013 to 2025!

Today’s protagonist: Zhao Mingfei, Founder of Mansi Technology

After twelve years, here are the key points we focus on:

1. We emphasize standardized LoRaWAN, welcoming the integration of any brand’s LoRaWAN gateways and devices, as long as they are standardized.

2. Thinklink is our LoRaWAN NS, currently the only open registration in the country, and it is permanently free for small projects (less than 1000 device connections).

3. For independently deployed small projects, we currently promote the Thinklink all-in-one machine.

4. For customers using modules, we focus on standardized global frequency LoRaWAN, allowing customers to simply modify hardware for quick and easy implementation of LoRaWAN.

5. Our gateways have ten years of stable on-site operation experience, with numerous overseas projects, emphasizing “reliability” and compatibility with mainstream overseas LoRaWAN NS.

6. In the energy sector, we primarily focus on equipment collection in the existing market (DTU), which we have been doing for seven years.

1. This is a segment of memories

I first encountered LoRa in July 2013.

In July of that year, I witnessed a single-point coverage test of LoRa covering an entire seven-story building in Nanshao. As someone who had been using FSK for power projects since 2006, my first impression of this test result was shock. Previously, I was torn between using SI4432 or CC1101, struggling to expand communication distance while ensuring system stability with a complex mesh protocol stack. As I recall, in 2013, the State Grid had just begun implementing small wireless meter reading solutions, adopting a seven-level jump network architecture, which made the entire network complex and fragile.LoRa, with its spread spectrum approach, changed the dimension of wireless communication applications in the ISM band.

This was revolutionary.

After seeing LoRa in 2013, I decided to join the field of LoRa technology development. As an entrepreneur emerging from the State Grid system, metering was bound to be the first application scenario for LoRa. As one of the earliest companies in China to scale LoRa applications, we primarily focused on simple transparent transmission modules in 2014. The module size was relatively large, and its functionality was limited (see the first-generation module product in the image below), only providing transparent transmission functionality. Relying on LoRa’s super reception sensitivity, the simple transparent transmission module still held absolute advantages in many applications.

In 2014, many companies were promoting Zigbee and other mesh network solutions to increase communication distance. However, mesh methods have significant drawbacks: key nodes can easily form network bottlenecks, consume a lot of power, and many scenarios require the deployment of numerous APs, which can become pain points in project management, power supply, and construction.

LoRa stands out, but accepting new technologies is not easy, and we undertook a lot of foundational education on LoRa.

Fortunately, we had the luck of new players entering the market. A company encountered communication distance issues in Africa. In Africa, electric meters are split, with the meter located outdoors on a pole and an indoor terminal used for recharging via purchased recharge cards. Communication between the indoor terminal and the outdoor meter was necessary, but FSK faced communication distance limitations, and previous meter manufacturers had failed in testing in this scenario. LoRa emerged at the right time, and we quickly seized the opportunity for testing and collaborated with the customer for rapid product development. This first-generation module achieved a shipment volume of 250k pcs in 2014, becoming the largest module product and application in LoRa’s history for that year.

In 2014, we began to attempt more complex applications, and by the second half of the year, we developed the automatic networking function for electric meters. In simple terms, in the meter reading application, there are roles for both collectors and concentrators, where collectors manage multiple meters, and concentrators manage multiple collectors, forming a three-level network architecture. This network architecture originated from the early RS-485 meter reading system, requiring proper management of meter records in both collectors and concentrators. However, with LoRa’s extensive coverage, a new problem arose: how to achieve cross-coverage of meters by collectors or concentrators. When a meter is not within the coverage of collector A but is within the coverage of collector B, data collection should still be possible without modifying records.

2015 was a special year, as Mansi Technology became a pioneer and leading company in the LoRa industry. Despite some innovations in communication modules, they were still too simplistic. It was also the year the LoRa Alliance was established, and Semtech launched the gateway chipset SX1301, capable of receiving and processing 8 frequency points across 49 channels. The LoRa Alliance, in collaboration with several operators and companies including Cisco and IBM, introduced the low-power wide-area network protocol LoRaWAN.

In terms of business direction, Mansi Technology faced two choices: Plan A was to dive into metering applications, providing PCBA solutions for the water and gas meter industry, effectively creating a vertical application market for LoRa. Plan B was to develop LoRaWAN modules, gateways, and NS, entering the seemingly larger market of general communication link products.

Plan B required us to fill more technical gaps, necessitating the development of a Linux-based gateway, while the previously used STM8L MCU struggled to accommodate the LoRaWAN protocol stack, and our software technology reserve was limited to C#.

At the time, Plan B appeared to have a significantly larger application space, encompassing not only water and gas meters but also smart agriculture, intelligent buildings, environmental monitoring, and industrial instruments. Plan A was merely a component in a vertical application.

We chose Plan B and became a member of the LoRa Alliance in its founding year, 2015. In October of that year, we managed to fit the LoRaWAN protocol stack into the 64k Flash space of the STM8L MCU, with the first-generation LoRaWAN gateway based on the MQX (a real-time operating system based on a preemptive kernel) system, and the first-generation LoRaWAN NS was also developed in C#. As one of the first members of the LoRa Alliance, we showcased our full-stack LoRaWAN products at an exhibition in Rotterdam in October. Alongside us were four companies, including the now-defunct August Technology, showcasing the first generation of LoRa enterprises. These companies, once at the forefront, gradually exited the LoRa technology field for various reasons.

New players continued to enter the market, and the LoRa ecosystem flourished, with Mansi Technology still thriving today.

In October 2015, several domestic companies gathered in Rotterdam, looking forward to the future while also receiving new information: Huawei had acquired a UK company and launched a new narrowband technology solution, NB-IoT. Huawei’s goal was to write NB-IoT into the 3GPP standard, expanding the LPWAN market through operators deploying NB-IoT networks. This would essentially create a triad in the LPWAN field consisting of LoRaWAN, SigFox, and NB-IoT. LoRaWAN has consistently followed an open, open-source approach, targeting more enterprise-level private network application scenarios; SigFox is closed, building its own network globally and operating as an operator, while NB-IoT promotes its network through operators. We could only participate in the LoRaWAN ecosystem, and given Huawei’s influence, there were underlying concerns about the future market prospects for LoRaWAN. However, this concern was quickly drowned out by the optimism based on technical perspectives: the inherent disadvantages of narrowband technology, lower reception sensitivity than LoRa, and significant differences in power consumption.

However, the reality was that during the promotions in 2016 and 2017, the impact of NB-IoT was substantial. Huawei’s promotion of the technology, along with strong support from operators, made NB-IoT and LoRa the two shining stars in the LPWAN market. Various LPWAN applications emerged continuously, but beneath the surface of prosperity, our shipment volumes in 2016 and 2017 were not ideal. Many were POC projects with personalized demands, and we were exhausted by these individual requirements with little output. Each project seemed to have vast market potential, but most ended up fizzling out. Meanwhile, the domestic LPWAN market inevitably split into two factions: those insisting on the LoRa ecosystem, primarily driven by technical thinking, firmly believing in LoRa’s superior reception sensitivity, low power consumption, and flexibility over NB-IoT, while many manufacturers adhering to NB-IoT were focused on vertical market applications, backed by Huawei and operators. Although large-scale network deployment of NB-IoT truly began at the end of 2017, many companies were still observing during 2016 and 2017, leading to less than stellar market performance for LoRa manufacturers.

After the LPWAN market promotions in 2016 and 2017, the need for repeated market education to convince users of LoRa’s high reception sensitivity and low power performance was no longer necessary. The focus of market promotion shifted to distinguishing and differentiating from NB-IoT, with almost every customer’s inquiry including comparisons with NB-IoT.

2017 was a challenging year, marking the industry’s low point.

The turning point came with the entry of internet companies. First, Alibaba announced a partnership with China Unicom to enter the LPWAN market, vigorously promoting LoRaWAN applications in China. Following that, Tencent and JD.com joined the LoRa Alliance, bringing internet companies into the LoRaWAN market, and with the initial scale of the NB-IoT network, the LPWAN market began to enter a true state of mixed competition and prosperity. We were fortunate to experience a year of joint debugging with Alibaba in 2017, and in 2018, we received strong support from Alibaba, first winning the bid for the metropolitan network deployment promoted by Alibaba and China Unicom, followed by winning the bid for the smart energy project in the Cainiao Park.

2018 was our golden year, during which we laid a private network in Hainan with a certain tower company and began the coal-to-electricity network deployment in Tongzhou, Beijing, becoming the largest single LoRaWAN project at that time.

Many similar projects emerged, each with expectations for phase two and three, and this state continued until the end of 2019.

Looking back now, it seems like a false prosperity. The truly meaningful and replicable large-scale applications are primarily in water and gas meters, but since these projects are backed by state-owned enterprises, many projects are driven by operators, and most customers choose NB-IoT over LoRa. The module prices and service fees for NB-IoT have also dropped to unbelievable levels.

In 2018, we shifted from primarily focusing on communication link products (modules, gateways, NS) to developing sensor devices and IoT applications. To this end, we established a subsidiary in Xi’an, Baifangge, to develop the NMS platform.

The main reason for this transition was that after five years of navigating the communication link market, we had established relationships with several leading clients in various vertical industries. The advantage of large clients is that once a product is well-developed, it can continuously supply the company with ongoing value. However, the downside is that once the demand from these clients grows, we must fundamentally develop our own solutions to minimize costs, which diminishes our value to the client. On the other hand, while small clients have high stickiness, 80% of them do not bring us value, and the workload for technical support is substantial. We had no choice but to pivot towards developing our own IoT applications, and like many peers in the industry, we produced a large number of LoRa sensors (manhole covers, door magnets, PIR, IAQ, DTU).

By the end of 2019, the company had grown to 30 people, and the largest application of LPWAN remained in water and gas meters.

In 2020, the pandemic began.

2. This is a reflection on memories

2020 was a significant turning point for Mansi Technology. At the year-end meeting in late 2019, facing such underwhelming results, I told everyone that this was the worst of times and the best of times. My judgment at the time was that LoRaWAN is a long-tail but diverse market. As people’s understanding of LPWAN deepens, a large number of existing markets need a new round of information technology transformation. In this transformation, wireless technology undoubtedly has significant advantages: low construction costs and minimal impact on existing buildings.

Our 2020 plan included: continuing to optimize gateways to flexibly adapt to various construction scenarios, increasing optimization of underlying device technology, upgrading MPOS and EdgeBus to achieve low-power wireless integration with different protocols, and starting a low-code architecture for the NMS platform to address the simple needs of small clients.

2.1. Understanding the LoRa module market

LoRa modules can be broadly divided into three categories.

The first category is simple RF front ends, where module suppliers design the SX1278/SX1262 RF front end and ship it to users. The target customers are those lacking RF layout experience but possessing technical development capabilities, who may adopt SPI interface RF modules for reasons such as size, reducing MCU power consumption, or developing unique protocols. These modules are characterized by their simplicity, not including embedded software development, and are cost-effective.

The second category is transparent transmission modules, where users communicate with the module via UART interface. The module converts the data sent by the user into LoRa data and sends the received LoRa data back to the user’s control MCU. The target customers for these modules typically have smaller application scenarios, requiring only point-to-point transmission. The advantages of these modules are their simplicity, as users do not need to develop drivers and protocols related to LoRa, and can simply understand the RF module as a connection line like RS-485. However, the downside is that it is challenging to create complex network architectures involving low power consumption, rate adjustments, collision avoidance, frequency adjustments, and time synchronization. During application, transparent transmission modules often require various parameter adjustments, necessitating a deep understanding of the customer’s actual application scenarios. Most of these customers are small, with low demand but high potential technical support workload.

The third category is networking modules, which can be simply divided into mesh modules and LoRaWAN modules. LoRaWAN is a protocol standard introduced by the LoRa Alliance, addressing issues of data security, adaptive rates, frequency allocation, low power consumption (three modes), and time synchronization, using a star network approach. Mesh modules, on the other hand, adopt a mesh networking approach to achieve larger network scales. Since there is no unified standard for mesh networking, these are also considered proprietary protocol modules.

LoRaWAN modules are characterized by their standardization.

In addition to the above module classifications, there are also modules that support secondary development. These modules typically provide development code from the manufacturer, allowing users to add their business logic on top of the code. Mansi Technology also supported secondary development in its early days, based on the MPOS operating system, allocating a portion of flash and RAM, mapping the function call addresses of MPOS to RAM, allowing users to establish tasks and develop business logic by calling RAM addresses.

To summarize the market characteristics of LoRa modules:

Transparent transmission modules have low technical content, often requiring substantial technical support during customer interactions. While these modules seem simple, various parameter adjustment needs arise during actual applications, necessitating a deep understanding of the customer’s actual application scenarios. Most of these customers are small, with low demand but high potential technical support workload.

LoRaWAN modules have standardized characteristics, allowing integration with any manufacturer’s LoRaWAN gateway and direct connection to standard LoRaWAN NS. There are suppliers of LoRaWAN NS in the market, including open-source ChirpStack and the free-to-use Thinklink (https://thinklink.manthink.cn). Developing LoRaWAN products benefits from good ecosystem support, as users do not need to complete the entire communication link product but can focus solely on sensor devices, procuring gateways and NS from suppliers. When undertaking total package projects, there are also more products available for project parties to choose from. The downside of LoRaWAN products is that manufacturers cannot establish customer barriers through proprietary protocols, making them easily replaceable by other manufacturers.

Regardless of whether they are proprietary protocol modules or LoRaWAN modules, both involve substantial technical support, which is a challenging issue. A common solution is Plan A: to establish a community, write detailed product documentation, and encourage users to complete technical support work independently. Plan B: to select customers with independent development capabilities, leaving problem-solving to the customers rather than assisting them. Plan A requires time to accumulate customer volume to eventually form a community effect, while Plan B may damage the module manufacturer’s reputation or serve as a method for the manufacturer to filter customers.

To maintain customer stickiness, it is essential to develop distinctive products, but is it meaningful to create distinctive products in the LoRa module market?

2.2. Is it meaningful to create distinctive products?

Yes, it is meaningful.

The application scenarios for LoRa are primarily B-end enterprise applications or industrial applications, where customers always have various application needs. Simply completing LoRa communication or implementing the LoRaWAN protocol does not perfectly solve the customer’s actual problems. In the early stages of promoting LoRa products, many were POC projects, and the main difference from actual projects is scale. Small-scale and large-scale projects have completely different requirements for products. Large-scale projects must consider operation and maintenance issues; if operational functions cannot be achieved, the maintenance of large-scale projects will become a disaster. So, what essential functions do excellent LoRa devices generally require to ensure reliability and operational functionality?

Here are ten essential functions that must be included in the development of LoRaWAN terminal devices:

1. Version Management

There must be an independent version number and related product number, and the version number and product model need to be uploaded to the application platform. Through the NMS platform (network management system), devices can be managed, maintained, network optimized, and upgraded. Therefore, version management is indispensable for an excellent sensor application.

2. FUOTA Upgrade

There are two scenarios in which sensors need to be upgraded during application:

• Product Bugs: Product bugs prevent normal functionality, necessitating firmware upgrades.

• Changes in Business Requirements: When the application layer requires more and richer functionalities beyond the original plan, firmware upgrades are necessary.

Implementing firmware upgrades in low-power applications is a challenging but necessary function.

3. Heartbeat Function

The heartbeat function maintains the link between the sensor and the application platform, notifying the application platform of the device’s model, version number, communication parameters, communication quality, etc. At the same time, the platform can send parameter information for business functions through the heartbeat packet. Therefore, the heartbeat is essential in every sensor application.

4. Engineering and Maintenance Functions

Sensor applications must face engineering issues during implementation, primarily divided into two categories:

• On-site product parameter initialization, record information retrieval, parameter adjustments, and engineering mode switching.

• During product debugging or maintenance engineering, it is necessary to retrieve operational parameter information, such as obtaining spreading factors, signal quality, and frequency band information. Modifications to operational parameters may also be required, such as changing frequency bands, rejoining the network, and adjusting frequency, rate, etc.

5. Rate Adjustment Issues

LoRa’s characteristics include low rates, long communication distances, but high power consumption and significant frequency resource occupation. High rates have low power consumption and occupy fewer frequency resources, but the communication distance is short. Therefore, selecting the most suitable communication rate is crucial. The ability of sensors to adaptively adjust rates is very important.

6. Collision Avoidance

The basic mechanism of LoRaWAN is based on collisions, meaning that collisions are inevitable. However, many sensor applications require reliable data delivery. Addressing collision issues based on the ALOHA model is a necessary consideration in system design.

The conventional solution is to implement time division, assigning time slots to sensor applications, significantly reducing system collisions.

7. Network Joining Modes

There are two joining methods: OTA and ABP. Which method should be chosen? In practice, there is no definitive answer; it should depend on different scenarios to implement different network protection methods. For example, the system should operate in ABP mode after startup, but if an anomaly occurs, it needs to be able to rejoin the network. For instance:

1) Changes in environmental noise require frequency band switching;

2) The network becomes complex, forming a multi-frequency band network that requires re-optimization of network resources;

3) Changes in system parameters necessitate rejoining the network to obtain new operational parameters.

A large number of joining packets can burden the system, leading to an increase in the proportion of invalid packets, affecting system performance.

8. Confirm Packet Ratio

Whether to use confirm or unconfirm packets in business models is a crucial consideration. Using unconfirm packets allows for larger system capacity and less resource occupation, but may result in data loss for critical information, and unconfirm packets cannot obtain network status for ADR adjustments. Using confirm packets occupies frequency and downlink resources, reducing system capacity.

Choosing a certain confirm ratio and using confirm for critical data, even confirming the confirm packets, is a common processing mechanism.

9. Relay Function

Every application site may encounter blind spots, and using base stations to fill these blind spots can be too costly. Using battery-powered relays is a necessary solution to consider.

10. Battery Level Monitoring

This is a must-have function for every battery-powered sensor.

Manufacturers using LoRa modules for sensor devices may not fully understand the essential functions of LoRa devices, often only requiring the ability to transmit business data. Therefore, an excellent LoRaWAN system needs to identify its characteristics based on these ten functions. This ensures the stable long-term operation of LoRa devices on-site and facilitates convenient maintenance.

2.3. Is LoRa application a long-tail market?

Our focus on the LoRa market is primarily concentrated on B-end industrial application scenarios, including data collection from industrial instruments, environmental monitoring, and the largest application market for LoRa—water meters. Compared to the C-end market, the B-end market has characteristics of long system construction cycles and slow deployment rhythms. Users typically need to conduct small-scale tests before deciding to adopt LoRa technology, and once a technical standard is selected, subsequent technical changes are relatively slow.

Due to the lengthy process of industrial instrument upgrades, LoRa is bound to become a long-tail market in the industrial IoT and metering application fields. For example, since promoting LoRa in 2014, overseas markets have seen water meter suppliers launch water meters supporting LoRaWAN communication. However, between 2014 and 2023, the mainstream wireless communication method in the overseas water meter market has remained wMBus. Starting in 2023, we have observed a gradual increase in demand for LoRaWAN water meters and dual-mode water meters supporting both LoRaWAN and wMBus in overseas markets.

The primary reasons customers choose LoRa are its low power consumption and long-distance RF performance, while the choice of LoRaWAN is due to its ecosystem and protocol standardization. This allows users to procure LoRaWAN devices, gateways, and NS servers from multiple suppliers during the purchasing process, avoiding being locked into a single vendor. Additionally, the open ecosystem of LoRaWAN can continuously ensure product supply capabilities, which is a crucial demand characteristic of the B-end long-tail market.

2.4. Should we adhere to the LoRaWAN standard?

The demand in overseas markets primarily revolves around standardized LoRaWAN products, mainly due to the long-tail characteristics of the B-end market. If proprietary protocols are adopted, it is easy to become locked into a single supplier. The advantage of standardization is that it allows for finding more suppliers within the ecosystem, continuously optimizing products and ensuring supply chain security.

In the domestic market, the volume of single customers is relatively large, allowing for customization. However, during market downturns, some suppliers may cut this business, leading to insecurity in the customer supply chain (ASR, Alibaba, ZTE, Tencent previously entered this market with great fanfare, but now many projects are in disarray, unable to be taken over. When they were doing it, they thought the market scale was large, customizing many protocols and functions, but when exiting, the lack of standardization made it difficult to find new suppliers in the supply chain).

LoRa is a long-tail market, and in recent years, we have encountered many demands for water and electricity meters, farms, warehouses, buildings, etc., in Latin America and Europe, all requiring LoRaWAN standards.

Mansi Technology has been engaged in LoRa for 12 years and LoRaWAN products for 10 years, insisting on producing standardized LoRaWAN products. In the future, we will focus on the technical field of LoRaWAN and continue to deepen this long-tail market.

3. Focusing on the Characteristics of Overseas LoRaWAN Products

3.1. Why focus on the overseas LoRaWAN market?

The industrial ecosystem overseas differs from that in China, as few companies engaged in device applications possess a complete product line across the entire industry chain. Most companies focus only on a specific segment of the industry chain. For example, in the LoRaWAN industry chain, companies like IMST only produce modules, while companies like TECTELIC, Multitech, and Kerlink primarily focus on gateway products. Companies providing LoRaWAN NS, such as TTN, ChirpStack, Actility, and Loriot, concentrate solely on LoRaWAN NS. This ecosystem not only encourages demand and projects to lean towards standardized products to ensure supply chain security but also prompts companies in the industry chain to emphasize standardized interfaces for smooth integration with other companies in the industry chain to complete projects, albeit constrained by engineering costs and supply chain systems that prevent them from producing complete products across the entire industry chain.

LoRa, as a product competing with NB-IoT in the LPWAN market, often requires customization in China to address personalized issues and establish customer barriers, resulting in minimal demand for LoRaWAN. Additionally, with changes in the broader economic environment, more and more metering companies and sensor device manufacturers need to expand into overseas markets, necessitating that more domestic customers adapt to the needs of their overseas clients, which is standardized LoRaWAN products. This has been a significant realization during our interactions with customers over the years.

Mansi Technology’s philosophy is standardization, and LoRaWAN is the technical direction we have consistently adhered to in the past and will continue to in the future. Therefore, whether directly or indirectly, engaging in the overseas market will be a focal point for Mansi Technology. Our ten years of LoRaWAN experience and extensive overseas product deployments represent our most significant accumulation over the past 12 years, enabling us to assist domestic customers in entering the competition within the LoRaWAN ecosystem.

3.2. What should overseas market products focus on?

Standardization

Overseas LoRaWAN products need to interface with gateways and NS from other brands, making product standardization a basic requirement. If LoRaWAN standards are not met, the product cannot be integrated into the user’s system. If only partially meeting LoRaWAN standards, issues may arise during later operations, leading to more significant consequences.

Example 1: Time synchronization function is not commonly used in LoRaWAN devices. In water meter applications, if local time display and freezing water volume are involved, accurate time is necessary, making time synchronization crucial. If this function is absent or not standardized, it may lead to errors or discrepancies with the NS’s time synchronization.

Example 2: The commonly used LoRaWAN standards 1.0.2, 1.0.3, and 1.0.4 have slight differences in certain areas. Ignoring these differences can lead to severe consequences, such as data parsing errors.

Stability and MaintenanceSystem stability and maintenance techniques are particularly important in overseas projects, as the system’s stability must account for the need to adapt to various changing application scenarios.For example, using the OTAA joining method during power meter applications is not advisable. In the event of a systemic power outage, when the system recovers and powers back on, all meters in the network may attempt to join simultaneously, leading to systemic congestion. Although this situation does not occur frequently, when it does, it can have catastrophic consequences.Maintenance channels are another essential function that must be implemented. When adjustments to frequency bands, modifications to device parameters, or upgrades are necessary, a maintenance channel must be available. If remote methods for upgrades and parameter modifications cannot be implemented, the operational costs for on-site maintenance will lead to disasters for the project.Personalized FunctionsPersonalized requirements are functional points that enhance product competitiveness, such as LoRaWAN compatibility with walk-by modes and handheld maintenance channels, which are personalized functions of Mansi Technology’s products from the LoRaWAN perspective.

4. Mansi Technology’s LoRaWAN Product Family

Mansi Technology focuses on the LoRaWAN technology field, with a product family based on our self-developed low-power operating system (MPOS) and edge computing virtualizer (Edge-bus), supporting global frequency LoRaWAN standards, featuring thirteen major functions to adapt to complex application scenarios. Modules, terminal devices, gateways, and NS have been widely applied in various countries and regions, including South America, Europe, and Japan, with the earliest large-scale applications starting in 2014, now exceeding ten years of stable on-site operation.

Modules and DTUs aim to provide users with an interface (UART/RS-485) and its protocol, enabling the realization of thirteen major functions, including LoRaWAN functionality, without any software development, along with a complete LoRaWAN system.

Gateways are enterprise-level gateways based on Ubuntu, capable of adapting to complex enterprise intranet systems, supporting interfaces such as ChirpStack, Basic Station, TTN, Thinklink, GWMP, and can connect to any system supporting the above protocols.

NS (Thinklink) Cloud version supports global LoRaWAN standards, allows users to register for free, and supports free access for 1000 LoRaWAN devices, accommodating any brand’s GWMP and Thinklink protocol connections.

Thinklink-edge version supports global LoRaWAN standards, featuring an 8-core processor, 8GB DDR, and 64GB eMMC, with built-in Home Assistant and Thingsboard, supporting seamless integration with Home Assistant, Thingsboard, and BACnet.

Mansi Technology’s LoRaWAN products began development in 2015, with the first LoRaWAN module UMx01LP based on the STM8L 8-bit MCU, the first LoRaWAN gateway GDI801 and GDO801, and the first LoRaWAN NS, ThinkOne 1.0.

The initial completion of the current LoRaWAN product family occurred in 2018, and it began to be widely used in Alibaba’s metropolitan network, the Tongzhou metropolitan network in Beijing, and the smart energy applications in logistics parks.

As of now, Mansi Technology’s LoRaWAN product family includes four major product modules: modules, sensor devices, gateways, and NS. All four product modules adhere to the LoRaWAN standard and maintain a principle that Mansi Technology’s products can connect to other companies’ standardized LoRaWAN systems while also supporting the integration of other brands’ products into Mansi Technology’s ecosystem.

Mansi Technology’s modules are based on MPOS and EB (Edge-bus), while sensor devices are based on Mansi Technology’s modules. The MPOS+EB combination implements ten major functions, which are also realized in the application layer functions of gateways and NS. From the NS (Thinklink) end, functions such as version management, upgrades, remote maintenance, time synchronization, and parameter modifications can be achieved, providing a one-stop solution for LoRaWAN product development.

4.1. MPOS+EB

MPOS is a low-power operating system independently developed by Mansi Technology, embedded with the LoRaWAN protocol stack. MPOS is based on a tickless concept, implementing lightweight task scheduling internally, supporting FUOTA upgrades through LoRa/LoRaWAN/UART interfaces. MPOS also supports periodic tasks and multiple task modes, as well as precise time task modes (which can achieve point-in-time collection functions), supporting automatic time synchronization and global confirm duty functions.

EB (Edge-bus) is Mansi Technology’s edge computing virtualizer based on MPOS, capable of miniaturizing tasks, allowing users to implement task programming through JS code and upgrade devices via the FUOTA function of MPOS. Mansi Technology’s modules and terminal products are all based on the MPOS+EB combination framework.

• 

MPOS+EB has the following thirteen major functions, referred to as MT13:

1. Built-in version management function

Ensures smooth upgrades of subsequent functions and orderly management of different devices.

2. Multi-bin FUOTA function

Divides firmware into independent functional blocks for independent upgrades. Mansi Technology’s multi-bin technology utilizes the concept of embedded dynamic libraries, making small data block upgrades possible. Coupled with Mansi Technology’s data compression algorithm, low-power upgrade functionality can be achieved, with an upgrade package compressed to within ten packets.

3. Built-in heartbeat function

The heartbeat function maintains the link between the sensor and the application platform, notifying the application platform of the device’s model, version number, communication parameters, communication quality, etc. At the same time, the platform can send parameter information for business functions through the heartbeat packet. Therefore, the heartbeat is essential in every sensor application.

4. Wireless handheld channel

The wireless SW channel enables maintenance of devices in Class A state.

5. Local ADR function

Built-in local ADR function can quickly find the most suitable communication rate.

6. Time division function

LoRaWAN is based on the Aloha method, and collisions are inevitable. For many applications, systemic collision issues also exist (time slot allocation can fully utilize frequency band value in the time domain).

7. Network joining protection function

Built-in network joining protection function automatically triggers the joining mechanism when the system detects deteriorating communication quality or increased packet loss rates, re-acquiring network parameters.

8. Built-in confirm packet ratio configuration

Using all confirm packets places high demands on downlink, reducing system capacity, while using all unconfirm packets cannot guarantee packet loss rates, failing to achieve optimal ADR values. Choosing an appropriate ratio is a must-consider for every system application.

9. Battery level monitoring and temperature monitoring

Built-in temperature measurement and battery level monitoring functions are essential for battery-powered systems.

10. Built-in time synchronization function

For metering applications, precise reading times are necessary for loss statistics. For most business layer statistical data, accurate time is required; otherwise, report inaccuracies may occur, especially for loss statistics. DTUs have the capability to accurately obtain UTC time (to the second).

11. Built-in scheduled reading and periodic reading functions

Especially for metering applications, timing means precise data collection for freezing data, making scheduled reading functions particularly important. For most IoT applications, periodic functionality is essentially a necessary choice for the vast majority of IoT sensors.

12. Built-in threshold judgment function and trigger upload function

Alarm notifications based on threshold judgments can reduce the volume of uplink data, avoiding collisions while ensuring real-time transmission of alarm data to the platform. Therefore, these two functions are very common in mature IoT applications.

13. Built-in data reorganization function

Many Modbus protocols have large data volumes, but effective data is relatively small. If raw data is uploaded directly, it results in large data volumes, making it difficult to ensure system capacity. Additionally, if the uplink protocol needs to be unified, data reorganization is necessary. Another category of data needs to be converted into a unified format for the server, such as temperature calculations, converting BCD codes to hexadecimal, alarm combinations, etc.

4.2. Modules

Only a UART interface and its protocol are needed, enabling the transformation of LoRaWAN devices supporting MT13 without any software development.

In 2018, we released the smallest module at the time, OM422/OM822, based on SX1262, supporting global frequency LoRaWAN modules. This module’s lifecycle has continued to the present. The OM422/OM822 module is based on the MPOS+EB virtualizer, supporting all thirteen major functions of MPOS+EB in addition to standard global LoRaWAN frequency bands.

The development model of OM422/OM822 allows users to provide UART interface protocols, generating EB’s obin files through JS programming, enabling firmware upgrades via UART or LoRaWAN interfaces, thus completing the original device’s support for the LoRaWAN protocol.

OM422/OM822 has successfully integrated over 100 protocols. For the CJ/188 electric meter’s 645 protocol, existing firmware can be directly upgraded, allowing the design of products using OM422/OM822, where users only need to conduct hardware design to complete the development of new LoRaWAN devices.

4.3. Sensor Devices

Only one interface and protocol are needed to realize the LoRaWAN collection system.

Mansi Technology’s sensor devices are primarily divided into two types: DTU for industrial scenarios and environmental sensors, all based on the MPOS+EB combination, supporting global LoRaWAN standards and all MT13 functions.

4.3.1. DTU

Widely used in on-site industrial instrument readings and water meter applications, DTUs are the best solution for retrofitting existing markets, as wired solutions have high construction costs and can be destructive to existing buildings.

DTUs support various interface functions such as RS-485/mbus/4-20mA/0-10V/DI/AI, and can be categorized into battery-powered versions and continuously powered versions.

4.3.2. Environmental Sensors

Environmental sensors primarily include temperature and humidity sensors and IAQ sensors, all supporting global LoRaWAN standards and MT13 function points.

4.4. Gateways

Enterprise-level LoRaWAN gateways support protocols such as TTN, ChirpStack, Thinklink, Basic Station, GWMP, and can connect to any NS system supporting the above protocols.

Mansi Technology’s gateways are enterprise-level gateways based on the Ubuntu system, having undergone eight years of on-site experience since 2017, capable of handling complex network environments and construction sites. The gateways are divided into indoor model GDI51 and outdoor model GDO51, both standard LoRaWAN gateways supporting SF5 and SF6 spreading factors, seamlessly connecting to TTN, ChirpStack, Thinklink, or supporting UDP-based GWMP protocols.

All of Mansi Technology’s gateway products support web-based configuration, allowing users to connect via Wi-Fi to configure and adjust gateway parameters. The outdoor gateway supports IP67 protection level, an external SIM card slot, and a debug interface, with indicator lights showing the gateway’s operational status.

4.5. NS

Mansi Technology’s NS (Thinklink) supports the connection of any gateway that supports the mt_mqtt protocol or GWMP protocol, and can interface with BACnet, Home Assistant, and Thingsboard systems, with built-in protocol parsing rules and alarm rules, implementing business functions through CARD or LIST methods.

Thinklink is divided into cloud and edge versions.

Thinklink-cloud (https://thinklink.manthink.cn) allows users to connect up to 1000 devices for free, currently the only enterprise-level LoRaWAN NS server in China that offers free registration and access.

Thinklink-edge is a hardware server with an 8-core processor, 8GB DDR, and 64GB eMMC, built with project-level Thinklink, Home Assistant, Thingsboard, and Node-RED. It supports the global frequency LoRaWAN protocol stack, primarily targeting small project scenarios with independent deployments of no more than 1000 connected devices.

Three hours of conversation condensed Mansi Technology’s twelve-year journey from LoRa to LoRaWAN.

More than a decade ago, when I first met Mingfei, he was thin; a few years later, he became quite chubby, and today, upon meeting again, he has slimmed down again. The fluctuations in his weight mirror the ups and downs of LoRa in the market!

Fortunately, the direction is set: focusing on overseas LoRaWAN and continuously deepening this long-tail market. I look forward to seeing him slim again next time, while Mansi Technology’s revenue grows robustly, with a string of numbers representing our best wishes!

Related Reading: LoRa, how are you doing?

Understanding the subtle details, follow us

Over 20 years of industry knowledge reshaping and breaking through, specializing in electric, water, gas, heat energy metering and its broader connectivity!

“Smart Metering Micro News” was founded by Lin Hong, former chief editor of Global Metering (WeChat ID: lh13801338724), with over 37,000 followers across the four-meter industry, under the Three Points Common Face (Beijing) Technology Information Service Company.