Press "Enter" to skip to content

M-Bus Master Hat Commissioning and Testing

Overview

Once assembled and cleaned, the process to commission and test an M-Bus Master Hat before packaging and shipping consists of the following steps:

  • Check the assembly for any obvious errors
  • Initial power on test
  • Burning the Hat’s EEPROM
  • Running basic functional tests
  • Running a burn in test

Checking

Once assembled and cleaned, the M-Bus Master Hat is given a thorough visual to check to ensure that

  • All components are present and properly soldered
  • There are no obvious short-circuits or other assembly defects

The board is also checked with a multimeter for a short-circuit across both the 3.3V and 5V pins to ground, as a short circuit might damage the host Pi when the Hat is connected.

Initial Power on Test

After checking, the Hat is connected to an un-powered Raspberry Pi. This could be any variant, although by default a Zero is used, as in the unlikely event that an assembly defect is present, damaging a Zero is cheaper than any other model.

The Raspberry Pi is powered on, and the Hat power LED is checked for illumination. This LED is typically green.

Burning the Hat EEPROM

A Hat’s EEPROM stores a variety of data including

  • information about the Hat itself, such as make and model, and serial number
  • which GPIOs the Hat uses
  • required boot states of the GPIOs.

To burn the EEPROM, the utilities provided by the Raspberry Pi foundation are used.

Note that to write EEPROM data to a Hat a Pi must have this line in the /boot/config.txt file. (This is not necessary unless the EEPROM is to be written.)

dtparam=i2c_vc=on

The follow steps are performed:

  • The EEPROM write protect pins are jumpered (to disable EEPROM write protect, to allow it to be written). The position of these pins vary depending the M-Bus Master Hat model. On v1.2 boards the pins are unlabelled and located next to the unpopulated micro USB pads.
  • The EEPROM file to be written is generated, including a unique serial number for the Hat, using eepmake.
  • The EEPROM file is written to the EEPROM using eepflash.
  • The contents of the EEPROM are read using
    eepflash.
  • The contents of the EEPROM that have been read in are inspected using hexedit. If the file contains all FFs then the write procedure failed (normally due to a failure to jumper the EEPROM write protect pins).
  • The EEPROM write protect pins are un-jumpered.

After this procedure the Raspberry Pi is rebooted, so that the Pi can read the Hat EEPROM data. (This read takes place at bootup.)

Running Tests

Prior to running tests, the Hat’s M-Bus port is connected up to at least one known good M-Bus slave with a known primary address. For testing purposes it is preferable to connect to multiple M-Bus slaves simultaneously (up to 3 are supported), with long cable runs (a maximum cable run of 100m is supported).

All M-Bus Master Hats are tested with a minimum of two slaves connected simultaneously, and a cable run of at least 100m.

All tests use mbus-httpd, a web server which exposes M-Bus function. The README explains how to install it.

Running Basic Functional Tests

The initial set of basic functional tests are:

  • Querying the Hat data, which the Raspberry Pi should have read in on the reboot and exposed at /proc/device-tree/hat/
  • Turning on power to the M-Bus
  • Querying the connected slave
  • Turning off power to the M-Bus

In more detail…

Querying Hat Data

Assuming mbus-httpd is running at port 8080, the following command is run:

curl http://localhost:8080/mbus/hat

The reply should be similar to the following:

{"product":"M-Bus Master",
  "productId":"0x0001",
  "productVer":"0x0004",
  "uuid":"07d39ea1-c19c-42e0-9f16-eafe8888a742",
  "vendor":"packom.net"}

The productVer and uuid values will differ, depending on the model number and serial number of the Hat. The productVer value of 0x0004 corresponds to a v1.2 full-size Hat.

Turning on M-Bus Power

This is achieved with:

curl -X POST http://localhost:8080/mbus/hat/on

The M-Bus power LED is checked for illumination.

Querying Slave

The attached M-Bus slave is queried using the following (with 48 replaced by the appropriate primary address):

curl -X POST http://localhost:8080/mbus/get/ttyAMA0/2400/48

The response will vary depending on the data provided by the slave, but should be of the following format:

<?xml version="1.0" encoding="ISO-8859-1"?>
 <MBusData>
     <SlaveInformation>

     ...

 </MBusData>

Turning off M-Bus Power

Similar to turning on the power:

curl -X POST http://localhost:8080/mbus/hat/off

The M-Bus power LED should go out, although this depends on the model. Prior to v1.2 the M-Bus power LED is dim but not completely off when the M-Bus power is disabled.

Running Burn In Test

The burn in test is designed to stress the M-Bus Master Hat to ensure proper operation of the device and expose early life failures. The burn in test uses multiple real, known good M-Bus slaves along with 100m cable runs, and performs the following operations:

  • Reading the Hat details both with the M-Bus power on and off
  • Switching the M-Bus power on and off repeatedly at different speeds
  • Scanning the M-Bus with the bus power on, and checking for a successful response from at least one slave
  • Querying data from that slave 100 times with the M-Bus power on, and checking for success
  • Turning the M-Bus power off, re-querying the slave, and checking that this query fails

The above process is typically repeated 10 times for each Hat, and takes just under an hour. A data query failure rate of 0.2% is permitted. No scan or other failures are permitted.

The test is performed with the following command:

docker run --rm -ti --name hat-tester \
   packom/mbus-httpd-hat-tester-release /hat-tester \
   --port 8080 --address 48 --baudrate 2400 --device ttyAMA0 \
   --reps 10 --get-reps 100 --hat --scan --check-scan \
   --product-ver 0x0004 --host test-pi

Completion

Upon successful completion of all of the above processes the Hat is labelled with the serial number and packaged ready for shipping.