From Signal to System,
to Industrial Intelligence.

The problem in the field. On overhead cranes, a pendant control ties the operator to the area under the load and to the line of travel; festoon cable systems suffer from breaks, crushing and connection faults, and every fault means a production stop. Imported wireless remotes come with a fixed button layout, special functions (analog speed, extra relays, interlocks) cannot be added, and service is abroad. When several cranes work in the same plant, remotes triggering each other is a safety risk.

The solution. The Elmes crane control system carries commands from a handheld or belt-pack transmitter to the receiver in encrypted RF packets; the receiver's relay contacts connect directly to the contactors or drives. Every system has a unique ID, so transmitters with a different ID cannot affect the receiver. The emergency stop command is processed with priority; if the link drops or the battery runs out, the receiver releases its relays to a safe state. The operator controls the load from wherever they see it best.

Customization. 6–32 channels, two-speed buttons, joystick/analog speed, analog 0/4–20 mA and 0–10 V outputs (up to a receiver with 27 digital + 6 analog outputs), latch/momentary selection and reverse-button protection are configured per application. For non-crane machines such as concrete pumps, horizontal lifts and doors/barriers, the same hardware is offered as Wireless Machine Start & Control.

The problem. On machines such as concrete pumps, sandblasting booths, horizontal lifts and mobile pumps, the operator needs to be away from the machine, wherever the work can be seen: at the boom tip, outside the booth, on the platform. Wired controls (coiled cables, pendant stations) break, snag, restrict movement and cause accidents. Off-the-shelf imported industrial remotes are expensive, closed to channel and logic customization, and serviced abroad. Cheap 433 MHz remotes, on the other hand, lack industrial safety features (emergency stop, defined link-loss behavior, interference protection).

The solution. The transmitter (membrane/buttons/joystick) and receiver (relays + analog outputs) hardware of the Wireless Crane Control System platform is configured for each machine: a 24-channel concrete pump remote, an 8-channel + emergency stop general-purpose remote, a single receiver with 10 transmitters, proportional drive with a joystick, single-channel pump start/stop. The receiver relays drive contactors or PLC inputs; if communication is lost, the relays drop out (safe state), and the emergency stop is handled with priority through a separate relay. Multiple machines on the same site are separated by channel and ID.

New series. The roadmap standardizes the receiver on DIN rail with the Elmes Module Series and EC carrier boards (EC-DIO8/16), moves the transmitter to a new platform, and adds encryption and OTA updates.

The problem. Carrying a few dry contacts between a pump and a tank, a machine and its control panel, a barrier and a guard booth, or a valve and a control room normally means pulling cable: trenching, conduit, road or stream crossings, third-party land, and the risk of lightning and breaks. In most applications the information is just 1–8 bits (full/empty, run/stop, open/closed, fault), yet cable costs and permits inflate the project. GSM/IoT solutions add subscriptions, cloud dependency and latency, which is overkill for a simple level control.

The solution. The Wireless Digital I/O Link carries digital signals over RF between two (or more) endpoints. A contact change at the input end immediately switches the relay at the far end; periodic status refreshes keep the link continuously verified. If communication is lost, the relays drop to a defined safe state (for example, the pump stops). To a PLC, the link looks like an I/O card shared by both panels: input terminals on one side, relay contacts on the other.

Generations. The ELD100 generation in the field delivers kilometer-class range with LoRa. The new series is planned to offer the same function on DIN rail with the EM-G0L-433 module and the EC-DIO8 carrier board, in 433 MHz and optional 868 MHz versions.

The problem in the field. In operating factories, heritage buildings, large warehouses and open sites, running a wired fire detection loop halts production, damages the structure and is expensive. Standard conventional/addressable panels raise the alarm, but site-specific actions (lock a door, shut off ventilation, trigger a specific extinguisher) require an extra PLC and more cabling. In solvent, paint and dusty environments, a single type of detector produces false alarms or reacts too late.

The solution. Firesens connects battery-powered or 24 V wireless end devices (smoke/heat sensors, buttons, sirens, relay output units) to the gateway and panel over LoRa 433 MHz. The panel, PC application and map HMI show every device with its location, battery, temperature and signal strength; on alarm, siren, door and extinguisher outputs are triggered according to the scenario. Thanks to two-way communication, the panel sends commands and each device acknowledges them. Installation is carried out in the running plant without stopping production.

