A telemetry platform today is much more than a single sensor sending a measurement to the cloud. In many OEM projects, the real value is only realized when a field device is connected to a secure backend, a historical database, a web application, an alarm system, user accounts, and a service delivery and maintenance model.

This project demonstrates how to build a complete IoT ecosystem for remote monitoring of tanks and measurement devices. The solution combines field devices, a backend API, a time-series database, a web application, and mechanisms for subscriptions, notifications, and secure device activation.

For an OEM manufacturer, such a system means more than just selling hardware. The device can become part of an online service: with measurement history, alarms, browser access, user management, and the ability to further develop the business model.

If your company is developing an electronic device that operates in the field, collects data, and provides customers with value in a digital model, it is worth considering a similar approach even at the device design stage.

Project Summary

Problem: Dispersed Tanks and Lack of Up-to-Date Data

In many industries, tanks, installations, and measurement devices are geographically dispersed. They may operate in farms, municipal facilities, industrial plants, logistics, fuel distribution, AdBlue, water, chemicals, or other media.

The lack of up-to-date information about the level of liquid or medium in a tank causes specific costs and risks:

• Unnecessary on-site visits
• Reaction only after a problem is reported by the customer
• More difficult planning of deliveries and service
• Lack of measurement history for trend analysis
• Delayed detection of alarms, leaks, or incorrect measurements
• Lack of a single system for multiple devices operating in the field.

The level sensor alone does not solve the entire problem. The end customer needs access to data, history, alarms, and statuses. The system operator needs user management, device management, permissions, and subscriptions. The device manufacturer needs a secure activation process and the ability to further develop the service over time.

Challenge: From Measurement Device to Complete IoT Platform

The goal of the project was to create a platform that does not limit itself to presenting a single measurement. The system was designed to handle the entire data flow: from the telemetry device in the field, through the backend and database, to the application accessible to the user.

Key challenges included:

• Supporting data from level meter / sonic devices
• Storing measurement history in a way that is suitable for telemetry data
• Presenting the current status and trends
• Interpreting device alarm statuses
• Managing user accounts and access to devices
• The ability to share devices with other users
• Preparing the foundation for a subscription model
• Secure device activation by the end user
• Integration with notifications and business systems
• Maintaining the solution in an environment ready for further development.

In practice, this was a project combining the IoT layer, software, security, UX, backend, infrastructure, and thinking about the products business model.

Solution: System Combining Devices, Data, and a Web Application

The platform was designed as a complete telemetry system in which field devices provide data to the backend, and users use a web application for monitoring and analysis.

The functional scope included:

• Monitoring the level of medium in tanks
• Supporting measurement history
• Analyzing trends, deliveries, consumption, and anomalies
• Device alarm statuses
• User accounts and access authorization
• Sharing devices with other users in read-only mode
• Subscription plans and function limits depending on the plan
• Integration with payments
• Secure device activation using a code or production marking
• Notifications and communication with the user
• Monitoring the technical infrastructure.

This is important from the perspective of an OEM: an IoT product does not end with electronics. If a device is to generate value after sale, it needs an application, data, accounts, permissions, security, and a maintenance process. This type of project fits well into a broader NPI process from idea to production, because it requires parallel development of electronics, software, testing, and operational deployment.

Inventronics Scope of Work

In such a project, the value is not a single component, but the combination of several layers into a cohesive product. A telemetry platform requires simultaneous thinking about the device, backend, application, data, security, user activation, and subsequent maintenance.

The areas of expertise needed for a similar project include:

• Analysis of product requirements and user processes
• Electronics design and integration with field devices
• Backend and API architecture
• Database tailored to historical measurements
• Web application for the end user
• Responsive web/mobile layer for users and operators
• Mechanisms for accounts, roles, and access to devices
• Integrations with notifications and business systems
• Preparation of the device activation process
• Preparation of the system for maintenance, monitoring, and further development.

This is the type of project where it is worth combining product development with preparation for contract electronics manufacturing from the beginning.

Architecture: Device, API, Data, and Web Application

The platform was designed around the flow of telemetry data. Devices in the field send measurement and status data, the backend is responsible for validation, business logic, and security, and the web application presents information to end users.

In the backend layer, an API-first approach was used. The system provides a REST interface, authorization mechanisms, data validation, and support for cyclic tasks. Measurement data is stored in a time-series database, which allows for efficient handling of measurement history, charts, and trend analysis.

The web application provides access via a browser, including on mobile devices. The user can view a list of devices, analyze the details of a tank, check history, observe alarm statuses, and use functions depending on the assigned plan.

