Firmware Status	LEGACY

Release 2685

Analogue Acquisition Changes

The acquire-on-change methodology has been enhanced to allow capture of "absolute" and "relative" changes in input signals. This was primarily done to accommodate EbiTrack 400 receivers.

Multiple EbiTrack 400 receivers can be configured on a device, with each receiver exhibiting very different levels of "track clear" current between 20 mA and 100 mA. A global absolute Acquire-on-Change setting was unable to capture enough information during the "track occupancy" phase, without gathering too much data in the "track clear" phase or vice-versa. This can be observed in the Centrix graphs below.

Obtaining quality data for GNF Rx results in too much data for FGC Rx

Obtaining quality data for FGC Rx results in poor data quality data for HRE Rx

Setting a "relative" change setting of 10% allows good quality data to be obtained during the "track occupied" state, whilst limiting the data collecting during the track clear phase. 10% was chosen, as it lies above the relativistic noise floor of the ITOT channel whilst the track is clear. The Centrix graph below demonstrates the enhanced data quality.

A new GUI element has been added to the config tool to allow the selection of "Absolute", or "Relative" acquire on change types.

To make the distinction clear between the two types of acquisition, and to provide continuity across the mpec product range:

Absolute Acquire-on-Change is specified in the engineering units of the sensor / channel
Relative Acquire-on-Change is specified in "Percent", e.g acquire a sample when the signal has changed by "x%". The engineering units are irrelevant.

The user guide extracts below explains the change in more detail.

Acquire-on-Change

All analogue input channels are continuously logged using a process known as “Acquire-on-change”.

A sample is acquired when the measured value changes by more than a certain amount.

If there is no change, there is no sample acquired.

Consider the following waveform. The acquired samples are shown as dots.

The waveform first changes at a fairly leisurely pace, then there is a spike. Each time the input changes significantly, a sample is acquired. It can be seen that more data points are acquired around the spike.

Acquire-on-change is an excellent match for many railway applications. Where there are long periods without much change, very little data is acquired. Where there is more detail in the waveform, more points are acquired.

After the data has been acquired it is possible to go back and just “join the dots” and we have an accurate representation of the entire waveform, with the minimum amount of data logged and transmitted.

Two methods of Acquire-on-Change are supported.

Absolute:

In absolute mode, a fresh sample is acquired each time the raw input signal changes by a fixed constant value, for example 5 mA.

E.g. If the last sample was acquired at 50 mA, the next sample will be acquired at +/- 5 mA, which is either 55 mA, or 45 mA. An absolute change of 5 mA is required to trigger the next acquisition.

The chart above shows how samples would be acquired along a straight line slope.

Absolute acquisition is a good fit where the minimum and maximum range of the input signal are well known and an even level of detail is required at all ranges.

Relative:

In relative mode, a fresh sample is acquired each time the raw input signal changes by a defined percentage since the previous acquisition. It is defined in percent, for example 5%.

E.g. If the last sample was acquired at 50 mA, the next sample will be acquired at +/- 5% of 50 mA, which is either 52.5 mA, or 47.5 mA. A relative change of 5% is required to trigger the next acquisition.

The chart above shows how samples would be acquired along a straight line slope.

Relative acquisition is a good fit where the minimum and maximum range of the input signal are not well known and where increased resolution is desired for small signals, at the expense of decreased resolution of large signals.

Example Applications for Acquire on Change:

Rail Temperature Monitoring
Track Circuit Monitoring
Overhead Line Force and Displacement Monitoring
Insulation Resistance Monitoring
Power Consumption Monitoring

See SA380TX-L Applications for more detail.

All unit configuration is performed using this screen.

Analogue

Analogue

Change Threshold

If Acq. Method is set to Relative, this number determines the percentage change relative to the last acquired value required to trigger the acquisition of a sample.

If Acq. Method is set to Absolute, this number governs the absolute change in signal level required to trigger acquisition of a sample.

For NR II DC track circuit monitoring a change threshold of 6 mA absolute has been suggested.

EBI Track

Change Settings

These settings dictate how sensitive the “Acquire-on-change” settings are for all monitored EbiTracks.

Parameter / Units - These fields are fixed for EbiTrack monitoring and cannot be changed

Change Threshold - Change the acquisition sensitivity of each channel in these fields.

