Lobaro wMBUS-LoRaWAN User manual

 wMBUS over LoRaWAN Bridge 
User Manual
Product Name: wMBUS-LoRaWAN
Related Firmware:  V1.5.1
Document Date: 2018-08-31

Contents
Contents
1. Overview 3
2. The Device 4
2.1. Deviceinstallation................................ 4
2.2. PowerSupply .................................. 4
2.3. Batterylifetime................................. 5
2.3.1. Example calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.2. Usage scenario recommendations . . . . . . . . . . . . . . . . . . . 6
3. Work Cycle 7
3.1. InitialPhase................................... 7
3.2. LoRaWANJoinPhase.............................. 7
3.3. DataCollectionPhase ............................. 8
3.4. DataTransferPhase .............................. 8
3.5. SleepPhase................................... 8
4. Conguration 9
4.1. The Lobaro Maintenance Tool . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Connecting the USB cong adapter . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Systemparameters ............................... 10
4.3.1. LoRaWAN network parameters . . . . . . . . . . . . . . . . . . . . . 11
4.3.2. wMBUS bridge parameters . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.3. Cronexpressions ............................ 14
5. LoRaWAN Data Upload Formats 14
5.1. StatusPacket.................................. 15
5.2. DataPacket................................... 15
5.2.1. Examples ................................ 16
5.2.2. UploadRate............................... 16
5.2.3. DecodingwMBUS ........................... 17
6. Technical characteristics 19
6.1. HousingDimensions............................... 20
A. CE Declaration of Conformity 21
B. Wireless M-Bus denitions 22
C. Disposal 23
D. Entsorgung (German) 25
E. Document Versions 26
wMBUS over LoRaWAN Bridge 2

1. Overview
1. Overview
The Lobaro wireless M-Bus (wMBUS) to LoRaWAN Bridge is a cost-eective & energy-
ecient device that receives, caches and transparently forwards wireless M-Bus metering
data from up to 500 consumption meters via any LoRaWAN network onto the Internet.
Many gas, water, electricity and heat meters can be read wirelessly today using the common
short range Wireless M-Bus standard. Because such wMBUS enabled meters use the classical
energy saving FSK radio modulation, the wireless range is often limited to less than 50m
and therefore requires the use of additional longer-range radio technologies to forward the
metering data onto the Internet. The advanced LoRa radio modulation used inside the Lobaro
wMBUS to LoRaWAN Bridge is such a key technology.
Figure 1: System overview wireless M-Bus over LoRaWAN bridge
1
LoRaWAN based LPWANs (Low Power wide area networks) allow connections to the Inter-
net from small battery powered devices with wireless ranges of up to 5 kilometers between
the transmitter and receiving gateway antenna - without the usual cellular network costs in
classical M2M or smart metering solutions. Also - unlike with cellular networks - it's possible
to setup own gateways if needed. This often results in much lower operational costs with the
Lobaro wMBUS bridge compared to conventional remote meter reading via LTE networks.
The metering data will not be decrypted by the LoRaWAN Bridge, instead an unchanged
1:1 forwarding takes place via one or more LoRaWAN packets (depending on the wMBUS
telegram byte size). Thus the end-to-end encryption of sensitive wireless MBUS consumption
data is preserved.
Initial conguration, rmware updates & status readouts are done user-friendly via USB on the
PC with the Lobaro Tool (Windows, Linux, Mac). An additional possibility of conguration
1
Energy- & Water Meter and House Icons made by Freepik from flaticon.com licensed by CC 3.0 BY
Heater Icon made by Nikita Golubev from https://www.flaticon.com/ licensed by CC 3.0 BY
Map Icon Icons made by Darius Dan from https://www.flaticon.com/ licensed by CC 3.0 BY
wMBUS over LoRaWAN Bridge 3