From an infrastructure perspective, the solution was prepared as a set of services running in a controlled environment. This model makes it easier to maintain, update, monitor, and develop the platform with additional types of devices or functions.

Web and Mobile Application: A Unified User Ecosystem

From the users perspective, a telemetry platform is primarily an application for daily device monitoring. The backend, database, and integrations are important, but it is the clear interface that makes the data from field devices useful for operations.

The frontend layer was designed with responsive use of the system in mind. The same ecosystem can support a web panel accessible through a browser and mobile versions for users working in the field.

The ecosystem also includes a smartwatch application for Wear OS, giving field users quick access to tank levels, device status, alarms and location information directly from their wrist.

The most important elements of the user experience include:

• A list of tanks with current status and alarms
• Detailed device view with measurement history and technical status
• Charts of trends, deliveries, consumption, and events
• Clear status icons instead of raw error codes
• A process for adding a device with a serial number, activation code, and tank configuration
• Subscription plans and payment screens
• Support for legacy accounts and messages resulting from the subscription model
• Multilingual application support
• The ability to prepare a mobile application for service technicians, operators, and end customers.
• A Wear OS smartwatch application for quick access to tank status, alarms, key measurements and location

In practice, the user does not have to analyze the technical data frames or status transmitted by the device. The application shows the information in a business-understandable format: what is happening with the tank, whether an alarm has occurred, when the last measurements were taken, and whether action is required.

This is one of the strongest arguments for an OEM manufacturer. The platform does not end with an API and a database. It creates a unified user ecosystem: field devices, backend, data, web panel, mobile version, accounts, subscriptions, and notifications.

Statuses and Alarms: More Than Just a Sensor Number

In telemetry, the value of a measurement is not always sufficient. The user needs to know whether the data is correct, whether the device is working properly, and whether a reaction is required.

The platform supports device statuses that can provide information about:

• Low liquid or medium level
• Low-level alarm
• Tank overflow
• Leak detection
• Temperature or level sensor problems
• Low battery level
• Incorrect leveling
• Delivery or consumption event
• Incorrect measurement.

Thanks to this, the system is not just a panel with a chart. It helps the user quickly understand what is happening with the installation and make a decision: plan a delivery, send a service technician, check the device, or verify operating conditions.

Users, Access, and Device Sharing

In practical telemetry implementations, data from a single device may be needed by several parties. The tank owner, service provider, medium distributor, service technician and end customer may need access to the same information, but with different permissions.

Therefore, the platform includes user account mechanisms, authorization, and device assignment. An important element is the ability to share selected devices with other users, e.g., in read-only mode.

This model increases the value of the platform in B2B projects, where a device is not used by only one person, but becomes part of an operational process between several participants.

Secure Device Activation

In IoT systems, it is important not only to collect data, but also to control who can assign a device to an account. The platform is equipped with a device activation mechanism that can be linked to a serial number and a code placed on the production label, e.g., in the form of a QR code or DataMatrix.

For the device manufacturer, this is a very important element. The end user can independently add the device to their account, and the system protects against accidental or unauthorized assignment of another device.

This mechanism combines software with the production process. The serial number, label, activation, account, and telemetry data must work as a single cohesive process.

In network-connected device projects, it is also increasingly important to consider cybersecurity requirements and maintain the product throughout its lifecycle. For OEM manufacturers, an important context is the Cyber Resilience Act and preparation of the electronics manufacturer for the CRA: from access control and updates to process evidence, documentation, and responsibility for the security of the device after deployment.

Subscriptions and Service Model

The platform is designed for a service-based model. In addition to basic monitoring, it can support different levels of functionality, limits on the number of devices, the scope of historical data, and integration with payments.

This allows the manufacturer or operator to offer the customer not only a device, but a service:

• Basic access to current data
• Longer measurement history
• Larger device limit
• Extended operational functions
• Notifications and integrations
• Ability to develop the offer over time.

From a business perspective, this is an important change. The hardware becomes the entry point to a relationship with the customer, and the platform allows you to build a recurring revenue model and better serve end users.

Integrations and Notifications

The telemetry platform can be part of a broader business ecosystem. The project includes integrations with areas such as online payments, company data, notifications, and external systems.

Practical applications include:

• Low tank level alerts
• Service notifications
• Device status messages
• Subscription management
• Data exchange with company systems
• Automation of recurring administrative tasks.

Thanks to this, the solution can be developed not only as a technical panel, but as part of a customer service, logistics, service, and monetization process.

Operational Readiness and System Maintenance

In IoT projects, simply launching an application is not enough. The platform must be easy to maintain, monitor, update and develop further.