- If Acq. Method is set to Relative, this number determines the percentage change relative to the last acquired value required to trigger the acquisition of a sample.

- If Acq. Method is set to Absolute, this number governs the absolute change in signal level required to trigger acquisition of a sample.

The default settings are suitable for NR II EbiTrack 200 applications.

Where EbiTrack 400 Receivers are to be monitored, it is suggested that IAVE is set to 10% Relative due to the variance in set-up current levels.

See SA380TX-L Unit Configuration for more detail

Server LED Indication Changes

The behaviour of the "Server LED" was incorrect when the SA380TX-L was set to use the "RailDAQ" protocol. The behaviour has been fixed and re-defined. This is explained in the user-guide extract below.

LED’s

The TX-L front panel features 8 LEDs.

The meaning of these LEDs is detailed in the table below:

LED	Indication	Meaning
LED	Indication	Meaning
Server	Steady On	Last transmission of sample data to the Central Data Server successful.
Server	Fast Blink**	Device is attempting to connect with the server.
Server	Slow Blink**	Transmission to the Central Data Server has recently failed. Device is now in FALLBACK and will retry shortly.
Server	Off	There is no data connection to the server
Comm	Steady On	Connected to the GSM or Ethernet Network
GSM	Steady Off	Modem is Powered Down or Network Registration Failed
GSM	Slow Flash	Searching for GSM Network (2 sec. on / 2 sec. off)
GSM	Flash	Registered with GSM Network (Quick Flash On / 2 sec. Off)
GSM	Steady On	Modem Fault
Master/Slave	Slow Alternating Flash (1 sec)	Normal Operation
Master/Slave	Fast Flash (0.25 sec)	Processor Sync Error*
Master/Slave	Steady On or Off	Processor Error
Storage	Blinking	Data Read/Write from database
Storage	Steady On	Database Error
Input	Blinking	Analogue or Digital Input Event Detected
RS485	Blinking	Data Transmit/Receive on RS485 Port

*It is normal to observe a “Processor Sync Error” during initial boot and during firmware upgrade.

** The table describes behaviour in MIMOSA protocol mode. In RailDAQ mode, the following behaviour is observed:

The server connection LED will not show fallback, as the timeout is short.
During Firmware upgrade over RailDAQ, the server LED will not illuminate.
If the device is not configured within Centrix, the server LED will not illuminate, as it cannot transmit samples.

See SA380TX-L Hardware for more detail

Bug Fixes

Timeout reductions for RailDAQ connections have been made to improve server communications performance (especially noticeable during firmware upgrade over GPRS).

Release 2678

Bug-Fixes

Removed IE11 bug where web-config tool was unable to open .zip firmware packages

Release 2676

New Features

Web Config Changes:

Revised Standalone / Slave settings
The SA380TX-L can operate in "standalone" mode (An independent data logging device), or "slave" mode (Acting as a peripheral device as part of a master-slave network).
The previous check-box selection proved confusion for users, this setting has been changed to a drop-down menu to make the present mode of operation clear to the user.
Additionally, When set as a "slave", nearly all settings are controlled by the "master" device, settings on the TX-L that are no longer applicable in "slave" mode are greyed out and made unavailable.

Real Time "Queued Events"
There is a subtle change in terminology here, the "Events to Send" entry in the real time display has been changed to "Queued Events".

An event can be:

- A single analogue or digital acquire-on-change sample.
- A single trigger-capture waveform.
- A single EbiTrack message.
- A single Syslog Message.
The batching and buffering process will attempt to empty the entire buffer when the buffer size exceeds the "buffer length" configuration parameter, or no data has been sent for "buffer timeout" settings.
This subtle change will drastically reduce the time taken to clear data buffers containing large numbers of events.
Syslog messages are only sent when RailDAQ protocol is selected. If MIMOSA protocol is selected, then Syslog Events are "skipped".

User alerted if a firmware package appears to be incompatible with the TX-L prior to upgrade.
Prevents obsolete or corrupt firmware from being placed on the device.

GSM Connectivity Changes

Full support for 3G modems (with 2G fallback).
All SA380TX-L devices serial number 7200 onward feature 3G GSM modems. This devices will exhibit more reliable and faster GSM communications. In areas with poor 3G network coverage, the devices will fall-back to the the 2G GSM network.