2. The Device
in the eld "over the air" by means of LoRaWAN downlinks will soon also be available via
rmware update.
Please read the manual carefully before operating the device. A safe operation of the
device is only possible if you follow the guides provided in this manual. Using the device
dierently than intended by Lobaro my cause damage to people, the environment, or
the device.
2. The Device
2.1. Device installation
The device must be xed on a at surface using the lateral mounting holes of the case, see
chapter 6.1 for a detailed description of all housing dimensions. Alternatively we oer as
accessory a mounting clip for a standard 35mm DIN rail. The device can then easily snapped
on a such rails. It can therefore be added to a variety of racks alongside other devices.
Under any circumstances the device must not be mounted higher than 2 meters above
ground to avoid any risks in case of falling down!
For optimal RF performance (e.g. LoRa range) any metal obstacles near the internal antenna
should be avoided. In this case `near' is dened as keep-out distance of about 3-5 centimeters
around the antenna. The internal helix antenna can be identied by the winding pcb traces
near the white printed encircled `connectivity' symbol. In any case a device mounting directly
on top of a metal surface is not advisable since it will degrade the possible RF range. Stone
walls, wood or plastic standos are perfectly ok.
In case of challenging installation locations (e.g. in basements) or unavoidable long distances
to the next LoRaWAN gateway, Lobaro oers on request custom product variant equipped
with a `SMA' connector to support a external antenna connection.
2.2. Power Supply
The wMBUS over LoRaWAN Bridge default power supply consists of two series connected
o-the-shelf 1.5V `AA' sized batteries. Be sure to get the polarity right, see the `+'-Symbol on
the board. In general only AA cells of the types Alkali-Manganese (1.5V, LR6) and Lithium-
Iron-Sulphide (1.5V, FR6) are allowed to be inserted in the device. Lobaro recommends the
use of FR6 batteries like the Energizer Ultimate Lithium over LR6 types because of the higher
capacity and better discharge properties.
Other Batteries or accumulators with a nominal voltage of more than 1.5V must not
inserted into the device under any circumstances. In particular, lithium based cells with
a nominal voltage of 3.6V or 3.7V must not be used on the AA battery slots!
wMBUS over LoRaWAN Bridge 4

2. The Device
On request we can supply custom product variants with special housings powered by even
bigger batteries. For example a 3.6V C sized mono cell typically has a capacity of 9Ah with
leads to a 3x increased battery life compared to the standard AA-cells. With D sized cells of
typically 19Ah capacity this value can be doubled once again (6x). Also available on request
are options with permanent external power supply (230V, 9-24V, 5V USB).
2.3. Battery life time
The battery life time of the wireless M-Bus to LoRaWAN Bridge can not be specifed trust-
worthy without knowledge of the detailed installation scenario. At least estimations for the
following custom project based parameters have to be known:
 Meter count per single wMBUS bridge, e.g. 10 dierent meters.
 Needed LoRaWAN transmission interval, e.g. daily uploads.
 Average wireless M-Bus telegram size in bytes, e.g. 35 byte.
 Wireless M-Bus telegram transmission interval of the meter, e.g. every 10 seconds.
 Typically used LoRa Spreading Factor / LoRa link quality, e.g. SF10.
