USER MANUAL

Overview

QuantusSoftware provides a quick and user-friendly way to interact with QuantusSeries hardware. It is accomplished by providing a REST interface available on the hardware. The REST interface uses HTTP and JSON requests.

The key benefits of a REST interface are:

• Driverless: It does not require a driver to communicate with the device. It requires no additional effort to install/distribute drivers.
• Platform Independent: Works on virtually any platform.
• Programming Language Independent: Almost all programming languages have support for connecting to REST Interfaces.
• Accelerated Integration: Integration time is reduced compared to other types of interfaces.

The current release of QuantusSoftware is Q 2.5.1.

Changelog

Q2.4.16 to Q 2.5.1

• New Features
  • Added Wake On LAN (WOL) support
  • QServer
    • Added support for the following modules
      • CAN450
      • THM450
      • GPS450
      • FLX450
      • ICS450
      • VIM450
      • ICT454
      • ALO450
      • ICP450
      • GPS42S6
    • Added support for output streaming of the ALO module
    • Streaming stability improvements
    • Always Reset to default settings after upgrading software
    • Add the Module Status Output Setting to control relays on the ALO42S4/ALO450
    • Added the following new endpoints:
      • Set system fan speed
      • Get system up-time
      • Calibrate the system
      • Shut down and restart System
  • Minor quality of life updates to QAcquire
• Bug fixes
  • QServer
    • Improved PTP Master stability on MicroQ
    • Fixed a bug where firmware upgrading sometimes failed
    • General Web Server and System Settings stability improvements

Q2.4.15 to Q2.4.16

• SC10: Improved reliability of boot FPGA flash image writes.

Q2.4.12 to Q2.4.15

• SC4210 - Fixed a stability problem introduced in a prior firmware version.
• Fixed a bug where broadcast bridge balance and bridge reset commands caused QServer to crash
• Improved settings apply speed when all ALO channels are not enabled

Q2.4.11 to Q2.4.12

• QServer - ICP42/ICT42 G2 TEDS read range fixed
• QServer - MIC42X G2 critical relay protection fixed

Q2.4.10 to Q2.4.11

• QServer - Enabled the DSP 1 Hz Highpass Filter and AC coupling options for CHS42X4 when in charge input mode.
• QServer - Resolved the issue where the ALO42S DC Function Generator amplitude change time would not always apply.
• QServer - Fixed ICP42S and ICT42S Analog channel phase delay when a low sampling rate is used.

Q2.4.8 to 2.4.10

• QServer - Added support for Thermocouple type N to THM427.

Q2.4.6 to Q2.4.8

• QAcquire - Fixed an issue where QAcquire failed to function properly on systems without Local Storage.
• QServer - Standardized sensitivity scaling across all charge channels. The data stream will no longer be scaled according to the charge sensitivity setting. Users must therefore account for this when converting voltage to measurement units.

Q2.4.4 to Q2.4.6

• QServer - Resolved an issue in the data packet packing engine which affected header alignment in the stream. This issue was introduced in Q2.4.2.

Q2.4.3 to Q2.4.4

• QServer - Resolved a phase delay issue affecting analog data channels.

Q2.4.2 to Q2.4.3

• QServer - Fixed a bug where the Tacho Generic Channel Header timestamp was incorrect.
• QServer - ALO Mirroring support added for DCH42 module.

Q2.3.4 to Q2.4.2

• New Features
  • QAcquire
    • Introduced minimum / maximum peak detection for analog channels, including a feature to hold the peaks.
    • Added the ability to set the recording duration in local storage before starting a recording.
    • Added a ‘Reset’ button to the main navigation. This will reset QServer and QAcquire settings to defaults.
    • Sidebar and fonts rework
      • Reworked all fonts to improve accessibility
      • Reworked the sidebar to represent the system as a logical mapping of the hardware
      • Removed the visual view and introduced a compact mode for the sidebar
      • Added an options menu to allow users to switch between list and compact views for the sidebar
    • Made changes to the sidebar channels and channel ID
      • Adjusted the display of the channel number in the list and included the QServer channel ID in the channel circle.
      • Added intermediate states to the local storage time string
      • Introduced icons for data status (local storage and streaming) for the sidebar channels in both list and visual mode.
  • QServer
    • Added an endpoint to get all the measurements recorded on local storage.
    • PTP network transport protocol can be configured using the Web Server.
• Bug fixes:
  • QDataManager
    • Resolved channel ID mismatches in local storage between QAcquire and QDataManager.
    • Local storage channel integrity field matches the data stream channel integrity field.
    • Fixed issue with plotting measurements less than 2 seconds.
    • Fixed local storage module ID assignment.
    • Fixed THM range scaling when exporting Local Storage measurements.
    • Fixed a bug where exported data is periodically zero.
  • QAcquire
    • Fixed a bug where the local storage start/stop button did not apply the settings correctly.
    • Fixed the bug where data state icons were disappearing
    • Fixed the bug where the slider component failed to update the value offset when switching between vertical split and normal mode
    • Local storage prevents the user from recording, displaying an error message if the disk is full.
    • Local storage settings are now disabled during recordings and removed arrow buttons for number inputs.
    • Fixed connection handling issues with QServer.
  • QServer
    • Fixed a bug where TEDS did not work on the MicroQ built-in ICP channels.
    • Local storage recording will return an error message if the disk space is full (disk reached the end of its reliable writing capacity).
    • PQ45 - Fixed a bug where the WiFi did not work when encryption is enabled.
    • WSB42Xx - Random periodic spikes/discharge distortion in constant current modes is now resolved.
    • CAN42S - Incorrect/inconsistent temperature readings fixed.
    • MicroQ - Fixed a bug where the XMC channels lose synchronisation with the system when using PTP. As a consequence, this bugfix causes QServer to reboot the MicroQ when enabling PTP or changing the Master Sampling Rate while PTP is enabled.

Q2.3.3 to Q2.3.4

• MicroQ - Fixed a bug where the XMC channels lose synchronisation with the system when using PTP. As a consequence, this bugfix causes QServer to reboot the MicroQ when enabling PTP or changing the Master Sampling Rate while PTP is enabled.

Q2.3.2 to Q2.3.3

• PQ45 - Fixed a bug that caused the system to crash when an input to a CAN module is an unaligned size.

Q2.3.1 to Q2.3.2

• MicroQ - Fixed a bug where the built in channels were slightly out of sync with the SC’s channels.

Q2.3.0 to Q2.3.1

• QServer - Fixed a bug where modules could miss a test restart after changing the sampling rate, causing a phase delay.

Q2.2.3 to Q2.3.0

• QServer - Added support for CHG42S9 module.
• QServer - Added support to “Mirror a Module” data stream using an ALO42S4.
• QAcquire - Updates for an improved user experience:
  • Local Storage:
    • The Settings section is initially hidden but can be revealed using the show/hide button.
    • The recording button will automatically apply system setting and show event notifications.
    • The current recording time, disk space and estimated time remaining are now available.
  • Navigation:
    • An enhanced navigation layout has been introduced to facilitate smoother action flow.
    • The save and restore are now part of the navigation as import / export.
  • System settings:
    • System settings and the channel sidebar have been merged.
    • The system node (QDevice controller) will be the first entry in the sidebar tree, selected by default.
    • Settings can be viewed/changed in the properties panel exactly the same as with the channels.
  • Embedded mode:
    • Home, Import, and Export buttons have been removed to align with the context of embedded mode.
    • Local Storage settings are always visible and adjusted the layout accordingly.
    • The recommended width for /?embedded is 315 pixels and with vertical split /?embedded&verticalSplit is 632 pixels.
    • QAcquire - The Temp / div settings have been adjusted to the highest level that the hardware can support.
