An Antilatency Device Network (ADN) determines the way of connecting Antilatency devices to each other as elements of a single network.

In this article

General Information

All Antilatency devices connected to the same Host create a network in the form of a device tree. The root point is the Host, and the other devices are considered Nodes. Each node of the device tree can execute a Task, which implements the functionality of this device. Each device has its own set of tasks.
ADN supports devices' connection via various protocols: USB, IP, SPI, Antilatency Radio Protocol, and provides data transfer from nodes to the Host and back. Additionally, ADN forms a device connection hierarchy and relieves the user from working out the details of their physical connection.

Interaction with ADN

To work with ADN, use the Antilatency.DeviceNetwork library. It allows you to receive and track changes in the list of connected devices, find devices, manage their properties, as well as run tasks and work with them.
For more information about working with the library refer to: Antilatency Device Network Library
The device tree is displayed in the Device Network tab in AntilatencyService app. Here you can read and edit the properties of any connected devices.

ADN example

A device tree for a full body VR set per 1 user might look like this:
Together, the devices form a network that can track the position of the user's body based on the positional data of five points.
The device tree in AntilatencyService for the described set looks like this:

Device tree

Within ADN, devices are organized as a tree. This tree structure repeats the structure of the devices physical connection. Each device in this tree is associated with a Node. When a device is connected, its node is assigned a unique number (NodeHandle) within the network. Node numbers in different ADN networks, even those created in the same executable process, may overlap. Therefore, many functions from Antilatency SDK accept the pair «ADN instance — node number in the network» as arguments, which serves as a unique device identifier.
A typical device tree looks like this:
The tree root is a virtual node with the number NodeHandle.Null. The children of the root are devices connected directly to the host via USB or IP network (it's the Universal Radio Socket in the diagram). The nodes of devices connected to them become the second level children, and so on. The device tree can be viewed in AntilatencyService.

Configuring properties

Each device in the ADN has properties that can be read, added, changed and deleted. They are stored on the device itself, hence are retained when reconnecting to ADN and when restarting the device itself.
For more information about device properties, their types and accepted conventions, refer to article.
In the AntilatencyService application, device properties can be viewed in the Device Network tab.
In the DeviceNetwork library, device properties are handled by IPropertyCotask. Besides it, there are also INetwork.nodeGetStringProperty and INetwork.nodeGetBinaryProperty methods, which return values from properties cache.

Properties cache

ADN caches properties of each Node. IPropertyCotask is launched implicitly between device connection and the first start of any task, and all properties are written to the cache. Later, when requesting nodeGetStringProperty and nodeGetBinaryProperty, the user gets values from the cache.
The values of some properties can be updated each time they are requested: for example, the device's temperature. If you need up-to-date data, you should request it using the IPropertyCotask from Antilatency Device Network Library.
The user can read any ADN node properties from the property cache, even if a Task is already running on that device. This allows you not to run a task for working with properties, when a continuous work of another task is required.
The device's property cache is updated by explicitly reading and overwriting properties during IPropertyCotask runtime.