Depending on these parameters battery life times from a few months to over 15 years can
be achieved. You may send us your use-case details as described above to [email protected]
and we will return to you a custom battery lifetime calculation, a recommendation for the
best power supply scheme and the needed minimal battery capacity.
2.3.1. Example calculation
In this battery lifetime calculation scenario the target meters send a 35 byte long (`L-Field')
wireless M-Bus telegram constantly every 10 seconds. This behavior is for example very
similar to a `Hydrus' ultrasonic water meter of Diehl Metering
2
. The Diehl meter itself has a
specied battery life time of 12 years.
Because of the mentioned 10 second send interval it is sucient to congure the bridge for
a wireless M-Bus listen period of 20 seconds by setting the bridge conguration parameter
cmodeDurSec to a value of 20 (refer to section 4.3.2). This will ensure that all meters of
interest sent their consumption telegrams at least onces during the congured listen period
of the bridge.
For a worst-case battery-lifetime calculation the weakest possible LoRaWAN connectivity has
been selected. That means to reach a LoRaWAN Gateway the Lobaro hardware has to send
out its Uplink data very slowly (  2 seconds) and redundant by using a LoRa spreading factor
of 12. Beside this the actual usable battery capacity has been set to 80% of the nominal
value. The resulting worst-case minimal battery-life times are presented in table 1.
2
https://www.diehl.com/metering/
wMBUS over LoRaWAN Bridge 5

2. The Device
Collected meters Battery life (years)
- AA cell (3Ah) Baby cell (9Ah)
1 10.7 32.0
5 7.0 21.1
10 4.9 14.8
20 3.1 9.3
40 1.8 5.3
80 1.0 2.9
Table 1: Battery life for daily LoRaWAN uploads with SF12
Collected meters Battery life (years)
- AA cell (3Ah) Baby cell (9Ah)
1 12.1 36.4
5 11.8 35.4
10 11.4 34.4
20 10.6 31.9
40 9.4 28.3
80 7.7 23.0
Table 2: Battery life for daily LoRaWAN uploads with SF7
Estimations for the opposite situation with a excellent LoRa link quality and thus the possible
usage of SF7 are also presented in table 2.
In real world installations the possible spreading factor may be optimized anytime by setting
up additional LoRaWAN Gateways near the meters of interest.
2.3.2. Usage scenario recommendations
As a simple rule of thumb using the Lobaro wireless M-Bus over LoRaWAN bridge is a good
t in applications that require daily (or less often) consumption values of 1 to 40 installed
wireless M-Bus meters. For installations with a higher meter count simply more Lobaro
bridges may be used.
Another key factor for high battery lifetime is to select or congure your wireless M-Bus
meters in a way that they send short telegrams very frequently, proven good values are
periods smaller than 30 seconds and telegram sizes smaller 50 bytes. This helps to minimize
the needed wMBus listening time period and avoids the need for multiple LoRaWAN packets
per single telegram (data splitting).
wMBUS over LoRaWAN Bridge 6

3. Work Cycle
Beside this the bridge is naturally most economical when multiple meters per single bridge
can be collected and forwarded via LoRWAN. Although for some applications a 1:1 setup,
e.g. one bridge per meter, may deliver enough benets to justify the invest.
For hourly or even more frequent meter data uploads, as requested by some of our custom-
ers, LoRaWAN isn't the perfect match from a technology point of view. The same holds
for scenarios where hundreds of meters are expected to be transfered by a single bridge,
e.g. in `sub-metering' applications with tons of installed heat cost allocators. For such more
demanding cases Lobaro can oer better solutions using higher bandwidth transmission tech-
niques like NB-IoT
3
or classical 4G/LTE. Contact us if you need such a alternative solution
by sending your request to [email protected]  either English or German is ne.
3. Work Cycle
Initial LoRaWAN
Join wMBUS Collection LoRaWAN Transfer Sleep
Cron expression
Figure 2: The ve phases of the wMBUS Bridge Workow
The Bridge has a simple work cycle that consists of ve phases. It is illustrated in gure 2.
3.1. Initial Phase
This is the phase that is executed after the device is started of restarted. The Bridge performs
a quick self test which you can easily spot by the green internal LED ashing. After that,
the conguration is evaluated. If successful, the LoRaWAN Join phase is executed next.
3.2. LoRaWAN Join Phase
If the Bridge is congured to use over the air activation (OTAA), the OTAA join is performed
at this point. The device will repeatedly try to join its LoRaWAN network until the process
is successful. It then enters the Data Collection Phase.
If the Bridge is congured to use ABP instead of OTAA, this phase is left immediately and
the Data Collection Phase is entered according to the cron conguration.
3
Narrowband IoT
wMBUS over LoRaWAN Bridge 7

3. Work Cycle
3.3. Data Collection Phase
During the wMBUS collection phase the device receives any wireless M-Bus data with valid
CRC and stores it for the following LoRaWAN upload phase but only if the received telegram
passes the user dened white list lters. Similar telegrams of one identical meter may be
received multiple times during this phase. In this case the newest telegram with the same
id, type and length will replace the previously received one. Only the latest telegram will be
uploaded via LoRaWAN.
After the congured amount of time for collecting data the LoRaWAN data transfer phase
is entered.
3.4. Data Transfer Phase
During the Data Transfer Phase the Bridge uploads all previously stored wMBUS data using
LoRaWAN. Depending on original wMBUS telegram byte sitze this can require multiple LoR-
aWAN messages to be sent. Since LoRa requires any device to respect a strict duty cycle,
it is possible, that the Bridge will need to wait before sending its messages. If this happens,
the device will enter a power saving modus while waiting for the next message. It is possible
that transferring all data will take several minutes.
In addition to the wireless M-Bus data, the Bridge sends a status packet once a day during
this phase. The status packet will always be transmitted prior to any data packets.
For a detailed description of the data sent refer to chapter 5.2.
3.5. Sleep Phase
After transferring all data packets the Bridge enters the Sleep Phase. During this it is com-
pletely inactive to avoid wasting power. It remains sleeping until one of the cron expressions
given in the conguration triggers. When that happens, it enters the Data Collection Phase
again.
wMBUS over LoRaWAN Bridge 8

4. Conguration
4. Conguration
4.1. The Lobaro Maintenance Tool
Figure 3: Lobaro maintenance tool (Windows, Linux, Mac)
The initial device conguration can be done very comfortably from your PC via the serial
conguration interface. Beside the needed Lobaro USB to UART adapter the Lobaro Main-
tenance Tool
4
needs to be installed. This tool is freely available for various operating systems
including Windows, Linux, Mac and Linux-ARM (e.g. Raspberry-PI) on and works with all
Lobaro sensors.
Technically this software opens a webserver on port 8585 that runs in a background console
window. The actual user interface can be accessed normally using a standard web browser
at address http://localhost:8585 (see g. 3). Normally your default browser should be
opened with this URL automatically after tool startup . Even remote conguration and log-
observation over the Internet is possible, e.g. having a Raspberry PI via USB connected to
the Lobaro device and accessing the maintenance tool from a remote machines browser over
the Internet.
Additionally to the device setup the tool can also be used for rmware updates (`Firmware
Tab') , watching real-time device diagnostic output (`Logs Tab') and initiating device restarts.
Please note that the device is automatically restarted each time the conguration has
been changed!
4
Lobaro Maintenance Tool free download: https://www.lobaro.com/lobaro-maintenance-tool/
wMBUS over LoRaWAN Bridge 9

