M-Bus Tool

User’s Guide

Version 2.1

Table Of Contents

User’s Guide.......................................................................................................................1Version 2.1...........................................................................................................................1

..............................................................................................................................................1

1. History and Overview1.1. M-Bus Protocol Overview

1.1.1. Developed in Germany for sub-metering communications1.1.2. Used in Europe primarily1.1.3. M-Bus Hardware primer

1.1.3.1. Uses a single twisted pair of wires1.1.3.2. The NES Meter is the Bus Master, the M-Bus meters are Slave devices1.1.3.3. There can only be one Bus Master, but up to 255 slaves1.1.3.4. Bus master (NES Meter) puts a 24VDC bias on that twisted pair1.1.3.5. Bus Master communicates to slaves by transitioning the DC bias between 12VDC

and 24VDC1.1.3.6. The slaves respond back to the master by turning a current drain on and off.1.1.3.7. M-Bus supports 3 baud rates, 300, 2400, and 9600 baud. 2400 baud is standard.

1.1.4. M-Bus packet structures1.1.4.1. Short Frame – 5 Byte Structure

1.1.4.1.1. 0x10 – Start Byte1.1.4.1.2. Command Bytes (the ones used by the target meters)

1.1.4.1.2.1. 0x40 – SNK_NKE1.1.4.1.2.1.1. Meter to M-Bus Device only1.1.4.1.2.1.2. I call this a “ping”1.1.4.1.2.1.3. This is sent to an M-Bus device prior to any request1.1.4.1.2.1.4. The correct response to the meter from the device is to send an

acknowledgment byte: 0xE51.1.4.1.2.2. 0x5B or 0x7B – REQ_UD2

1.1.4.1.2.2.1. Meter to M-Bus Device only1.1.4.1.2.2.2. Request for billing data1.1.4.1.2.2.3. For multi-packet billing reads, the meter will toggle between

these two bytes1.1.4.1.2.2.4. The correct response to this request is billing read data

1.1.4.1.3. Address number of targeted M-Bus Device1.1.4.1.4. Checksum, equal to the Command Byte and the Address Byte added

together1.1.4.1.5. 0x16 Stop Byte

1.1.4.2. Application Reset Frame - Meter to M-Bus Device only1.1.4.2.1. 0x68 start byte1.1.4.2.2. Packet length byte1.1.4.2.3. Packet length byte repeated1.1.4.2.4. 0x68 start byte again1.1.4.2.5. 0x53 0r 0x73 - Control Byte1.1.4.2.6. Address of targeted M-Bus device1.1.4.2.7. 0x50 – Application Reset Command1.1.4.2.8. Reset Parameter byte

1.1.4.2.8.1. 0x60 puts M-Bus device into special LP mode1.1.4.2.8.2. 0x00 exits M-Bus device from special LP mode

1.1.4.2.9. Checksum Byte1.1.4.2.10. 0x16 Stop Byte

1.1.4.3. Address Change Frame - Meter to M-Bus Device only1.1.4.3.1. 0x68 start byte1.1.4.3.2. Packet length byte1.1.4.3.3. Packet length byte repeated1.1.4.3.4. 0x68 start byte again1.1.4.3.5. 0x53 0r 0x73 - Control Byte1.1.4.3.6. Current address of targeted M-Bus device

1.1.4.3.7. 0x51 – Send Data Command1.1.4.3.8. 0x01 – DIF, one byte of data1.1.4.3.9. 0x7A – Data is Bus Address1.1.4.3.10. New Address1.1.4.3.11. Checksum Byte1.1.4.3.12. 0x16 Stop Byte

1.1.4.4. Time Sync Frame - Meter to M-Bus Device only1.1.4.4.1. 0x68 start byte1.1.4.4.2. Packet length byte1.1.4.4.3. Packet length byte repeated1.1.4.4.4. 0x68 start byte again1.1.4.4.5. 0x53 0r 0x73 - Control Byte1.1.4.4.6. Current address of targeted M-Bus device1.1.4.4.7. 0x51 – Send Data Command1.1.4.4.8. 0x04 – DIF, four bytes of data1.1.4.4.9. 0x6D – Data 4-byte date and time1.1.4.4.10. Four bytes of Type-F data1.1.4.4.11. Checksum Byte1.1.4.4.12. 0x16 Stop Byte

1.1.4.4.12.1.1.1.4.5. Long Frame – Billing Read Data from

1.1.4.5.1. Fixed Data Structure1.1.4.5.1.1. 0x68 - start byte1.1.4.5.1.2. 0x13 - Packet length byte1.1.4.5.1.3. 0x13 - Packet length byte repeated1.1.4.5.1.4. 0x68 start byte again1.1.4.5.1.5. 0x08 - Control Byte1.1.4.5.1.6. Address Byte1.1.4.5.1.7. 0x73 or 0x77 - CI Byte1.1.4.5.1.8. 4-byte Serial Number1.1.4.5.1.9. 1-byte transmission counter1.1.4.5.1.10. 1-byte status1.1.4.5.1.11. 2-byte type and unit for the two counters to follow1.1.4.5.1.12. 4-byte counter 11.1.4.5.1.13. 4-byte counter 21.1.4.5.1.14. 1-byte checksum1.1.4.5.1.15. 0x16 stop sign

1.1.4.5.2. Variable Data Structure1.1.4.5.2.1. 0x68 - start byte1.1.4.5.2.2. Packet length byte1.1.4.5.2.3. Packet length byte repeated1.1.4.5.2.4. 0x68 start byte again1.1.4.5.2.5. 0x08 - Control Byte1.1.4.5.2.6. Address Byte1.1.4.5.2.7. 0x72 or 0x76 - CI Byte1.1.4.5.2.8. 4-byte Serial Number1.1.4.5.2.9. 2-byte Manufacturer ID1.1.4.5.2.10. 1-byte Version1.1.4.5.2.11. 1-byte Medium, Meter Type1.1.4.5.2.12. 1-byte transmission counter1.1.4.5.2.13. 1-byte status1.1.4.5.2.14. 2-byte Signature (encryption type and number of encrypted bytes)1.1.4.5.2.15. Some number of data blocks consisting of:

1.1.4.5.2.15.1. 1 DIF1.1.4.5.2.15.2. 0 to 10 DIFE’s 1.1.4.5.2.15.3. 1 VIF

1.1.4.5.2.15.4. 0 to 10 VIFE’s1.1.4.5.2.15.5. Actual data as defined by DIF and VIF

1.1.4.5.2.16. 1-byte checksum1.1.4.5.2.17. 0x16 stop sign

1.1.5. Used M-Bus commands1.2. References

1.2.1. M-Bus: A Documentation1.2.2. British Standard Specification1.2.3. In-House Specifications1.2.4. Gentoo 2.1 M-Bus LP.doc1.2.5. Gentoo 3.3 meter - Interval Data V6.docx1.2.6. Gentoo 3.3 meter - Critical Event Logging V12.doc

1.3. M-Bus Tool Hardware Requirement

M-Bus Tool spoofing capabilities

The M-Bus Tool can perform several M-Bus related functions. It can simulate up to four configurable M-Bus devices to up to 20 different meters, it can act as M-Bus Master to communicate with real M-Bus devices, it can passively pass data between M-Bus master and slave devices allowing monitoring of communications, and it can actively control power to the meter.

All of these functions require hardware support in some way to facilitate communication or control.

M-Bus Slave Adapter Boards

To simulate M-Bus slave devices, the M-Bus Tool requires a M-Bus Slave adapter to translate RS-232 signals into M-Bus signals. These are typically small PC boards that have a DB-9 connector on one end and a two-wire connector on the other. Two examples of M-Bus slave adapters are shown below.

Style #1 of the M-Bus Slave Adapter Style #2 of the M-Bus Slave Adapter

Caution: The meter’s M-Bus signals are referenced to the meter’s Neutral power. Depending on how the meter is wired (or mis-wired) the M-Bus could have 230 VAC on it. Since the M-Bus slave adapters are loose, bare PCB’s, they may have exposed dangerous voltages on them. They should be screwed down to a non-conductive sub-straight and/or covered to prevent accidental hazardous contact.

The first M-Bus slave adapters we had, Style #1, echoed all RS-232 traffic back to the PC by default. The M-Bus Tool was designed to handle these echoes, counting and tossing echoed bytes after every transmission to the meter.

Newer M-Bus slave adapters , Style #2, can be jumpered to echo or not echo, so to work with the M-Bus Tool, they need be jumpered to echo characters. The jumper is located on the PCB just behind the DB-9. Note that when changing the jumpers on these M-Bus adapters, they need to be power-cycled after the jumper is changed by disconnecting the adapter from everything. I have seen evidence that the jumper change will not take effect until this is done

Picture of the Style #2 jumper setting

Required Modifications to slave adaptersWhen the test team first obtained M-Bus slave adapters, it was found that they needed modification to work reliably at 9600 baud. Modifications were done to these adapters as they arrived from their source to correct the problem.

It is unknown if modifications were needed on 2nd generation slave adapters

PC Ground to M-Bus Neutral modificationData errors may occur when using the M-Bus slave adapter at 9600 baud due to an unstable ground signal on the RS-232 portion of the adapter. This unstable ground may be caused by the fact that the power to the meter is isolated from the PCs power, therefore the PC’s ground floats relative to the meter. One way to stop these data errors is to connect one of the M-Bus pins to signal ground on the PC.

Caution: The following fix, incorrectly done or modified, can put 230 VAC onto the M-Bus Slave Adapter, posing a safety risk, as well as risking damage to your PC. It is suggested that this fix be used only if really needed, and be removed when no longer required.

This 9600 baud data error problem can be corrected by soldering a wire from the DB-9 pin 5 (PC signal ground) to one of the M-Bus pins.

Before attaching that wire, verify that there is no AC voltage potential between the M-Bus and the PC ground. Use a volt meter, set to read AC voltage, to measure voltage from either pin of the M-Bus to ground on the PC (Pin 5 of the DB-9 serial port.)

It is also best to use the side of the M-Bus that shows no DC bias to the meters neutral power. Use a volt meter, set to measure DC volts, to measure from the meter’s neutral power to the M-Bus pins on the slave adapter. Look for the pin that shows 0 (zero) volts DC.

If more than one slave adapter resides on the M-Bus, only ONE of those adapters should be modified this way. Installing this fix on additional slave adapters improves nothing but risks mis-wiring the M-Bus to create a short.

All voltage measurements should be re-checked if the meter is changed or the M-Bus connections are moved around. Also, recheck the 24 VDC bias on the M-Bus twisted par and verify it is still there.

If you are not using an isolated power supply, make sure the meter’s neutral power is the supply’s neutral power, not the hot power. Use of an isolated power supply is common in meter testing due to dangers inherent to non-isolated supplies. The danger in this fix is that it violates the isolation.

Picture showing M-Bus Twisted Pair wires to the Style #2 M-Bus Slave Adapter

Spoofing M-Bus devices with different baud rates on with M-Bus Tool

One slave adapter and one COM port are needed for baud rate used to simulate M-Bus devices. If it is desired to simulate M-Bus devices operating at two or three different baud rates, then two or three M-Bus slave adapters will need to be attached to two or three COM ports of the PC.

M-Bus Tool can use one M-Bus slave adapter to simulate up to four M-Bus devices on a single meter but all simulated devices must be configured at the same baud rate because M-Bus tool only operates each COM port at one baud rate at a time.

If multiple baud rates and adapters are used, the M-Bus Tool automatically resolves several issues. For instance, when the meter (M-Bus master) sends a command to the M-Bus at a given baud rate, adapter on COM ports configured to different baud rates will see gibberish. Only the adapter whose COM port baud rate matches the request will see a valid request. M-Bus Tool will recognize and toss the gibberish and respond only to the valid request on the same COM port it saw the request.

Below is a picture of a M-Bus slave adapter setup that allows M-Bus Tool to simulate up to four M-Bus slave devices at up to three different baud rates on one meter. Note that the twisted-pair M-Bus from all

three adapters are connected together with a fourth twisted pair going off to the meter. Also note that there is a separate COM port attached to each M-Bus slave adapter. Lastly, note that the adapters are firmly screwed down to a piece of non-conductive particle board for safety.

Example of multiple Style #1 Slave Adapters on one M-Bus

Spoofing M-Bus devices for multiple meters with M-Bus Tool

For some installations, it is a good idea to have the M-Bus tool provide multiple M-Bus devices for more than one meter. An example of this is System Software testing with installations of many meters, all of which need M-Bus devices. The M-Bus Tool can provide up to 4 simulated M-Bus devices at different baud rates for up to 20 NES meters

A minimum of one M-Bus adapter and PC COM port is needed per NES meter. All of the NES meters will have access to identical spoofed M-Bus meters since they will all use the same four configurations. The device address, 1 through 4, will need to be set for each device in the M-Bus Tool prior to AutoDiscovering them with the meters.

With high activity on many NES meters, there may be delays in service of those meters’ M-Bus requests. The M-Bus tool will service M-Bus requests sequentially and if several requests arrive at or near the same time it may take a few seconds to service them all. This is especially true of meters performing scheduled billing reads to their M-Bus devices when the clocks of all meters are synchronized. A potential fix for this would be to increase the MT13 Ta and To times to allow more time for the M-Bus Tool to respond.

Exploring M-Bus slave devices with M-Bus Tool