The project includes elements of operational maturity:

• Container-based environment
• Separation of backend services, frontend, database, and cache
• Technical monitoring
• Ability to run test and production environments
• Data migration planning
• Smoke tests before production switchover
• Rollback scenarios.

This is especially important when the platform replaces or develops an existing system. Migration should not mean loss of data, interruption of service, or disconnection of existing users. A well-planned implementation includes not only a new feature, but also continuity of service and operational security.

Value for OEM Manufacturers

The most important conclusion from this project is simple: in modern electronics, the value of a product is increasingly created at the intersection of hardware, software, data, and service.

A device manufacturer can offer the customer:

• Remote monitoring without on-site physical control
• Measurement history and trend analysis
• Faster detection of alarms and problems
• Fewer unnecessary service visits
• Better planning of deliveries and service
• Online access for multiple user groups
• The ability to sell the service in a subscription model
• A unified user experience in the web and mobile channel
• A foundation for additional device types and integrations.

For an OEM manufacturer, this means the opportunity to increase the value of the product, build a better relationship with the customer, and develop a business model based on service. For the end customer, it means less guessing, fewer visits, and faster reaction to real events in the field.

How a Similar Solution Can Help Your Company

A similar architecture can be used not only in tank monitoring. The same way of thinking works in many projects where devices operate in the field, collect data, and require remote supervision.

Example applications include:

• Industrial telemetry
• Monitoring of fuel, AdBlue, water or chemicals
• Water and wastewater management
• Agriculture and livestock farming
• Municipal infrastructure
• maintenance operations
• IoT devices operating with end customers
• OEM products requiring an application, backend, and a service model.

If your company has devices in the field, but lacks an application, backend, data history, notifications, or a system for customers, a telemetry platform can be a natural next step in product development.

We describe how to move from concept to a finished product in the guide From Idea to Ready Electronic Device.

Summary

The IoT telemetry platform shows that a modern electronic product can be more than just a measurement device. It can be a complete service: with data, alarms, history, user accounts, subscriptions, integrations, and operational support.

For an OEM manufacturer, this means an opportunity to increase the value of the product, build a better relationship with the customer, and develop a business model based on service. For the end customer, it means less guessing, fewer visits, and faster reaction to real events in the field.

Do you want to build a similar telemetry platform for your devices? Talk to Inventronics about the architecture, application, backend and deployment path for your IoT system. Contact us through the contact form.

FAQ

The post IoT Telemetry Platform for Remote Tank Monitoring appeared first on INVENTRONICS.

An industrial flow meter used in the field has to meet two requirements that often pull in opposite directions. On one hand, it should work locally, independently of network coverage, applications and cloud services. On the other hand, these devices are increasingly expected to become part of a remote monitoring system that can analyze consumption, alarms and operating history without an on-site inspection.

This case study shows the development of an LCD flow meter into the next-generation iDFM-500XL device with a large display, battery operation and LoRaWAN communication. The project combines local flow measurement, consumption logging, LCD status indication, magnetic tamper detection and remote data transmission to IoT platforms.

For an OEM manufacturer, this is an example of how a proven measurement device can be extended with telemetry without losing independent local operation. This direction fits projects where a classic electronic device needs to become part of a broader data, service and monitoring system.

If your company is developing a field measurement device, it is worth combining electronic device development with firmware, wireless communication, production and service requirements from the start.

Project Summary

Problem: Field Measurement and the Need for Remote Data

In many installations, a flow meter has to work as a standalone field device. The user needs a local reading, the service team needs information about device status, and the system operator wants remote access to consumption data.

Typical challenges in this type of project include:

• battery operation and low power consumption
• clear local readout in the field
• logging consumption data in device memory
• remote data transmission without Wi-Fi and without permanent mains power
• resilience to temporary loss of coverage or incorrect network configuration
• preparing the device for service, production and secure network configuration
• protection against attempts to tamper with the measurement.

Simply adding a radio modem does not solve the problem. In a battery-powered device, the radio has to be managed very carefully, data must not be lost when connectivity is unavailable, and network configuration has to be manageable in service and production processes.

Challenge: Battery-Powered Local Flow Meter with LoRaWAN

The goal of the project was to develop a new version of the industrial flow meter that keeps the advantages of a battery-powered device with a local LCD, while enabling remote data readout through a LoRaWAN network.

The main requirements included:

• a large, readable LCD for field operation
• flow measurement and local presentation of consumption values
• data logging in device memory
• transmission of consumption data over LoRaWAN
• resilience to communication errors and temporary loss of coverage
• detection of magnetic tamper attempts
• preparation for production, service and repeatable LoRaWAN configuration.