4. Conguration
4.2. Connecting the USB cong adapter
For conguration and rmware updates we provide a special serial-USB adapter that can be
connected as shown in gure 4. The corresponding connector on the PCB is marked with
the word `Cong'.
The USB-adapter will add a virtual serial `COM' Port to your system. Your operating system
needs the CP210x USB to UART Bridge
5
driver installed. A download link is provided next
to the `Connect' button when you start the Maintenance Tool.
While the cong adapter is connected, the device will be powered from the USB port with
a regulated voltage of 3.3V. It is not necessary  although it would be no problem  hav-
ing batteries inserted or a dierent supply connected while using the cong adapter. All
conguration parameters will be kept non-volatile regardless of the power supply.
Figure 4: Connected Lobaro USB conguration adapter
4.3. System parameters
After being successfully connected to the hardware using the Lobaro Maintenance Tool you
can press `Reload Cong' in the `Conguration' tab to read the current conguration from the
device. For every parameter a default value is stored non volatile inside the hardware to which
you can revert using the `Restore default' button in case anything got miss congured.
All LoRaWAN & other rmware parameters are explained in the following.
5
https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers
wMBUS over LoRaWAN Bridge 10

4. Conguration
4.3.1. LoRaWAN network parameters
A large part of the conguration parameters are used to control the device's usage of LoR-
aWAN. Table 3 lists all of them. There are two dierent ways to use LoRaWAN: over-the-air
activation (OTAA) and activation by personalization (ABP). Some conguration parameters
are only used with one of those methods, others are used for both.
wMBUS over LoRaWAN Bridge 11

4. Conguration
Name Type Used Description
OTAA bool both true : use over-the-air activation (OTAA)
f alse : use activation by personalization (ABP)
DevEUI bytes[8] OTAA the 8 byte long DevEUI is used with OTAA to identify the
device on join. The default is predened in the hardware
and guarantees an ID that is unique world wide. Should
not be changed unless required by the network provider.
Hex format without 0x prex.
AppEUI bytes[8] OTAA ID dening the application used in the LoRaWAN net-
work. Hex format without 0x prex.
AppKey bytes[16] OTAA Application Key as dened by the LoRaWAN network
operator. This is used to encrypt communication, so
keep it secret. Hex format without 0x prex.
OTAADelay int OTAA Seconds to wait for a new attempt after an unsuccessful
OTAA join. The actual waiting time will be randomly in-
creased by up to a third of that amount, in order to avoid
devices repeatedly interfering with each other through
bad timing. The default value is 300, which means the
timeout between attempts is 300-400 seconds.
AppSKey bytes[16] ABP App Session Key as dened by the LoRaWAN network
operator. Hex format without 0x prex.
NetSKey bytes[16] ABP Network Session Key ad dened by the LoRaWAN net-
work operator. Hex format without 0x prex.
DevAdr bytes[4] ABP Device Address as dened by the LoRaWAN network op-
erator. Hex format without 0x prex.
SF int both Initial LoRa spreading factor used for transmissions.
Valid range is 7-12. The actual spreading factor used
might change during operation of the device if Adaptive
Data Rate (ADR) is used.
TxPower int both Initial transmission output power in dBm. The LoR-
aWAN protocol allows only specic values: 2, 5, 8, 11,
14. The actual power used might change during opera-
tion if Adaptive Data Rate (ADR) is used.
ADR bool both true : use adaptive data rate (ADR)
f alse : don't use adaptive data rate (ADR)
Table 3: LoRaWAN network parameters
wMBUS over LoRaWAN Bridge 12

4. Conguration
4.3.2. wMBUS bridge parameters
Table 4 lists all parameters that a relevant for wireless M-Bus bridge rmware behavior:
Name Type Description
loraMaxMsgSize int Received wireless M-Bus telegrams might have a byte size big-
ger than a single LoRaWAN message can hold. This parameter
denes the bytes per LoRaWAN message before a partition over
multiple LoRaWAN Uplink msg appears. (Range 10-50 bytes)
resetHours int Hours after which the rmware will reset and rejoin the net-
work. Can support the change of LoRaWAN network providers
with already deployed devices. (0 = never)
cmodeCron string Cron Expression dening when the device starts wMBUS
T1/C1 mode receive phases. Please refer to chapter 4.3.3
for an introduction. (blank = no T1/C1 receive)
cmodeDurSec int Duration in seconds for each C1/T1-mode wMBUS receive
phase, if cmodeCron != blank. Should be chosen in relation
the wMBUS sendout interval of the target meter.
smodeCron string Cron Expression dening when the device starts wMBUS S1
mode receive phases. Please refer to chapter 4.3.3 for an in-
troduction. (blank = no S1 receive)
smodeDurSec int Duration in seconds for each S1-mode wMBUS receive phase, if
smodeCron != blank. Should be chosen in relation the wMBUS
sendout interval of the target meter.
devFilter string wMBUS device id white-list lter using 8 digits with leading
zeros list separated by `,'. Example `88009035,06198833'.
(blank = lter inactive)
mFilter string wMBUS manufacturer white-list lter separated by `,' . Ex-
ample: `DME,QDS' for receiving just telegrams from Diehl
Metering GmbH and Qundis GmbH meters. Telegrams with
dierent 3 character wMBUS manufacturer id will not be up-
loaded via LoRaWAN. (blank = lter inactive)
typFilter string wMBUS device type white-list lter list separated by `,'. Ex-
ample: `08,07' for Heat-Cost and Water meters. Please refer
to appendix B.1 for a list of possible values. (blank = lter
inactive)
Table 4: wMBUS bridge parameters
wMBUS over LoRaWAN Bridge 13