• QAcquire - Implemented automatic range scaling for spectrum graphs.
• QDataManager - Added the new logo.
• QDataManager - Added MATLAB and Wav exporters.
• PQ30 and PQ45 fan controller adjustments - fan speed set to “Maximum” at >= 75degC, will restore user fan setting at <= 70degC. System shuts down at >= 85degC.
• PQ45 fix to correctly display mainframe information in webserver.

Q2.2.2 to Q2.2.3

• QServer: Fix a bug where CAN modules do not work when PTP is enabled on the PQ45.

Q2.2.1 to Q2.2.2

• QDeviceDiscovery - Duplicate entries are now removed if the client PC has multiple network interfaces on the same subnet. In general, having multiple interfaces on the same subnet can lead to unexpected network behavior and potential issues. This network configuration is inadvisable due to it’s undefined behaviour.
• PQ45 Power Supply update:
  • Dim OLED after 2min, turn off after 5min - DEFAULT setting. Heartbeat LED now active on front panel - 1 brief flash (blue) every 5s.
  • Add support for BAT5203 which supports in system sleep.
  • Dynamic Charge now forced ON by default, will always be active after a reboot. Charge will start when battery <= 90%. Default minimum Dynamic Charge power changed to:
    • 1 battery = 5W
    • 2 batteries in system = 8W
    • 3 batteries = 10W
  • Adjust temperature protection, shutdown at >=86degC for 1 min, immediate shutdown at >=90degC.
• Add PQ45 support for SC45 and SC25.

Q2.2.0 to Q2.2.1

• QServer - Implemented a High Sampling Rate option for the CHS42X4, ICS421 and ICS425 Modules. In this Operation mode the Module will disable channels 2 and 5 allowing the remaining 4 channels to allocate at an effective Sampling Rate of MSR divide by 1.
• QServer - Improved buffer level calculations. This adds a bit more stability if there is jitter on the client streaming application.

Q2.1.1 to Q2.2.0

• QAcquire - Added ability to use QAcquire as a pop-out panel where it can be used to change all QServer settings without streaming or rendering, in a compact form factor. To enable it simply append ?embedded to the QAcquire link in the browser. The complete URL should be http://<Device>/QAcquire/?embedded
• QAcquire - Added user controls for the properties layout and fixed a couple of user interface issues:
  • A vertical split for the properties panel and a hide / show button for the properties.
  • Fixed scroll into view when selecting a channel.
  • Tool-tips will now always be in view.
  • Added the vertical split option for embedded mode. To enable it append &verticalSplit after ?embedded in the QAcquire link. The complete URL should be http://<Device>/QAcquire/?embedded&verticalSplit
• QAcquire - Performance and stability improvements:
  • Improved performance and stability by decoupling the streaming engine from the rendering engine.
  • Now renders at dynamic frame rates, has faster frame rates and doesn’t leak memory at high throughput. Thus also improving stability over longer periods.
  • Optimize payload parsing to only parse payloads that have corresponding channels / graphs.
• QAcquire - Added Save and Restore Settings. This can save and restore QServer and QAcquire settings for the system to and from a JSON file.
• QServer - Minor onboard flash speed improvement.
• QServer - Added missing charge sensitivity option for CHS42X4 Channels.
• QServer - PTP domain and resynchronisation threshold can be configured.
• QServer - Fixed incorrect AutoZero settings being used for the “System and Sensor” option.
• QServer - Fixed unsupported Items being listed with unique ItemNameIdentifiers.
• QServer - Fixed empty Items being listed as Unsupported.
• QServer - Fixed incorrect amplitude scaling of the DCH42S Channel Differential Mode.
• QServer - Fixed corrupt CAN messages when message length was an odd size.
• QServer - Fixed a bug where Local Storage wasn’t stopped when user calls the SuspendDataStream action.
• QServer - Fixed a bug where the Landing Page and System Settings showed an error while trying to read the SMART info.
• QServer - Add support for WSB42X6 module.
• QDataManager - Added zooming controls for Analog and Tacho plots.
• QDataManager - Fixed bug where QDataManager crashed when then recording has more than one sampling group.

Q2.1.0 to Q2.1.1

• QServer - Minor stability and performance improvements.
• QServer - Fixed bug where the REST server’s HTTP content-length was case sensitive, thus not working with some clients.

Q2.0.306 to Q2.1.0

• QServer - Performance improvement. Latency has also been reduced. The order of channel data on the streaming socket is now more scattered.
• QServer - Add Raw data format for analog channels. Using this data format instead of the default Processed format improves performance above the above improvement.
• QServer - Improved REST interface socket stability.
• QServer - Fixed a CAN42S2 Participate setting field incorrectly displaying “Send At Fast Bitrate” as “Fast Bitrate”.
• QServer - Removed the incorrectly displaying the Data field in the response of GET /item/settings/defaults/ endpoint.
• QServer - Added new fields to the /dataStream/setup/ endpoint which are correctly defined for common serializers.

Q2.0.298 to Q2.0.306

• QServer - Fixed a stability issue when streaming clients disconnect and connect frequently in short intervals.
• QServer - Fix Local Storage time when using PTP.
• QServer - Fixed issue where data might be out of phase due to missing data.

Q2.0.264 to Q2.0.298

• QAcquire - Added a rendering engine that controls the frame rate of rendering channels. The display limit has been increased to 96 channels.
• QAcquire - Decouple the streaming engine from the display engine. QAcquire will not disable streaming for channels that have display turned off.
• QServer - Minor stability improvements.
• QServer - Fixed a bug where MicroQ and MicroQ Black stopped streaming XMC channels during long term tests.
• QServer - Added ability for QServer to suspend and resume streaming during upgrades and QDataManager recording downloads, thereby improving the speed at which these tasks happen.
• QServer - Added ability to Set and Get the System Time.
• QServer - Fixed a bug where the WSB42X4 module did not track its state correctly.
• QServer - Fixed the incorrect values reported for local storage and data streaming on the GET item/settings/defaults endpoint.
• QServer - Added validation for CAN FD message list.

Q1.4.11 to Q2.0.264

• QServer - Added support for IEEE 1588-2008 PTP
• QServer - Added support for Local Storage
• QAcquire - Added support for Local Storage
• QServer - Renamed endpoints for better standardisation and readability
• QServer - Changed the headers of the data stream packets
• QAcquire - Added support for CHS42X4, DCH42S2 and MIC42X7
• QDataManager - Added QDataManager for managing, viewing and exporting Local Storage data.

Q1.4.6 to Q1.4.11

• QServer - Fixed various issues with the Integrity values in the data stream
• QServer - Fixed an issue where the CHS42X4 and THM427 will not return Test Restart Required for a Sample Rate change
• QSoftwareUpdate - Fixed a bug preventing upgrades for very old versions of QSoftware

Q1.4.5 to Q1.4.6

• QServer - WSB Closed loop disabled

Q1.4.3 to Q1.4.5

• QServer - Fixed bugs where the integrity information for modules and XMC ICP channels in the data stream was incorrect
• QServer - Fixed a bug where the WSB42 (X) module excitation was inaccurate after doing a balance

Q1.4.2 to Q1.4.3

• QServer - Fixed a bug where the ICP42 G2 and ICP42S G2 Module would re-allocate when only the Module Grounding setting is changed
• QServer - Fixed a bug where systems synced using PTP will not sync properly after applying certain settings
• QServer - Fixed the THM427’s voltage range when configuring for temperature modes
• QServer - Fixed a bug where the CHS42X4 module would deallocate itself after applying settings

Q1.4.1 to Q1.4.2

• QServer - WSB42X hardware gain combination changes to improve noise performance

Q1.3.3 to 1.4.1

• QServer - Removed support for CAN FD Arbitration Bitrate 10 kHz and 33 kHz due to lack of support from the chipset
• QServer - Resolved the issue where the CAN message list contained garbage values
• QServer - Add support for XMC ICP channels
• QServer - Fixed a bug where disabled ICS channels would always trigger a test restart, even if the restart is not required
• QServer - Disabled WSB42X closed-loop excitation control because of instability in certain setup combinations
• QAcquire - Fixed property field notifications breaking layout

