Page
35
of
60
©
2019 Radiocrafts AS
MBUS User Manual (ver 2.01)
MBUS USER MANUAL
Due to the long range of the N mode, a large number of meters are expected to be handled by one single master.
Hence the MBUS4 Master is designed to support more than 1000 meters. Several mechanisms are used to
achieve this (patented):
•
128 slaves can be registered in non-volatile memory Address and Key Registers, with corresponding Flag Register
supporting auto-message generation
•
4 slaves can be registered in volatile memory Address and Key Registers (no write cycle limitations), with
corresponding Flag register supporting auto-message generation
•
122 slaves can be registered in non-volatile memory Address and Key Registers, but without corresponding Flag
register.
•
An “infinite” number of slaves can be supported through a special protocol between the module and the host. In this
case, the host must store the Addresses and Keys.
The auto-message generator can be used for the 128 slaves in non-volatile memory, and the 4 slaves in volatile
memory, by using the Flag Register. The 4 slaves in volatile memory can be registered by “b” and “k” command,
and can be listed using the “l” command. The Flag Register can be access by “a” and “o” command (they are also
mapped as Flag Registers 129-
132 using the “A” and “O” command. Note, non-volatile registers 129-132 should
not be used.
The 122 slaves (registers 133 to 254) in non-volatile memory without corresponding Flag Register are using
ENCRYPT_FLAG and DECRYPT_FLAG in configuration memory for enabling encryption and decryption,
respectively. Incoming messages from these Slaves can be decrypted using the registered key if the decrypt flag is
set. But note that the auto-message generation of standard or mailbox messages are not possible for these slaves.
However using the special protocol to the host, it is still possible to respond to these slaves with the correct
response time as handled by the module.
An “infinite” number of slaves can be supported in the host, only limited by the memory and processing power of
the host controller, interacting with the module over a special protocol. The master module is still handling the
response timing and message encryption. The same protocol can be used for the 122 slaves without flag registers.
When a slave message is received, the master module will search for the slave address in the Address register. If
the slave was registered, the message will be decrypted before sent to the host (if decryption was enabled in the
individual Flag register or by the DECRYPT_FLAG). If the slave address was not found, the (still encrypted)
message is sent to the host. The host may now send a Key (“Key challenge” using 0xFC) to the module, and the
module will decrypt the message using this Key, and send the decrypted message to the host. Further, the host
may now send a new message to the module. This message will be encrypted using the previously transferred Key
challenge, or the Key already registered in the module (as for the 122 slaves). If a Key challenge was not sent, a
Key may be sent to the module after the message was transferred. The fast/slow timing of the response is handled
by the module. If no response is to be sent, the host may terminate the response cycle by sending the 0xFB
command.
The “Key challenge”, or the Key following the message, is sent to the module using the 0xFC command (instead of
length byte) followed by the 16 Key bytes.
Using this special protocol, the timing is important. When the Slave expect a fast response, they Key challenge,
new message (and following key), must be transferred to the module within 90 ms. If a slow response is used,
within 1090/2090 ms. It is recommended to use a UART Baud rate of minimum 115 kBd to meet these timing
requirements.
If a message is sent to the module during the response time cycle that does not match the last incoming message
address, the response time cycle is terminated and the message is sent as a normal message without further time
delay.