In practice, this required firmware that handles not only measurement and display, but also radio communication, data queuing, network configuration, non-volatile memory and status indication for the user.

Solution: iDFM-500XL with Firmware, LCD, LoRaWAN and Network Configuration

The project included firmware development and hardware integration for the iDFM-500XL flow meter with a LoRaWAN module. The device uses a 32-bit Arm Cortex-M0+ microcontroller, a large segmented LCD measuring 13555 mm, Hall-sensor-based measurement inputs and a LoRaWAN modem controlled through AT commands.

Key elements of the solution:

• a large LCD for local presentation of consumption, status and configuration
• LoRaWAN for data transmission from a field device without local Wi-Fi infrastructure
• radio modem activation only when there is data to transmit
• a data queue that protects consumption data when coverage is unavailable or configuration is incorrect
• transactional handling of AT commands to the radio modem
• LoRaWAN configuration stored in persistent device memory with integrity validation
• a service menu available directly from the device
• magnetic tamper detection.

This approach preserves the core function of a local device while extending it with remote telemetry. It is important in projects where the device must work independently, but data should reach the monitoring system whenever connectivity is available.

Local Measurement and Independence from the Cloud

One of the main assumptions of the project was that the flow meter must not depend on a permanent cloud connection. The device measures, displays and stores data locally, while LoRaWAN transmission is a reporting channel rather than a condition for measurement.

As a result, temporary loss of coverage, a problem joining the LoRaWAN network or incorrect configuration does not mean that consumption data is lost. Data can be stored in a queue and sent later, after transmission conditions or configuration are restored.

For the field user, this means continuity of local operation. For the system operator, it means greater resilience to typical communication problems in distributed installations.

LoRaWAN and IoT Integration

LoRaWAN is a suitable direction for battery-powered devices operating in the field, especially where there is no local Wi-Fi infrastructure and data is transmitted periodically or based on events.

In this project, the complete transmission path was verified: from the flow meter, through the LoRaWAN modem and network, to the IoT platform and data dashboard. Tests covered consumption data transmission, handling of pending messages and verification of secure network configuration mechanisms.

From a product perspective, three elements are important:

• device data can reach the monitoring system
• the user can see transmission status on the LCD
• LoRaWAN configuration can be prepared and verified in the service process.

This is a good example of a project where device software, radio communication and the IoT system have to be designed together, not as separate independent layers.

Operational Safety and Tamper Detection

In measurement devices, it is important not only to record data, but also to resist incorrect operation and tampering attempts.

The project included magnetic tamper detection, including situations where a magnetic field could interfere with measurement reliability. In fuel, industrial and metering applications, this is an important element of operational safety.

For the user, such events can be indicated as a status or alarm. At system level, they can become part of the device history and a basis for further service analysis.

For connected devices, cybersecurity and product maintenance after deployment are becoming increasingly important. For OEM manufacturers, an important context is the Cyber Resilience Act and CRA readiness for electronics manufacturers: from access control and updates to documentation, process evidence and responsibility for device security throughout the lifecycle.

Production and Service Readiness

In a LoRaWAN device, a working demo is not enough. Each device needs its own configuration, identifiers and network access parameters, and these have to be assigned in a repeatable and secure way.

Therefore, the project focused on:

• storing LoRaWAN parameters in persistent device memory
• validating the integrity of configuration data
• a service menu available directly from the device
• configuration and transmission status indication on the LCD
• preparation for the production process and factory tests
• configuration verification without modifying firmware code.

These elements often decide whether a prototype can be turned into a repeatably manufactured device. We describe a similar approach in the NPI process from idea to production.

Results

The project made it possible to develop a classic LCD flow meter into an industrial-grade telemetry device.

The main outcomes:

• local measurement and data presentation on a large LCD
• data transmission over LoRaWAN
• verified complete communication path to the IoT platform
• handling of real consumption data and events
• a queue of pending frames and transmission after correct configuration or connectivity is restored
• a LoRaWAN configuration menu available directly from the device
• storage and validation of device configuration data
• transmission status indication using LCD icons
• preserved battery operation by activating the radio only for transmission.

For the OEM manufacturer, the key value is the ability to develop an existing device line without losing its fundamental advantages: local operation, low power consumption and resistance to field conditions.

How a Similar Solution Can Help Your Company

A similar development path makes sense wherever a measurement device operates in the field and should remain autonomous while also delivering data to a remote monitoring system.

Example applications:

• industrial flow meters and counters
• battery-powered IoT devices
• monitoring of fuel, AdBlue, water or chemical consumption
• measurement devices for distributed installations
• LoRaWAN telemetry for industry
• OEM products that require firmware, radio communication and preparation for production.

