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. 

Hardware zum Protocol Stack
Microcontroller (MCU)  
  • 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  
  • … 
System-on-Chip (SOC)  
  • Texas Instruments: CC430F6137, CC1310/CC1350, CC1312/CC1352  
  • Silicon Labs: EZR32, EFR32, Si1000  
  • ST Microelectronics: STM32WL family  
  • …  

Hardware requirements 

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) 

Memory requirements

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.  

Library only 


  • Flash: ~ 35-55 kB
  • RAM: ~ 8-12 kB


  • Flash: ~ 55-70 kB
  • RAM: ~ 9-13 kB


Modem firmware


  • 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!   

Loading Conversation