For sites with special requirements. Firesens is not a replacement for a legally mandated fire detection system; it is positioned as an additional, special-purpose protection layer for industrial sites and sites with special requirements, and is evaluated project by project. The smoke/heat sensor is EN 54-7 self-declared; EN 54-25 (wireless components) certification is planned. The roadmap covers early warning based on threshold and trend analysis across several sensor types (optical smoke, temperature, rate-of-rise, gas), BMS/SCADA integration over Modbus TCP, and a new version of mobile notifications.

The problem in the field. On large sites, guard posts are far from the control room; radio calls carry no identity or location, and running wired alarm lines is costly and open to sabotage. Whether a guard is on duty and alert usually cannot be verified, and after an incident there is no record of who, when and where.

The solution. The system is button-based: each guard post gets a wireless device (ELC402) with Attack, Fire and Check-in buttons. When a button is pressed, the alarm type and location appear instantly on the central panel, and the sirens and alarm contact are triggered according to the scenario. Check-in supervision prompts the guard at a set interval (e.g. 30 min); if the check-in button is not pressed within 1 minute, the control room is alerted. Once the duty roster is entered, the personnel on duty at the time of an alarm are logged.

Expansion. RFID checkpoints are optional: with an RFID card or fingerprint reader, check-ins can only be made by authorized personnel. In the Professional tier, alarm and personnel information is shown on a dynamic site plan. The roadmap covers PC/mobile monitoring and reporting, GSM/4G backup notifications, the WR-001 portable notification unit for the response team and, in the longer term, a BLE/UWB-based real-time location (RTLS) layer.

The problem in the field. On large farmland, parks, gardens and golf courses, valves are hundreds of meters to kilometers away from the control point. A wired valve network means trenching, cable theft and rodent damage; decoder systems are expensive and tied to a single brand. Manual irrigation schedules are inconsistent, water and energy waste is high, and pumps fail from dry running and phase faults.

The solution. The Elmes irrigation system manages solar-powered wireless valve/pump nodes from a central unit. Daily, weekly, monthly and yearly programs are defined in the scheduler software; the central unit sends commands to the nodes over RF, and each node opens its valve and confirms its status. A pressure node monitors line pressure; the pump node protects the pump with dry-run and phase protection. Water consumption is logged and analyzed.

Expansion. Soil moisture, temperature/humidity and weather data feed into irrigation decisions; frost warnings and triggering of frost-protection equipment are planned. Target vertical: hybrid AI greenhouse automation — optimizing climate, irrigation and fertigation decisions through sensor fusion and a learning model (together with Telemetry & Process Intelligence).

The problem in the field. There are often hundreds of meters to kilometers between a well/pump and the water tank. Carrying level information by cable means trenching, cable theft and lightning damage. In manual operation, the tank overflows (wasting water and energy) or runs dry (supply interruption); the pump runs dry and burns out, and phase faults damage the motor.

The solution. The tank unit reads the level from a float switch or an analog level sensor and sends it wirelessly to the well unit. The well unit starts the pump at the low level and stops it at the high level, protecting it through dry-run and phase-protection inputs. If communication is lost, the pump stops after a defined time. Status is visible on site via LCD/LED, and several tanks and wells are managed in the same system. Tanks without mains power use a solar panel kit. The first generation (N1) and the ELD100-based second generation (N2) are in the field; the new KD001 board is coming soon.

Expansion. The roadmap covers level/flow telemetry with an analog level sensor (4–20 mA) and a flow meter (shared with the Wireless Analog & Digital Data Link), SCADA and mobile monitoring through the Wireless Gateway / RTU and Telemetry & Process Intelligence, and a water-network loss and leak package. For general-purpose contact transfer, the same platform is offered as the Wireless Digital I/O Link.

The problem in the field. Between a field sensor (level, pressure, flow, temperature) and the control room there may be a road, a river, a railway, another company's property or simply several hundred meters. Running cable means trenching, permits and theft; the longer a 4–20 mA line gets, the more noise and grounding problems it picks up. Collecting multi-point contact signals (motor status, doors, level switches) one cable at a time is expensive.

The solution. The data link digitizes the digital inputs and analog signals at one end and carries them over 433 MHz to the other end, where relay and analog outputs hand them to the PLC "as if hard-wired". The M16 master unit of the RT152 family collects 16 inputs, talks to the PLC over RS485 / Modbus RTU and is monitored through a web interface; SLI16 input and SLR16 relay expansion units increase the channel count. If the link drops, the outputs go to a defined safe state and a fault contact is signaled.