If your company has a proven local device that you want to extend with remote communication, it is worth planning not only the radio modem, but the whole process: firmware, network configuration, tests, production, service and integration with the monitoring system.

This case naturally connects with the IoT telemetry platform, where data from field devices can become part of a broader user ecosystem, applications and services.

Summary

The iDFM-500XL shows how a classic measurement device can be developed into an IoT-ready version. The large LCD provides clear local readout, firmware manages measurement, memory and communication, and LoRaWAN enables remote reporting of consumption without permanent power supply and without local network infrastructure.

The greatest value of the project is the combination of local reliability and telemetry. The device works as a standalone flow meter, but it can also become part of a monitoring, service and data analysis system.

Do you want to develop a measurement device with LoRaWAN, firmware and remote monitoring? Talk to Inventronics about architecture, prototyping, testing and production implementation. Contact us through the contact form.

FAQ

The post Industrial LCD and LoRaWAN Flow Meter for Remote Consumption Monitoring appeared first on INVENTRONICS.

Project Summary

The device measured liquid levels in tanks, including mobile tanks. It used ultrasonic measurement, an ultra-low-power microcontroller and a COMBO module integrating GNSS positioning with GPRS/GSM communication. Its firmware performed measurements, detected events and periodically exchanged data with the customer’s backend in both directions.

The device achieved a measurement resolution of 1 mm. The work covered both device development and preparation for repeatable manufacturing. Calibration and testing formed part of the path from sensor selection to regular customer deliveries.

Key outcome: the solution connected measurement, positioning and communication with a calibration process prepared for series production.

The Customer’s Challenge

A long-standing INVENTRONICS customer needed an autonomous, battery-powered device. The requirements included at least one year of operation, preferably two, outdoor use and reliable communication with the customer’s own server. Integrated GNSS was needed to locate mobile tanks.

The challenge was to meet these requirements together. An affordable measurement method could struggle in strong light, while a technology less sensitive to its surroundings might not deliver the required accuracy within budget. Measurement, positioning and transmission also drew on a limited energy supply. Selecting a sensor with a promising specification was therefore not enough: the complete architecture had to suit the actual application.

Engineering Decisions

The first step was to compare three measurement approaches against the tanks and customer requirements. Translucent, infrared-transmitting tanks were an important consideration: their material properties affected the operating conditions of an optical sensor.

Ultrasound offered the best fit among the evaluated solutions. That choice brought an additional task: making calibration and temperature compensation part of both the product and its manufacturing process.

As a general principle, ultrasonic ranging determines distance from the time taken for an echo to return. The speed of sound changes with temperature, so timing alone is insufficient to keep readings consistent as temperature varies. This device incorporated temperature compensation and production calibration of the ultrasonic measurement path. These were deliberate consequences of the technology choice, not additions left until the end of development.

Energy use was the second key area. An ultra-low-power microcontroller was selected, and its power-management modes were used to reduce current consumption. In a battery-powered device generally, both the consumption of each operating state and its duration matter to the energy budget. Measurement, positioning and communication patterns therefore matter as much to battery life as selecting low-power components.

An integrated COMBO module handled positioning and transmission. GNSS located the tank, while GPRS/GSM provided communication with the customer’s server. This historical implementation used 2G; connectivity selection for a new project requires a check of service availability and compatibility with the intended markets.

Architecture from Measurement to Backend

The dedicated calibration and test station closed the loop between architecture and production: the measurement path could be calibrated, compensation parameters incorporated and device operation verified before delivery.

INVENTRONICS’ Responsibilities

INVENTRONICS assessed measurement technologies, developed the electronics and firmware, and prepared the solution for series production. Device software covered measurement, event detection and periodic bidirectional communication with the customer’s backend.

The work also included an assembly station and a calibration and test system. This connected measurement requirements to the manufacturing process. For the OEM, the objective was not simply a working device, but an established way to reproduce its measurement performance across subsequent units.

Calibration, Testing and Production

Choosing ultrasound meant making calibration part of production rather than limiting it to development work. INVENTRONICS created a dedicated assembly station, a specialised calibration and test system, and a procedure for calibrating the measurement path. Temperature-compensation parameters were included in the process.

In general engineering terms, calibration and compensation perform different, complementary roles: calibration relates device readings to reference conditions, while compensation accounts for the effect of changing temperature on measurement. Connecting both to manufacturing is particularly important when moving from an individual device to successive units in a production run.

