Document toolboxDocument toolbox

17-5-21 Release 1259

Full support for the RailDAQ protocol when connected to Centrix

Historically the SA380TX has connected to Centrix using the MIMOSA protocol. More recently we've utilised a second connection using Mpec's RailDAQ protocol. This has allowed us to offer remote config and firmware updates, but with RCM data transferred over MIMOSA. As of release 1259, the TX will make exclusive use of the RailDAQ protocol when connected to Centrix.

How does it work?

The TX will automatically determine the type of server it is connected to (based on the headers from replies to MIMOSA messages).

What are the benefits?

  • Reduced load on the TX when it's building messages

  • Significantly reduced communications data volume

  • Data reaches Centrix faster

  • Easier channel configuration:

    • Channel names and units appear the same in Centrix as they do on the TX's configuration.

    • No need to map channels on Centrix

What do you need to do?

Typically, just upgrade your TX loggers to the new version of firmware, however there are a few things to watch out for:

Renamed channels on Centrix

If channels have been renamed in the channel mapping on Centrix, these should be updated in the logger's configuration to match. Failure to do this could break existing alarms, graphs, assets, etc. If in doubt please contact us for support.

Invalid channel names

Channels ending with space characters (typically seen on slave SA380 sites) must be renamed in the logger to remove this in order for data to be associated with the correct channel in Centrix.

Logger Contact Alarms

Logger contact alarms may be raise if they have been set up to be driven from the MIMOSA connection. These should be modified to use the RDAQ logger counterpart.

What's next?

We're working on improvements to time synchronisation between loggers on Centrix. This means better time alignment of data from different loggers.

Other changes

  • Various performance and stability improvements

  • Fixed a minor UI bug that occurred when the logger didn't have an ethernet IP address.

  • Fixed a rare issue where multiple events could occur on a channel at the same timestamp.