The M-Bus Tool can simulate an M-Bus master device through a RS-232 to M-Bus Master adapter. This permits it to perform the following functions: - Communicate with and explore M-Bus devices - Diagnose communications issues and find work-arounds - Change M-Bus device configurations - Determine what the M-Bus meter configuration is - Act as viewer onto communications between the NES meter and M-Bus meter

Since the M-Bus master device needs to provide a 24VDC bias on the twisted-pair, it will need to have some external power source. I have seen this come from an AC adapter or from a plug for a PS2 mouse port.

Two types of M-Bus Master Adapters

M-Bus Tool can control meter power

The M-Bus Tool can be configured to control the NES meters power by opening and closing a COM port. This allows the M-Bus Tool to perform power-cycling tests requiring synchronization with M-Bus events.

A Solid State Relay is used to turn power on and off. These can be obtained from Digi-Key at:http://www.digikey.com/?wt.mc_id=Dxn_US_US2010_HdLogo_home

I prefer the Omron Solid State Relay type G3NA-225B DC5-24V. It is Digi-Key part number Z170-ND. This relay will handle switching up to 265 VAC at 25 Amps, and the switch voltage is in RS-232 range.

Omron Solid State Relay type G3NA-205B DC5-24V is a cheaper alternative with the same packaging form, but it can only handle up to 5 Amps, and I have seen these fail when I accidentally put more than 5 Amps through it.

A COM port from the PC controls the Solid State Relay, and I use the DTR signal to do the actual driving of the relay. The DTR signal needs to change state when the COM port is opened and closed, and it is a good idea to verify that DTR does indeed change state when the port is opened and closed before relying on it.

Wiring Diagram for Omron Solid State Relay

The M-Bus Tool uses SSR power control to enable the “Toggle Meter Power” Button on main panel, the Auto Toggle Power function on main panel, and the Axe Drop function in Spoofing mode

1.4. Creation Rational 1.4.1. We needed a variety of packet and meter types

1.4.1.1. We needed to vary baud rates and addresses1.4.1.2. We needed to vary packet sizes1.4.1.3. We needed to vary packet types1.4.1.4. We needed to vary packet content1.4.1.5. We needed custom packets1.4.1.6. We needed multi-packet responses1.4.1.7. We needed packets that no current meter produces1.4.1.8. We needed to be able to set alarms in packets

1.4.2. We needed reliable meters1.4.2.1. Some M-Bus meters stop working after a set number of communications in a day.1.4.2.2. Some meters don’t follow the specs1.4.2.3. Fargo needs up to 4 M-Bus meters per NES meter on large installations, that’s a lot

of M-Bus meters.1.4.3. We needed to be able to inject faults

1.4.3.1. Bad packetizing1.4.3.1.1. Wrong checksum1.4.3.1.2. Wrong start or stop bytes1.4.3.1.3. Wrong packet lengths1.4.3.1.4. Wrong answering address1.4.3.1.5. Delayed responses1.4.3.1.6. Missing responses1.4.3.1.7. Improper responses

1.4.4. We need some special functions1.4.4.1. We needed power control over the meter

1.4.4.1.1. We need power down the meter in mid-communication1.4.4.1.2. We needed the ability to auto-toggle power at various speeds

1.4.4.2. We need to be able to see communications between the NES meter and a real M-Bus meter

1.4.4.3. We need a simple tool for checking real M-Bus meters, address and baud rate1.4.4.4. We need a simple way of changing a real M-Bus meter’s address or baud rate

1.4.4.4.1. We need M-Bus communications during testing to be logged for later examination.

1.4.4.5. We needed a way to monitor the reliability of status reads from the meter1.4.4.5.1. Set the MT13 Status Read Frequency1.4.4.5.2. Set and enable the Health Monitor Function in the M-Bus Tool

1.4.4.5.3. The M-Bus Tool notes if the meter fails to perform a status read on time1.4.4.5.3.1. Log to disk file1.4.4.5.3.2. Log to display screen1.4.4.5.3.3. Message to reporting COM port

2. Installation and set up2.1. M-Bus Tool Version History

M-Bus Tool versions 1.0.X

All versions in the M-Bus Tool series grew from the same code-base, and it started with 1.0.X. It is found in “M-Bus Tool” folder on Virgil and Perforce. This was the first series of M-Bus Tool versions grown to meet initial requirements The bytes in the billing data are pretty much randomized, there was no attempt, really, to create M-Bus compliant data blocks. The only “real” data portions of the data were “special function” bytes: 0x1F, “remaining data is user data, ask for another frame”, and 0x2F. “This is a placeholder, the next byte is a real DIF”. The meter pretty-much didn’t care about the data content other than that, the Meter would just capture the raw billing data into MT16 and pass it to the head office. Since the meter didn’t look at the data, there was no need to make it real

This series has been frozen at 1.0.27 and will not longer be supported. When MDTs were created in Meter FW 3.30, it suddenly became necessary to generate real data blocks rather than the almost-random data currently being generated. Doing that required extensive changes to the code, which would mean I would have it torn apart for quite some time. I was concerned about a need to make another change to the code while the real data blocks were being created, and I would be unable to comply with the request because the code was torn apart. So I cloned the code, set the new code-base to version 2.0.0, and worked from there. Now that the 2.X.X code base is working, there is no need for the 1.0.X code base any more, so it is only kept for archival purposes.

M-Bus Tool versions 2.X.X

This is the second generation of M-Bus Tool based on the first. It has all the features and functions of the first generation, including much of the same source code. But it also has the ability to define specific data blocks in the variable length frames for testing new meter features released in meter FW 3.30. This will be the generation that will be maintained going forward.

The meter FW 3.30 introduced several functions that needed to be able to search M-Bus packets for specific information. These include Load Profiling data from specific data blocks within the billing data, monitoring and capturing valve-state information from those same billing packets, and scanning outgoing packets to the M-Bus device for valve control commands. With these features, we suddenly needed the ability to create specific data blocks in the M-Bus packets.

This version of the M-Bus Tool is found in “M-Bus Tool 2” folder on Virgil and Perforce.

2.2. Installing M-Bus Tool

Links to installation packages

The M-Bus Tool source folder is backed up to Perforce in n:\Tools\Spoofers\MBUSTOOL_2\. It is also located at \\Virgil\system test\__User\Jeffm\LabWindows Code\MbusTool_2

The installation folder is at \\Virgil\system test\__User\Jeffm\LabWindows Code\MbusTool_2\cvidistkit.MbusTool_2

Information about installation

Use of the M-Bus tool requires the installation of the National Instruments LabWindows runtime engine. It is automatically installed when the M-Bus Tool is installed. Once this engine is installed, any LabWindows application can be executed with it. There is no fee or registration required to use this engine.

The installation packages indicated above contain an installation package for both the runtime engine and the M-Bus Tool 2. It is suggested that the latest version be selected, the rest are for backup. Execute setup.exe to install both the engine and the M-Bus tool. The M-Bus Tool will be placed in your Program Files in a file called MBusTool_2. All log files generated by the tool will be created there.

Setting up the M-Bus Tool hardware

You will need one RS-232 port on your PC for each M-Bus slave adapter you wish to use, plus ports for the M-Bus master adapter and/or power control if you intend to use those features.

I have found RocketPort Universal PCI cards by Comtrol to be reliable solutions for additional serial ports on the PC. http://www.comtrol.com/products/family/rp_uPCI

Be careful of any serial port solutions purchased at Fry’s or other retail outlet. The drivers are often problematic due to inadequate testing, even if the hardware is good. Failures I have seen include dropping large numbers of characters, stacking up received character and bursting them out minutes later, excessively long transmission times, and skewing of the internal buffers. These failures are often intermittent and/or difficult to trace, often being blamed on the product being tested instead of the test hardware. Days can (and have been) spent troubleshooting a problem that turned out to be a faulty driver for a serial port. This warning covers USB-to-RS232 as well as motherboard-mounted internal cards

Wiring of an M-Bus Tool InstallationTwo M-Bus Tool installation examples are shown below, a simple example and a complex example. The simple example shows components wired up for M-Bus testing with a single M-Bus slave adapter. This will work for performing most tests at a single M-Bus baud rate.

Wiring example of a Simple M-Bus Tool Installation

The complex installation example shows components wired up for M-Bus testing with three M-Bus slave adapters, MEP interface (for access to useful utilities in the MEP spoofer), automated power control using a solid state relay, and a method of easily switching around the M-Bus.

Wiring example of a Complex M-Bus Tool Installation

It is suggested that you should start with the simple M-Bus installation example and then incorporate the desired features of the complex M-Bus installation example to permit the level of testing you desire.

Verify 24 VDC M-Bus biasUse a voltmeter set to measure DC voltage to verify that there is a 24VDC (give or take a couple of volts) on the M-Bus. The polarity does not matter, you just want to verify that the M-Bus master (usually the meter) is actually providing this voltage.

Meter button-press simulation with a relay cardFor test automation using tcl, you may want to provide a method for the script to put the meter into M-Bus AutoDiscovery mode. The picture below shows where to solder two wires to the board. These wires can be brought to a relay controller board that will be managed by the tcl script.

On the relay board, attach the wires to the NO and Common connector of the relay to be used for this function.

Locations to solder wires for automated button control

Here is a link to the 8-relay from Controlanything: http://www.controlanything.com/Relay/Device/R81DPDTOC8LP

Configuring M-Bus tool for your application

The main configuration that needs to be done on a new M-Bus Tool installation is to match up PC COM ports with the devices they are attached to.

Configuring Slave AdaptersAttach each M-Bus slave adapter to a PC COM port, note the COM ports they are attached to.

In the “COM Port Config” panel, configure one of the COM Ports for each slave. Click the “Slave X Control” toggle switch to “ON”, set the COM number, and set the Baud Rate. All slave ports not being used should have their control set to “Off”. Don’t have any two slave ports on the same meter set to the same baud rate.

Configuring Solid State Relay Power ControlAttach the SSR power controller to a PC COM port.

In the “COM Port Config” panel, configure the “Meter Power Port” for the correct COM port. Close the “COM Port Control” Panel and click the “Toggle Meter Power button a couple times and observe that the meter powers up and down.

Note that on power-up, the M-Bus Tool does not power up the meter.

Configuring M-Bus Master AdapterPlug the M-Bus Master Adapter into a PC com port and provide the required power supply for that device.

In the “COM Port Config” panel, configure the Micro-Master Port for the correct COM number. Select and configure a Slave Port to be used in conjunction with the Micro Master Port (if desired.) Select the baud rate the Micro Master and Slave Adapters should be operated at.

General M-Bus Tool ConfigurationsIn the lower-left corner of the Main Panel, the following settings should be verified: - “Don’t Show Echoes” - “No Trash” - Don’t Reload Device Configs - Increment Packet Number - Delay Before Response should be 0.00

Set the Health Monitor (Upper Right) to Off.

Configure your M-Bus devices as desired, see Device Configuration Panel for how to do this.

Synchronize the time between the meter and the PCIt is a good idea to synchronize the time between the meter and your PC. M-Bus billing read timestamps are referenced to the PC clock. Decryption of M-Bus packets may fail if the meter has a different time. If you want the packets to have a different time, You can set a time skew for a device or data block for testing.

Debugging is easier with the same time on meter and PC. Timestamps in the disk file and display are referenced to the PC clock. History events are referenced to meter time, and Billing read timestamps are also referenced to meter clock. Matching up events between meter events and the M-Bus Tool will be easier if the timestamps match.

If the PC is also running the MEP2 Spoofer, synchronizing time is just a couple mouse-clicks.

3. Use CasesAutoDiscovery from meter

AutoDiscovery is the process the meter uses to register new M-Bus devices. The steps involved are 1) setting up the M-Bus Tool and attaching the meter to the M-Bus, 2) setting up the M-Bus devices in M-Bus Tool, 3) starting the AutoDiscovery process in the meter, 4) observing and/or assisting the meter with registering the M-Bus devices, and 5) Terminating the meters AutoDiscovery mode.

The first step is covered in the Installation and Setup section of this document. Please refer to that section if help is needed.

The second step is setting up the basic M-Bus devices in M-bus Tool. Click on the Device X button to bring up the configuration panel for a device. The simplest thing is to just click the “Reset Packet Defaults” button to set up the default device. You will also need to set the Device Enable/Disable to Enable.

If you want this device to be found at a specific address from 1 to 4, then select the address.

The baud rate for the port will default to 2400 baud, but you may change that to 300 baud or 9600 baud, provided you have configured these in the “Com Port Config” panel and have the hardware to support these baud rates.

The Frame Type defaults to Single Variable Length frame, but you may change it if desired. The Packet Length must be greater than 12.

The Serial Number, Manufacturer ID, and Status Byte can be set any way you want, and you will probably want to make sure the Serial Number is different from the other M-Bus devices just for the sake of diversity.

You can leave Encryption Method at No Encryption. If you select Type 0x02, or 0x03, you will need to enter matching encryption keys in to the device configuration of the M-Bus Tool and in MT13 in the meter.

There are more options that will be discussed in more detail later.

The third step is to get the AutoDiscovery process started. Verify that the M-Bus Tool is in spoofing mode (click the “Start M-Bus Spoofer” button). Verify that all the requires serial ports returned an error code of 0 (zero) when they were opened.

Press and hold the meter button that steps through the meter display for ten seconds. After about 3 seconds the display will start counting off the seconds the button has been held, so when that number hits 10, you can let go.