The product entered series production, and INVENTRONICS made regular deliveries to the customer. Moving from technology selection to an established assembly and calibration process was an important project outcome.

Results and Their Meaning

The device combined 1 mm measurement resolution, mobile-tank positioning and backend communication for remote monitoring. Liquid level and location data could therefore serve a shared purpose: remotely observing a mobile asset.

Up to two years of battery life was achieved under the project’s field operating conditions; runtime depends on measurement, positioning and communication patterns. The measurement choice and temperature compensation addressed outdoor requirements, while the calibration process supported repeatable manufacturing.

Value for an OEM

This project illustrates why measurement-device development and production preparation belong together. Selecting ultrasound addressed a particular application problem while introducing calibration requirements. Accounting for both sides of that decision enabled the transition from a technical solution to a product supplied in series.

For another OEM project, the starting points should be tank material and geometry, environmental conditions, required accuracy, measurement and communication patterns, and the intended market. Agreeing on these criteria before component selection helps connect user requirements with technical decisions and production preparation.

Planning a battery-powered measurement device? Contact INVENTRONICS with details of the tank and intended use. Explore our product development services, from electronics and firmware to production preparation.

Frequently Asked Questions

The post Ultrasonic Level Meter: From Technology Selection to Series Production appeared first on INVENTRONICS.

Project summary

HYDROCLIMA 2 is an electronic heat cost allocator with two temperature sensors, tamper detection and Wireless M-Bus data transmission. It is used in heating cost allocation systems, not as a heat meter measuring energy in kWh.

Series production covered electronics and mechanical assembly, final testing and packaging. It combined SMT and THT with a parametric-functional tester developed specifically for the device, resulting in a complete product manufactured to the customer’s design.

Key outcome: the customer’s design was implemented as a complete series production process with dedicated verification of finished allocator functions.

The customer’s challenge

The customer, a metering solutions provider, needed a partner to translate its design into series production. Throughput had to be considered alongside verification of device parameters and functions. Quality assurance, traceability and the complete production cycle were also customer requirements.

A device with two sensors and radio communication required verification of several interacting areas. The platform had to cover temperature sensing, transmission, power, the display and tamper detection. The manufacturing partner’s task was to account for these functions within production of the complete allocator.

Engineering decisions: assembly and testing together

Starting from the customer’s design, INVENTRONICS developed and optimised manufacturing by combining electronics and mechanical assembly, programming and dedicated testing through to final inspection.

A key decision was to use a tester tailored to this product. Its scope matched the device’s temperature sensors, Wireless M-Bus communication, battery power and interface. This connection between test coverage and product design was central to industrialising HYDROCLIMA 2.

The process was optimised with throughput and reliability in mind. In series production, the two are connected: assembly productivity needs to be considered alongside the inspection coverage required for the device.

From Documentation to a Finished Allocator

INVENTRONICS translated the customer’s documentation into five connected stages of complete device production. Product design and proprietary firmware remained the customer’s responsibility, while INVENTRONICS handled industrialisation, manufacturing and final inspection.

This connected electronics manufacturing, mechanical completion and function checks, providing OEM support from production documentation to a packaged allocator.

Testing linked to device functions

The HYDROCLIMA 2 tester combined calibration and parameter checks with functional verification. It covered six areas relevant to allocator operation:

Sensor calibration and response testing across temperature ranges covered the temperature-sensing chain. Separate tester functions addressed data transmission, display and tamper detection.

Battery and power consumption diagnostics added power verification to this scope. For a device intended for long-term battery operation, this is an important area of inspection alongside sensor operation and radio communication.

Results: a series production process

The collaboration established a complete series production process for HYDROCLIMA 2. The customer gained manufacturing capability for its own product, covering assembly, programming, final testing and packaging. The dedicated testing platform linked production inspection to allocator parameters and functions, from temperature sensors to Wireless M-Bus and tamper detection.

Value for OEMs

This model is relevant to companies developing their own devices and software while seeking an industrialisation partner. It shows why supplier assessment should consider not only assembly capability but also product-specific test engineering and the operations required after electronics assembly.

For a new project, useful starting materials include:

• Electronics and mechanical documentation needed for assembly.
• Firmware version information and programming requirements.
• Functions and parameters to be checked, together with acceptance criteria.
• Expected scope for final product completion, packaging, quantities and delivery dates.

These provide a basis for discussing responsibilities, test station scope and production arrangements with the OEM design team.

Have your own electronics design and need a manufacturing partner? Contact INVENTRONICS with your product’s development stage and expected assembly and testing scope. Let’s discuss the move from documentation to manufacturing a complete device. Explore our EMS electronics manufacturing services as well.