5. LoRaWAN Data Upload Formats
4.3.3. Cron expressions
Cron expressions are used to dene specic points in time and regular repetitions of them.
The schedule for data collecting phases is dened using the Cron
6
format which is very
powerful format to dene repeatedly occurring events
7
.
Standard Lobaro devices typically do not need to know the real time for proper opera-
tion. All times are relative to the random time when batteries are inserted. If needed
by the target application Lobaro can deliver on request special hardware support for keeping
data acquisition intervals based on a real time clock which stays in sync with the real time.
Please contact Lobaro directly if you need such a custom product variant.
A cron expression consists of 6 values separated by spaces:
 Seconds (0-59)
 Minutes (0-59)
 Hours (0-23)
 Days (1-31)
 Month (1-12)
 Day of Week (SUN-SAT b = [0,6])
Examples of CRON denitions:
05**** Hourly at minute 5, second 0 (at 00:05:00, 01:05:00, ...)
01/10**** every 10 minutes from minute 1, second 0 (minutes 1, 11, 21, ...)
006*** Daily at 6:00:00
0 0 13 1,15 * * 1st and 15th day of every month at 13:00:00
0091-5** Every month daily from day 1 till 5 at 9:00:00
5. LoRaWAN Data Upload Formats
After collecting wireless M-Bus telegrams over the air, the Bridge starts uploading data
via LoRaWAN. There exist two data formats that are transmitted over dierent LoRaWAN
ports.
As LoRaWAN can only transmit very short messages, the message formats contain only data
bytes. The meaning of a byte is determined by its position within a message. The following
describes the package formats used by the wireless M-Bus Bridge.
6
For more information about Cron see https://en.wikipedia.org/wiki/Cron
7
Online introduction: https://github.com/lobaro/docs/wiki/CRON-Expressions
wMBUS over LoRaWAN Bridge 14