The fourth step is to observe the commencement of M-Bus activity on the M-Bus Tool display. The meter will be sending groups of three SND_NKE (ping) frames. These groups will step through each address 0 (zero) to 4 looking for M-Bus devices. It will also be rotating through the three baud rates M-Bus uses. If your setup neglects one or two of those baud rates, there will be silence on the M-Bus Tool display while those unsupported baud rates are checked by the meter.

When an M-Bus device is spotted at the meter, the meter will send an immediate REQ_UD2 (billing read request) to that address. If the spotted device was set to address 1 to 4, it will be immediately registered and entered into MT13 and MT14 at that address. If the spotted device is set for address 0, the meter will continue scanning the M-Bus while it waits for you to press the meter button for 5+ seconds. Do that and a few seconds later the meter will send an Address Change command to M-Bus Tool instructing it to change the address of that device from 0 (zero) to another address that it knows to be available. The M-Bus Tool, by default, will acknowledge that command and make the address change in the device.

You can add more devices from M-Bus Tool to the M-Bus, one at a time or several at once. Just make sure that no two enabled devices have the same address or one of them will never get accessed.

Once all desired M-Bus devices have been registered by the meter, you can execute the fifth step and terminate the AutoDiscovery mode in the meter. Just press and hold the meter button for 10 seconds.

Deleting devices from meterMP17 is used to delete an M-Bus device from the meters tables. There are two ways to execute MP17: Remove MEP Device; 1) with specific Device Handle, and 2) with Device Handle of 65535.

To remove a specific M-Bus device, you will need to look up that device in MT14 and find its Device Handle. When doing this type of removal you can select to have the devices address set to 0 or to 250. Setting the address to 250 guarantees that the meter will not be able to AutoDiscover it again, it becomes trash. (Of course, recovery from address 250 in M-Bus Tool is just a matter of changing the address selection in the device configuration.)

Here is a TstBench screenshot of device handle 10 being removed from the meter:

A few seconds after executing this procedure you should observe the meter sending the appropriate address change command to that M-Bus device. The handle in MT14 for that device will be set to 0 (zero). M-Bus Tool will (by default) make the indicated change to the address of the indicated device.

If MP17 is executed with a handle of 65535, then the meter will not send any address change requests to the M-Bus at all. It will simply remove all M-Bus and MEP devices from registration, setting their handles to 0 (zero).

Billing ReadsIn the M-Bus world, Billing reads and Status Reads are identical. The same protocol is followed for both. The packets are identical. The only difference between the Billing Read and the Status Read is what the meter does with the packet when it arrives.

Once an M-Bus device is registered in the meter (has a non-zero device handle) there will be scheduled billing reads to it, there is no way to turn them off. One can set the frequency of the reads to Hourly, Daily, Weekly, or Monthly in MT13, and one can shift the time of the billing reads there too. The data from billing reads will be stored in MT16 and/or MT45.

Status reads look just like billing reads but are used by the meter to tell if the M-Bus device is active or down. The frequency can be set in MT13 from 1 minute to 65535 minutes. Setting the frequency to 0 (zero) turns off Status Reads and uses Billing Reads to monitor device health.

Both Status Reads and Billing Reads can be invoked by performing an MP19. Billing reads are also performed during Load Profile intervals and AutoDiscovery.

Time Syncs

The purpose of a time sync is to synchronize the real-time clock of the M-Bus device and the meter. Synchronization is important for encryption in the meter and probably for numerous reasons regarding billing functions.

Time Syncs were introduced in meter FW version 3.00 and will not be found in lower versions of the meter FW code.

The meter will perform a Time Sync on newly discovered M-Bus devices upon exiting AutoDiscovery, and if enabled in MT34 a periodic Time Sync can be performed every 1 to 255 hours. Setting MT34 Time Sync Period to 0 (zero) disables the Time Sync to that device. If enabled in MT34, the meter will also send a Time Sync packet to the M-Bus devices every time the meter powers up.

Time Syncs can also be invoked to a given M-Bus device by calling MP19 and setting it to do a Time Sync.

In the M-Bus Tool display, a Time Sync will look like this:

8:41:5; Got a COM10 2400 baud 'Are You There' M-Bus command for Address 1, Device 1, sent an E5 response{10}{40}{01}{41}{16}

8:41:5; Got a COM10 2400 baud 'Time Sync' M-Bus command for Address 1, Device 1, sent an 'e5' response sent an E5 response{68}{09}{09}{68}{73}{01}{51}{04}{6d}{01}{0c}{4a}{13}{a0}{16}

Mode 0: Time = 12:01 - Date = 2010/03/10

The timepoint in the M-Bus Time Sync packet is a type-F Date and Time. This type is covered in the M-Bus specification. The M-Bus Tool will decode the time in the packet and display it, as can be seen above.

Load ProfileThere are three methods for doing Load Profiling on M-Bus data.

LP Method 1: Load Profile Packet methodThe specification for this method is at:\\Virgil\nes\Projects\Meter\Firmware Development\Gen 2.1\Functional Specs\Archive\Gentoo 2.1 M-Bus LP.doc

This method only works for M-Bus devices that support this proprietary method, I don’t know of any other than the M-Bus Tool.

Sample MP11 setup

When setting up an MP11 to use this method of M-Bus Load Profile, the data sources are:• 73 and 74 for Meter Device 0• 75 and 76 for Meter Device 1• 77 and 78 for Meter Device 2• 79 and 80 for Meter Device 3

The way this LP Process works is as follows:• The meter will send an Application Reset command to the M-Bus device that causes that device to

go into LP mode• While the device is in LP mode, the meter will perform a REQ_UD2 billing read to it.• The device will respond with a special LP packet instead of the normal billing read packet.• The LP data will be in the two 4-byte values in that packet• The meter must then send another Application Reset command to the device to take it out of LP

mode and back to normal operation

The following is a capture of data done when the meter performed this type of LP on an M-Bus Tool device:

Sample LP:15:23:7; Got a COM10 2400 baud 'Application Reset' M-Bus command for Address 2, Device 2, sent an 'e5' response sent an E5 response{68}{04}{04}{68}{73}{02}{50}{60}{25}{16}

15:23:7; COM10 2400 baud, sending Load Profile Response to Address 0, Device 2. responded correctly{10}{7b}{02}{7d}{16}

[68][29][29][68][08][02][76][22][22][22][22][12][34][01][00][04]

[00][00][00][07][79][22][22][22][22][12][34][01][00][02][6c][12]

[43][04][10][0f][17][07][1e][04][10][10][18][08][1f][27][16]

This packet had a total length of 47 bytes.

15:23:7; Got a COM10 2400 baud 'Application Reset' M-Bus command for Address 2, Device 2, sent an 'e5' response sent an E5 response{68}{04}{04}{68}{73}{02}{50}{00}{c5}{16}

LP Method 2: Data Source 237The specification for this Load Profile method can be found at:\\Virgil\nes\Projects\Meter\Firmware Development\Gen 2.1\Functional Specs\Gentoo 2.1 meter - M-Bus Blg in Load Profile v0.4.doc

This method only works for later versions of FW2.10 and for FW2.11. It was created at the request of one customer and only that customer uses it. It has not been carried over to any of the 3.XX versions of FW.

This method looks simply like a MP11 procedure that uses source ID 237 as a source. The meter will perform a billing read and then capture the first bytes of that billing read to the LP interval. The amount of data captured depends on the number of sources per interval and how many sources preceded source 237 in the list of sources. If multiple sources are named in the MP11, none will be honored after source 237.

A maximum of 64 bytes of M-Bus data can be LP’d this way, 16 sources requested, only 237 named, 4 bytes per source, all filled.

If multiple M-Bus devices are registered, the one with the lowest address will be used.

LP Method 3: Load Profiling data by MDTLoad profiling by MDT only applies to meter FW 3.30 and later. The idea is to identify specific data blocks in the M-Bus billing data and capture the data from those blocks into the Load Profile Interval data.

The specification covering this method can be found at:\\Virgil\nes\Projects\Meter\Firmware Development\Gen 3.3\Functional Specs\Archive\ Gentoo 3.3 meter - Interval Data V6.docx

Setting up MDT Load ProfileThe first step is to determine which data blocks in the M-Bus Billing data are to be captured by a Load Profile. If you are using M-Bus tool as an M-Bus device, use the Defined Variable Frame type and set up the data blocks using the DIF VIF List.

However, is a real M-Bus device is being used, it may be necessary to examine the billing data of that device to identify the desired data blocks. If you are using a real M-Bus device instead of M-Bus Tool You will want to identify the data blocks within the billing data of that device. You can use the “Find M-Bus Device” feature of M-Bus tool to examine the billing read data the device.

In either case, take note of the DIF, DIFE’s, VIF, and VIFE’s (the MDT’s) you wish to monitor the data for. Set up MT57 with the MDTs to be searched for and select “M-Bus” as the Entry Type. Multiple “Entry’s” can be used for long MDTs, just select “Extension” for the type after the first Entry. Enter the entire MDT into MT57, using multiple entries if required.

The MDT number is just a label. If more than one MDT has the same number, then the meter will use the first data block found that matches an MDT with that number. For “Extensions”, the number is not used.

Setting up MP11 for MDT Load ProfilesFor MDT-mapped LP, use Interval Sources 112 to 163. 112 points to Extended Source 0, 113 indicates Extended Source 1, etc. The default is that there are 16 Extended Sources, so the max default range for MDT-mapped sources is from 112 to 127.

Set up the Extended Source IDsBits 15…12 11…8 7…5 4…0

Range

Fixed Value for MDT MEP Device Number Not Used MDT Number

Range

4 0 to 5 0 0 to 31

• Bits 12 to 15 – This first Nibble must be 4 for MDT Load Profile• Bits 8 to 11 - Second nibble is the Device ID (not handle) as seen in MT14• Bits 5 to 7 are unused, set to 0• Bits 0 to 4 - The lowest 5 bits are the MDT number in MT57 to look for to get this value.

Sample of MP11 for MDT Load Profile Setup

MP19 On-Demand M-Bus Requests

3.1.1. MP19 M-Bus Application Reset 3.1.2. MP19 Billing Read Request3.1.3. MP19 Status Read Request

3.1.4. MP19 Time Syncs3.1.5. MP19 Write User Data3.1.6. MP19 Multicast to Specified Devices.

Filling up MT16 and/or MT45 Billing Read DataBilling Read data from M-Bus and MEP devices can be stored in MT16 and/or MT45.

Recurring Billing Reads are scheduled billing reads, and the frequency is set in MT13.

Non-Recurring Billing Reads are MP19 billing reads, and they are always stored in MT16 only.

Storage of Recurring Billing Reads for both MEP and M-Bus

Recurring billing reads in MT16

Recurring billing reads in MT45

MT36: MT45 Current Entries = 0 Yes NoMT54: ICS – ICA NAK = 0 Yes YesMT54: ICS – ICA NAK = 1 No Yes

MP37 is used to set up MT45

MT54 Interface Compatibility Settings: ICS – ICA NAK is the flag for logging non-recurring billing reads to MT16 as well as to MT45

4. Program controls: Buttons and Doo-Dads

This section will discuss all the controls and settings available in the M-Bus Tool. Please reference either an executing copy of the program on your PC or the screenshot below.

Main M-Bus Tool Screen

Version DisplayThe M-Bus Tool version is displayed in the upper left corner of the main panel.

The practice is to increment the lowest (minor) version number for every new release. The major number indicates a new code base with the previous code base being archived. The middle number will tie the version to the documentation, so that the user only needs to verify the first two numbers match between this guide and the version of M-Bus Tool he is using.Main text viewThis text display is where the M-Bus Tool displays its activity. The contents of all communications are time-stamped and displayed here in hex. Note that the brackets for sent and received data are different, so you can tell which is which. The status of the COM ports displayed in this display upon opening or closing. This display is an informational display, and while one could edit the contents of it, nothing typed here has any effect on the actual execution of the M-Bus Tool.

Special Error LEDThis indicator changes from green to red if there is a serious packet error from the meter. Possible errors could be wrong packet structure, incorrect checksum, or Health Function Timeout.

This indicator is only affected by packets FROM the meter, not sent to it. These Special Errors will also be noted on the main display and logged to SpoofData.txt and to SpecialError.txt.

Clicking on the red LED will set it back to green.

Health Monitor setting and switchThe Health Monitor allows the M-Bus Tool to verify periodic M-Bus activity happens on schedule. When you set it and turn it on, if the Health Time passes without any M-Bus activity, then a Special Error is logged. The purpose of this control is to verify that periodic events happen at no more than the set time. For instance, if you set Status Reads on an M-Bus device to happen every five minutes in the MT13 configuration of the meter, then you can set the Health Time for 4 minutes 55 seconds, and you should never see the Special Error alarm get set.

The Health Monitor function counts the time since the last M-Bus activity with any device. It does not keep track of how long a particular device has gone since the last access. Therefore it really works best when only one M-Bus device is registered.

The Health Monitor switch turns this function on or off. The time limit for the next M-Bus access is set upon turning on the switch and when an M-Bus access occurs. Changing the time between access will not change the expectation for the next access, but it will affect the one after that.

The settings of the Health Monitor switch and time are saved to disk when the M-Bus Tool is exited and reloaded when the M-Bus Tool is restarted.

The COM Port Config button There are LOTS of COM ports to configure if you want them, so their configuration was placed in a separate panel. Clicking this button brings up that panel. Note that this panel is only available when the M-Bus Tool is not in Spoofer mode. All COM Port settings and enables are saved to disk when M-Bus Tool is exited and reloaded when M-Bus Tool is restarted