FAQ

The post HYDROCLIMA 2: heat cost allocator manufacturing and dedicated testing appeared first on INVENTRONICS.

Project Summary

The marker used a microcontroller to control six LEDs. Monochrome and RGB versions were developed, supporting different lighting patterns and colour combinations. An ISM 868 MHz radio module enabled marker synchronisation, wave-like lighting sequences or simultaneous flashing, and communication with external devices.

Power came from photovoltaic cells, energy storage and low-power electronics, without an external power connection. The mechanical design used an internal honeycomb structure and polymer blends selected for road-environment requirements. The enclosure was assessed using the finite element method, with equivalent stresses evaluated according to the HMH criterion.

Key outcome: the project produced a coherent active-marker design combining signalling, radio, autonomous power, mechanical engineering and material selection.

The Customer’s Challenge

The aim was active signalling installed directly in the road surface. It needed good visibility in adverse weather, operation without external power and wireless coordination between markers. Potential applications included pedestrian crossings and hazard areas, where coordinated signalling could draw road users’ attention.

The environment imposed requirements beyond electronics design. The enclosure had to accommodate loads from passing vehicles, water, UV exposure and contact with fuels, oils and other road contaminants. Long-term use therefore required geometry and material to be considered together. Putting a controller inside a sealed housing would not, by itself, address the way wheel loads travelled through the structure.

Engineering Decisions

Light control and synchronisation. ISM 868 MHz radio provided communication between markers for coordinated effects such as a travelling light wave and synchronised flashing.

The solution also supported external ISM/GPRS gateways for remote system monitoring and control. The marker handled local signalling and ISM radio communication, while the external gateway linked that communication to GPRS transmission. This separated light control and access to the remote system into distinct, cooperating functions.

An energy budget, not just a solar panel. Photovoltaic cells supplied an energy-storage system that powered the electronics, LEDs and radio. Low-power components and balancing the available energy were important design choices. The storage system was intended to sustain operation during extended overcast periods.

The general principle is to balance energy harvested over time against the energy consumed by signalling and communication. Designing a solar-powered device therefore involves considering sunlight at the installation site, lighting duration and patterns, radio activity and storage capacity. The operating profile is part of the energy requirements, not simply a choice of lighting effect.

Geometry that carries loads. A hexagonal honeycomb structure was incorporated inside the enclosure. Its purpose was to distribute loads and redirect stresses towards less vulnerable parts of the structure. This decision addressed how forces travelled through the enclosure, rather than only its external shape.

In general mechanical design, load magnitude is only part of the problem: the point of application and the load path also matter. Internal structure affects stress distribution. In this project, numerical analysis was used to assess the geometry and support enclosure-design decisions.

Material as part of the solution. Polymer blends were selected for enhanced resistance to UV, hydrocarbons, weather and mechanical loads. These criteria mattered because road contaminants and wheel pressure acted on the same enclosure. Material selection complemented the geometry: both addressed the requirements of long-term use in a road environment.

IP68 was adopted as the enclosure’s ingress-protection design target. Sealing was considered alongside material resistance and the transmission of vehicle wheel loads.

Five Interacting Device Layers

The layers were interdependent: lighting patterns and radio activity affected the energy budget, while the electronics and energy storage had to fit inside an enclosure that carried loads and operated in a road environment. Electronic, energy, mechanical and material decisions were therefore made as parts of one product.

INVENTRONICS’ Responsibilities

The work covered LED control electronics, radio communication, photovoltaic power with energy storage, and mechanical design. INVENTRONICS combined those tasks with stress analysis and enclosure-material selection. The project was therefore broader than supplying an electronic board for an existing housing.

Considering these disciplines together was important because their requirements were connected: signalling and radio shared an energy supply, while the enclosure had to address both environmental and mechanical objectives.

Mechanical Design and FEM Analysis

The enclosure was assessed using FEM, the finite element method. The analysis used equivalent stresses according to the Huber-Mises-Hencky, or HMH, criterion, which combines the components of a stress state into a single value. The analysis supported assessment of stress distribution and optimisation of enclosure behaviour under vehicle loading.

In engineering practice, FEM allows designers to examine not only the point where a force is applied, but also the areas reached through the internal load path. The material model and support conditions connect geometry with expected use. For this type of device, it is a valuable tool for assessing how the outer enclosure and its internal reinforcement work together.

Project Results

The outcome was an active marker design combining six LEDs, microcontroller control, radio synchronisation and its own photovoltaic supply with energy storage. The honeycomb structure, FEM analysis using the HMH criterion and polymer selection addressed the requirements of installation in the road surface.