Expansion. The new series targets a battery-powered telemetry node (powering a level/flow/pressure sensor from a battery or solar panel and reporting periodically) and a pulse (meter) input (wireless reading of water/electricity meters through their S0 pulse output, sharing its platform with the Wireless Meter Reading Node). Modbus TCP via the Wireless Gateway / RTU, cloud monitoring via Telemetry & Process Intelligence and use as a building block of the IIoT Retrofit Kit are planned.

The problem in the field. At hotels and resorts, guests are on the beach, by the pool, in the garden or on the terrace, and the waiter is out of sight. Short-range call systems do not reach the beach; Wi-Fi based solutions struggle with coverage and battery life; raising a hand or shouting lowers the quality of service. Management has no idea how many seconds it takes to answer a call.

The solution. Every table, sun lounger or room gets a battery-powered call button; when a guest presses it, the call appears on the central display and on the pager of the waiter responsible for that area. The current-generation system works with a range of 100–200 m and shows the table/room number and call priority. The new generation aims to cover the indoor areas and the beach with a single gateway or one repeater thanks to long-range LoRa, to broadcast the waiter's acknowledgment to the other pagers and the display as "received", and to log call times for shift reports.

Application profiles. Single-button (call), three-button (call / bill / cancel) and six-button (menu-specific) versions; in the new generation, an IP65, UV-resistant sun-lounger button and a wall-mounted room/VIP button. The same button platform is also used for taxi calls, guard alarms and forklift/operator calls: Wireless Call Button Platform.

The problem. Taxi stands take calls from their subscribers (elderly and disabled people, residents of housing estates, shopkeepers) by phone: the line is busy, the number is forgotten, and not every customer has a smartphone or app. Existing wireless button systems work with simple light/sound receivers: you cannot see which subscriber pressed, in what order or how many times; there is no "received" signal from the driver's remote; the devices are old and spare parts are gone.

The solution. When pressed, the battery-powered button in the subscriber's home sends its ID and button number to the stand over RF. The stand receiver shows the subscriber's name/address, the time and the queue on a DWIN touchscreen, and a buzzer sounds. The next driver takes the call from the screen or from their own remote, and the call drops off the list. A web interface (ESP) manages the subscriber list and logs from a browser. With the two-way LoRa profile, an LED on the subscriber's button is intended to confirm the pickup.

Gradual migration. The new stand receiver uses the same RF settings as the subscriber buttons already installed in the field, so stands can switch over without replacing their buttons. In new installations, the LoRa button of the Wireless Call Button Platform provides long range and long battery life.

The problem. Call and alarm buttons all do the same job: someone presses, someone somewhere is notified. Yet each application is sold as a separate product — waiter button, panic button, taxi button, fire button — and most are short-range (100–200 m), one-way, unencrypted 433 MHz "remote" circuits with unknown battery life. They do not reach from the beach to the kitchen, from the neighborhood to the taxi stand, or from the factory yard to the guard hut; nobody knows whether a press was received; and two systems on the same site trigger each other.

The solution. The platform puts a battery-powered LoRa node (EM-G0L-433-LP) into a button housing. Each press sends an encrypted packet with the button ID, button number, battery status and a counter; when the central unit or receiver returns an acknowledgment (ACK), the LED on the button turns green (two-way operation is targeted). The firmware profile defines what a press means: waiter / bill / cancel, attack / fire / patrol, taxi call / cancel, break-glass alarm + tamper.

Wake-on-press design. The MCU and radio sleep until the button is pressed; periodic "I'm alive" packets let the central unit track battery and link status. Housing and labeling change with the application; the electronics stay the same.

The problem. Water utilities and organized industrial zones read hundreds of meters by hand: late bills, reading errors, trouble getting into meter pits and basements. Non-revenue water (NRW) analysis requires district inlet meters and subscriber totals to be read over the same time window, which monthly manual reading cannot deliver. In factories, energy, water and compressed-air consumption cannot be tracked per line; the meters have S0 outputs, but no cable was ever run. Off-the-shelf LoRaWAN meter modules require an operator subscription and a closed platform, and nothing can be done in the field apart from changing the battery.