Q1.2.416 to Q1.3.3

• QServer - Add support for the ICS42L module
• QServer - Add support for the THM module
• QServer - Fixed a bug where CAN data is corrupt if the message size is uneven
• QServer - Fixed bug where XMC ICP channel (still in beta phase) samples had gaps in the data stream
• QSoftwareUpgrade - Improved reliability of QSoftwareUpgrade to be able to upgrade systems even when the system has failed the boot process

Q1.2.413 to Q1.2.416

• Fixed bug where Overload is always zero

Q1.2.412 to Q1.2.413

• QServer - Improve throughput of tacho channels
• QAcquire - Fixed Sidebar navigation for smaller screens
• QServer - Improve long-term stability
• QServer - Fix a bug that causes the system to hang if MSR is changed many times

Migrating from Q1.X to Q2.X

QuantusSoftware version Q2.0 introduces many breaking changes. These changes were needed due to added features and customer feedback. This section will guide developers that are migrating from Q1.X to Q2.X.

Endpoint Renaming

Multiple endpoints were renamed to improve readability, extendability and ease of integration.

See the list below for all the Endpoint changes:

Endpoint Response

This Q 2.0 release strives to standardize the RESTfull response from the endpoint calls.

Common Changes

For all Settings, MessageData and CanFdBusStatus objects, the Type field responses has been update for the following values:

Some endpoint responses were to be changed, they are listed below:

GET system/settings

What has changed

• The “System” field has been removed
• The “Value” field has been renamed to “Id” in the “OperationMode” data