5. LoRaWAN Data Upload Formats
5.1. Status Packet
Port 1  In order to provide some information about the health & connectivity state of the
device itself, the device sends a status update at a daily basis. The status packet is sent
on the rst upload phase after activation of the device (after reboot) and then repeatedly in
every upload phase that takes place a day or longer after the previous status packet. It has
a xed length of 7 bytes. The battery voltages and ambient temperature are encodes as 16
bit integer using little endian encoding.
0123456
version v_bat temp
Figure 5: Bytes, port 1  Status Packet
name type description example
version uint8[3] Version of the rmware running on the device 1, 5, 1  v1.5.1
v_bat uint16 Battery voltage in mV 2947  2 : 947 V
temp int16 Temperature measured inside the device in
1
10

C 246  24 : 6

C
Table 5: Fields port 1  Status Packet
We provide a JavaScript reference implementation of a decoder for this status packet on
GitHub
8
, which can be used directly for decoding in The Things Network
9
.
5.2. Data Packet
After each wMBUS collecting phase, all saved telegrams (up to 500 can be stored) will be
uploaded via LoRaWAN uplink messages as fast as possible. The received wMBUS telegrams
that did pass the congured white list lters will be uploaded without any modication in one
or more LoRaWAN messages.
If a wMBUS telegram is bigger than the bridge conguration parameter loraMaxMsgSize the
transmission will be done using multiple LoRaWAN messages. This parameter is limited to 
50 bytes due to LoRaWANs maximum payload size restrictions. In case of telegram splitting
is needed the receiving backend application server as to reassemble the original wMBUS
telegram before decryption & parsing of the meter data. This is done by simply joining the
messages together in the order of receive.
The LoRaWAN port encodes identies a LoRaWAN fragment of the original wireless M-Bus
telegram. This way partial messages can be identied using the LoRaWAN Port:
8
https://github.com/lobaro/ttn-data-formats/blob/master/wmbus-bridge/decoder.js
9
The Things Network (TTN): An open source LoRaWAN network provider
see https://www.thethingsnetwork.org/
wMBUS over LoRaWAN Bridge 15

5. LoRaWAN Data Upload Formats
10 < LoRaWAN Port < 100  (Part Number | Total Parts)
Gaps in the LoRaWAN Frame Counter are giving a hint for missing telegram parts which can
happen in LoRaWAN since it's a ALOHA based protocol, e.g. collisions and some packet
losses are accepted by principle of operation. In case the backend noticed a missing packet
the wMBUS telegram can't be assembled anymore as described before.
5.2.1. Examples
Examples (with loraMaxMsgSize = 50):
 A 48 Byte wMBUS telegram will be send on LoRaWAN port 11. Port 11 says it is the
rst message of only one message (no splitting).
 A 75 byte wMBUS telegram will be send in two messages on LoRaWAN ports 12 and
22. Port 12 means this part one of a wMBUS telegram that got splitted into two
LoRaWAN messages. Port 22 means that this data is the 2nd part of the original
wMBUS data. Both parts have to been concatenated in the order of receive by the
backend.
 A 101 byte wMBUS telegram will be send in three messages on LoRaWAN ports 13,