There are twenty “Slave x to Meter” configurations, so that the M-Bus Tool can provide M-Bud device spoofing for up to twenty meters. In normal installations though, only one to 3 of these ports will be needed. Each “Slave x to Meter” COM port is configurable with a PC COM port number and baud rate, and it can be enabled or disabled from use.

There is a “Report to Equipment” Port that was requested by the EMI testing group. They needed to have their program detect if a Health Function violation had occurred. They could not monitor the disk files or the display. We opted to send a “1” to a COM port they could monitor, and this is how you can select that COM port and set its baud rate. If this function is not needed, just select a non-existant PC COM port and it will not impact M-Bus Tool functions.

The “Meter Power Port” can be set here. This is the COM port used to drive a Solid State Relay that in turn powers the meter. Special hardware containing that SSR , power in, power out, and COM Port access will be needed. Opening this port will apply power to the meter, and closing this port will power-down the meter. The M-Bus tool will not automatically open the “Meter Power Port” port on startup.

Micro-Master Port and Slave Port buttonsThe “Micro-Master” is the product name of the M-Bus master adapter I use, so this configuration refers to the serial port that device resides on. The Micro-Master and Slave port configurations share some functions as linked ports, so it is useful to define them together.

The Slave Port can be the same as one of the “Slave X to Meter” ports if you wish. Just select which one you wish to use. Then set the Micro-Master COM port. The baud rate setting affects both ports.

“Find M-Bus Devices” uses this Slave Port, “M-Bus Pass Through” uses both ports, and Diddle M-Bus Devices used the Micro-Master port

Toggle Meter PowerClicking this button alternates between opening and closing the Meter Power Port as configured in the COM Port Configuration panel. This is how to manually control the SSR supplying power to the meter.

Auto-Toggle Power pull-down.This feature uses the SSR controlling power to the meter to toggle power up and down automatically with a selectable duty-cycle. The intent was to assist in testing drift in the meters Real Time Clock due to power-cycling. To use it you need to first select the duty-cycle here, then start Spoofer mode. To stop the power-cycling, Stop the spoofer mode.

There is a maximum allowable drift in the RTC due to a power-cycle of 0.025 seconds. While the power-cycling is going on, a count of the number of power cycles is kept and the maximum allowable drift for that number of cycles is displayed. You would synchronize the times between the meter and an external clock (like your PC), allow the power-cycling to run for a long time, and then stop it and match the actual drift against the Maximum Allowable Drift.

This is a bit of a crude tool for checking clock drift, there is a much better tool built into the MEP Spoofer.

The Auto-Toggle Power setting is saved to disk when M-Bus Tool is exited and reloaded when M-Bus Tool is restarted.

Start M-Bus Spoofer buttonClicking the “Start M-Bus Spoofer” button causes the M-Bus tool to spawn the spoofing process as a sub-porcess. Upon entering spoofer-mode, the M-Bus tool will go through all 20 slave ports listed in the COM Port Config menu and attempt to open the ones that are enabled, at the baud rate they were configured for. A message will be posted to the display for each attempt to open a port, the port number will be shown and a resulting “error” will be given. Error 0 means there was no error opening the port. Below is a table of the most likely error causes:

-0 No Error-1 Unknown system error.-2 Invalid port number.-3 Port is not open.-4 Unknown I/O error.-5 Unexpected internal error.-6 No serial port found.-7 Cannot open port.

Most Common Port Opening Errors