Communication with external devices offered potential for integration with Intelligent Transportation Systems, or ITS. Monochrome and RGB variants, together with synchronisation, enabled different approaches to active road marking, with the aim of supporting road safety.

Value for an OEM

For an OEM, this project demonstrates the importance of developing electronics, mechanical design and materials together. Solar power must be considered alongside lighting and communication patterns, while the enclosure must be assessed against both loading and chemical exposure. None of these areas can be evaluated solely through the specification of one component.

A similar project should begin by defining installation conditions, signalling patterns, available energy, integration with a supervisory system and testing requirements. These inputs help establish device functions and finished-product acceptance criteria before components and enclosure geometry are selected.

Developing an OEM device for outdoor use? Contact INVENTRONICS with the required functions and installation conditions. Explore our product development services, bringing together electronics, mechanical design and power.

Frequently Asked Questions

The post Solar-Powered LED Road Marker: Electronics, Structure and Radio Communication appeared first on INVENTRONICS.

The project family at a glance

The family included rectangular, linear, combined and round designs. Power variants comprised CV DC, CC DC and versions powered directly from 230 VAC with an integrated supply. Selected designs could include BLE or ISM for wireless lighting control.

These are separate design variants selected for the application, not switchable power modes on one universal board. The common feature was electronics design based on the customer’s concept, combined with manufacturing at INVENTRONICS.

Key outcome: INVENTRONICS combined design and manufacturing for a multi-variant family of LED modules tailored to OEM product concepts.

The OEM customers’ challenge

Manufacturers needed a partner able to develop and manufacture non-standard LED modules. Different shapes and power arrangements called for application-specific designs, connecting electronics decisions with their implementation in production.

Where a concept called for radio-based lighting control, optional communication had to be considered alongside electronics and power. The cooperation therefore extended beyond PCB assembly.

Tailoring a module to the customer’s product also considered thermal requirements, expected optical performance and dimensional constraints. These parameters served as design inputs for the individual variant.

Design decisions and variants

Engineering covered customer-specific electronics, power supply design and optional communication integration:

BLE stands for Bluetooth Low Energy. ISM refers to radio frequency bands; the term alone specifies neither a particular frequency nor a protocol. Requirements for range, network topology and integration with other devices are established for the individual project.

INVENTRONICS’ scope of work

INVENTRONICS combined design and manufacturing activities:

• Engineering services and electronics design based on customer requirements and concepts.
• Design of CV DC, CC DC or direct 230 VAC variants with an integrated supply for the mains-powered versions.
• Integration of BLE or ISM communication where included in the module concept.
• Electronics manufacturing using surface-mount SMT and through-hole THT assembly.
• Automated optical inspection, AOI, for assembly inspection.

Combining design and manufacturing allowed each module to be considered in terms of both OEM product functions and series production.

Assembly inspection using AOI

Production included AOI, automated optical inspection of electronics assembly using images. It assesses board assembly separately from lighting parameters and finished-product operation.

For a new project, it is worth defining whether photometric measurements, functional or electrical tests are required and which criteria apply. This matches the verification plan to the module’s application.

Results: manufacturing across multiple variants

The outcome was a family of custom OEM LED modules in different geometries, DC variants and mains-powered designs, with optional wireless connectivity. INVENTRONICS combined electronics development with SMT/THT manufacturing and AOI assembly inspection, covering module development and series production.

OEM value and questions for a new project

One partner for design and production can simplify coordination of geometry, power and communication in the context of both product functions and manufacturing.

For a new project, it is worth preparing answers to a few questions:

• What space, geometry and mounting arrangement does the product allow?
• Is the required variant CV DC, CC DC or a 230 VAC design?
• Is wireless communication necessary, and what must the module communicate with?
• Which thermal and environmental conditions need to be considered?
• Which lighting parameters, acceptance tests and safety requirements need agreement?
• How far has the concept progressed, and what quantities and delivery dates are expected?

These answers establish the engineering and manufacturing scope. A mounting-space drawing and expected-function description provide a useful starting point for selecting the module variant.

Gallery of Manufactured Modules

The images below show three manufactured designs from the LED module family: a round PCB with multiple LEDs, a comb-shaped linear PCB and a rectangular PCB with integrated components.

Need custom LED electronics for an OEM product? Contact INVENTRONICS with your geometry, intended power supply and communication requirements. These provide a starting point for discussing design, manufacturing and verification scope. For more on the manufacturing side, explore our EMS electronics manufacturing services.

FAQ

The post OEM LED modules: design and manufacturing with optional BLE or ISM connectivity appeared first on INVENTRONICS.