TCP/IP socket connection attempts will retry 5 times before entering MIMOSA fallback. This will improve connection availability in instances of poor GSM network performance.
The TX-L will now aggressively attempt to connect to the GSM network in areas of poor connectivity. This will also improve connection availability in instances of poor GSM network performance.

The registration status (3G or 2G) will be displayed in the "Registration" field in the "GSM Modem" area of the real-time display.

To provide the user with better feedback about the state of the TCP/IP socket connection to the central data server, the behaviour of the "Server" LED has been revised. The Server light will blink rapidly for up to 5 minutes when attempting a TCP/IP transaction prior to entering MIMOSA fallback. Whilst in MIMOSA fallback, the server light blinks slowly.

LED	Indication	Meaning
Server	Steady On	Last transmission to the Central Data Server successful. Device is now idle
Server	Fast Blink	Device is attempting TCP/IP transmission to the server.
Server	Slow Blink	Transmission to the Central Data Server has recently failed. Device is now in FALLBACK
Comm	Steady On	Connected to the GSM Network
GSM	Steady On	Modem Powered On
Master/Slave	Slow Alternating Flash (1 sec)	Normal Operation
Master/Slave	Fast Flash (0.25 sec)	Processor Sync Error*
Master/Slave	Steady On or Off	Processor Error
Storage	Blinking	Data Read/Write from database
Storage	Steady On	Database Error
Input	Blinking	Analogue or Digital Input Event Detected
RS485	Blinking	Data Transmit/Receive on RS485 Port

Automated Firmware Upgrade and Configuration via Centrix

If the RailDAQ protocol is adopted, the SA380TX-L now supports remote firmware upgrade and configuration via the Centrix platform.

- This exciting new feature allows the user to deploy upgrades / hot-fixes to all or a selection of deployed SA380TX-L automatically.
- Reading and writing of config via Centrix will allow users to configure and troubleshoot loggers in the field, without a fixed IP address connection.
- It will enable sophisticated configuration management and provide a auditable trial of config changes.
- It allows mpec to provide top quality product support.

These features will be gradually rolled out in Centrix over the coming months. SA380TX-L devices must be upgraded to 2676 or later firmware manually before these features can be leveraged.

Major Bug Fixes

Database resilient to corruption. Previously seen on loggers under high-load in service.
EbiTrack Timestamp Error Fix. Data from EbiTrack receivers could be timestamped incorrectly.
RailDaq Push Configuration: TX-L will now send all enabled channels to Centrix.

Minor Bug Fixes

MIMOSA DAInt Datatype Expanded: Can now report 32 character numbers as 16 characters did not provide enough resolution in certain circumstances.
EbiTrack Timestamp Errors: In rare circumstances, the time-stamping of EbiTrack events could be erroneous. This is no longer the case.
EbiTrack Names: Reduced to 31 characters to prevent name string overflows.

Known Issues

Logger Restart may be caused by polling the logger for large quantities of historic data.

Release 1017-1017-1017

Supports RailDAQ protocol (Super efficient communications protocol - Centrix Only)
Further historic data query fixes
Removed critical database corruption problems under heavy load
Improved SD card life

Release 799-799-733

Supports HL8548 modem in 2G mode (Fitted to serial number: LAS-3.1-XXXXXX) devices
WebConfig Bug-fixes - Historic data queries more reliable.

Release 798-798-1018

SNTP time update does not lock up.
EB200 – Sideband Ratio Calculation
EB200 & EB400 Filtering of IOUT and VOUT
Default MIMOSA ID upon reset is 9998
Improvements to SD card and database reliability (LOTS OF FIXES)
Historic data query massively improved with many bugs removed
Web-Based Configuration
No dependence on dPanel Desktop (which is rapidly becoming unusable on NR machines)
Large or Corrupt Ebitrack error logs will not lock up the logger
Full EB400 support to NR ADS
Configurable EbiTrack retries
Master / Slave support with SA380TX
Supports FI Wireless temperature sensor
Supports Polynomial sensors
Captures can be longer than 7.5 seconds (variable sample rate)
Temperature sent with points swings
SNMP traps
Support for 3G modems
TCP/IP stack bug fixes – more reliable coms
Acquire on Change now ADS compliant (2 delta change)
EB200 – Cope with EbiTrack not knowing the time

Browser not supported