The solution. The node connects to the meter's S0/reed pulse output; it counts pulses (debounced, 4 independent inputs), keeps the totals in non-volatile memory and, at a configured interval (e.g. 15 min / 1 hour), sends the total, interval flow, battery and RSSI over LoRa to the gateway (Wireless Gateway / RTU). The gateway passes the data to SCADA or to the Telemetry & Process Intelligence platform as Modbus, MQTT or CSV.

Versions. The battery version is designed to run in a meter pit for years; the mains-powered version sits on a DIN rail with a threshold relay (e.g. a leak alarm when the night-flow threshold is exceeded). To prevent data loss, the node is intended to keep its latest reports and the gateway to re-request missing intervals. Where continuous analog or contact signals must be carried, the Wireless Analog & Digital Data Link is used; the two products share the same pulse-input platform.

The problem. Most PLCs, RTUs, energy analyzers and meters speak RS485/Modbus RTU. When devices are spread across a site (wells, reservoirs, pump stations, transformers, silos), running an RS485 line means trenching, conduit and cable costs; road and stream crossings or third-party land can make the line impossible. Existing cable runs break due to lightning, moisture and digging accidents, and finding the fault takes hours. GSM modems bring subscriptions and dependence on network coverage.

The solution. The wireless RS485 modem is installed at both ends of the RS485 line and carries the serial data transparently over radio. The PLC/SCADA software does not change; the modem looks like a cable. The current EL485L-S links up to 10 km in open field (1200 bps, per the technical datasheet) with 500 mW output power; 40 channels let several links run side by side on the same site. With master/slave firmware, one central station can poll several remote ends (Modbus polling).

New series. The same function is to be delivered with an EM-G0L-433 or EM-G0L-868 module and the EC-485 carrier board (I/O Carrier Boards): LoRa modulation gives higher sensitivity and interference immunity at low data rates, the RS485 port becomes isolated, and an optional Wi-Fi/Ethernet Modbus TCP bridge (Wireless Gateway / RTU) is offered in the same housing.

The problem. In factories, hotels, warehouses and plants, getting an alarm (fire, intrusion, machine stop, customer call) to the person in charge depends on a siren and a light on the panel. That person is not always at the panel; phone/GSM notifications depend on coverage and apps, and they arrive late. When several staff members are on duty, nobody knows who is handling it, so the alarm is either handled twice or not at all.

The solution. WR-001 carries the alarm broadcast by the central unit (a panel or the Wireless Gateway / RTU) to the staff member's pocket over LoRa within seconds. The OLED shows the alarm code and its source, and a buzzer sounds. When the user acknowledges with OK, the ACK goes both to the central unit and, as a broadcast, to the other pagers; the central unit repeats it as ACK_RELAY, so pagers that were out of range are cleared too. The device normally sits in STOP mode while the radio listens with RX duty-cycling, aiming for low consumption and long battery life. Frequency, SF, power and address are set from the menu; a TX/RX test mode checks range during installation.

Works with. Alarms are generated by Elmes central units: Wireless Fire Alarm System (Firesens), Wireless Guard Patrol System, Wireless Waiter Call — Long Range and Wireless Call Button Platform. WR-001 is the pocket notification end of these systems; the text of the 8 alarm codes is defined per customer.

The problem. Doors in factories and campuses are scattered: outer barriers, warehouse doors, cold rooms, passages between production areas. With wired access control panels, every door needs reader, lock, contact and exit-button cabling; distance and inter-zone runs drive up the cost. Existing plants often have no cable route at all. Remote-type RF door openers, on the other hand, do not record who opened the door, can be copied and do not talk to a central unit. During a fire, nobody knows the state of the doors.

In the field today. The current generation makes the control part of the door chain wireless: door status is monitored and doors are opened and closed from the central touch panel; battery-powered button transmitters at remote points such as the guard booth or on forklifts send open commands to the door receiver over 433 MHz. The door receiver has relay outputs; frequency, channel and output power are set from its LCD menu.

New generation. A wireless door controller at every door: lock relay, door contact, request-to-exit (REX) button and MIFARE reader are wired locally, and the controller talks to the central unit over 433 MHz LoRa. The permission table is cached at the door, so cards are still read if the central unit is offline; events (card, door held open, forced entry, remote open) are sent to the central unit and logged. The door map, manual open/close, zone- and time-based access levels and anti-passback (on doors with entry and exit readers) are managed from the touch panel or a web interface. The reader, event log and web interface are targets of the new generation.