Example of the old response

 {                                     
    "System": {                        
        "ItemId": 1,                   
        "ItemName": "PQ30G2",          
        "ItemNameIdentifier": 30090,   
        "ItemType": "Controller",      
        "ItemTypeIdentifier": 0,       
        "Info": [                      
            {                          
                "Name": "SerialNumber",
                "Value": "1118M3103"   
            }                          
        ],                             
        "OperationMode": {             
            "Description": "Enabled",  
            "Value": 1                 
        },                             
        "SettingsApplied": true,       
        "Settings": [                  
        ...                           

Example of the new response

 {                                     
    "ItemId": 1,                   
    "ItemName": "PQ30G2",          
    "ItemNameIdentifier": 30090,   
    "ItemType": "Controller",      
    "ItemTypeIdentifier": 0,       
    "Info": [                      
        {                          
            "Name": "SerialNumber",
            "Value": "1118M3103"   
        }                          
    ],                             
    "OperationMode": {             
        "Description": "Enabled",  
        "Id": 1                 
    },                             
    "SettingsApplied": true,       
    "Settings": [                  
    ...                             

GET item/settings and GET item/settings/defaults

What has changed

• The “Value” field has been renamed to “Id” in the “OperationMode” data

Example of the old response

{
    "ItemId": 1,
    "ItemName": "PQ30G2",
    "ItemNameIdentifier": 30090,
    "ItemType": "Controller",
    "ItemTypeIdentifier": 0,
    "Info": [
        {
            "Name": "SerialNumber",
            "Value": "1118M3103"
        }
    ],
    "OperationMode": {
        "Description": "Enabled",
        "Value": 1
    },
    "SettingsApplied": true,
    "Settings": [
    ...

Example of the new response

{
    "ItemId": 1,
    "ItemName": "PQ30G2",
    "ItemNameIdentifier": 30090,
    "ItemType": "Controller",
    "ItemTypeIdentifier": 0,
    "Info": [
        {
            "Name": "SerialNumber",
            "Value": "1118M3103"
        }
    ],
    "OperationMode": {
        "Description": "Enabled",
        "Id": 1
    },
    "SettingsApplied": true,
    "Settings": [
    ...

GET autoZero/settings

What has changed

• The “AutoZeroSettings” field has been renamed to “Settings”

Example of the old response

{
    "ItemId": 7,
    "ItemName": "ICS425",
    "ItemNameIdentifier": 15,
    "ItemType": "Channel",
    "ItemTypeIdentifier": 4,
    "AutoZeroSettings": [   
    ...

Example of the new response

{
    "ItemId": 7,
    "ItemName": "ICS425",
    "ItemNameIdentifier": 15,
    "ItemType": "Channel",
    "ItemTypeIdentifier": 4,
    "Settings": [
    ...

canfd/message/list

What has changed

• The format was changed by grouping the settings and data for a Message entry

Example of the old response

{
    "MessageList": [
        [
            {
                "Name": "Extended Frame",
                "Type": "Enumeration",
                "SupportedValues": [
                    {
                        "Id": 0,
                        "Description": "Disabled"
                    },
                    {
                        "Id": 1,
                        "Description": "Enabled"
                    }
                ],
                "Value": 1
            },
            ...

Example of the new response

[
    {
        "Settings": [
            {
                "Name": "Extended Frame",
                "Type": "Enumeration",
                "SupportedValues": [
                    {
                        "Id": 0,
                        "Description": "Disabled"
                    },
                    {
                        "Id": 1,
                        "Description": "Enabled"
                    }
                ],
                "Value": 1
            },
            {
                "Name": "Message ID",
                "Type": "Unsigned Integer",
                "ValidationLimits": {
                    "Upper": 4294967295,
                    "Lower": 0
                },
                "Value": 4
            },
            {
                "Name": "Message Length",
                "Type": "Unsigned Integer",
                "ValidationLimits": {
                    "Upper": 64,
                    "Lower": 0
                },
                "Value": 64
            },
            {
                "Name": "Transmit Period In Milliseconds",
                "Type": "Unsigned Integer",
                "ValidationLimits": {
                    "Upper": 4294967295,
                    "Lower": 0
                },
                "Value": 0
            },
            {
                "Name": "Hold Period In Milliseconds",
                "Type": "Unsigned Integer",
                "ValidationLimits": {
                    "Upper": 4294967295,
                    "Lower": 0
                },
                "Value": 0
            }
        ],
        "MessageData": {
            "Name": "Message Data",
            "Type": "Byte []",
            "ValidationLimits": {
                "Upper": 255,
                "Lower": 0
            },
            "Value": [
                1,
                2,
                3,
                4,
        ...

canfd/bus/status/list

What has changed

• The “Bus Status” field has been removed

Example of the old response

{
    "Bus Status": [
        {
            "Name": "Transmit Error Count",
            "Type": "Unsigned Integer",
            "ValidationLimits": {
                "Upper": 4294967295,
                "Lower": 0
            },
            "Value": 0
        },
        {
            "Name": "Receive Error Count",
            "Type": "Unsigned Integer",
            "ValidationLimits": {
                "Upper": 4294967295,
                "Lower": 0
            },
            "Value": 0
        },
        ...

Example of the new response

[
    {
        "Name": "Transmit Error Count",
        "Type": "Unsigned Integer",
        "ValidationLimits": {
            "Upper": 4294967295,
            "Lower": 0
        },
        "Value": 0
    },
    {
        "Name": "Receive Error Count",
        "Type": "Unsigned Integer",
        "ValidationLimits": {
            "Upper": 4294967295,
            "Lower": 0
        },
        "Value": 0
    },
    ...

Subscribe to Data

There has been a change in how users enable/disable data streaming for channels.

In Q1.X, data streaming was enabled using the /subscribeToData endpoint. In Q2.X, there is now a setting on the channel to enable/disable streaming. This is the same mechanism to enable Local Storage for the selected channel. To enable data streaming for a channel, the Streaming State setting should be set to Enabled (Id: 1), which will require a system/settings/apply before the change takes effect.

The settings for a channel will now have the additional section:

"Data":[
        {
            "Name":"Streaming State",
            "Type":"Enumeration",
            "SupportedValues":[
                {
                    "Id":0,
                    "Description":"Disabled"
                },
                {
                    "Id":1,
                    "Description":"Enabled"
                }
            ],
            "Value":1
        },
        {
            "Name":"Local Storage State",
            "Type":"Enumeration",
            "SupportedValues":[
                {
                    "Id":0,
                    "Description":"Disabled"
                },
                {
                    "Id":1,
                    "Description":"Enabled"
                }
            ],
            "Value":1
        }
    ]

Item Operation Modes and Settings

Some settings and Operation Mode names have been renamed for consistency:

Hidden Settings Exposed

Some settings were previously hidden and are now exposed. The majority of these will only have one option. The change is to give the user more information about the configuration of the item. These changes are not breaking changes, but will change the way GUI’s might automatically populate fields for channel settings.

Streaming Data Format

Packet Header

In the Packet Header, the Reserved field has been replaced by Payload Type. This new Payload Type allows QServer to add metadata into the data stream. Q1.X only implemented streaming data payloads, which is now indicated as Payload Type equal to 0.

Note: Initially, when migrating from Q1.X to Q2.X, the software receiving the data stream should check the Payload Type and ignore all types that are not Data (0), and treat Data types the same way as Q1.X. Once the migration of the Packet Header* and Generic Channel Header has been completed, users can incorporate other Payload Types.

The Packet Header layout change is as follows:

Generic Channel Header

Introducing IEEE 1588-2008 PTP required the addition of a timestamp in the Generic Channel Header. There has also been a minor improvement to make implementing data streamers easier by changing the Offset To Next Header to Data Size.

The Generic Channel Header changes are as follows:

Note: The fields in the data payloads are packed tightly without any padding. They should be parsed on a byte-for-byte basis.

Sample Type

Each sample type is now unique for its matching channel type

Known issues

Supported Features in Q 2.5.1

QuantusSoftware supports the following features:

Limitations regarding streaming:

• Only one streaming client is allowed to connect to the device at a time.

Limitations regarding Local Storage:

• Local Storage adds additional strain to the system. Assigning channels to Local Storage will decrease the channel count that can be streamed.

Local storage

Supported Hardware

This section contains a summary of the hardware supported in QServer and QAcquire. Please see the relevant hardware manuals and brochures for a detailed explanation about the features and hardware capabilities, not yet supported by QServer.

Controller

ALO42S4, ALO450

CAN42S2, CAN450, MICROQ built-in CAN FD

CHG42S9

CHS42X4

DCH42S2

GPS42S6, GPS450 and XMC237 GPS

ICM450

ICP4211, ICP42S11, ICP450

ICS425, ICS450

ICS42L5

ICT426, ICT42S6, ICT454

Analog input channels

Tacho channels

MIC42X7, MIC450

MICROQ built-in XMC237 ICP

TAC221

THM427, THM450

VIM450

WSB42X2, WSB42X5, WSB42X6

Getting Started

Network Configuration

QuantusSeries devices connect to the User’s computer through a network. This network can be either Ethernet or Wi-Fi (if the option is available on your system). A couple of configuration options are supported. These will be discussed below.

Ethernet Network with DHCP Server

The most common configuration is to connect your device to the Ethernet switch, which connects your computer to the rest of the network. Most networks have a DHCP server that will provide your device with an IP address when setting up for the first time. If your company has a strict policy regarding devices on the network, such as requiring the IT department to approve devices before they are provided with DHCP server access, then instead use the direct connection method in the next section.

Here is a diagram of a typical network structure if a DHCP server is available on the network:

In this configuration, your computer should receive its IP address from the DHCP server. Once the QuantusSeries device is connected to the network, it should also receive an IP address from the DHCP server.

You can now proceed to the next section to Discover your QuantusSeries Device.

Ethernet Network without DHCP Server

In this configuration, your computer is on an isolated network that does not contain a DHCP server. The device can connect directly with an Ethernet cable or through a network switch.

Here is a diagram of an isolated network through a network switch:

And here is a direct connection:

In these configurations, the QuantusSeries device will detect the lack of a DHCP server on the network. It will fall back to the AutoIP protocol and choose a random (free) IP address in the 169.254.xxx.yyy range. If your computer is set up to use DHCP (you are connected to the company network, and you temporarily connect to the device for configuration), then your computer would behave similarly. Your computer should also choose a free IP address in the same range.

If your computer is set up to have a static IP address, you will have to change the address to 169.254.1.1 for the initial configuration.

You can now proceed to the next section to Discover your QuantusSeries Device.

Wi-Fi Network

For QuantusSeries devices with optional Wi-Fi, you can have the following network configuration:

The default configuration of the Wi-Fi interface on a QuantusSeries device is Access Point mode with DHCP server enabled. This means that once connected via Wi-Fi, your computer will be given an IP address by the device. Create a wireless connection to the device from the computer by connecting to the SSID Quantus_1234M5678, where the postfix is your device serial number. The security type is “Open”.

You can now proceed to the next section to Discover your QuantusSeries Device.

Discovering Your QuantusSeries Device

Before you can communicate with your device, you first have to discover it on your network.

By default, all devices are shipped with the following settings:

• Ethernet port: The IP address is obtained using DHCP. If no DHCP server exists on the network, the device will fall back to AutoIP and assign itself a free IP in the 169.254.xxx.yyy range.
• Wi-Fi port: By default, Wi-Fi is set up in Access Point mode. The Wi-Fi SSID is Quantus_1234M5678, and the postfix is your device serial number. When connecting to Wi-Fi for the first time, you do not require a password as there is no security selected by default (security type is “Open”). The connecting device will also receive an IP address from the DHCP server running on the Wi-Fi port.
• Name: Your device name will be Quantus_1234M5678, and the postfix is the device serial number. This name can be changed on the Settings page of the device’s System Settings.

All QuantusSeries devices are shipped with mDNS enabled. mDNS is the primary method used to discover devices. There are a couple of options available:

• Library: If the programming language includes a user-friendly mDNS library, you can use it to find a list of devices on the network. QuantusSeries devices have the prodIdent field populated with the keyword Quantus. At the moment the only service being advertised is the device’s Systems Settings ("_http._tcp" on port 80), but in the future the list will be more complete.
• Binary Utility: The QuantusSoftware package contains tools to ease integration. One of these is the QDeviceDiscovery application. This utility can be invoked from your application or the command line.

We will use the QDeviceDiscovery tool as an example. The application’s output is a JSON string containing a list of QuantusSeries devices on the network. After turning on your device, open the command line in the QDeviceDiscovery folder located in the QuantusSoftware package. Invoke the application by typing QDeviceDiscovery . The application will discover devices on the network within the next 10 seconds. After that, it will output the list:

> QDeviceDiscovery
{
  "numberOfentries": 1,
  "entries": [
    {
      "deviceName": "Quantus_0718M8880",
      "deviceIp": "10.0.0.202"
    }
  ]
}

Access your System Settings

Once you have discovered the IP address or name of your device, you will be able to access your devices’s System Settings.

QuantusSeries devices have a built-in Web Server which includes System Settings pages. To access the Web Server, open your preferred Web Browser and enter either of the following in the address bar:

• IP address: http://<SystemIpAddress>, for example, using the device discovered in the previous section http://10.0.0.202
• Name: http://<Name>.local, for example, using the device discovered in the previous section http://Quantus_0718M8880.local

You will be greeted with the Landing Page. The Landing Page provides basic information about your device and allows you to navigate to your System Settings and/or QAcquire.

The device’s System Settings allows Users to configure the system as a whole:

• System name
• Power settings
• Fan controller settings
• Network settings
• Software upgrade

QAcquire

QAcquire configures, controls and monitors your measurement in a modern and effortless way. It is an alternative method for setting up measurements for clients that do not require OEM Software Packages.

QAcquire is a client-side Web application hosted on the device. You can launch it by opening the Web Browser, navigating to the device’s Landing Page and clicking on the QAcquire link.

With QAcquire the system can be configured online. However, it still requires a streaming client to retrieve the data stream for analysis.

QAcquire can be embedded in your application if your application environment supports embedding a browser. This is done by appending ?embedded to the QAcquire URL. This allows you to embed QAcquire if you want to use it to change all QServer settings without streaming or rendering, in a compact form factor.

How is the frequency-domain spectrum implemented?

QAcquire uses the Fast Fourier Transform (FFT) algorithm to convert time-domain signals into a frequency-domain spectrum.

The process begins by applying a Hanning window to the signal. This windowed signal is then processed by the FFT algorithm, which computes the Discrete Fourier Transform (DFT). After the FFT is applied, the signal’s amplitude is converted to decibels volts (dBV).

The bin width is variable and depends on both the channel sample rate and the frequency range selected by the user. If the entire frequency range is chosen, the FFT size is a minimum of 1024, resulting in 512 frequency bins. However, if the user focuses on a specific frequency range, the FFT size can increase up to a maximum of 8096, resulting in 4048 frequency bins. In the FFT algorithm, the number of frequency bins is halved because the spectrum is symmetrical due to the nature of the Fourier transform for real-valued signals. The bin width is calculated based on the selected frequency range and the current sample rate of the channel.

QDataManager

QDataManager is a Graphical User Interface to Import, Manage, View and Export your Local Storage measurements.

Import measurements from QuantusSeries devices. Using the Import window, you can access all devices on a network, manually or discovered (QDataManager discovers QuantusSeries devices on the network using the QDeviceDiscovery utility). You can view, manage and import Local Storage measurements to a local Depo (a local folder on your computer).

Manage local Depos and measurements. Using the Main window, you can view and manage your measurements and their channels.

Plot your measurement channels. Using the same window, you can view and plot measurement channels. Currently, Analog and Tacho channels are supported. This allows you to quickly see if the recorded measurements are correct.

Export channels to your preferred data format. You can select channels to export into different formats. A CSV exporter is included with a couple of settings. QDataManager supports exporter Plugins, which you can use to format the data in any format needed. You can then use the exported data in other third-party tools for analysing.

REST Interface

The REST API uses HTTP requests for clients to interact with services. This section will show basic interaction with the REST API. A detailed reference can be found in the REST API Reference section.

Note: To demonstrate concepts related to the use of REST APIs we need certain tools. We have opted to use tools that are already installed on new Windows computers. These examples do not reflect how a regular User would use QuantusSoftware, but rather help us present the concepts. We recommend using REST tools and scripting / programming languages that are more suited to this application when doing development.

Reading Settings with the Web Browser

Since REST APIs use HTTP, the same protocol used by websites on the internet, we can demonstrate some functionality without writing any code.

First, we can check if the system is alive. We can “ping” the REST server using the /info/ping endpoint. Open your internet browser and enter http://SystemIpAddress:8080/info/ping into the URL address bar (replacing the SystemIpAddress with your QuantusSeries device IP Address or the mDNS name). Continuing from the previous section, that would be either of the following:

http://10.0.0.202:8080/info/ping
http://Quantus_0718M8880.local:8080/info/ping

The system should respond with the following JSON string:

{
    "Code": 0,
    "Message":  "System is operational"
}

Another useful endpoint is the /endpoints endpoint which will return a list of endpoints supported by QuantusSoftware. Here is a snippet of the response for this endpoint:

[
    {
        "Action":   "GET",
        "Path": "system/settings/",
        "QueryString":  "",
        "Info": "Returns the cached system settings",
        "Example URL":  "http://<SystemIpAddress>:8080/systemSettings/"
    }, 
    {
        "Action":   "PUT",
        "Path": "system/settings/apply/",
        "QueryString":  "",
        "Info": "Applies the system settings that was set using PUT /itemSettings"
    }, 
    {
        "Action":   "GET",
        "Path": "item/operationMode/",
        "QueryString":  "?itemId=X",
        "Info": "Returns the cached operation mode of the item specified by the itemId query string",
        "Example URL":  "http://<SystemIpAddress>:8080/operationMode/?itemId=X"
    },
  ...
],

Writing Settings to the REST API

Writing back to the server is a bit more involved. We will have to use a scripting language for the example. Generally any language would work, but the only one that does not require installing anything on Windows is Powershell.

Open the command line and enter the following (replace the IP with your system IP or name):

powershell Invoke-WebRequest "http://10.0.0.202:8080/item/settings/?itemId=1" -OutFile "itemSettings.json"

This will read system settings into the itemSettings.json file. You can open this file in your favourite text editor. You will be presented with a tree structure of the system configuration. Each node in the tree has a similar structure, which is a list of Settings, SupportedValues for the setting and the current Value of the setting (which is the Id in the SupportedValues list). Below is an example of what the output would be:

{
  "System": {
    "DeviceId": 1,
    "DeviceName": "PQ30G2",
    "DeviceType": "Controller",
    "Info": [],
    "Settings": [
      {
        "Name": "Master Sampling Rate",
        "Type": "Enumeration",
        "SupportedValues": [
          {
            "Id": 0,
            "Description": "131072 Hz"
          },
          {
            "Id": 1,
            "Description": "160000 Hz"
          },
          {
            "Id": 2,
            "Description": "163840 Hz"
          },
          {
            "Id": 3,
            "Description": "176400 Hz"
          },
          {
            "Id": 4,
            "Description": "192000 Hz"
          },
          {
            "Id": 5,
            "Description": "200000 Hz"
          },
          {
            "Id": 6,
            "Description": "204800 Hz"
          }
        ],
        "Value": 0
      }
    ],
...

This system is currently running at a Master Sample Rate of 131072 Hz. Let’s modify the Sample Rate to 204800 by changing the Value field to 6. Save the file and run the following in the command-line:

powershell Invoke-WebRequest "http://10.0.0.202:8080/item/settings/?itemId=1" -Method Put -infile "itemSettings.json"

The settings are now cached on the system, but need to be applied for the change to happen:

powershell Invoke-WebRequest "http://10.0.0.202:8080/system/settings/apply" -Method Put

The system should now be running at a Master Sample Rate of 204800.

Data Streaming

For performance reasons, the data stream cannot be REST. The data stream format is a proprietary binary format. See Data Streaming Reference for in-depth information regarding how to read the data stream.

Binary Utilities

This section will explain the purpose and usage of the tools contained in the QuantusSoftware package.

QDeviceDiscovery

The QDeviceDiscovery application discovers QuantusSeries devices on the network using mDNS. It searches for devices for a specific time. This time is an input parameter on the application with a default of 5 seconds. The output is a list of devices in JSON format.

Usage

QDeviceDiscovery [OPTIONS]

Options
--help          Help Screen      
--timeout       Timeout in seconds to wait for devices to be detected on the network. The default is 5s.

Examples

Basic usage and output:

QDeviceDiscovery.exe
{
        "numberOfentries":      1,
        "entries":      [
            {
                        "deviceName":   "Quantus_0718M8880",
                        "deviceIp":     "10.0.0.202"
            }
        ]
}

QSoftwareUpgrade

There are a couple of ways to upgrade the software of a QuantusSeries device. The first is by using the device’s System Settings (from the Landing Page, navigate to System Settings).

The second is the QSoftwareUpgrade utility. It is a simple command-line utility that will upgrade the given device. It can easily be incorporated into the software package being used with the QuantusSeries device.

A software upgrade can take several minutes to complete. At the moment the software does not provide any feedback on the progress of the upgrade.

Usage

QSoftwareUpgrade.exe [options] DeviceIpOrName
Ip address or device name is required.
Parameter Options:
  --help                Help Screen
  --filename arg        QSoftware package file name (can include a path), leave
                        blank to use the default
  --upgradePassword arg Password to upgrade the software, leave blank to use
                        the default password
  --progress            Display the progress of the Upgrade process
  --pretty              Display output text in pretty human readable text
                        instead of JSON format

Return Values

The application can return one of the following values:

UpgradeSuccessful = 0,
GeneralFailure = -1,
InvalidDeviceIpAddress = -2,
FailedToLoginToDevice = -3,
InvalidUpgradePassword = -4,
InvalidFirmwareFile = -5,
IncompatibleFirmwareFile = -6,
InvalidCommandLineArguments = -8,
FailedToOpenFile = -9

It can also return a JSON object with the code and a description:

{
        "Result":       -3,
        "Description":  "Software upgraded failed, unable to open the specified software package file"
}

Examples

Minimum parameters specified:

QSoftwareUpgrade.exe 192.168.5.151

Specifying upgrade file and password:

QSoftwareUpgrade.exe --upgradePassword MySecretPassword --filename C:\Users\MyName\Quantus\MyCustomQSoftwarePackageName.cmp 192.168.5.151

Progress of the upgrade can be obtained using the --progress parameter. The progress is given in JSON format for applications that want to parse the output:

QSoftwareUpgrade.exe --progress 192.168.5.151 

Each progress update will have a JSON object followed by a new line. The JSON object has the following format:

{
    "UpgradeStage":         4,
    "StageDescription":     "Software Upgrade Complete",
    "UpgradeStageProgress": 0,
    "Result":               0,
    "Description":          "Software already up to date"
}

QSoftwareUpgrade can also display the progress in the terminal/command-line by adding the --pretty parameter:

QSoftwareUpgrade.exe --progress --pretty 192.168.5.151 

Reset to Default Settings

Any QuantusSeries device can be reset back to its default settings. This is useful if the device has irreversible invalid settings.

MICROQ / MICROQ Black

To reset a MICROQ to default settings, keep the Power On/ Off button pressed down for about 3 seconds. Wait for the PoE and Battery LEDs to turn solid orange, then release the power button. Repeat this action three times within 15 seconds. If successful, the LEDs will slowly flash orange after the third sequence. The reset settings will be available once the MICROQ has been initialized.

DECAQ

The DECAQ reset procedure differs from that of the MICROQ. Using the Power On / Off button, scroll through the options until the device display shows DFLT. Press the OK button on the device and when prompted by SURE on the display, press the OK button again.

Default Settings

Default settings for a QuantusSeries device are as follows:

• Ethernet port: The IP Address is obtained using DHCP. If no DHCP server is available, the device will fall back to AutoIP. It will automatically assign a free IP in the 169.254.xxx.yyy range.

• Wi-Fi port: By default, the Wi-Fi is set up in Access Point mode. The Wi-Fi SSID is Quantus_1234M5678 and the postfix is your device serial number. When connecting to Wi-Fi for the first time, no password is required. The default security is set to type “Open”. The connecting device will also receive an IP address from the DHCP server running on the Wi-Fi port.

• Name: Your device name will be in the format Quantus_1234M5678. The postfix is the device serial number. This name can be changed on the Settings page of your device’s System Settings.

• QServer: The default settings for each node will be set, as specified in the REST API Reference

Hardware Interface

MICROQ

System Boot

These three blue LEDs indicate the progress of system initialization (1 - 3). Each LED will blink and then turn solid blue until all three LEDs are on, indicating that initialization is complete.

System Active

Once the system has finished the boot process the LED sequence will typically take place in the following order:

• One solid green LED indicates the system is active and the application is starting
• One solid and one flashing green indicates the system is busy with the self-calibration routine
• Two solid LEDs indicate the application is active and running, QServer is now ready to measure
• If all three green LEDs are on, this indicates QAcquire is open or data is being streamed to a TCP socket

Error States

The LEDs will indicate some error information should something go wrong.

DECAQ

System Boot

Various messages will be displayed on the User Interface display to indicate the progress of system initialization. The message Idle indicates that initialization is complete.

System Active

Once the system has finished the boot process the QServer will display the following messages:

• INIT when QServer initialises
• SCAL when the system self-calibration routine is being initialized, followed by a percentage progress counter during execution of the routine
• DLFT when the Default settings are being Applied
• APPL when Apply was set
• QSRV when QServer is running and ready for data collection
• ERR when an error has occurred during Apply
• STOP when QServer was terminated

REST API Reference

The REST API uses HTTP requests for clients to interact with services.

The REST API has resources with which Users can interact. Each resource can be accessed through a request via its endpoint. In essence, an endpoint is the URI that links to a given resource. HTTP request methods dictate how a User wants to interact with the resource:

• GET: Read - Read the resource from the system.
• PUT: Update - Update the resource on the system.
• POST: Create - Create the resource on the system.
• DELETE: Delete - Delete the resource on the system.

This section will provide information about all endpoints / resources available on the QuantusSoftware REST API. It will also specify which methods are supported (GET, POST, etc.).

Error / Info Feedback

The REST API follows HTTP status code convention.

The following error codes can be expected:

• 200: Ok - Request was successful.
• 204: No content - Request was successful, but no content will be sent to the client.
• 400: Bad request - The request failed, possible the action is not allowed for the node specified.
• 404: Not found - The requested endpoint could not be found.
• 500: Internal server error - An internal server error has occurred.
• 501: Not implemented - The endpoint requested has not been implemented.

Additionally, if an error occurs or the endpoint has a response the User should take note of, a JSON status message with the following format will be returned:

{
    "TypeCode" : 2,
    "StatusCode" : 5,
    "Message" : "Invalid item id, refer to the systemSettings/itemList for an overview"
}

Http status codes

Endpoints

Basic Endpoints

System Endpoints

Status Endpoints

Streaming Endpoints

Measurement Configuration Endpoints

Measurement Configuration

What is an Item?

When looking at measurement endpoints from the previous section, it should be noted that there are endpoints that contain the word “item”. Due to the modular nature of QuantusSeries systems, it is best to visualise each system and its components as a parent / children (hierarchical) structure. Each of the components are named “items” in the REST API.

A simple system would have the following structure:

In this system, the Controller, Signal Conditioners, Modules and channels are all items. They are all accessible resources in the REST API. Most items will have settings that can be modified, some might not have any. Settings on the Parent item might have an impact on the performance or configuration of the Children.

The /system/settings endpoint will present all the items in a tree data structure. The /item/list will present all items in the system (without their settings) in a linear list.

It is recommended that Users begin by configuring measurements at the root node and working their way down the tree.

Supported items

Item types

Supported controllers

Supported signal conditioners

Supported modules

Supported channels

Operation Modes

QuantusSeries devices are feature-rich and thus have a lot of settings. To ease configuration, settings are grouped into “operation modes”. These modes will change the mode of operation of an item (Module or channel) and allow Users to change a subset of settings relevant to that mode.

Here is a sequence diagram of a typical setup using operation modes:

Channel Endpoints

Sensor TEDS Read

QuantusSoftware can query the Dallas/Maxim memory chips included in sensors compliant with the IEEE 1451.4 TEDS standard. The information returned by QuantusSoftware is a byte array containing the contents of the memory chip.

TEDS data is very compact and not byte aligned. Each field has a specific bit length and decoding method as described in the standard. QuantusSoftware does not interpret the information in the byte array. This must be done by the software receiving the QuantusSoftware TEDS response.

A channel’s TEDS data can be obtained by calling the GET /tedsInfo endpoint. The endpoint will return the TEDS data in a JSON byte array:

{
    "Name": "TEDS",
    "Value":    [40, 129, 35, 200, 0, 0, 0, 80, 0, 255, ... , 255]
}

Channel Auto-Zero

The channel Auto-Zero can be used to clear and zero any offsets present within the channel hardware only (system) or the entire signal channel (system and sensor).

After a channel Auto-Zero, each channel will be restored to pre-Auto-Zero channel settings.

Channel Auto-Zero settings can be obtained by reading from the /autoZero/settings endpoint. The settings can be applied by updating the setting with the /autoZero/settings endpoint and calling /autoZero/settings/apply. Auto-Zero settings can be seen as an action that can be applied if there is a perceived offset in the data:

Here is a sequence diagram of a typical Auto-Zero action:

Item Settings

Controller

Controller Item Description

The Controller Item is the main entry point for the settings structure and is responsible for hosting the Signal Conditioning boards, Modules and Channels.

Depending on the configuration, the Controller board might have additional features:
* WiFi for remote access
* SSD for local storage
* Battery for an uninterrupted power supply

Operation Mode

Gets or sets the Controller operation mode. The active Module operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

Enabled Settings

This operation mode will set the Controller in a “powered on” state. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

ALO42S4

Module Item Description

The ALO42S4 Module provides four independent output channels for the generation of analog signals. Each channel also incorporates Status Input and Output signals, enabling further communication with external equipment for applications such as test supervision or workflow control.

The Module can be used for applications such as:

• Excitation signals for shaker / modal testing
  
• Drive signals for acoustic testing
  
• Arbitrary analog signals to feed into other circuits requiring ±10 V static or dynamic signals
  
• Output the sampled data stream from a Module installed to the left.

Operation Mode

Gets or sets the Module operation mode. The active Module operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

Enabled Settings

This operation mode will set the Module in a “powered on” state and allow use of the built-in function generator.
The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Mirror Left Module Settings

This operation mode will set the Module in a “powered on” state and stream the sampled data of the Module to the left. Some restrictions do apply:

• The ALO42S4 should be installed in either SC slot 2 or 4
  
• It can only stream data from the Module directly to its left
  
• All 4 channels will be Enabled and cannot be Disabled
  
• No settings or Operation Mode can be set to the channels

The channel mapping will recursively assign the data stream from first Enabled channel of the Module to the left, to the first available channel on the ALO42S4. Disabled channels are not assigned and skipped over.
The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Arbitrary Waveform Settings

This operation mode will set the Module in a “powered on” state and allow streaming of user provided data.
The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Additional endpoints

Some additional endpoints are available for this Item node.

GetBlockSize

This endpoint returns block size required by the module. When streaming data the user will be required
send at least the block size number of bytes.

Channel Item Description

Each channel operates independently from one another. Some restrictions do apply:

• Grounding configuration on the Module affects all channels.

Operation Mode

Gets or sets the channel operation mode. The active channel operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

DC Generator Settings

This operation mode will configure the signal generator for a DC waveform. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Sine Wave Generator Settings

This operation mode will configure the signal generator for an AC waveform. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Square Wave Generator Settings

This operation mode will configure the signal generator for a square waveform. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Triangular Wave Generator Settings

This operation mode will configure the signal generator for a triangular waveform. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

White Noise Generator Settings

This operation mode will configure the signal generator for a white noise waveform. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Mirror Left Module Settings

This operation mode will configure the signal generator to stream the sampled data from the Module to the left. The data samples are scaled to half of the 10 Vpp full scale output. As an example: for a 10 V input range the mirrored signal will be scaled to 5 V on the ALO42S4 channel, 100 mV input range will also be scaled to 5 V. This allows the ALO42S4 to generate signal which matches the full dynamic range of the sampling channel.
There are no settings available.

Streaming Settings

This operation mode allows the user to continuously stream data samples.

Buffered Settings

This operation mode allows the user to preload data samples.

Additional endpoints

Some additional endpoints are available for this Item node.

GetPortNumber

This endpoint returns the port number to which a client needs to connect in order to stream data to
the ALO42S4 channel. Note the port number is dynamic, so always query it before connecting.

ClearData

This endpoint clears the data in the streaming buffer, effectively returning the data stream to the
chosen fallback mechanism.

ALO450

Module Item Description

The ALO450 Module provides four independent output channels for the generation of analog signals. Each channel also incorporates Status Input and Output signals, enabling further communication with external equipment for applications such as test supervision or workflow control.

The Module can be used for applications such as:

• Excitation signals for shaker / modal testing
  
• Drive signals for acoustic testing
  
• Arbitrary analog signals to feed into other circuits requiring ±10 V static or dynamic signals
  
• Output the sampled data stream from a Module installed to the left.

Operation Mode

Gets or sets the Module operation mode. The active Module operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

Enabled Settings

This operation mode will set the Module in a “powered on” state. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Mirror Left Module Settings

This operation mode will set the Module in a “powered on” state and stream the sampled data of the Module to the left. Some restrictions do apply:

• The ALO450 should be installed in either SC slot 2 or 4
  
• It can only stream data from the Module directly to its left
  
• All 4 channels will be Enabled and cannot be Disabled
  
• No settings or Operation Mode can be set to the channels

The channel mapping will recursively assign the data stream from first Enabled channel of the Module to the left, to the first available channel on the ALO450. Disabled channels are not assigned and skipped over.
The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Arbitrary Waveform Settings

This operation mode will set the Module in a “powered on” state and allow streaming of user provided data.
The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Additional endpoints

Some additional endpoints are available for this Item node.

GetBlockSize

This endpoint returns block size required by the module. When streaming data the user will be required
send at least the block size number of bytes.

Channel Item Description

Each channel operates independently from one another. Some restrictions do apply:

• Grounding configuration on the Module affects all channels.

Operation Mode

Gets or sets the channel operation mode. The active channel operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

DC Generator Settings

This operation mode will configure the signal generator for a DC waveform. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Sine Wave Generator Settings

This operation mode will configure the signal generator for an AC waveform. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Square Wave Generator Settings

This operation mode will configure the signal generator for a square waveform. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Triangular Wave Generator Settings

This operation mode will configure the signal generator for a triangular waveform. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

White Noise Generator Settings

This operation mode will configure the signal generator for a white noise waveform. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Mirror Left Module Settings

This operation mode will configure the signal generator to stream the sampled data from the Module to the left. The data samples are scaled to half of the 10 Vpp full scale output. As an example: for a 10 V input range the mirrored signal will be scaled to 5 V on the ALO450 channel, 100 mV input range will also be scaled to 5 V. This allows the ALO450 to generate signal which matches the full dynamic range of the sampling channel.
There are no settings available.

Streaming Settings

This operation mode allows the user to continuously stream data samples.

Buffered Settings

This operation mode allows the user to preload data samples.

Additional endpoints

Some additional endpoints are available for this Item node.

GetPortNumber

This endpoint returns the port number to which a client needs to connect in order to stream data to
the ALO42S4 channel. Note the port number is dynamic, so always query it before connecting.

ClearData

This endpoint clears the data in the streaming buffer, effectively returning the data stream to the
chosen fallback mechanism.

CAN42S2

Module Item Description

The CAN42S2 Module provides interfaces to two CAN or CAN FD (CAN with Flexible Data-Rate) busses. CAN FD is an extension of the original CAN (Controller Area Network) protocol, which allows for higher data bandwidth. Messages received from CAN are time-stamped to synchronize their reception with analog and digital measurements from other Modules in the system. A self-reception of sent messages is provided as well as two operational modes, Participate and Listen-Only mode.

The CAN42S2 Module features independent channel filtering and can be used:

• When monitoring CAN and CAN FD based messages
  
• When controlling CAN and CAN FD based devices

Operation Mode

The active Module operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

Channel Item Description

Each channel operates independently from one another. CAN FD is an extension of the original CAN (Controller Area Network) protocol, which allows for higher data bandwidth. Messages received from CAN are time-stamped to synchronize their reception with analog and digital measurements from other Modules in the system. A self-reception of sent messages is provided as well as two operational modes, Participate and Listen-Only mode.

Operation Mode

The active channel operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

Listen Only Settings

Listen Only mode means the CAN FD node will not acknowledge messages on the bus
in order to receive them. Only matching messages that are acknowledged by
some other node on the bus will be received. In addition, Listen Only mode means
that the node will not signal errors on the bus when they occur.

Participate Settings

Participate mode means the CAN FD node will acknowledge matching messages
so that they can be received, and will signal errors on the bus when they occur.

Additional endpoints

Some additional endpoints are available for this Item node.

GetTransmitMessageList

Returns the buffered messages queued to be sent on the bus.

SetTransmitMessageList

Sets the messages in a buffer which can be sent with the /canfd/message/transmit/ endpoint.

ClearTransmitMessageList

Clears the entire transmit message buffer.

GetBusStatus

Gets the status of the bus in order to check if the bus is healthy.

CAN450

Module Item Description

The CAN450 Module provides interfaces to two CAN or CAN FD (CAN with Flexible Data-Rate) busses. CAN FD is an extension of the original CAN (Controller Area Network) protocol, which allows for higher data bandwidth. Messages received from CAN are time-stamped to synchronize their reception with analog and digital measurements from other Modules in the system. A self-reception of sent messages is provided as well as two operational modes, Participate and Listen-Only mode.

The CAN450 Module features independent channel filtering and can be used:

• When monitoring CAN and CAN FD based messages
  
• When controlling CAN and CAN FD based devices

Operation Mode

The active Module operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

Channel Item Description

Each channel operates independently from one another. CAN FD is an extension of the original CAN (Controller Area Network) protocol, which allows for higher data bandwidth. Messages received from CAN are time-stamped to synchronize their reception with analog and digital measurements from other Modules in the system. A self-reception of sent messages is provided as well as two operational modes, Participate and Listen-Only mode.

Operation Mode

The active channel operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

Listen Only Settings

Listen Only mode means the CAN FD node will not acknowledge messages on the bus
in order to receive them. Only matching messages that are acknowledged by
some other node on the bus will be received. In addition, Listen Only mode means
that the node will not signal errors on the bus when they occur.

Participate Settings

Participate mode means the CAN FD node will acknowledge matching messages
so that they can be received, and will signal errors on the bus when they occur.

Additional endpoints

Some additional endpoints are available for this Item node.

GetTransmitMessageList

Returns the buffered messages queued to be sent on the bus.

SetTransmitMessageList

Sets the messages in a buffer which can be sent with the /canfd/message/transmit/ endpoint.

ClearTransmitMessageList

Clears the entire transmit message buffer.

GetBusStatus

Gets the status of the bus in order to check if the bus is healthy.

CHG42S9

Module Item Description

The CHG42S9 Module has 4 independent input channels for Quartz or Piezoelectric Ceramic sensors.
These sensors are typically used when improved signal performance such as low noise and low distortion
is required or where high temperature or nuclear radiation prevents the use of ICP® based sensors.
Various grounding options allow for low noise measurements regardless of external grounding constraints.
The Module can be used with:
* Piezoelectric sensors commonly used to measure vibration, acceleration, force, torque and pressure

Operation Mode

The active Module operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

Enabled Settings

This operation mode will set the Module to a “powered on” state and will enable data streaming. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Channel Item Description

Each channel operates independently from one another. Some restrictions do apply:

• All channels have the same sample rate.
  
• Module Grounding configuration affects all channels.

Operation Mode

The active channel operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

Charge Input Settings

This operation mode is often used with piezoelectric sensors to measure vibration, acceleration, force, torque and pressure.The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

CHS42X4

Module Item Description

The CHS42X4 Module can be used with ICP® based accelerometers, force and pressure sensors, quartz or piezoelectric ceramic sensors or to measure analog voltages.

The Module can be used with:

• With any ICP® based sensor commonly used to measure vibration, acceleration, force or pressure
  
• With piezoelectric sensors commonly used to measure vibration, acceleration, force, torque and pressure
  
• With any voltage source up to ±10 V in voltage input mode

Operation Mode

The active Module operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

Enabled Settings

This operation mode will set the Module to a “powered on” state and will enable data streaming. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Four Channel High Sample Rate Settings

This operation mode will set the Module to a “powered on” state, and will enable a higher sampling rate for data streaming at the cost of disabling channel 2 and 5. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Channel Item Description

Each channel operates independently from one another. Some restrictions do apply:

• All channels have the same sample rate.
  
• Grounding configuration affects all channels.
  
• Channel 1, 2 and 3 are limited to the same operation mode, as well a channel 4, 5 and 6.

Operation Mode

The active channel operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

Voltage Input Settings

This operation mode is often used when measuring voltage sources without the use of sensors. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

ICP® Input Settings

This operation mode is often used when measuring ICP® based accelerometers, force and pressure sensors. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Charge Input Settings

This operation mode is often used with piezoelectric sensors to measure vibration, acceleration, force, torque and pressure.The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

DCH42S2

Module Item Description

The DCH42S2 Module has 2 independent input channels for Quartz or Piezoelectric Ceramic sensors. These sensors are typically used when improved signal performance such as low noise and low distortion is required or where high temperature or nuclear radiation prevents the use of ICP® based sensors. Differential piezoelectric output sensors have all the advantages of single ended piezoelectric output sensors with the additional advantages of improved electromagnetic immunity, ground isolation and double the sensitivity.

The Module can be used:
• With differential and single ended piezoelectric sensors commonly used to measure vibration, acceleration, force, torque and pressure.

Operation Mode

The active Module operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

Enabled Settings

This operation mode will set the Module to a “powered on” state and will enable data streaming. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Channel Item Description

Each channel operates independently from one another. Some restrictions do apply:

• All channels have the same sample rate.
  
• Grounding configuration on the Module node affects all channels.

Operation Mode

The active channel operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

Differential Input Settings

This operation mode is often used with differential piezoelectric sensors. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Single Ended Input Settings

This operation mode is often used with single ended piezoelectric sensors. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

DCH450

Module Item Description

The DCH450 Module has 2 independent input channels for Quartz or Piezoelectric Ceramic sensors. These sensors are typically used when improved signal performance such as low noise and low distortion is required or where high temperature or nuclear radiation prevents the use of ICP® based sensors. Differential piezoelectric output sensors have all the advantages of single ended piezoelectric output sensors with the additional advantages of improved electromagnetic immunity, ground isolation and double the sensitivity.

The Module can be used:
• With differential and single ended piezoelectric sensors commonly used to measure vibration, acceleration, force, torque and pressure.

Operation Mode

The active Module operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

Enabled Settings

This operation mode will set the Module to a “powered on” state and will enable data streaming. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Channel Item Description

Each channel operates independently from one another. Some restrictions do apply:

• All channels have the same sample rate.
  
• Grounding configuration on the Module node affects all channels.

Operation Mode

The active channel operation mode can be retrieved by reading from the /operationMode/ and modified by writing to the /operationMode/ endpoint. See the tables below for all supported mode options and mode settings.

Differential Input Settings

This operation mode is often used with differential piezoelectric sensors. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

Single Ended Input Settings

This operation mode is often used with single ended piezoelectric sensors. The settings below can be retrieved by reading from the /itemSettings/ and modified by writing to the /itemSettings/ endpoint.

FLX422

Module Item Description

The FLX module provides an interface to connect to a FlexRay network. FlexRay is a very fast, deterministic,
and fault-tolerant protocol that could satisfy the speed, reliability, and safety requirements of such
applications as brake-by-wire and steer-by-wire.

Module Item

Represents the configuration settings for the FLX422 module,
defining operational modes and their specific settings.

Additional endpoints

Some additional endpoints are available for this Item node.

GetDefaultSettings

Retrieves the default settings for the module.

GetOperationMode

Retrieves the current operation mode for the module and indicates whether the settings have been applied.