23 and 33. Port 13 means this part one of a wMBUS telegram that got splitted into
three LoRaWAN messages. Port 23 means that this data is the 2nd part of the original
wMBUS data. Port 33 means that this data is the 3rd part of the original wMBUS
data. All three parts have to been concatenated in the order of receive by the backend.
5.2.2. Upload Rate
The bridge has to work in compliance with the European SRD 868 1% duty-cycle regulations.
This implies as a rule of thumb the device can upload at most wMBUS telegrams for 36
seconds every hour. The actual transmit time (`ToA: time on air') for each LoRaWAN
message depends on the byte size and the used LoRa spreading factor (SF) which denes how
redundant LoRa data is send. This means a device with good connectivity and consequently
using LoRa SF7 (ToA  0,050s) can upload much faster more data than a node using LoRa
SF11 (ToA  1s) due to a hard to reach LoRaWAN gateway. The bridge will upload in
conformity with the regulations automatically as fast as possible. When it has to wait it
enters a low power sleep mode until the next transmission is possible again.
The next data collection phase will be started only after completion of the previous upload
phase in respect to the congured cmodeCron or smodeCron , whichever is earlier. Because
of this it is advisable to dene the cron parameters with an estimation of the upload duration
in mind. This will avoid unexpected `skipping' of data collection phases.
wMBUS over LoRaWAN Bridge 16

5. LoRaWAN Data Upload Formats
If you nd that the data rate LoRaWAN oers is a limitation for your setup, we could also
provide you with a wireless M-Bus solution that uses alternate data transmission technologies,
for example GSM/LTE or NarrowBand-IoT.
Find our contact information under https://www.lobaro.com/contact/ , or simple send us
an email to [email protected]  either English or German is ne.
5.2.3. Decoding wireless M-Bus
After receiving the raw wireless M-Bus telegrams from your LoRaWAN network provider
the actual metering data has to be decrypted and decoded by a backend service for further
processing. The details of this are described in the EN 13757 norm and the newer OMS
10
specication, which is a clarication of the original underlying norm.
A universal wireless M-Bus decoder is a relatively complicated piece of software if you start
implementing it from scratch since the norm covers many dierent use cases, units, meter
types and data formats. If you know in advance the exact telegram format of the deployed
meters in your setup a hard coded data decoding may be a feasible approach. This is because
wireless M-Bus devices often send the same telegram format in every transmission. Please
contact the manufacturer of your meters for the needed telegram format details.
Figure 6: Lobaro wirless M-Bus decoder REST-API
An an alternative to support a quick evaluation of our hardware Lobaro oers a easy to use
webservice which is designed to decode all sorts of wMBUS input data including decryption
if the correct key has been provided (see gure 6). This REST API returns a JSON object
10
https://oms-group.org/en/download4all/oms-specification/
wMBUS over LoRaWAN Bridge 17

5. LoRaWAN Data Upload Formats
including all encapsulated elds, e.g. the actual metering values. This greatly simplies the
bridge integration into your web based service or application.
A 12 months period of free access to this API is included in our `wmbus bridge testpacket'
oer for quick device evaluation. API Integration into production systems is also possible,
but in this case a separate agreement about a royalty fee must be achieved up front. For
more information on licensing our wireless M-Bus parsing API plase send us your request via
email to [email protected]  either English or German is ne.
wMBUS over LoRaWAN Bridge 18

6. Technical characteristics
6. Technical characteristics
Product
Type name wMBUS-LoRaWAN
Description wMBUS over LoRaWAN Bridge
RF transceiver
Chipset Semtech SX1272
Frequency Range 863 to 870 MHz
TX Power  14 dBm
LoRa communication
LoRaWAN Protocol LoRaWAN 1.0.1, Class A, EU868
Activation method Over-the-air activation (OTAA)
Activation by personalization (ABP)
Encryption AES128
Typically RF range  2km
Ideal RF range  10km (free line of sight)
Wireless M-BUS communication
Supported Modes (EN13757-4) S1, C1, T1
Frequencies 868.3 MHz, 868.95 MHz
RF Range  30m
Telegram memory up to 500 telegrams (on request: 1.500)
Power Supply
Nominal Supply Voltage 3V
Supply Voltage Range 2.2V - 3.7V
Power supply 2  AA battery, 1.5V (LR6/FR6)
5V USB powered over Lobaro Adapter
On Request: 230V mains adapter, 3.6V Battery
Current consumption @3V
Normal  3 mA
Wireless M-BUS RX  14 mA
LoRa RX  14 mA
LoRa TX  80 mA
Sleep with RTC running  20  A
Mechanical dimensions
Size 114.3 mm  59.3 mm  26.8 mm
Housing Material ABS plastic
Environmental Requirements
Operating temperature range -20

C to +55

C
Max. Installation height 2m
Conformity
wMBUS over LoRaWAN Bridge 19

6. Technical characteristics
6.1. Housing Dimensions
wMBUS over LoRaWAN Bridge 20