Fire integration. When integrated with the Wireless Fire Alarm System (Firesens), the assigned doors open or lock automatically on an alarm, and door status appears on the fire map.

The problem. Environmental quantities are critical in industrial sites but often go unmeasured: cold-room temperature, humidity in chemical stores, wind on crane and port yards (load sway, crane lock-out rules), panel and ambient temperature on solar farms, tank and well covers left open, motion outside working hours. There is no cable route for a wired sensor network; Wi-Fi/BLE sensors struggle with coverage and batteries; cloud IoT sensors require subscriptions and closed platforms. Alarms such as high wind or temperature drift do not reach anyone in time.

The solution. The sensor node family fits different sensor heads onto a single battery-powered LoRa node. The node sends periodic measurements (e.g. every 10 minutes) and an instant alarm packet when a threshold is crossed; the Wireless Gateway / RTU passes the data to SCADA or to the Telemetry & Process Intelligence layer via Modbus, MQTT or CSV, and WR-001 carries alarms to the staff member's pocket. The mains-powered version adds a local relay output: a crane lock relay when the wind limit is exceeded, a fan when a temperature threshold is crossed.

The family. The anemometer housing and PCB are designed by Elmes; the temperature-humidity node moves from the earlier SHT11-based design to modern SHT3x/SHT4x sensors; the level and door-contact nodes are derived from existing I/O firmware. Thermal, infrared and laser sensors are planned members of the family; they have no prototypes yet and are listed as coming soon.

The problem. When a machine or device manufacturer wants to add wireless features, it runs into three obstacles: (1) RF design and the matching network require expertise, and range and interference problems surface in the first prototype; (2) RED/EMC testing and the documentation burden repeat for every new product; (3) off-the-shelf Far East modules are cheap, but their firmware is closed, their pinout and supply change with the next revision, and there is no local support in Turkish.

The solution. The EM series opens up the MCU + radio module that Elmes uses in its own products: a measured radio path, an open SDK and bootloader, a fixed pinout and a documented production test. The integrator only writes the carrier board and the application code; the radio, power management and update infrastructure are ready. Because the same pinout is shared by the LoRa (L), Wi-Fi/BLE (W), cellular (C) and combined LoRa + Wi-Fi (LW) members, a product family can offer different connectivity options from a single PCB design.

The family. The common MCU is the STM32G0 (Cortex-M0+). EM-G0L-433 is the main MCU + LoRa member; EM-G0LW-433 combines LoRa and Wi-Fi/BLE in a gateway core; EM-NL-433 is a radio-only module for designs that already have their own MCU. EM-G0W is the Wi-Fi/BLE member, EM-G0C the cellular member, EM-G0N the radio-less core and EM-W5L-433 the STM32WLE5 integrated LoRa member. MOD-M0, already in the field, provides a migration path to the new series with the same software.

Ecosystem. The modules are used on I/O carrier boards with relay, analog, RS485 and pulse-counter interfaces; a fixture and SDK package covers programming, production testing and software development.

The problem. A manufacturer that wants to add wireless features faces RF design risk, a RED/EMC documentation burden that repeats for every product, and imported modules with closed firmware. For long-range, low-data-rate industrial control and telemetry at 433 MHz, neither a Wi-Fi module nor 2.4 GHz solutions are enough; LoRa is the right physical layer for getting through walls and terrain and for battery-powered nodes.

The solution. EM-G0L-433 combines an STM32G0 (Cortex-M0+) and an SX1268 in a single castellated module; the matching network, TCXO and PA path come measured by Elmes. The integrator only writes the carrier board and the application code. Variants of the same PCB (battery-powered LP, low-cost K, 868/915 MHz) are managed with a single validation and a single BOM family.

The difference. Off-the-shelf imported LoRa modules either have no MCU (radio only) or a closed one; on EM-G0L-433 the MCU is open and programmed with the SDK. Shared features such as the bootloader, OTA, ID programming and low-power profiles are described on the EM Module Series page.

The problem. Every Elmes RF system has a “central end”: the fire alarm gateway, the irrigation master, the taxi call receiver, the well and tank receiver. Until now these were built with separate boards, different MCUs and different connection paths (USB-CDC, Raspberry Pi, GSM–CAN). For every new product the LoRa radio, connectivity and power were designed again, and placing Wi-Fi and LoRa on the same board caused coexistence problems each time.

