Monthly Archives: April 2017

MSTP message delay guarantee

Posted on by

There are 2 types of BACnet service: unconfirmed and confirmed. The sender(client) of confirmed service request will wait for reply until timeout expires.

Usually there are no side effect of excess message delay for unconfirmed service. For confirmed service request or reply,  excess message delay will result in poor network performance, because the service reply will be dropped by client due to timeout.

Furthermore, too late reply for confirmed service will cause application logic wrong. Each confirmed service request has a invokeID, the reply message carries same invokeID. The value range of invokeID is 0~255. On a busy client, the invokeID will be exhausted and re-used soon. if the invokeID of a delayed confirmed service reply is re-used by another service, the reply will be regarded as replying to later one. For exmaple:

  • Client send WriteProperty service A to device X object Y property Z. The invokeID is 0.  The request or reply messages is delayed.
  • Client waits until timeout expires. Service A fails so invokeID 0 is reclaimed.
  • Client send WriteProperty service B to device X object U property V. The invokeID 0 is chosed.
  • Reply for service A is arrived, because its invokeID is same as service B, client believes that service B success.

For high speed data link type as Ethernet or IP, the message delay is neglect-able, but for MSTP, there are several possible reasons for excess message delay:

  1. Signal noise.
  2. Incorrect/improper device configuration(baudrate, max-master, max_info_frames)
  3. Excess traffic.
  4. Slow device

To avoid invokeID conflict and improve network performance, BACRouter with firmware version >=2.0 implements message delay guarantee of 10 seconds (It is changed to 6 seconds from v4.17 respecting BACnet default APDU_Timeout). Messages which could not be sent within the delay will be dropped by BACRouter.

Fixed/Auto/Forced baudrate for MSTP

Posted on by

Update on 2020-11-20 (Appended info. about JCI module)

MSTP baudrate is always painful for field technician. If the baudrate is wrong, device can’t join a MSTP bus.

Most devices have fixed baudrate. To modify the baudrate setting, technician have to physically access the device and change dip switches. Some devices support changing baudrate by BACnet service. but before that they should already have correctly baudrate setting for BACnet service to access it.

Some vendors implement auto baudrate, but introduce more problem than it solves. There are two types of auto baudrate mechanism:

  • Starting detection: The device detects and adopts baudrate on the bus when it starts. then never changes baudrate.
  • Dynamic detection: The device does same as starting detection type when it starts, but if it find there are error on bus for a predefined time, it considers that the baudrate is changed, it detects baudrate again.

For both types, it is difficult to change baudrate when devices is working. Simply changing baudrate on all fixed baudrate devices can not work, because auto baudrate devices are still working on old baudrate. The solution is to power off all auto baudrate devices, then power on all auto baudrate devices（Don’t power off/on auto baudrate devices one by one)

Our new firmware(>=2.0) introduces new baudrate management mechanism(Patent pending). There are 3 types of baudrate mode for BACRouter : Fixed/Auto/Force:

  • Fixed baudrate mode works as most traditional devices.
  • Auto baudrate mode is same as above-mentioned dynamic detection. The predefined time to re-initiate detection is 10 error frames, it usually take several seconds.
  • Forced baudrate mode is same as auto mode except that when the device get token, it changes baudrate to predefined value.

When there is a device with forced baudrate mode, the baudrate on the bus will be forced to predefined value. Devices with auto baudrate mode will automatically synchronize to predefined baudrate. Devices with fixed baudrate mode but baudrate setting different with predefined value will not be seen on bus (It’s easy to check out in “Recent active devices” field from BACRouter’s runtime info). Devices with starting detection type may run on wrong baudrate, they will not be seen on bus too, but powering off/on them one by one will synchronize them to forced value.

More than one device with forced baudrate mode could coexist on a bus, but the baudrate values on them should be same.

JCI FEC/IOM modules implements baudrate dynamic detection mechanism, the re-detect interval is about 150 sec on the test.

On a test bus , BACRouter cooperate perfectly with FEC2611, IOM3731,  the baudrate is dynamically controlled by BACRouter from 9.6k ~ 76.8k, FEC2611 and IOM3731 will catch up after 2.5 minutes.