The Wireless M-Bus Stack is the ideal partner for smart metering, sub-metering or smart city applications. In Part 1 of our article, we looked at the stack features, the different standards and the stack offering. Part 2 of the article now focuses on the hardware that can be used to enable devices to communicate with Wireless M-Bus and the options for product certification.
Microcontrollers, radio chips and system-on-chip
The stack has already been ported to a variety of hardware platforms consisting of either a microcontroller (MCU) in conjunction with a radio chip (TRX), or a system-on-chip (SOC) silicon. The table below provides an overview of what hardware can be considered to enable a device Wireless M-Bus. The list grows with each project we implement. Do you want to use hardware that is not listed? Contact us and we will clarify the possibilities.
- Texas Instruments: MSP430F2xx, MSP430F54xx, MSP430F53xx, …
- Silicon Labs: EFM32 all Gecko families
- Renesas Synergy: SX, RL78G1x, RX62N, RZ
- ST Microelectronics: STM32L0 family, STM32L4 family
Single Chip Radio (TRX)
- Texas Instruments: CC1101, CC110L, CC1120, CC1125, CC1200
- Semtech: SX1232, SX1236, SX1272, SX1276, SX1261/62
- Silicon Labs: Si4460, Si4460C, Si4461, Si4461C, Si4463, Si4463C, Si4464
- Analog Devices: ADF7021N, ADF7023
- Rohm/LAPIS: ML7406
- Onsemi: AX5031
- Texas Instruments: CC430F6137, CC1310/CC1350, CC1312/CC1352
- Silicon Labs: EZR32, EFR32, Si1000
- ST Microelectronics: STM32WL family
The stack includes a Hardware Abstraction Layer (HAL) that allows the stack to run on a specific hardware platform. The HAL attaches the following required hardware to the Protocol Stack itself:
- 1-2x timers
- 1x SPI (applies to dedicated transceiver)
- 2-4x GPIO (applies to and depends on dedicated transceivers)
- Software RF interface (applies to System-on-Chip)
- AES encryption in hardware (if available and applicable)
- CRC calculation in hardware (if available and applicable)
- Encoding (Manchester, 3oo6) in hardware (if present and applicable)
The following code sizes specify the working memory for typical wM-Bus (OMS v4.1.2) applications on a STM32 Cortex-M4 with drivers and peripherals in order to use the stack as a library with the associated drivers. The values are only to be understood as reference points and basically depend on the selected platform. In addition, the values explicitly do not consider any memory requirements of the application. In addition, the values regarding RAM and flash can vary greatly due to maintenance or depending on the selected options or customizations.
- Flash: ~ 35-55 kB
- RAM: ~ 8-12 kB
- Flash: ~ 55-70 kB
- RAM: ~ 9-13 kB
- Flash: ~ 60-75 kB
- RAM: ~ 10-15 kB
- Flash: ~ 75-90 kB
- RAM: ~ 12-17 kB
Product certification – security for manufacturer and user
When it comes to product certification, it also makes sense to rely on one of the common standards such as OMS. The certification of products offers all market participants the security that defined standards and norms are adhered to. OMS certification mainly ensures the interoperability of devices. Thus, an OMS certified wM-Bus receiver from a specific manufacturer can receive any wM-Bus meter from different manufacturers. The available OMS certification process is carried out together with DVGW CERT or VDE PZI.
For STACKFORCE's Wireless M-Bus stack, the possibility of certification means in concrete terms that we integrate RF test functions (radio tests) into each of our wM-Bus stacks, which activate specific test modes. In this way, an institution such as TÜV can test the product to see if it operates within the legal requirements in terms of radio technology and can award the product a seal of approval.
Would you like to get an impression of how wM-Bus devices work in detail? Then take a look at our next video contribution on the use case "swimming pool technology". If you don’t want to take that long, just contact us directly!