The solution. EM-G0LW-433 standardizes this central end in a single module. The STM32G0 manages the LoRa network (addressing, ACK, timing, local I/O and RTU logic); the ESP32 is only a Wi-Fi/BLE “modem” and uses the same bridge protocol as EM-G0W: data to the Telemetry & Process Intelligence platform over MQTT/HTTP, maintenance through a local web interface, and phone access over BLE. USB (G0B1) keeps PC-side gateway use available. Ethernet and a 4G modem are added on the carrier board (EC-GW carrier, EM-G0C cellular module).

RF coexistence is solved once, at module level: separate antennas, a harmonic filter on the 433 MHz PA output, separate power domains and timing in the SDK (planned: deferring Wi-Fi transmission during the LoRa receive window). The module's main user is the Wireless Gateway / RTU product.

The problem. Some Elmes products (crane receivers/transmitters, the RT152 data transmitter family) already have an MCU that is not going to change; all they need is a LoRa radio. Today that gap is filled by imported off-the-shelf radio modules: single source, closed design, pinouts that change between revisions and no documentation in Turkish. Designing around a bare SX1268 instead means repeating the matching network and measurements for every product.

The solution. EM-NL-433 takes the radio section of the EM-G0L-433 module and makes it a separate castellated module: SX1268 + 32 MHz TCXO + RF switch (controlled by DIO2) + matching and harmonic filter + u.FL/antenna pin. The interface is plain SPI + BUSY/DIO1/NRESET with 3.3 V logic. The driver is open and platform-independent.

Variants. The same PCB takes LLCC68 (EM-NK-433) and SX1262 (868/915 MHz) versions. In Elmes products it replaces the imported off-the-shelf module; for other manufacturers it offers a “take the radio, keep your MCU” option.

The problem. In a wireless control project, the module is the small part of the job; most of the time goes into relays, opto-isolated inputs, 4–20 mA measurement, RS485 isolation, 24 V supply protection, terminal layout and the enclosure. In Elmes's existing products (Wireless Well & Tank Control System, Wireless Analog & Digital Data Transmitter, Wireless RS485 Modem), these blocks were redrawn on a separate PCB for every product; an external customer who buys a module has to do the same work from scratch and fights EMC, relay and power-supply problems in the first prototype.

The solution. The EC series separates the function circuitry from the module: the module carries the radio and MCU, the carrier board handles the field side. Five function boards (digital, analog, serial, pulse, gateway) and one wide digital board share the same module socket and the same common block (power, service connector, antenna path, LEDs). Elmes products — well/tank control, data transmitter, RS485 modem, Wireless Gateway / RTU, Wireless Digital I/O Link — 8 Channels and Wireless Meter Reading Node — are these boards loaded with application firmware; external customers use the same board with their own firmware or with Elmes's standard Modbus/I/O firmware.

Module and housing. The castellated members of the Elmes Module Series plug into the boards; for applications that need LoRa and Wi-Fi together, the EM-G0LW-433. Two housing options are available: a fast, economical DIN-rail housing or an industrial DIN-rail housing, with the same PCB in both.

The problem. Once wireless nodes are installed in the field, the end that carries data to the control room is rebuilt for every project: a USB converter on a PC, a Raspberry Pi script, a GSM modem and hand-written protocols. This end is the most fragile part on site: it does not restart after a power cut, data is lost when the connection drops, PLC integration needs a separate converter, and updates have to be done on site.

The solution. The Gateway/RTU turns the central end of the Elmes LoRa network into a standard product. The gateway layer forwards LoRa packets to a server over USB-CDC, Ethernet or 4G using a binary/JSON protocol, and to PLC/SCADA over Modbus TCP; the node list, polling interval and alarm acknowledgment are configured on the device. The RTU layer adds local I/O (carrier boards), a time-stamped buffer (no data loss when the link drops), rule-based local logic (threshold → relay, timers) and an RS485 Modbus master. The Edge-AI layer (planned) uses an STM32H7 to detect anomalies in node data on site and sends only events upstream.

Hardware. The device is built by fitting the EM-G0LW-433 module (STM32 + SX1268 + ESP32) onto the EC-GW board of the I/O Carrier Boards family. The RTU version adds local I/O with EC-DIO8 and EC-AIO boards; the 4G version uses the EM-G0C cellular module.

