Wireless M-Bus Repeater
Description
The Wireless M-Bus Repeater brings wireless M-Bus meters into reach of your gateway when they are too far away or behind too many walls and ceilings: in basements, stairwells, underground garages or the far end of a building. It needs no cabling, no SIM card and no cloud account. It works with any wireless M-Bus gateway, not only with Lobaro gateways, because the repeated telegrams stay standard wireless M-Bus telegrams.
How it works
- Listen. The repeater listens for wireless M-Bus telegrams of the meters around it (C1/T1, optionally S1) in configurable listen windows, by default once a day at 08:00 UTC for 31 minutes. On an external supply it listens continuously.
- Select. Only the telegrams you need are passed on: filters by meter ID, manufacturer, device type and minimum signal strength keep foreign meters and meters the gateway already hears directly out of the airtime. The same telegram of a meter is forwarded only once within the suppression window, also when the repeater hears it a second time as a copy from a neighbouring repeater.
- Forward. A few seconds after reception (5 to 30 seconds, as the wireless M-Bus standard allows) the repeater sends the telegram again, unchanged and still encrypted, with a short footer appended: its own serial number and the signal strength at which it received the meter. The gateway receives the telegram as if the meter were next to it and decodes it as usual.
- Report. Every five minutes the repeater sends its own status telegram with battery voltage, time and the numbers of forwarded and dropped telegrams (counted since power-up), so the gateway also shows that the repeater itself is alive. Once a day, and every 15 minutes during installation, an extended status telegram adds the firmware version, uptime and counters of received, forwarded and dropped telegrams.
Several repeaters can be chained to bridge longer distances. Each one adds its footer, so on the gateway side you see the whole path of a telegram and the signal quality of every link, and a telegram can never circle between repeaters. Repeaters that hear each other do not multiply the traffic: each forwards a meter telegram once, however many copies it hears. The repeater keeps to the legal transmit limits of the 868 MHz band by itself (transmit power and duty cycle), also in buildings with hundreds of meters.
What you get
- More meters per gateway: meters in poor radio locations no longer need an extra gateway.
- Data you can trust: meter telegrams are passed on byte for byte, encryption included; the repeater never needs the meter keys.
- Insight into the radio field: signal strength per hop in every repeated telegram helps to find the best mounting position and to monitor installations remotely.
- Easy installation: during the first hour after power-up the repeater listens continuously, may use more airtime and blinks its green LED, so the gateway shows right away which meters it can serve.
- Long battery life: listening only in the configured windows, sleeping in between.
Real-time clock, set at the factory
The repeater has a temperature-compensated real-time clock on its add-on board, set to UTC at the factory and kept running by its own backup cell:
- Works from the first minute: the listen schedule (
listenCron) is correct right after installation. No network, no time server and no time synchronisation over the air are needed – the repeater has no internet connection anyway. - In step with the gateway: repeater and gateway listen at the same time of day, which is what makes short daily listen windows and a long battery life possible.
- Survives battery changes: the backup cell keeps the clock running while the main battery is replaced; the schedule continues without reconfiguration.
- Stays accurate for years: temperature compensation keeps the drift low, and the repeater takes the time from the RTC into its internal clock at the start of every listen window, at least every 10 hours. At room temperature the clock drifts by at most about one minute per year, up to 2.5 minutes in the first year while its crystal ages. Let the gateway's listen window start a few minutes before the repeater's and end a few minutes after it, or set the repeater's clock again during maintenance.
- Valid timestamps: every status telegram carries the current time. If the clock was ever lost, the status telegram says so (TPL.sts
0x43). - Faults are visible on site: the clock is mandatory since v0.16.0 (the former parameter
rtcChipis gone). If the RTC does not answer, the repeater does not start: like any Gateway V4 with a missing add-on, it blinks its red LED for 60 seconds and restarts. If the RTC answers but has lost the time, the repeater cannot keep to the gateway's schedule. It then stops repeating, sleeps and wakes every 15 minutes to send a status telegram with the alarm since v0.16.0, until the time is set again; on external supply it keeps listening. During install mode its LED blinks red instead of green.
Features
- Wireless M-Bus repeater, 868 MHz: receives C1/T1 and S1 telegrams, re-transmits them in C1 mode
- Appends a repeater footer with its serial number and the received signal strength (RSSI) to each re-transmitted telegram, one footer per hop
- Multi-hop chains with loop protection, configurable hop count and static routes (
repeatFrom) - Reception filters by meter ID, manufacturer, device type, CI field and minimum signal strength (
minRssi) - Duplicate suppression per meter and an airtime limiter that keeps the 0.1 % duty cycle of the 868 MHz band
- Transmit power adjustable to the antenna gain (
antennaGain) - Periodic status telegrams with battery voltage, time and transmit counter, plus a daily extended status telegram with firmware version, uptime and diagnostic counters; factory-set RTC with backup cell on the Repeater Add-On board
- Install mode after power-up: continuous reception, green LED blinks at 0.5 Hz
- Continuous reception on external supply
- Local configuration only via USB Config Adapter (no cloud connectivity, no remote config)
How listening, filtering, re-transmission and the airtime limit work in detail is described under Operation below.
Product Components
- Firmware
- app-nrf91-origin · Firmware updates
- Housing
- LoCube — 122 × 82 × 55 mm
- Power supply
- Battery 38 Ah (Li-SOCl₂, 3.6 V) · External 12 V DC or 230 V AC available
- Optional accessories
- External antenna (SMA) · IP68 encapsulation · LoCube wall mounting kit · Pole mounting kit
Operation
Listening and sleeping
The repeater listens in windows, like a gateway: every listenCron trigger starts the configured cmodeDurSec (C1/T1) and smodeDurSec (S1) windows, then the device sleeps until the next trigger. With the defaults it listens once a day at 08:00 UTC for 31 minutes on battery, and continuously when it is supplied externally (extPowerAlwaysListen); on battery, 0 0/15 * * * * with cmodeDurSec=900 makes it listen continuously.
During the first installModeDuration seconds after power-up (default one hour) it listens continuously regardless of the schedule, blinks the green LED at 0.5 Hz and may use 1 % airtime instead of 0.1 % (see Airtime limit).
Telegrams are only repeated while the repeater is listening. A telegram that arrives in the last seconds of a window is still sent.
What is repeated
A received telegram passes this chain; each step can drop it:
- The reception filters
mFilter,typFilter,devFilterandciFilter. minRssi: received weaker than the threshold → not repeated.- Only OMS telegrams (format A or B with a valid header) are repeated.
maxHopCount: the telegram has already passed that many repeaters → not repeated.- Loop protection: the telegram already carries this repeater's own footer → not repeated. The repeater also recognises its own status telegrams coming back from a neighbour.
repeatFrom: a telegram that was already repeated is only repeated again if its last hop is a whitelisted repeater.- Duplicate suppression: the same meter telegram was already repeated within
suppressionTime→ not repeated. Footers do not count: a neighbour's copy of a telegram this repeater has already sent is the same telegram.
When telegrams are sent
- Telegrams are re-transmitted in C1 mode, whether they were received in T1, C1 or S1; the frame format (A or B) is kept. A gateway that only listens in S1 mode therefore does not receive the repeats.
- Repeats go out in bursts: a burst starts 5 to 20 seconds after the previous one and sends every telegram that has waited at least 6 seconds, oldest first. A telegram is repeated 5 to 30 seconds after reception, typically after about 12 seconds. Telegrams older than 30 seconds are discarded; the standard does not allow later repeats.
- Status telegrams are sent at the start and the end of every listen window since v0.16.0 and every
statusIntervalseconds in between (default 300 s). The extended status telegram is sent in the first window after power-up, with every status telegram during install mode and then about once a day, with the default schedule in the daily window.
When the repeater transmits
| Telegram | Install mode (first hour after power-up) | Battery, default schedule (daily 08:00 UTC, 31 min) | External supply (continuous listening) |
|---|---|---|---|
| Repeated meter telegrams | 5 to 30 s after reception, continuous listening, 1 % airtime | 5 to 30 s after reception, only in the window, 0.1 % airtime | 5 to 30 s after reception, 0.1 % airtime |
| Status telegram | right after power-up, then every statusInterval (300 s) | at the window start, then every 300 s (4 per window) | every 300 s |
| Extended status telegram | together with every status telegram | together with the first status of the window (once a day) | hourly, together with a status telegram |
All telegrams are only sent while the repeater listens, which is also when the gateway listens. The byte formats are described on the wM-Bus telegram formats page.
Airtime limit
The repeater transmits on 868.95 MHz in the band 868.7 to 869.2 MHz, which allows a duty cycle of 0.1 %: 3.6 seconds of airtime per hour. The firmware enforces this with a sliding one-hour budget measured in real time, so airtime used before a sleep period counts down while the repeater sleeps. A repeated telegram costs about 8 ms for a typical meter telegram of 60 to 70 bytes (about 6.5 ms for 50 bytes, 10 ms for 100 bytes, footer included), a status telegram about 5 ms, the daily extended status about 13 ms. How many telegrams fit into an hour therefore depends on the meters: about 350 with 100-byte telegrams, about 450 with typical 60 to 70 bytes, up to about 700 with very short telegrams of 30 bytes. Repeated telegrams leave the airtime the repeater's own status telegrams need since v0.16.0 (about 85 ms per hour with the default statusInterval, about 310 ms at 60 s), so these still get through at the limit and report it in their status byte. When the budget is exhausted the queue waits, oldest telegrams first, and telegrams that grow older than 30 seconds meanwhile are dropped. In dense installations use minRssi, the reception filters and suppressionTime to spend the airtime on the meters that need the repeater.
Install mode. During installModeDuration after power-up the limit is 1 %, i.e. 36 seconds per hour. Commissioning is not part of normal operation in the sense of EN 300 220-2, and the higher limit lets the gateway receive every meter the repeater can serve: use that hour to decide which meters belong in devFilter and where to set minRssi. When install mode ends the limit drops back to 0.1 % and the repeater continues without a pause.
Monitoring the repeater
Most questions about a repeater in the field are answered by its status telegram; the extended status adds firmware, settings and detailed counters. All counters run since power-up: compare two telegrams of the same repeater, and if a value went down, the repeater restarted and the new value is the difference.
| Question | Status telegram | Extended status telegram | Footer of repeated telegrams |
|---|---|---|---|
| Is it alive, is its window running? | arrives every 300 s while it listens | ||
| Is it at the airtime limit? | status byte bit 20 since v0.16.0, rising dropped counter 04 FF 04 | FF 08 busiest hour, FF 0A total airtime / FF 0B listening time | |
| How much does it forward? | repeated counter 04 6E | FF 02 received, FF 03 repeated, FF 05 suppressed, FF 06 CRC errors | |
| Is its clock right? | date and time 06 6D, status byte 43 | FF 07 bit 2 | |
| Battery voltage? | 02 FD 46 | 02 FD 46 | |
| External supply, install mode? | FF 07 bits 1 and 0 | ||
| Did it restart? | counters lower than before | 04 20 uptime, FF 01 reboot code | |
| Firmware version and configuration? | 03 FD 0E, FF 10 to FF 17 | ||
| Which way did a meter telegram take, how good is each link? | serial number and RSSI per hop | ||
| Which meters does a repeater reach? | all telegrams with its serial number in a footer |
The average load while listening is the difference of FF 0A divided by the difference of FF 0B between two extended status telegrams, in ms per second; the limit is 1 ms/s. A set bit 20 alone means the repeater is at the limit but has not lost anything yet; a rising dropped counter means meter readings are lost: narrow the meters down with devFilter or minRssi, or add a second repeater. The byte layouts are on the wM-Bus telegram formats page: header and status byte, status telegram, extended status telegram, footer.
Multi-hop Chains
Every hop appends a footer with the repeater's serial number and the signal strength at which it received the telegram, so the gateway sees the whole path and the quality of every link (formats). Loops are impossible: a repeater never repeats a telegram that already carries its own footer, and maxHopCount caps the chain length. Chains of up to four repeaters work with the defaults; every hop adds 5 to 30 seconds.
Static routes
For a defined topology, give every repeater a whitelist of its upstream neighbours in repeatFrom and set maxHopCount to the chain length. Example, meters at the far end, gateway at the other:
| Device | repeatFrom | maxHopCount | Meaning |
|---|---|---|---|
| Repeater A (near the meters) | * or empty list | 1 | repeats only telegrams straight from meters |
| Repeater B | <serial of A> | 2 | repeats meter telegrams and telegrams that came through A |
| Repeater C (near the gateway) | <serial of B> | 3 | repeats meter telegrams and telegrams that came through B |
repeatFrom never blocks telegrams that come directly from meters; every repeater also serves the meters it hears itself. If a devFilter whitelist is used on the gateway or the repeaters, add the serial numbers of the repeaters in the chain, otherwise their status telegrams are discarded and the chain cannot be monitored.
Repeaters of other manufacturers
The repeater footer (serial number plus RSSI, 10 bytes) corresponds to the Lansen format with RSSI appended, so the repeater recognises such footers and they show up in the hop path.
Some repeaters can be configured to forward telegrams without any footer; then only the hop bit marks a repeated telegram, and many telegram types (e.g. OMS security mode 7, or telegrams without a transport header) have no hop bit at all. Such a copy looks like a telegram straight from the meter:
- This repeater forwards it once with its own footer. If the copy comes back, the footer is recognised and it is not forwarded again: at most one extra round, no loop.
repeatFromcannot check a hop without a footer; it only applies to telegrams with at least one footer.- The other repeaters have no footer of their own to recognise; they limit repeats with their duplicate suppression only. Keep
suppressionTimeabove0on every device in such a field.
Planning an Installation
Repeater and gateway windows. The repeater shifts every telegram by 5 to 30 seconds. A gateway that listens only in short windows loses the telegrams that arrive in the last 30 seconds of its window: with a 4-minute window that is up to 12 % of the window. Choose the gateway's listen windows considerably longer than 30 seconds, at least several minutes, and align the repeater's listenCron with the gateway's so that the repeater is awake whenever the gateway is.
Duplicate suppression. suppressionTime sets how often the repeater forwards the same meter. With listen windows it decides how many chances a meter gets per window. An OMS meter sends at least every 15 minutes, so the default window of 31 minutes hears every meter at least twice; the default suppressionTime of 20 minutes repeats it once, at most twice, per window since v0.16.0. This keeps the airtime low: depending on the telegram length, one repeater can serve about 350 to 700 meters per window within the duty cycle (about 450 with typical meters). A shorter suppressionTime (e.g. 10 minutes) repeats each meter more often, so a telegram lost once still gets through; use it where a repeater serves fewer than half that number, i.e. about 175 to 350 meters depending on the telegram length. A longer listen window for more chances is the more expensive way, because the gateway has to listen just as long. When listening continuously, set suppressionTime to one third to one quarter of the interval in which the backend needs a value, e.g. 30 minutes for one value every two hours.
Copies on the gateway. The gateway does not merge a meter telegram it receives directly with the copies that arrive through repeaters: every copy carries different repeater footers and is uploaded on its own. This costs little and is useful. On the platform you see for every meter which paths reach the gateway and with which signal strength per hop, so you can spot repeaters that are not needed for a meter (the gateway already hears it directly with a good signal) or that are poorly positioned (weak RSSI on the link to the meter or to the next hop). Use that to move a repeater, or to keep such meters off it with devFilter or minRssi and save its airtime.
Signal strength. Run the repeater with verbose=true during install mode or for a few hours, read the RSSI of every meter from the wmbus| RXed: ... RSSI: ... ID: ... lines and set minRssi so that meters the gateway hears well on its own and meters too far away to be useful stay below it. The footers of the repeated telegrams show the same values on the gateway side.
Antennas with gain. Enter the antenna's gain in antennaGain; the repeater lowers its transmit power accordingly.
Power Consumption and Battery Life
Listening is what drains the battery: deep sleep, repeating telegrams and sending status telegrams
add only a few percent. The battery life therefore follows almost entirely from the time the
repeater listens per day (listenCron, cmodeDurSec and smodeDurSec).
Typical battery life with the 38 Ah battery pack (worst-case capacity, 10 % safety margin), measured with firmware 0.16.0:
| Listening per day | Battery life |
|---|---|
| 1 × 15 min | more than 12 years |
| 1 × 31 min (default) | about 13 years |
| 1 × 60 min | about 7 years |
| 2 × 31 min | about 6.5 years |
| 4 × 31 min | about 3 years |
| Continuous | about 3.5 months, use an external supply |
For a battery life of 10 years, keep the listening time below about 40 minutes per day. The first hour after power-up (install mode) is included.
Product Identification
- Name: Wireless M-Bus Repeater
- Type: LOB-GW4-REP
- Ordering code:
1201298
LED Signal Patterns
The device uses the standard V4 LED signal patterns. See LED Signal Patterns for the full reference.
During install mode, the green LED blinks at 0.5 Hz (one second on, one second off) while the repeater listens continuously. Install mode is active for the first hour after reboot (installModeDuration).
Configuration
Configuration is done locally only via the USB Config Adapter and the Lobaro Config Tool. Remote configuration (CoAP / MQTT / LoRaWAN downlink) is not supported. All parameters with defaults and value ranges are listed on the Repeater Add-On configuration page.
Configuration Parameters
The Wireless M-Bus Repeater does not use most of the standard app-nrf91-origin parameters. There is no cloud upload, no NB-IoT/LTE-M/LoRaWAN upload configuration, and no platform connectivity. Only the parameters listed on the Repeater Add-On configuration page apply.
- Repeater Add-On parameters — listen schedule, wM-Bus filters, minimum RSSI, hop count, duplicate suppression, antenna gain, RTC, install mode
- wM-Bus telegram formats — repeater footer, short footer, status and extended status telegram
Firmware Updates
Public firmware downloads for this product are not yet available. They will be published here soon.
If you require a firmware version in the meantime, please contact support@lobaro.de.
Upload Formats
Unlike other Gateway V4 variants, the Repeater has no cloud connectivity — it does not send data to any backend. Instead, it re-transmits received wM-Bus telegrams over the air with an appended footer, and sends its own status telegram every five minutes. A receiving wM-Bus gateway (e.g. a Gateway V4) handles the upload.
The byte formats of the repeater footer, the short footer for very long telegrams and the status telegram are described on the wM-Bus Telegram Formats page.