After initializing several things (variables, flags, timers, etc., the main spoofer loop is entered.

The main spoofing loop does several functions in a big loop. These functions include:

Monitoring Health Activity; checking the changing state of Health Enable to start/stop the internal timer, re-initializing the health timer on M-Bus activity, and generates a Special Error for expired timer.

Monitoring AutoToggle of power; Checking for changing setting, checking AutoToggle timer for expiration, changing the power state between on and off, and re-initializing AutoToggle timer.

Checking all active M-Bus serial ports for activity; checking for bytes on each port, adding them to buffers for that port, checking for valid M-Bus frames on received data, optionally tossing invalid data, and responding to M-Bus requests as configured.

In addition, the spoofer mode checks and services the Toggle Meter Power button and checks for telnet activity (if telnet sessions active)

Exiting the spoofer mode is done by clicking on the “STOP” button in the lower right corner of the main panel. This closes all slave ports and terminates spoofing sub-process.

Find M-Bus Device Button

There are times when we are handed a real M-Bus device and have no knowledge of the baud rate or address it communicates on. This utility uses a M-Bus Master device to try to determine the baud rate and address of such a device, and to capture a billing read from it.

This feature will search all 256 possible addresses at the currently configured baud rate for a response. The COM port of that adapter must be programmed into the COM Port Config menu along with the baud rate you wish to search at. It is a good idea to verify that the M-Bus master adapter is functioning properly by using it to find an known-good M-Bus device before searching for the un-known device.

The three M-Bus baud rates used are (in order of most frequent to least frequent): 2400 baud, 300 baud, and 9600 baud. Once the config is set, click the “Find M-Bus Device” button. The M-Bus Tool will:

Open the com port with the indicated baud rate Send SND_NKE’s (pings) to com port starting at address 0 (zero) and counting up to 255. After each ping the M-Bus Tool will wait ½ second for a reply and then move on to the next

address Echoed characters from the M-Bus master adapter will be displayed, allowing you to monitor

progress. When the M-Bus tool reaches address 255, it will reset to address 0 (zero) and keep searching.

If the M-Bus tool gets a 0x5E acknowledgement from the device, it will then send a REQ_UD2 (billing request) to the port. The M-Bus Tool waits a LONG time for a response to that billing request. (It has to wait 15 seconds before even sending the request because some M-Bus devices cannot be accessed more than once per 15 seconds, and the SND_NKE counts as an access. Also long billing packets at 300 baud take a long time to transfer, and M-Bus Tool does not vary the wait based on baud rates.)

The M-Bus Tool will displays and logs the received billing packet and decode it for examination. The log file used is FindMe.txt.

The M-Bus tool will then continue scanning for devices at the next address.

To terminate the “Find M-Bus Device” function, click the “STOP” button.

M-Bus Pass ThroughThis is a utility for monitoring communications between a meter and an M-Bus device. It requires an M-Bus slave adapter to communicate with a meter, and an M-Bus master adapter communicates with the M-Bus device.

The COM ports and baud rate for the adapters are configured in the COM Port Config menu.

Click on the “M-Bus Pass Through” button to start this function. The M-Bus Tool will open both master and slave COM ports and display status.

All characters received from either port will be displayed on the main panel, logged to PassData.txt, and sent to the other port.

This function is pretty much a passive function, it does not react to any data other than to log and pass it. However, this function does introduce a small delay in data flow, due to the need to retransmit it on a second time. The meter’s Ta and To values (MT13 MEP Device Config Table) may need to be adjusted to allow for this delay, however the delay is usually not a problem.

Terminate the “M-Bus Pass Through” function by clicking the “STOP” button.

Diddle M-Bus DevicesIf you know the address and baud rate an M-Bus device is using and wish to change either of these values,

This function uses the M-Bus Master Adapter.

Clicking the “Diddle M-Bus Devices” button will bring up the Diddle M-Bus Devices panel. In there, you can set the current address and baud rate, and the desired new address and/or baud rate. Then, by clicking the button for “Change Baud Rate” or “Change Address” you can cause the M-Bus spoofer to make that change.

Diddle M-Bus Devices Panel

To determine the current baud rate and address of the device, you can use the “Find M-Bus Device” function of the M-Bus Tool. Even if you know these, it is not a bad idea to run that function first just to verify the hardware and the configuration.

Clicking either “Change” button will cause the M-Bus too to attempt the change. M-Bus Tool will first close the menu, and progress can be monitored on the main display. It will open the COM port for the M-Bus Master Device with the Current Baud Rate. It will first ping the current address and then send the desired change command to that address or baud rate. M-Bus Tool will then close the port and terminate the function.

Clicking the “Quit” button terminates the menu without doing anything.

Device x ButtonsThere are four buttons for configuring four M-Bus Devices, and they all work the same, but they pertain to different devices.

The Device Configuration Panel will be discussed in greater detail in another section.

Each device can be enabled or disabled by right-clicking on the button for configuring that device. Left-clicking on the button brings up the Device Configuration panel for that device. All devices can be modified while the M-Bus tool is in spoofer mode, making it possible to change configurations on-the-fly. Any changes made to the configuration panels will take effect when the panel is closed.

All device configurations are saved to disk and re-loaded when the M-Bus Tool is restarted.

Clear Screen ButtonThis button just clears all text from the display. It has no other effect on program function.

Axe Drop ControlThis is the control used for cutting power to the meter during an M-Bus transaction. It requires that the M-Bus Tool is controlling a Solid State Relay that in turn controls power to the meter.

The following diagram shows a wiring diagram for the Solid State Relay power control.

Diagram of wiring of meter to Solid State Relay

When the “Axe Drop Control” button is clicked, the Axe Drop Control panel is brought up.

Axe Drop Control panel

One can enable the Axe Drop function here, and set the number of echoed characters that need to be echoed before power to the meter is dropped.

Once the Axe Drop Enable switch is set to “On” and the panel is closed, the Axe Drop function will act on the next M-Bus response on any device if there are enough bytes in that response to trigger the Axe Drop. The Axe Drop function will count characters echoed by the M-Bus Slave Adapter and when the “Drop Power After” number is reached, it will close the COM port to the SSR.

The power drop is not instantaneous because capacitors in the meter will keep it functioning for a short time after power is removed, but that is a matter of milliseconds.

“STOP” Button terminates M-Bus Tool functionsThe “Stop” button is the button used to terminate all looping functions in the M-Bus Tool These functions include “Start M-Bus Spoofer”, “Find M-Bus Device”, and “M-Bus Pass Through”.

“Clear Log Files” buttonClicking this button resets the log files log files by opening them for a write and then closing them immediately. The files will still exist but they will be 0 (zero) bytes long.

This function is not foolproof during M-Bus Spoofing. The spoofer keeps the file open during the spoofing loop. This button clears the file itself but does not flush the buffers. Some bytes may remain unflushed in

the buffer and will be written with the next time the buffers are flushed. Flushing occurs when the buffer gets full or when the M-Bus spoofing mode is terminated.

The files affected by the “Clear Log Files” button are axarray.txt, FindMe.txt, PassData.txt, ReadLog.txt, andSpoofData.txt.

“Comma Delimited Text File” buttonWhen using M-Bus tool to verify DC M-Bus functions, Provisioning Tool M-Bus functions, or other systems M-Bus functions, it is sometimes very handy to have a cheat-sheet of how M-Bus Tool devices are configured. This feature was created to automate making that cheat-sheet.

This button causes the M-Bus Device configurations to be written to a comma-delimited text file in the M-Bus Tool folder named ExcelConfigFile.txt. The user can open an Excel spreadsheet and import that file to it as a comma-delimited file. He will then have a single sheet showing the configuration of all four M-Bus devices. The contents of this file will show the device serial number, baud rate, address, Mfg ID, alarms, etc.

“M-Bus Packet File” buttonWhen using M-Bus Tool to verify MDT functions and things like that, it is sometimes helpful to have a cheat-sheet of billing packet data for easy reference. Clicking this button causes a dump of the data portion of billing read data (as configured for Defined Variable Packets). The filename is “MBusPackets.txt” and the file will be created in the M-Bus Tool folder.

This makes a handy document for verifying what has been collected by Provisioning Tool and for helping configure the meter for Load Profiling M-Bus data.

Telnet Port LEDs and “Disconnect” buttonThe M-Bus Tool can be remote controlled via telnets from tcl or other computers. There are two telnet servers created by the M-Bus Tool on the host computer. One is for giving commands to M-Bus Tool via telnet, the other is for M-Bus Tool to send packet data to the client that established the telnet. Normally, both telnets would be established from the same system that will control the M-Bus tool and monitor M-Bus traffic.

There is one LED to show telnet activity for each of the telnet servers, green means the telnet is active, red means no current login. The “Disconnect” button forcibly terminates both telnets.

This topic is covered in greater detail in “Remote Control of M-Bus Tool”.

“Delay Before Response” settingThere are time when, for testing purposes, we want to introduce a delay between when M-Bus Tool gets a request and when it sends a response. This setting is the time, in seconds, of that delay.

Normally this value should be 0.00 seconds, no delay.

The delay is disruptive, no processing of other events happens while the M-Bus Tool waits out the delay. That means other requests and/or functions will not be processed during that time. The user needs to be aware of this.

Running Time displayThis is the time, in minutes, seconds, and fractional seconds, since the spoofing function has been started. It is updated on every pass through the spoofing loop.

Don’t Show Echoes/Show EchoesAs stated earlier, the M-Bus Slave adapters echo back every character the Spoofer sends to the meter. Normally the spoofer counts incoming bytes and tosses the echoed bytes. Setting this to “Show Echoes”

makes the spoofer display the echoes before tossing them. This is useful for debugging at times, but overall is very bothersome.

It is suggested that this setting be left at “Don’t Show Echoes”

No Trash/Show TrashThere are times when the M-Bus Slave ports get gibberish trash, like when the meter powers on, or when M-Bus traffic arrives at a M-Bus slave adapter that is using a different baud rate. The M-Bus Spoofing function will normally filter and toss much of this trash and not act on it. Setting this to “Show Trash” will have the trash displayed before tossing it. This is useful for debugging at times, but overall is very bothersome.

It is suggested that this setting be left at “No Trash”.

Reload Device Configs on Message/Don’t Reload Device ConfigsSetting this to “Reload Configs” will cause the device configurations to be reloaded every time there is an M-Bus transaction. This feature was put in at Andrei’s request. I forget how this works or why he wanted it, but the need for it went away when the ability to telnet to M-Bus tool was put in.

It is suggested that this setting be left at “Don’t Reload Configs” unless your name is Andrei.

Increment Packet Number/Don’t Increment Packet NumberEvery M-Bus Variable Length packet has a packet number associated with it. Normally the packet number gets incremented per M-Bus specification for every packet. There is a time, during testing, however, where we do not want to the packet numbers to increment. Setting this to Don’t Increment Packet Number stops the incrementing of packet numbers.

It is suggested that for normal use, this setting should be left at Increment Packet Number.

Device Configuration Buttons There are four buttons labeled “Device 1”, “Device 2”, “Device 3”, and “Device 4”, that open the M-Bus Device Configuration panel on the four configurable simulated devices. They all actually open the same panel. The data stuffed into the panel and collected from the panel upon closing is keyed to which button was originally clicked.

The color of these four buttons indicates the current enable-state and baud rate of the device. A gray button indicates that the device is disabled. Any other color indicates the device is enabled, green indicates 300 baud, blue indicates 2400 baud, and purple indicates 9600 baud.

Device Configuration Panel

Device Enable switchThis switch enables and disables this device from being active. When an M-Bus command arrives from the meter, an inactive device will not even be considered as the source of a reply.

The enabled/disabled status of a device can also be toggled from the main panel by right-clicking the Device X button.

When disabled, the device will not respond to any M-Bus stimulus

M-Bus address Change EnableThis selects how this device will respond to an address change command from the meter. The options are:

• Reply and Change - Normal setting, M-Bus Tool replies to the command with a 0xE5 acknowledgement and changes the Device Address setting automatically.

• Reply, Don’t Change – M-Bus Tool replies to the command with a 0xE5 acknowledgement but does not change the Device Address setting automatically. This is used during testing.

• Don’t Reply, Don’t Change – M-Bus Tool does not reply to the command with a 0xE5 acknowledgement and does not change the Device Address setting automatically. This is also used during testing.

Baud Rate Selector

When an M-Bus command is received from the meter, M-Bus tool checks the device configurations to see if one of them is able to answer. In order to reply, the device must be enabled and set to the same baud rate that the command was sent in and be set for the address the command was sent to.

This selects the baud rate this device will communicate at. Normal baud rates are 2400, 300, and 9600 baud, they are the only baud rates used by the target meters and suggested for use by the M-Bus specification.

M-Bus tool does support other baud rates, but none are ever used.

Address selectorThis setting selects the M-Bus address that this device will respond to. Commands sent to other addresses will never be responded to by this device.

Address 0 is the address that indicates “ready for AutoDiscovery”. Address 1 thru 4 are normal operating addresses for our meter. Address 250 is the throw-away address.

Our meter can be instructed to delete an M-Bus device (MP17) and set its address to 250. At this address, our meter can never communicate with that device again. This is for devices that need to be thrown away and never re-used. The M-Bus Tool needs to be able to configure to this address to test that function.

Frame Type selectorWhen a billing read request arrives, this selector indicates the type of frame format to use for the response.

Frame types available:• Fixed Format Frame - The settings in the configuration are mushed into a M-Bus fixed-format

frame as defined by the M-Bus specification. All elements of that frame type are rigidly defined. This is the only way we have ever found of providing Fixed Format M-Bus frames, no devices have been found that use them. But our meter’s ability to handle them must be tested.

• Single Variable Length - Defined by the M-Bus specification, this is the most common billing read frame type. All of the settable fields of this frame type are defined farther down in this document.

• Two Variable length – The basic frame is the same construction as the Single Variable Length setting, but for the first frame, the 0x0C DIF of the third data block is replaced with a 0x1F special DIF indicating that the meter needs to request another frame. The second frame matches the Single Variable Length frame with no 0x1F in the third data block.

• Three Variable Length – The basic frame is the same construction as the Single Variable Length setting, but for the first two frames, the 0x0C DIF of the third data block is replaced with a 0x1F special DIF indicating that the meter needs to request another frame. The third frame matches the Single Variable Length frame with no 0x1F in the third data block.

• Four Variable Length – The basic frame is the same construction as the Single Variable Length setting, but for the first three frames, the 0x0C DIF of the third data block is replaced with a 0x1F special DIF indicating that the meter needs to request another frame. The Forth frame matches the Single Variable Length frame with no 0x1F in the third data block.

• Ten Variable Length – The basic frame is the same construction as the Single Variable Length setting, but for the first nine frames, the 0x0C DIF of the third data block is replaced with a 0x1F special DIF indicating that the meter needs to request another frame. The tenth frame matches the Single Variable Length frame with no 0x1F in the third data block.

• General Application Error: CI = 0x70 - The M-Bus specification allows for an M-Bus device to respond to a billing read request with a General Application Error frame. This setting makes the M-Bus tool do just that.

The frame will look similar to this: [68][04][04][68][08][02][70][00][7a][16]

This is the only known way to test the meters ability to handle this condition.• Don’t Respond to REQ_UD2 - This frame type selection causes the M-Bus Tool to reply to all

M-Bus requests except a billing read request, which it will ignore. It is useful for some test cases.• Defined Variable Frame – This setting causes the meter to respond to a billing read request with

a variable length frame containing a data block as defined in the DIF VIF list setting. The use of this setting is discussed in detail in Defined Variable Frame Configuration

4.1.1.1.1.1. Length can be set.4.1.1.1.1.2. The data portion of this frame is mostly garbage data

4.1.1.1.1.2.1. The first data block is an 8-byte Enhanced Identification block – needed for type 0x02 and 0x03 encryption

4.1.1.1.1.2.2. The second data block is a 2-byte Type G Time Point – Needed for Type 0x02 encryption

4.1.1.1.1.2.3. The third data block has a DIF of 0x0C and a definable VIF4.1.1.1.1.2.4. After that, the data does not conform to the M-Bus, but it can

be set to various patterns.

Data OrderWhen data is stuffed into the M-Bus packets, this setting determines if that data is stuffed in MSB or LSB format.

This setting also impacts the corresponding bit in the packet CI byte

Packet SizeThis size pertains to all variable length type frames except the Defined Variable Frame type. The total frame lengths will be this number plus 4-byte header, plus 3 bytes for the C-byte, address, and CI-byte, plus two bytes for the Checksum and Stop Byte.

This value should show up in the MT16 “Telegram Length” field.

The L-Bytes in the packet will be this number plus 3, we don’t count the C, address, or CI bytes.

The range for this value is a minimum of 12 (this is the length of the Manufacturer Specific Data Block, and the M-Bus Tool coding does not permit truncating that block,) and a maximum of 252 (the L-Bytes in the packet are 0xFF.)

Meter TypeThis pull down defines the Meter Type byte of all the Variable Length packets.

Note that there is a separate Meter Type setting for Fixed Length packets, they are different values.

Manufacturer IDThis 2-byte value will be used in all Variable Length frames.

Manufacturer ID is actually considered to be a 3-character ASCII value. The three ASCII characters are encoded into the two bytes. The M-Bus Tool packet configuration tool will convert the 2-byte value into 3-character ASCII for you so you can see how they decode. That 3-character ASCII is what you will see in Provisioning Tool when you go to verify PT functionality.

VersionThis 1-byte version is inserted into all Variable Length Frames.

Packet Stuffing

This setting pertains to all variable length type frames except the Defined Variable Frame type.

This allows you to specify the type of data to pad out variable length frames with. Since, until FW 3.30, in most cases the meter did not do much with the data, it could be pretty-much whatever you wanted. We do have to be careful with 0x1F, that could accidentally trigger a follow-on billing read we don’t want. M-Bus Tool will replace any unintentional 0x1F with a 0x0C.

Types of data for stuffing:• Normal Data – Simple count-up from 35• All 0x55 – All data is 0x55, used for testing M-Bus hardware at 9600 baud• All 0xFF – All data is 0xFF, used for testing M-Bus hardware at 300 baud• Varying Data – Simple count-up from different starting points• EPR 44938 – Data detailed in this ERP caused trouble, so I built it into the M-Bus Tool for

testing.

0x2F Filler Bytes before DIFThis setting pertains to all variable length type frames except the Defined Variable Frame type.

The M-Bus specification allows for any number of 0x2F special bytes to be inserted, as placeholders, before any DIF in the data block. When parsing for the first DIF, the meter must recognize these bytes and step past them. This setting allows the insertion of up to ten 0x2F bytes before the first DIF. The purpose was to verify that the meter could identify the 0x1F special character following all the 0x2F placeholders and signal that recognition by requesting another frame.

Now that the M-Bus Tool has configurable data blocks this testing could be better done there.

Use VIFThis setting pertains to all variable length type frames except the Defined Variable Frame type.

For non-defined variable size packets, this value will be inserted after the third DIF of 0x0C.

Now that the M-Bus Tool has configurable data blocks this testing could be better done there.

Serial NumberThis is a 4-byte BCD containing the serial number that will be shown in all billing read packets. The ordering of those bytes in the packet will change according to the Data Order setting.

Status Byte ControlsThe Status Byte in an M-Bus packet is encoded as bits or bit-groups within the status byte. The M-Bus Tool breaks out these bits allowing you to set or clear them by name.

• Application Status - Two bits, bit 0 and 1 have different meanings between variable and fixed length packets, but set them here for either.

• Low Power – Bit 2• Perm Error – Bit 3• Temp Error – Bit 4• Mfg Specific Status – 3 bits: bit 5, 6, and 7.

These bits have meaning in the meter for setting both MEP alarms and ST03 alarms. The M-Bus tool is the way to reliably set these bits, you cannot count on them from actual M-Bus devices.

Encryption SettingsThere are two things to set to make M-Bus encryption work: Encryption Type, and Encryption Key.

The way encryption works and how to set it up will be discussed in Encryption Testing.

Load Profile VIFsThese VIFs pertain only to M-Bus Load Profile types that use ST16 Data Sources 73 through 80. When those data sources are used, the Load Profile packet returned to the meter from M-Bus Tool devices will include two DIFs and two VIFs. The DIFs are pre-defined, but the VIFs can vary. This is how they are set.

There are two configurable VIF values per M-Bus device, for Channel 1 and Channel 2. These are hex values.

This is a proprietary method of doing a Load Profile. The meter sends the M-Bus device an Application Reset frame with a parameter of 0x60 to put that device into a special LP mode. The meter then sends a REQ-UD2 billing read request and the device responds with a specially defined LP packet. The meter must then send another Application Reset packet, this time with a parameter of 0x00, to return the device to normal function.

These are the bytes used in the VIF fields of the LP packet.

Counter 1 Actual Value and Counter 2 Historic ValueThese values pertain only to Fixed Length packets, they are the hex values inserted in the data fields of those packets.

Meter Type – Fixed PacketsThis is the meter type for Fixed Length packets, the encoding of meter types is different than in Variable Length packets. For Fixed Length packets, the meter type is a nibble (4 bits) in length, and it is broken into two 2-bit chunks and included in the bytes with the Physical Units.

See the M-Bus specification for more details on how this all works

Physical Units 1 and Physical Units 2These pertain to Fixed Length packets. Each value is 6 bits long and each value is combined with two bits of the Meter Type.

See the M-Bus specification for more details on how this all works

Time SkewThere are numerous types of data blocks that can encrypt date/time into an M-Bus Packet. When that happens, the time inserted into the data block is keyed to the PC’s internal time. If you want the inserted time to be related to the meter’s time, synchronize the Meters RTC with the PC running M-Bus Tool. This Time Skew setting will skew all M-Bus timepoints from the PC clock by the set amount.

There are time skew settings in years, months, days, hours, minutes, and seconds that can be set forward or backwards. The total skew will sum up all of these skews.

There are three ways to change any of the skew settings, click on the slider and move it, click on the up/down arrows by the text window to increment or decrement count by 1, or click on the window itself and enter the number as text.

All date and times stamps in the device’s data packets will be skewed by this amount unless a Defined Variable Frame type packet is being used and a data-block-specific skew is entered when the data block is defined. In that case, the data-block-specific time skews will override this device-wide skew.

Error injection on the M-Bus packetsOne of the important types of testing to do on the M-Bus is to verify that our meter will not react badly to packetizing or transmission errors on the part of external M-Bus devices. This is done by generating errors and monitoring the meters handling of them.

The frame and transmission error settings are on the right-hand half of the device configuration panels. Each device can have its own, unique errors and problems. Most of these injected errors will not affect the “Defined Variable Frame” type of frame. The routines to generate those frames did not take error injection into account. Please use other frame types when injecting errors.

Specifying when the errors are to be injected.The way to specify when an error is injected is to set a number for how many un-corrupted frames to allow to pass followed by some number of corrupted frames. This way one can inject an error into the middle of a series of frames.

Frames Before Errors - This is the number of frames to send without any errors before we begin sending errors. This number will count down as packets are sent. A SND_NKE (ping) answered with an 0xE5 acknowledgement counts as a packet even though there was not much to it.

This can be set from 0 packets (start immediately) to 10 packets.

Number of ErrorsOnce the Frames Before Errors has been depleted, this will specify how many frames should get errors. This defines that number of corrupted frames. This number will also count down as packets are sent. A SND_NKE (ping) answered with an 0xE5 acknowledgement counts as a packet even though there was not much to it and perhaps no error was injected.

This can be set from 0 packets (start immediately) to 10 packets, or it can be set for unlimited (Infinite) packets. Once this number counts down to 0 (zero), normal operation will resume.

The idea here is that one could be expecting a quick series of M-Bus transactions, but want to inject an error into some number of transactions in the middle of the series. So one could specify to allow some number of transactions to proceed without error, and then inject some number of errors into the transactions.

Type(s) of error to generate.Normally one would inject only one error at a time into transactions. However, provided the error types do not conflict, there is no reason why one could not inject more than one into a given transaction. All settable error types have a “no error” setting as a default

Aborted ResponseThese are response errors where some or all of the packet is missing. Possible settings are:

• Normal Response – Default, no error.• No response – Don’t respond to a request at all• Aborted, header only – Respond with only the packet header and truncate the rest• Aborted, half frame – Create the response frame, but actually send only the first half• Aborted, missing Stop Byte – Send a response frame that is missing the Stop Byte• Aborted, missing Checksum - Send a response frame that is missing the Checksum and Stop Byte

Parity ErrorNone of these settings work, I never found a way of generating any of these errors without totally interrupting the packet and data flow.

Leading GibberishThis error inserts some number of random bytes in front of the frame to be sent. It can be set from 0 to 10 bytes of gibberish.

Num of Encrypted BytesThis pertains to packets with data encryption but not with defined data block frames. Those are handled elsewhere.

When data encryption is used, the number of encrypted bytes is shown in the first byte of the Signature in a Variable Length packet. This setting messes with that number, halving or doubling it.

Checksum ErrorThis error adds or subtracts one or two to the packet checksum byte. It can also set the checksum to 0x00.

Incorrect AddressThis error replaces the correct address in the response packet with another value. The incorrect address can be set to 0, 1, 2, 3, 4, 5, 128, or 0xFE. The default is to use correct address.

1st L-Byte and 2nd L-ByteThe L-Bytes are part of the 4-byte header of a long M-Bus frame. The L-Byte is the “Length Byte”, indicating the number of bytes in the M-Bus frame following the 4-byte header. The L-Byte is repeated for verification, if they don’t match the frame is invalid.

These settings allow the tester to vary either the first or second L-Byte and verify the meter sees the frame as invalid (retries). Each L-Byte can be set to +/- 10. The default is to use the correct value.

First Start Byte and Second Start ByteThe M-Bus start byte is 0x68. It marks the beginning of an M-Bus long frame and is part of the 4-byte header. Two Start Bytes bracket the two L-Bytes.

If either of these bytes is NOT 0x68, the frame is invalid. These settings allow the tester to vary either one of the Start Bytes. The values for these bytes can be set to 0x68, 0x69, 0x67, 0xE5, and 0x00.

Stop SignThe Stop Sign is a 0x16 byte that marks the end of any M-Bus packet. If the final byte of the packet is not 0x16, the packet is invalid.

This setting lets you vary the Stop Byte. The Stop Byte can be set to 0x16 (default), 0x17, 0x15, 0x68, 0xE5, and 0x00.

Invalid ResponseThis setting makes the M-Bus spoofer respond to a request with a totally incorrect response. Improper responses can be set to:

• The correct response (default)• Send a 0xE5 acknowlegement to a REQ_UD2 billing read request.• Send a billing read frame in response to a SND_NKE ping• Respond to any request with an application error frame.

General Application Error DataThere are two ways to generate application error packets, this setting enters the data in both methods.

When an application error packet is sent, one byte of data can be included following the CI byte• 0 – Unspecified error: also indicates no data• 1 – Unimplemented CI-Field• 2 – Buffer too long, truncated• 3 – Too many records• 4 – Premature end of record• 5 – More than 10 DIFE’s• 6 – More than 10 VIFE’s• 7 – Reserved• 8 – Application too busy for handling readout request

• 9 – Too many readouts (in period of time)• 10 to 0xFF – Reserved

In M-Bus Tool; • Data 0 through 9 can be directly selected• Data 10 randomly selects one of 0x00 through 0x09• Data 11 randomly selects a number from 0 to 255

Additional buttonsDIF VIF List – this will be discussed in the Defined Variable Frame Configuration, discussed later.

Reset Error Defaults – clears all error settings back to default, quick recovery.

Reset Packet Defaults – Returns all packet data back to what it was when the program was first installed.

Encryption Error EnablesThis is a sub-menu started for holding injectable errors regarding encryption. This was created before the Defined Variable Frame feature was added to the M-Bus Tool.

Encryption Error Enables Panel

The first and second DIF and VIF can also be modified in the “Defined Variable Frame” type. These settings pertain to Variable Length Frames other than the Defined Variable Length type.

Type 0x02 and 0x03 encryption require an enhanced ID data block to be somewhere in the packet. Type 0x02 encryption also requires a 2-byte, Type G date-stamp to be somewhere in the frame. The first and second DIF and VIF selections are a way of messing with those data blocks.

MSB/LSB Mixup sets the packet bit indicating one format, then uses the other.

Encryption Type in Signature

The 2-byte packet signature consists of two parts: Second byte is encryption type. The M-Bus specification defines three valid values for encryption type: Valid types are 0x00 (no encryption), 0x02, and 0x03. No other types are defined in that specification, but all are reserved. Setting this byte to another value indicates an un-known encryption type. The meter will collect the data into MT16 or MT45 verbatim from the packet and attempt no decryption.

Number of Encrypted Bytes in SignatureThe first byte of the signature is the number of encrypted bytes. Since data is encrypted eight bytes at a time, this number should be a multiple of eight. Data can be padded with 0x2F bytes so that the number of data bytes is a multiple of 8. Another option is to leave some number of bytes un-encrypted, usually some number less than 8.

Defined Variable Frame ConfigurationReasons for specific data blocksThe ability to define a packet or multi-packet response to a billing read request became required when FW version 3.30 introduced MDTs into the specification. New meter features requiring MDT testing support were:

• M-Bus Sniffer Matching - Sniffs MP19 Write User Data procedures for definable valve-control commands. This also works in MEP commands. This feature generates ST74 events when the indicated commands are detected.

• M-Bus State Monitoring - Scans M-Bus Billing Data for a Data Block indicating the state of the gas valve and records the gas valve state in MT58 Control Status. If the state has changed, is there an event and/or alert? (investigate, I don’t remember offhand)

• Load Profile data blocks - Defines Load Pofile data by associated MDT and captures that data into the Load Profile interval data. These MDTs can be defined as virtually any data block and they can be anywhere in the billing read packet(s). 4 bytes of corresponding data captured into the Load Profile interval data.

Additional features provided by definable data blocksWhen the M-Bus Tool was required to be capable of completely defining a billing packet, it became necessary to make it capable of other functions as well. These include:

• Defined frames needed ability to include the data blocks required for encryption.• Defined frames needed ability to define multi-packet responses to billing read requests with

varying data in each packet.• Testing functions needed the ability to make date/time stamps match meter time or be skewed with

respect to meter time.• We also needed the ability to include variable length text strings or user-defined data.• We needed the ability to define data blocks with multiple DIFE’s and VIFE’s for testing long

MDTs.

The DIF VIF List PanelFrom the Device Configuration panel, clicking on the “DIF VIF List” Button will bring up the DIF VIF List Panel.

The DIF VIF List Panel

Note that the DIF VIF List panel is a bunch of rows and columns. Each row is one data block, with a definable DIB (Data Information Block) and data. Most of this panel is informational, detailing the way the Data Blocks are currently configured. There are only two types of actions available here in this panel: Inserting or deleting a Data Block, and entering the Data Block configuration panel on a particular Data Block. (Of course, there is also the “Quit” button for exiting the panel, but that is a given.)

“Ins/Del” selectors allow you to perform two functions: Insert a DB row, moving the selected row and those below it downward, and Delete a DB row, moving all lower rows up. Selecting “Ins/Del” does noting, it is just a label.

Clicking the DB number button opens the configuration panel for that data block row.

The information fields on this panel are:• On/Off – Shows if the DB is enabled with a check mark. Only enabled data blocks are included in

a billing read packet. A disabled packet will retain its configuration but not have its contents displayed. One must click on the DB number button and enter the Data Block Config panel to enable or disable a data block row.

• DIF – This is the currently configured DIF as configured in pieces in the DIF VIF Micro Panel.• DIFE’s – Shows all enabled DIFE’s as configured in the DIF VIF Micro Panel.• VIF – This is the current VIF as configured in pieces in the DIF VIF Micro Panel.• VIFE’s – All enabled DIFE’s configured in the DIF VIF Micro Panel • Data - This is the data that will be included in the data block. There are several sources for the

content of this data:o Randomized in the DIF VIF Micro Panelo Specifically entered in the DIF VIF Micro Panelo Enhanced ID is generated as needed from the Device Configuration Panel settings

o Time and Date data is generated as needed from PC time and any skews set are applied to that.

o ASCII data is pulled from a long string in the code.• Byte Count is just a running tally of packet data size. It lets you see how big your packet is

getting. This count resets at beginning of a new packet in a multi-packet response. The real M-Bus packet size is this size plus 21 bytes for overhead.

DIF VIF Micro PanelFrom the DIF VIF List Panel, clicking on the DB number button will bring up the DIF VIF Micro Panel. I named it that because this is where you can micro-manage the data blocks.

DIF VIF Micro Panel

The DIF VIF Micro Panel is divided into three sections: the DIF and DIFE Definition, the VIF and VIFE Definition, and the Data Definition.

DIF and DIFE DefinitionThe DIF defines the size and type of data in the data block, which means it indicates how many data bytes there are and if they are ASCII or HEX or BCD or whatever. It also defines special cases and storage requirements and a little of the meaning. The DIFE(s) indicate more data about storage

• DIF Enable has selectable settingso Off – Disables the DIF and DB row entirely.o Standard DIF sets up a standard data block and the DIF configuration is in parts below.o Special Func. allows the use of a special data block. These data blocks do not follow the

normal DIF/DIFE/VIF/VIFE format and have special meanings. These Special Function DIFs are defined as follows:

0x0F - Mfg Data – The rest of the packet is user-defined data and a canned ASCII string will be used by M-Bus Tool to fill this data in.

0x1F - Mfg Data Plus - The rest of the packet is user-defined data and a canned ASCII string will be used by M-Bus Tool to fill this data in. This Special

Type is also an indicator to the meter to ask for another packet of additional data.

0x2F - Idle Filler, This is just a filler byte and it indicates that the next data block starts with the next byte.

0x3F, 0x4F, 0x5F, or 0x6F – Reserved - These Special Function DIFs are undefined in the M-Bus specification and are reserved for future use. M-Bus Tool will just place the selected DIF in the packet and add no data.

0x7F - Global Readout Request – I have not known what to do with this other than to just place the selected DIF in the packet and add no data. I believe it is supposed to prompt the meter to do a “Global Readout”, but our meter does not react to it.

• Use DIFE - This button signals the use of the first DIFE. If “No”, then there will be no DIFE’s included in this data block. If “Yes”, then there will be a DIFE added and the Bit 7 of the DIF will be set. The first DIFE may indicate more DIFE’s, up to 10 total.

• Storage Bit – This is a 1 or 0, usually 0. It has no bearing on M-Bus Tool function other than to set a bit in the DIF. This will be Bit 6 of the DIF.

• Function – There are four Function settings, and they are encoded in bits 4 and 5 of the DIF.o 0x00 - Inst. Value – Indicates that this is an instantaneous value.o 0x01 - Max Value – Historical maximum value.o 0x10 - Min Value – Historical minimum value.o 0x11 - Error Value – Value related to an error condition.

• DIF Data Type – The lower nibble of the DIF is the data type indicating the size and usage of the data in this data block. It is pretty much self-explanatory except:

o Selection for Readout – M-Bus rool just inserts two bytes randomized data, ando Variable String - The first byte of data is the number of bytes of ASCII in the string. The

length of the string can be set in the data section of the DIF VIF Micro Panel. The data itself is from a canned ASCII string.

• DIFE Configuration – You can set select to add up to ten DIFE’s to the data block, and they will be defined here. For the “More DIFE” button, “Yes” indicates another DIFE will follow, making it possible to add multiple DIFEs. The Unit, Tariff, and Storage Number values are definable but have no real meaning to M-Bus Tool or the meter.

VIF and VIFE DefinitionThe VIF’s primary function is to define the meaning of the data in the data block.

• Use VIFE - If “No”, then there will be no VIFE’s included in this data block, if “Yes”, then there will be a VIFE added, and that VIFE may indicate more VIFE’s. This setting will be overridden if an extension VIF is used.

• Primary VIF Range – Many VIFs use 2 or 3 bits of the VIF to indicate the range or granularity of the indicated measurement. Rather than create many more VIFs in the pull-down, the M-Bus tool allows you to set that range or granularity here. If the selected VIF uses some bits for range or granularity, they will be extracted from this setting.

• Primary VIF – This is where you would select the standard VIF. Most VIFs are un-interesting, just select the ones you want. There are some special VIFs though:

o 0x6C – Type G time-point - The M-Bus Tool will generate a 2-byte date time-point based on the PC RTC and any programmed time skews will be applied.

o 0x6D – Type F, I, or J time-point - The size indicated by the DIF will indicate the format type; 4 bytes is Type F, 6 bytes is Type I, and 3 bytes is Type J. The M-Bus Tool will generate a time-point based on the PC RTC and any programmed time skews will be applied. Some time-point formats incorporate settings from the six controls just above the “Quit” button on this panel. Those controls will be enabled if this VIF is selected.

o 0x79 - Identification (Enhanced) - This data type will repeat much of the data from the 12-byte Variable Packet header. It is needed for decryption of M-Bys packets if

encryption is applied. The data will be automatically stuffed at the time of use. This VIF requires the DIF to indicate an 8-byte integer.

o 0xFB – Extension VIF 2 - M-Bus Tool will place 0xFB for the VIF and the next byte in the packet will be the Extended VIF 2 byte. This Extension VIF 2 byte can be selected below the Primary VIF selection.

o 0xFD – Extension VIF 1 - M-Bus Tool will place 0xFD for the VIF and the next byte in the packet will be the Extended VIF 1 byte. The Extension VIF 1 byte can be selected below the Primary VIF selection.

• Use Extended VIFE button - This setting only used if an Extended VIF is being used, and it will be used on the extended VIF byte. If “No”, then there will be no further VIFE’s included in this data block. If “Yes”, then there will be a VIFE added, and that VIFE may indicate more VIFE’s.

• Extension VIF 1 – As discussed above, this selection is used if the Primary VIF is 0xFD.• Extension VIF 2 – As discussed above, this selection is used if the Primary VIF is 0xFB• Volt & Amp Range – This 4-bit setting applies to some Extension 1 VIFs. The range is 0 to 15.• VIFE Configuration – There are ten VIFE configurations, all pretty much the same. Each has

two settings:o More VIFE – “Yes” indicates another VIFE to follow, and o VIFE, which is definable but has no real meaning.

Data DefinitionData for DBThis is a large text window that displays the data that currently will be placed into the data block. The data in this window will be automatically modified as DIF and VIF settings are selected. For normal data, the bytes of data will be randomly set. Using the mouse to right-click on this display will re-randomize the data.

Left-clicking on this display will clear it and allow manual entry of desired data. Type in data in hex format. Include no spaces, or the typed data will be tossed and reverted to what it was. Excess data will be truncated to the correct number of bytes. Insufficient data will be padded with previous data to the correct number of bytes. To re-enter the data, first left-click on another control, then left-click on the display again.

DB Data Size For variable-sized data, this number defines the length of the data. The size of the data will be first a number of following bytes, then that number of ASCII characters. The string used for those characters is hard-coded and cannot be changed.

Time Skew in SecondsThis time skew applies only to this data block but it covers to all time-point data types. Value can be positive or negative. This skew is added to the PC time.

If this value is non-zero, it takes precedence over the time skew in the Device Config Panel.

Truncate Time ToTruncation applies only to this data block but it covers all time-point data types. The time used is PC time plus Time Skew, and then truncated to indicated granularity.

This control is for use when it is desired to have the time-point set to a time earlier than the current or skewed, but close to it. Can be set to various time increments:

• None: No truncation• Minute: Truncate time to the previous minute• 15 Minutes: Truncate to previous quarter hour• 30 Minutes: Truncate to previous half hour• Hour: Truncate to previous hour

• 12 hours: Truncate to previous half day• Day: Truncate to 12 midnight

Day of WeekThis control is enabled if VIF 0x6D is selected. It only impacts Type I Time-point and sets the Way of the Week for that Time-point.

Week NumberThis control is enabled if VIF 0x6D is selected. It only impacts Type I Time-point and sets the week number in the year for that Time-point.

DST SkewThis control is enabled if VIF 0x6D is selected. It only impacts Type I Time-point and sets the number of hours for DST skew. This has no actual impact on the time used, it is merely bit settings for the Type I formatted data.

L-YearThis control is enabled if VIF 0x6D is selected. It only impacts Type I Time-point and indicates if the current year is a leap-year.

DSTThis control is enabled if VIF 0x6D is selected. It only impacts Type I and Type F Time-point and sets the “DST Active” bit for that Time-point.

ValidThis control is enabled if VIF 0x6D is selected. It only impacts Type I and Type F Time-point and sets the “Time-point Valid” bit for that Time-point.

Encryption TestingEncryption SetupThere is an M-Bus encryption key in the meter for each registered M-Bus device. It is located in MT13 in the “Security Key section. The “Security Key Length” needs to be set to 0x08 and the eight security key bytes are entered in hex. Please note that, for security reasons, the MT13 security key cannot be read from the meter, they will always show up as all 0x00. Please note also that each device in the meter has its own M-Bus security key in MT13.

The encryption keys in M-Bus Tool are set in the Device Configuration Panel as eight hex bytes and should match the MT13 encryption keys. Please note that Device 1 in the M-Bus Tool is not necessarily Device 0 in the meter, as the correlation is done by M-Bus address, and any M-Bus Tool device can have any address.

To start or stop the encryption of data on an M-Bus Tool device, set “Encryption Method” for the device to use encryption. The selectable options are:

• No Encryption – Causes normal default M-Bus packets, where no encryption is used. The “Signature” in variable length packets is 0x00 0x00.

• Type 0x02 – This is a lower level of encryption and it requires both an Enhanced ID as the first data block in the data field and a G-format date somewhere in data field, date matching meter time. The “Signature” in variable length packets will be the number of encrypted bytes and 0x02.

• Type 0x03 – This is a higher level of encryption, and it requires an Enhanced ID data block to be somewhere in the data field. Since, with this encryption type, the date is used for encryption, there is no need to replicate that data in the data fields. The “Signature” in variable length packets will be the number of encrypted bytes and 0x03.

• Random Signature – This is not a valid encryption, it is used for negative testing only. This will stick a random number in the “Signature” and cause the meter to fail encryption.

For M-Bus encryption to work, you will need to synchronize time between the meter and the PC running the M-Bus Tool. The M-Bus Tool keys timestamps to the PC’s RTC, and is the meter and PC have times too dissimilar, the decryption may fail. There is some forgiveness around the meters midnight time, to allow for small differences in when the date changes.

Setting up Defined Data BlocksIf you use old-style variable length frames, the data setup for encryption has always worked and still does.

However, if you use Defined Variable Frames on the device, you must create data blocks to allow encryption to work.

• There must be an Identification (Enhanced) block in the packet. Select DIF = 0x07 and VIF = 0x79. The M-Bus Tool will take care of creating the correct data with the SN, Mfg ID, Version, and Meter Type for this data block. For Type 0x02 encryption, this data block must be the first data block in the data field.

• For type 0x02 encryption, there must be data block a G-format date data block somewhere in the packet. This data block has a DIF = x02 and VIF = 0x6C. The M-Bus Tool will insert the PC’s current time and apply time skews as configured.

• After those two blocks you can use any data types you wish.• If you use multiple variable length packets, these first two data blocks must be repeated in each

packet.

What to look for in M-Bus Tool’s dataIn the M-Bus tool display, the M-Bus encrypted packet is displayed when it is sent. The standard header, C Byte, Address Byte, CI Byte, and 12-byte header will all be unencrypted. The last byte of the 12-byte header defines the encryption type.

The second-to-last byte of the 12-byte header is the number of bytes encrypted. Since the encryption works on 8 bytes at a time, so this length byte will be a multiple of 8. The number of bytes encrypted may be less than the number of data bytes, In this case, the remaining data bytes are left un-encrypted. You can append additional data bytes by adding special DIFs of 0x2F to make the data length an even multiple of 8.

Check MT16 to verify proper decryption of the data, look for the following:• MT16 Key Availability should be “Decryption Occurred as Necessary”• MT16 Authentication Status Passed• MT16 Security Status Passed• MT16 Signature reflects the encryption type and length• MT16 Data Records contains unencrypted data

5. Log files on diskThere are several disk files created by the M-Bus Tool during operation. These fall into two classes: Configuration files for use by M-Bus Tool and event logging files for use by the user. There is a “Clear Log Files” button on the mail panel that will zero-out the log files when resetting them is desired.

The two configuration files are:- MbusDevice.cfg – This is where the configurations for the four devices are stored. - MbusTool.cfg – This is where the program settings not related to the devices is stored.

The log files are:- axarray.txt – This file will be cleared by the “Clear Log Files” Button. It is intended aid

in determining how well the Axe Drop function was working. A count of echoed bytes if kept while the meter is powering down. That total is recorded here every time the Axe Drop function is used.

- DiddleMEP.txt - This is the log file for the Diddle MEP function. It logs communications during address or baud rate changes. This file is not cleared by by the “Clear Log Files” Button.

- EnterDB.txt – This file is for debugging packet-stuffing issues and was used during development. It should not be created or added to during normal program usage. It should only get written to if the “ExtraDebug” flag is set true, and that flag can only be set at compile time, not normal runtime.

- ExcelConfigFile.txt - This is a comma-delimited text file containing all four M-Bus device configurations. It can be imported into an Excel spreadsheet and it provides a handy reference when verifying packet and/or PT content. This file is overwritten with fresh data every time the “Comma Delimited txt File” button gets clicked.

- FindMe.txt – This file is cleared by the “Clear Log Files” Button, it is a log file for the “Find M-Bus Device” function.

- MBusPackets.txt – This file contains a list of currently programmed data blocks in the DIF VIF list. It file is overwritten with fresh data every time the “M-Bus Packet File” button gets clicked. This is a handy way to get a list of what the M-Bus billing read packets should look like.

- PassData.txt – This file is cleared by the “Clear Log Files” Button. It is the log file for the “M-Bus Pass Through” function.

- ReadLog.txt – This file is cleared by the “Clear Log Files” Button. It is a log file of billing read times. Every time there is a billing read to an M-Bus device in Spoofer mode, an entry is made her of which device got the request, what time, and how long it had been since the previous billing read to that device. This is an easy way to track billing read timing over a long period. All timestamps are referenced to the PC clock. Be aware that if the meter is attached to a DC with a different time, the periodic time adjustments from the DC will throw off the time between reads.

- SpecialError.txt - This file is a log of any conditions that cause the “Special Error” LED to turn red. These conditions are: Packet from meter has checksum error, packet from meter has mismatched L-Bytes, packet from meter has incorrect bit-order on Time Sync, or Health Timer violation. This list could probably be expanded if desired, if it was desired to track other error conditions.

- SpoofData.txt – This file is cleared by “Clear Log Files” Button. SpoofData.txt is the main log file in spoofer mode. All communications in spoofer mode get recorded here even if they are also recorded in other locations.

6. Remote Control of M-Bus ToolWhen the M-Bus tool is started, it creates two telnet servers on the host machine. These servers are designed to allow control and monitoring of M-Bus tool from another system or program. Access to these telnet servers can be gained via any telnet client. From the DOS shell, one can simply type at the command prompt: telnet IPaddr Port, where “IPaddr” is the IP address of the PC running M-Bus Tool and “Port” is the port number of the server.

When M-Bus Tool is started, the IP address of the PC running it is shown on the display for easy reference. If the telnet is being done from the same PC that is running M-Bus Tool, you can use the self-ID of 127.0.0.1 for the IP address.

The two server ports created by the M-Bus Tool are 1000 for the Command Port, and 1001 for the Activity Port.

Since much of companies design verification is based on a tcl library of scripts and utilities, the intention of these telnet servers was to allow access to M-Bus Tool from tcl telnet clients. However, there is no reason other systems could not utilize these interfaces.

The first telnet server set up by the M-Bus Tool is the Command server. It is port 1000, and a telnet here creates a dialog session for sending commands to M-Bus tool regarding setups and actions to be taken.

The second telnet server set up by the M-Bus Tool is the Activity server. It is port 1001, and a telnet here sets up a channel on which the M-Bus Tool can report ongoing M-Bus activity it sees and/or responds to.

There are two LED indicators on the main panel that indicate active telnets, one each for the command and activity ports. Red means no active telnet session, green indicates an active telnet session.

There is a “Disconnect” button between the LED indicators. Clicking this button forcibly terminates the tenet sessions. This can be useful if your tcl script crashed leaving the telnets active.

6.1. CommandsIn all commands referring to a port number, that number refers to the M-Bus device number in the M-Bus Tool, not the M-Bus address or the meter device number. Note that the port number in the M-Bus Tool is not linked to the M-Bus address it is using.

When AutoDiscovering a new device, the meter frequently does not assign a new M-Bus device the very next available M-Bus address, there is no way to guarantee the ordering of devices. Using the “set” commands, it is possible to re-order addresses after discovery if desired

New commands can be added to the telnet interface upon request, time permitting. I will happily take requests for new features. There are some newer features in M-Bus Tool for which there are no telnet controls yet, for instance there are currently no commands for defining the data blocks of Defined Variable Length packets. New commands will require a small amount of new code in the M-Bus Tool and a new release. The way the command interface is structured allows for easy addition of new commands.

The following is a list of currently supported commands:• disconnect command - Makes the M-Bus Tool disconnect the telnets from its end• startspoofer command - Causes the M-Bus tool to start the spoofer mode. This command does

essentially the same thing as clicking the “Start M-Bus Spoofer” button, pawning a chld process to run the spoofer function. If this command is sent while the M-Bus Tool is already in spoofing mode, M-Bus Tool will so inform you.

• endspoofer command – This command terminates spoofing mode in the M-Bus Tool. It does the same thing as clicking the “Stop” button, just clearing a flag to allow the loop to expire.

• help command – This is the basic “help” command and it returns a list of commands that can be used. There are two help commands that return sets of additional commands:

o set help - Returns a list of commands and syntax for setting things in M-Bus Tool.o error help - Returns a list of controls for error injection.

The “set” commands are used to set up parameters for simulated M-Bus devices. All of these settings have analogous settings in the Device Configuration panel.

• set DeviceEnable <port 1 to 4> <on/off> - Enable/Disable M-Bus Tool device• set DeviceAddr <port 1 to 4> <0 to 4 or 250> - Set the address of an M-Bus Tool device• set MeterType <port 1 to 4> <0 to 19> - Set the variable length frame Meter Type• set FixedMeterType <port 1 to 4> <0 to 15> - Set the variable length frame Meter Type• set AppError <port 1 to 4> <0 to 3> - Sets the two LSB bits of the alarm byte in the M-Bus

billing read packet• set DeviceBaud <port 1 to 4> <baud rate> - Sets the baud rate the selected M-Bus Tool device

will communicate at• set PowerLow <port 1 to 4> <on/off> - Sets bit 2 of the alarm byte in the M-Bus billing read

packet• set PermError <port 1 to 4> <on/off> - Sets bit 3 of the alarm byte in the M-Bus billing read

packet• set TempError <port 1 to 4> <on/off> - Sets bit 4 of the alarm byte in the M-Bus billing read

packet

• set MfgSpecStat <port 1 to 4> <0 to 7> - Sets the three MSB bits of the alarm byte in the M-Bus billing read packet

• set PhysUnits1 <port 1 to 4> <0 to 63> - Sets the Fixed Length Physical Unit 1 value for the selected M-Bus Tool device

• set PhysUnits2 <port 1 to 4> <0 to 63> - Sets the Fixed Length Physical Unit 2 value for the selected M-Bus Tool device

• set VIF1 <port 1 to 4> <0 to 255> - Sets the Load Profile packet VIF1 value for the selected M-Bus Tool device

• set VIF2 <port 1 to 4> <0 to 255> - Sets the Load Profile packet VIF2 value for the selected M-Bus Tool device

• set FrameType <port 1 to 4> <0 to 4 or 10 or 11> - Sets the frame type for the billing read packet on an M-Bus Tool device. Supported types are:

o 0 – Fixed Length Frameo 1 – Single Variable Lengtho 2 – Two Variable Lengtho 3 – Three Variable Lengtho 4 – Four Variable Lengtho 10 – Ten Variable Lengtho 11 – General Application Error frameThere are two types currently in use by the M-Bus Tool that are not supported by the telnet interface. There has not yet been a need to add them, but these types could and should be added to the telnet interface.o 20 – Don’t respond to REQ_UD2o 21 – Defined Variable Packet

• set PacketSize <port 1 to 4> <12 to 234> - Sets the packet size for undefined Variable Length Frames to this number.

• set DataOrder <port 1 to 4> <lsb/msb> - Sets the “msb” or “lsb” byte ordering of the packets• set FillerBytes <port 1 to 4> <0 to 10> - Sets the number of 0x2F filler bytes to pad the data

with.• set EnableEncryption <port 1 to 4> <0 or 2 or 3> - Sets the type of M-Bus encryption to use

The “error” commands are used to set up parameters for error injection on simulated M-Bus devices. All of these settings have analogous settings in the Device Configuration panel.

• error GoodFrames <port 1 to 4> <0 to 255> - Sets the number of frames to let pass before beginning error injection.

• error BadFrames <port 1 to 4> <0 to 255> - Sets the number of frames to inject errors into.• error AbortedResponse <port 1 to 4> <type> - Sets the type of aborted response to be injected.

Valid settings for type are:o NormalResponse o NoResponse o HeaderOnly o HalfFrame o MissngStopByte o MissingChecksum

• error ParityError <port 1 to 4> <EvenParity OddParity NoParity> - Sets the type of parity problem to inject. Note; parity injection has never worked.

• error LeadingGibberish <port 1 to 4> <0 to 10> - Sets the number of random bytes to precede the M-Bus packet with.

• error FollowingGibberish <port 1 to 4> <0 to 10> - Sets the number of random bytes to append to the M-Bus packet.

• error ChecksumError <port 1 to 4> <setting> - Modifies the checksum on the M-Bus packet. Valid settings are;

o NoError o AddOne - add one to the checksumo AddTwo - add two to the checksumo SubtractOne - subtract one from the checksumo SubtractTwo - subtract two from the checksumo NULL – replace the checksum with 0x00

• error LByte1 <port 1 to 4> <CorrectValue or -10 to 10> - Number of bytes to subtract or add to the first L-Byte in the M-Bus packet.

• error LByte2 <port 1 to 4> <CorrectValue or -10 to 10> - Number of bytes to subtract or add to the second L-Byte in the M-Bus packet.

• error StartSign1 <port 1 to 4> <Setting> - Modify the first start sign of the M-Bus packet. Valid settings are;

o Normalo OneUp - use 0x69o OneDown - use 0x67o E5 – use 0xE5o Null – use 0x00

• error StartSign2 <port 1 to 4> <Setting>> - Modify the second start sign of the M-Bus packet. Valid settings are;

o Normalo OneUp - use 0x69o OneDown - use 0x67o E5 – use 0xE5o Null – use 0x00

• error StopSign <port 1 to 4> <Normal, StartSign, OneUp, OneDown, E5, Null>> - Modify the first start sign of the M-Bus packet. Valid settings are;

o Normalo StartSign – use 0x68o OneUp - use 0x17o OneDown - use 0x15o E5 – use 0xE5o Null – use 0x00

• error IncorrectResponse <port 1 to 4> <setting> - Substitute different response typeo Normalo E5forStatus – Send a 0xE5 response when a Variable Length Frame is called foro StatusforE5– Send a Variable Length Frame response when a 0xE5 is called for

Activity telnet data sampleWhen the Activity telnet is opened, all activity on the M-Bus gets copied to the telnet activity monitor port. If the telnet is not open it has no affect on M-Bus Tool operation. All data is sent as hex values separated by space characters. These strings can be handled by tcl as lists very easily.

0xE5 acknowledgements will not be displayed.

Here is a sample SND_NKE (ping) followed by a REQ_UD2 and response.

10 40 03 43 16

10 7b 03 7e 16

68 67 67 68 08 03 72 33 13 13 33 34 12 01 00 01

00 00 00 07 79 33 13 13 33 34 12 01 00 02 6c 52

12 0c 7a 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31

32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41

42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50 51

52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60 61

62 63 64 65 66 67 68 69 6a 6b 6c 60 16

This packet had a total length of 109 bytes.

7. Appendix A – tcl Scripting Examples7.1. A good sample of tcl control of the M-Bus Tool would be the M-Bus scripts 9875 through 9881

7.1.1. Examples of AutoDiscover of one and four M-Bus devices7.1.2. Examples of opening and closing telnets7.1.3. Examples of sending setup commands to M-Bus Tool7.1.4. Examples of parsing data from the Activity Telnet for specific frames and devices7.1.5. Examples of using the relay board to control the meter button

7.2. Setting up the Data set Script(spoof,ip) 127.0.0.1 set Script(spoof,portCmd) 1000 set Script(spoof,portData) 1001

7.3. Opening the Telnet Sessionsforeach port [list $Script(spoof,portCmd) $Script(spoof,portData)] name {Command Activity} {

set Step(id) S[incr step]set Step(descr) "Open Spoofer $name Port <$port>"set Step(func) socketset Step(param) [list $Script(spoof,ip) $port]set Script($name) [miscExecuteStep $Step(id) $Step(descr) $Step(func) $Step(param) {} 0]set Step(id) S[incr step]set Step(descr) "Configure Spoofer Command Port <$port>"set Step(func) fconfigureset Step(param) [list $Script($name) -buffering none -blocking 0 -encoding binary -translation binary -eofchar {}]miscExecuteStep $Step(id) $Step(descr) $Step(func) $Step(param) -1 0

}

7.4. Starting Spoofer Modeputs $Script(Command) "startspoofer\r"miscWait 1

7.5. Disabling all devices in M_Bus Toolputs $Script(Command) "set DeviceEnable 1 off\r"puts $Script(Command) "set DeviceEnable 2 off\r"puts $Script(Command) "set DeviceEnable 3 off\r"puts $Script(Command) "set DeviceEnable 4 off\r"

7.6. AutoDiscovery of four M-Bus Tool Devices# For each device number,.....for {set DevNum 1} {$DevNum <= 4} {incr DevNum} { powerOutputData "Adding device #$DevNum" $Script(debugfile) 1

# Prepare and enable that device in the spoofer, address 0 puts $Script(Command) "set DeviceBaud $DevNum 2400\r" puts $Script(Command) "set DeviceAddr $DevNum 0\r" puts $Script(Command) "set DeviceEnable $DevNum on\r"# Pause 2 seconds while monitoring the Spoofer activity set timer2 [clock seconds] while {[clock seconds] < [expr {$timer2 + 2}]} { set data [read $Script(Activity) 4096] if {[string length $data]} { powerOutputData "Got3 - $data\r\n" $Script(debugfile) 1 } }

# We will allow 90 seconds for this device to be seen and accepted. set timer [clock seconds] while {[clock seconds] < [expr {$timer + 90}]} { set data [read $Script(Activity) 4096] if {[string length $data]} { powerOutputData "GOt - $data\r\n" $Script(debugfile) 1# Check is this packet is a request for status read from address 0 set byte1 [string compare [lindex $data 0] 10] set byte2 [string compare [lindex $data 1] 7b] set byte3 [string compare [lindex $data 2] 00] set StatusByte [expr {$byte1 | $byte2 | $byte3}] if {$StatusByte == 0} {# Pause for a few seconds, just 'cause, but monitor spoofer anyway. set timer2 [clock seconds] while {[clock seconds] < [expr {$timer2 + 6}]} { set data [read $Script(Activity) 4096] if {[string length $data]} { powerOutputData "-1- $data\r\n" $Script(debugfile) 1 } }

# Push button for 6 seconds to accept the device. relay::cmd::setRelay $Script(PushButton) 1 set timer2 [clock seconds] while {[clock seconds] < [expr {$timer2 + 6}]} { set data [read $Script(Activity) 4096] if {[string length $data]} { powerOutputData "-2- $data\r\n" $Script(debugfile) 1 } } relay::cmd::setRelay $Script(PushButton) 0 }

# Check if this is an address change request set byte1 [string compare [lindex $data 0] 68] set byte2 [string compare [lindex $data 1] 06] set byte3 [string compare [lindex $data 4] 73] set byte4 [string compare [lindex $data 5] 00] set byte5 [string compare [lindex $data 6] 51] set byte6 [string compare [lindex $data 7] 01] set byte7 [string compare [lindex $data 8] 7a] set bytesum [expr {$byte1 | $byte2 | $byte3 | $byte4 | $byte5 | $byte6 | $byte7}] if {$bytesum == 0} {# If it is an address change request, set array value to indicate this address is now used. set DevOccupancy([lindex $data 9]) 1# Setting the timer to 0 makes the loop complete early. set timer 0 } } }# Show me devices what are now used.

powerOutputData "Device Occupancy = $DevOccupancy(01) $DevOccupancy(02) $DevOccupancy(03) $DevOccupancy(04)" $Script(debugfile) 1 }

