Introduction

The aim of this project is to offer user-friendly measurement and automation system. As you know, VISA, which stands for Virtual Instrument Software Architecture, is a industry standard library for this purpose. It provides the programming interface between application software and measurement instruments using GPIB, USB, LAN and/or UART. Although this solution is very practical and widely used in production line, it doesn't meet the basic requirements for DIY projects. This is because it is relatively large-scale system, and specifications are totally controlled by measuring instruments manufacturers. First of all, it usually depends on proprietary software released by vendors. This makes it difficult for you to build automation system with user program or a new gadget created by yourself.

https://cdn.hackaday.io/images/3873681460983902652.png

Therefore, I decided to make both of a simple multimeter/logger named as Luke and open source SDK which supports multi-platform. Luke doesn't even have display nor any control button. It should be connected to PC or smartphone via USB, and then application software or command line tool controls it and acquire data. I'm trying to make it simple as much as possible to improve usability and flexibility. For example, you don't have to install device driver because Luke is recognized as HID. Also, APIs for C++/Python will be prepared for users. It will be available to make your own measurement system based on this project. Please see below for the details.

Luke specifications

Hardware

Measurement

Host Interface

License

Firmware

Cross Platform SDK

Features

License


Implementation


Communication protocol

How to talk PC software and device firmware is always big issue. It is not too much to say that design of this part determines whether a product connected to PC is valuable or not. For my products, I designed new protocol named TBI, ToolBit Interface, to exchange data by simple messages. This protocol has something in common with GATT for BLE (Bluetooth Low Energy). Firstly, a host computer and a device have different roles. A host works as client to send a command to server in order to read/write a value. On the other hand, a device works as server to response a command from client. In addition, a fundamental unit handling read/write data is called attribute. The data stored in attribute can have any type like int, char, float, etc, but the max length of data is limited to 32-byte. Each attribute is indexed by a unique 2-byte number, attribute ID. For example, a product name stored in firmware is defined as follows as:

Attribute
ID: 0x0000
value: "Luke"

This means you can get a product name by reading attribute ID:0x0000. The minimum set of commands to read/write attribute is defined for now as follows as:


OP_ATTR_VALUE_GET 

Client Command Packet Format 
| Header | OP Code | Attribute ID |
| 1-byte | 1-byte  | 2-byte       |

Server Response Packet Format
| Header | OP Code |Return Code| Attribute Value     |
| 1-byte | 1-byte  | 1-byte    | n-byte(conditional) |


OP_ATTR_VALUE_SET 

Client Command Packet Format 
| Header | OP Code | Attribute ID | Attribute Value     |
| 1-byte | 1-byte  | 2-byte       | n-byte(conditional) |

Server Response Packet Format
| Header | OP Code |Return Code|
| 1-byte | 1-byte  | 1-byte    |


Where header is defined as follows as:

Header
7-6bit: Protocol Version
5-0bit: Length of Packet (Max=64)