Introduction

The VictoR Core Library will provide a standardized, user-friendly set of interfaces and base classes for interacting with the various services within an FN VictoR device without needing to reference an ICD to figure out the low-level details required for those interactions. To facilitate the development of those interfaces, a common Base Service class will be created with the intent of providing a common set of methods and fields that utilize the device communication interfaces, as well as any common data to be shared among any services that inherit from this base service.

Requirements

https://unity3d.atlassian.net/wiki/spaces/FNUPEXT/pages/1584529409/Software+Requirements#4.-Device-Information-Service

https://unity3d.atlassian.net/wiki/spaces/FNUPEXT/pages/1584529409/Software+Requirements#5.-Device-Configuration-Service

https://unity3d.atlassian.net/wiki/spaces/FNUPEXT/pages/1584529409/Software+Requirements#6.-Object-Transfer-Service

Related Jira Issues

FNSDKEXT-74 - Getting issue details... STATUS

Constraints

Performance

Read/Write calls to a VictoR device are time intensive I/O operations. The Services should not block and force the end-user to wait for the operations to complete.

OS Abstraction

End-users should not have to directly interact with OS-specific APIs to communicate with a VictoR device. The Base Service, and by extension all Derived Services, should abstract away the OS-specific implementation details and only provide the end-user with the data that they are interested in.

Ease of Use

End-users should not have to operate on data in binary form. The Derived Services should provide ordered, human-readable data structures that will be serialized into binary data when sending to a device, and deserialized from binary data from when receiving from a device.

Detailed Design

The Base Service will provide the common data inherited by derived Services, including the common portion of service and attribute UUIDs. It will also provide common functions that every derived service will need, such as the ability to read and write binary data to a particular device attribute using the device manager, and subscribing and unsubscribing from notifications of changes for a particular device attribute using the device manager. Derived services will maintain a set of enumerations that map to all supported attributes relevant to that service to its underlying UUID, which will be used in conjunction with the provided read/write/subscribe/unsubscribe functions. All I/O operations to/from a VictoR device are performed in a non-blocking, asynchronous manner. In addition, the Base Service provides end-users with the ability to set and get a Current Device, which is the device that will be used for communication if no device is specified in a read/write operation. This allows the end-user to just set the device once and perform any number of read/write operations on that device, without having to manually specify the same device for each call.

System Interaction

The sequence diagram below in figure 2 illustrates the typical sequence of events when an end-user’s application uses the SDK to retrieve data from a VictoR device. In this example, the end-user makes a call to the Device Information Service to retrieve the CPU Utilization. This function has knowledge of which particular attribute ID this data corresponds to, and uses that information along with the provided device ID (if provided - otherwise it uses the Current Device ID) to call into the Base Service. The Base Service uses the Device Manager to request a read of the specified attribute from the specified device ID. The Device Manager takes that request, looks up the matching Device from its internal map of devices, and forwards the request to that device. The Device in turn requests a read of the specified attribute from a VictoR Device over the underlying communications protocol (which is determined by the particular Device that was constructed). This sequence of function calls is non-blocking, so that the end-user is not left blocked waiting for the device to respond with the data. Once the physical device has finished processing the request and the data has been successfully transmitted back to the Device, it is propagated back up to the Device Information Service in its serialized binary form. The original function used to retrieve the CPU Utilization contains logic to deserialize the the data from its binary form into a CPU Utilization data structure that is then finally returned to the end-user.

Glossary