# If not all devices are recognized, generate a failure. if {$DevOccupancy(01) == 0} { powerOutputStepError "MEP Device #1 never recognized" $Script(debugfile) return 0 } if {$DevOccupancy(02) == 0} { powerOutputStepError "MEP Device #2 never recognized" $Script(debugfile) return 0 } if {$DevOccupancy(03) == 0} { powerOutputStepError "MEP Device #3 never recognized" $Script(debugfile) return 0 } if {$DevOccupancy(04) == 0} { powerOutputStepError "MEP Device #4 never recognized" $Script(debugfile) return 0 }

7.7. Looking for a Time Sync packet sent to four M-Bus Tool devices# We will allow 30 seconds for the time syncs to appear set timer [clock seconds] while {[clock seconds] < [expr {$timer + 30}]} { set data [read $Script(Activity) 4096] if {[string length $data]} { powerOutputData "goT - $data\r\n" $Script(debugfile) 1# Is this a time sync packet? set byte1 [string compare [lindex $data 0] 68] set byte2 [string compare [lindex $data 1] 09] set byte3 [string compare [lindex $data 4] 73] set byte4 [string compare [lindex $data 7] 04] set byte5 [string compare [lindex $data 8] 6d] set byte6 [expr {[string compare [lindex $data 6] 55] & [string compare [lindex $data 6] 51]}] set bytesum [expr {$byte1 | $byte2 | $byte3 | $byte4 | $byte5 | $byte6}] if {$bytesum == 0} {# Mark this one as seen set DevTime([lindex $data 5]) 1 } } }

# Show and check that all devices got a time sync. powerOutputData "Devices that got time sync after AutoDiscovery = $DevTime(01) $DevTime(02) $DevTime(03) $DevTime(04)" $Script(debugfile) 1 if {$DevTime(01) == 0} { powerOutputStepError "MEP Device #1 never got time sync packet after AutoDiscovery" $Script(debugfile) return 0 } if {$DevTime(02) == 0} { powerOutputStepError "MEP Device #2 never got time sync packet after AutoDiscovery" $Script(debugfile) return 0 } if {$DevTime(03) == 0} { powerOutputStepError "MEP Device #3 never got time sync packet after AutoDiscovery" $Script(debugfile) return 0 } if {$DevTime(04) == 0} { powerOutputStepError "MEP Device #4 never got time sync packet after AutoDiscovery" $Script(debugfile) return 0 }