The problem. Most field failures in wireless control systems come from the antenna, not the radio: a whip antenna stuck to a metal cabinet, a cheap antenna for the wrong band, a long lossy cable, a loose connector, a pigtail that has taken in water. Users look for a stronger radio because “the range is not enough”, yet a 3 dB gain difference or raising the antenna by 2 m gives the same result. Gain claims of imported antennas are often unverified.

The solution. The Elmes antenna series is an accessory list matched to Elmes products, with a defined band and connector for every item: omni whip antennas for inside and outside the cabinet (standard), a directional Yagi for remote points (433 MHz, 8.9 dBi declared), a vertical J-pole at 868 MHz, plus mounts and cable sets. For Elmes Module Series customers, u.FL pigtail and SMA options are on the same list. The goal is for every product page to link to this list through a “recommended antenna” row, with range tables naming the antenna used for the measurement.

Gain values. Gains in the tables are manufacturer datasheet claims. Elmes measurements are published separately, together with the measurement conditions, as they are completed.

The problem. Selling a module is not enough: the integrator's first question is “how do I program it, how do I test it, how do I update the firmware?” With imported modules, the answer is an AT command set and closed firmware, and production testing is left to the customer. In Elmes' own production, too, testing and programming are done with product-specific scripts and hand-connected SWD cables; they are rewritten for every product and no measurement records are kept.

The solution. ET-FIX-EM is a fixture that holds the castellated module on pogo pins and provides SWD, UART, power/current measurement and the RF output (SMA → attenuator → power meter/spectrum analyzer) over a single USB connection. The test script (the SDK production test protocol) runs the steps in sequence, logs the result against the module's UID, and writes the ID/NetID/channel and calibration values. ET-SDK-EM delivers the same protocol and every software layer of the module (HAL, radio driver, bootloader/OTA, protocol core, examples) under an open license; Elmes product applications and network/fleet tools stay in the Pro tier.

Two license tiers, one code base.

The open tier drives adoption of the module and builds trust; that is the real difference from closed imported modules. Open and Pro builds come from the same repository with different build profiles. The bootloader is open; the signature verification key is embedded in the product and the private key stays with its owner — customers can sign their own modules with their own key.

The problem. Imbalance in fans, pumps, motors and rotors is the most common source of vibration in industry. To balance a rotor in the field without removing it, plants use imported vibration analyzers (VIBXPERT II class); being multi-channel and multi-function, these are expensive and come with neither a Turkish interface nor local service. Yet balancing services and maintenance teams need only “1X amplitude + phase + single-plane correction” for most jobs.

The solution. VibroBal measures 1X amplitude and phase with a single vibration sensor and an optical tachometer, and a guided wizard (reference run → trial weight → result) gives the correction weight in grams and degrees. The same device shows machine condition with a spectrum (4096 points), time waveform, RMS/peak/crest values and ISO 20816 zone colors. The programmable analog front end selects gain and anti-alias filtering automatically, so the operator never has to deal with signal levels.

Positioning. The aim is not to replace the VIBXPERT II but to cover the most frequently performed subset of its jobs with an affordable, locally made device. Two-plane balancing and multi-channel measurement are out of scope; those jobs are left to a balancing-machine measurement system.

The problem. A machine builder making foggers, ovens, laboratory cabinets or chillers is an expert in mechanics and process; for electronics it either uses an off-the-shelf PLC/HMI (expensive, does not fit in the device, high unit cost) or a one-off contract design (built from scratch on every project: bootloader, HMI, alarms, logging, production test, CE). On the second route, know-how gets scattered, there is no version management, field updates need a technician, and consumables revenue cannot be protected.

The solution. The platform builds the OEM device's entire electronics stack from ready-made blocks: a mainboard (I/O, power stages, HMI port, module slot), a firmware framework (recipes/programs, multi-step process, PID, alarms/logging, user levels, operating hours, bootloader + Wi-Fi/USB OTA), HMI (DWIN/Nextion for a fast solution, DiscOS for advanced interfaces), modules (RFID consumable validation and usage counter, load-cell weighing, RF/phone remote control), fleet software (device inventory, firmware rollout, logs) and a production/compliance package (QC checklist, test fixture, CE technical file template). Only the device-specific layer is customized for each OEM.