Events are used to get asynchronous information from the system.
The information could be an alert if a sensor is out of range, or if the link disappears.
To receive any event, the Event Stream must be used and must be polled continuously.
The following event types can be received:
|NT_EVENT_SOURCE_PORT||Triggered if there is a change in the link status for one of the ports|
|NT_EVENT_SOURCE_SENSOR||Triggered if a sensor is out of range|
|NT_EVENT_SOURCE_CONFIG||Triggered if a configuration has been changed|
|NT_EVENT_SOURCE_TIMESYNC||Triggered by PPS timesync when a new time is needed|
|NT_EVENT_SOURCE_SDRAM_FILL_LEVEL||Triggered by fill level events|
|NT_EVENT_SOURCE_PTP_PORT||Triggered by PTP port link up/down events|
|NT_EVENT_SOURCE_TIMESYNC_STATE_MACHINE||Triggered by changes in timesync state events|
The event types are defined in the NtEventSource_e enum
Port link events are triggered if there is a change in the link status of a port
|NT_EVENT_PORT_LINK_UP||A link up occured|
|NT_EVENT_PORT_LINK_DOWN||A link down occured|
|NT_EVENT_RXAUI_LINK_ERROR||An internal error occured|
The port events are defined in the NtEventPort_e enum
When a configuration change is made, either by an application using the configuration stream NT_ConfigWrite, or internally,
a config change event is triggered. The event contains a copy of the NtConfig_t
configuration structure used by the NT_ConfigWrite configuration stream to send the change request.
Sensor events are triggered if a sensor is out of range. This could be a temperature sensor
that is too hot or a fan sensor that is too low due to a blocked fan.
|NT_EVENT_SENSOR_ALARM_STATE_ENTRY||The sensor is out of range and enters the alarm state|
|NT_EVENT_SENSOR_ALARM_STATE_EXIT||The sensor is within range and leaves the alarm state again|
Timesync events are triggered by PPS timesync when a new time is needed.
The adapter receives a PPS pulse then requires the matching time.
|NT_EVENT_TIMESYNC_PPS_REQUEST_TIME||Timesync needs an updated time|
An event can be sent if the host buffers are running full. Up to 4 levels can be defined in the ntservice.ini file.
The event works on a single host buffer. If several host buffers are defined and used, each host buffer will
trigger its own event.
In the above example, an event is sent if the SDRAM fill level exceeds 20%, 40%, 60% and 80% and
when the SDRAM fill level drops below the levels again.
The SDRAM fill warning events are received like any other events by using the event stream.
The event mask should either be NT_EVENT_SOURCE_ALL or NT_EVENT_SOURCE_SDRAM_FILL_LEVEL
if only the SDRAM fill level events are required. The outputs from the SDRAM fill level events are placed in the
NtSDRAMFillLevel_s structure and contain a number of values describing the SDRAM and host buffer usage, and
the fill level in percent.
Note: If the numStreams is larger than 1, the host buffer is shared between applications.
Setting the SDRAMFillLevelWarning to zero disables the event.
Note: Setting the fill levels to, for example, 0,50,80 will also disable the event.
How it works
The SDRAM fill level is monitored every millisecond. If the fill level is above one of the limits
defined in the ntservice.ini file, an event is triggered. The triggered event contains information about
the current fill level.
Only the 65% event is triggered. An event will not be triggered for every limit
being crossed. In the above case an event will not be triggered when crossing the 20%
limit and the 50% limit.
To avoid event flooding, a hysterisis of 10% is used. This means when a limit is crossed with
a rising level an event is triggered. However, when a limit is crossed with a falling level, the level
must be 10% below the limit before an event is triggered. The figure below shows when an event is
triggered with rising and falling levels.
0% and 100%
An event will always be triggered when reaching either 100% SDRAM (full) or 0% SDRAM (empty)
even though 0% and 100% are not defined in the ntservice.ini file.
Values can be omitted - if a value is omitted it is replaced by a zero
See the eventMonitor_example.c example for further information about how to read an event.