Xtreme Power Systems

Untitled Document

Developer Support

Shopping cart

0 Product(s) in cart

Total $0.00

» Checkout

XtremeLink® Telemetry Developer

Information Guide

You are welcome to link to this data, but please do not post it anywhere. We will make numerous improvements and we want the most up to date information available to our customers.

The developer package is now available! Click here to download it. The developer package includes a schematic, circuit board artwork, and source code for a functioning dual sensor setup.

------------------------------------------------------
History
------------------------------------------------------

v1.0 - 08/06/08

First release.

v1.1 - 08/07/08

Changed ReqsPerSec variable to TelRate, which reflects
a more accurate meaning for the variable.

v1.2 - 08/07/08

Fixed RPM sensor circuitry and schematic. New schematic
and PCB files.

v1.3 - 08/08/08

Changed schematic and board to support both positive
and negative going pulses for the RPM input.

V1.4 - 08/16/08

Fixed problem with ground trace on PCB. Previous versions must add a wire from GND to ground terminal on the push button switch. It was not possible for the switch to function without this trace. This problem was caused by clearing of solder pour around J1, done to prevent possible shorting. Fixed DDRC issue with source code.

Overview

The XtremeLink® telemetry system interface consists of power, ground, and a 1-wire high speed serial bus. Power is provided by the receiver's servo bus and can be anything from 3.5v to 30v. It is highly recommended that your sensor electronics be powered with 3.3v by using an ultra-low dropout regulator. This will yield the best results and least amount of cost. The communication protocol is standard serial (8-N-1) at 125000 baud. 125000 baud is 8us per bit. Each byte of data requires 80us of time. Inherent delays between bytes are normal, and should not exceed 20us between bytes being sent/received. These delays are generally necessary for the call/return of the transfer routine as well as loading/saving the data.

The serial interface is open collector. There is a 10K pull-up resistor on the receiver's telemetry port. This port line is pulled up to 3.3v by this resistor. Sensors MUST only drive the line LOW during communications. You can NEVER pull the line HIGH. The only exception would be when using another serial interface port that is also 3.3v compatible (such as a PIC16F688's serial port when powered at 3.3v). Sensors can NEVER communicate with the receiver unless they are told to. All devices must remain off the bus until called upon.

Cable length for the sensors should be kept as short as necessary. We have tested multiple sensors through 30 feet of cable with no issues, but RF and other noise can enter through excessive wire lengths, so some care must be taken.

Sensors are assigned ID's during the learning process. When the learning mode is entered, the receiver issues the command "InitMode" to all devices on the bus. At this point, all devices should turn on their status LED and enter learning mode. When the button on a sensor is pressed, the sensor will send the command "Request Device ID" to the receiver. This command asks the receiver to assign the sensor an ID number. The receiver then responds with an ID number that the sensor will store and use during normal operation. Sensors with multiple functions will need to send the "Request Device ID" command for each function. For example, if your sensor package contained a RPM sensor and a temperature sensor (like our example), then you would send the "Request Device ID" command, wait for the response, and repeat for the 2nd sensor. There is no need to use multiple button pushes.

The receiver will only wait 1ms for a sensor to respond to any data request, so it is important that you handle the communications efficiently as possible. We recommend that the communications be interrupt driven to insure a speedy response. Our example sensor uses a polled configuration to show that it can be done this way, it is just not as efficient.

Testing & Debugging Sensors

Since 125000 is a non-standard baud rate for most PC's, you probably will not be able to use the COM port for debugging sensors. The easiest method for testing sensors is by using a USB<>serial cable. We recommend using the TTL-232R-3V3 from FTDI. Click here for details. This device allows you to set virtually any baud rate and uses 3.3v lines. You will need to use a diode to bridge the Tx and Rx lines together in order to have the proper 1-wire interface. The anode of the diode connects to the yellow wire and the cathode connects to the orange wire. The orange wire is the serial I/O line.

Once you have the proper serial connection, you can send commands and receive data via a terminal program. We use MaxStream's XCTU software available here. It has the ability to create packets, display hex and ASCII data, etc.

Note: The XDP.EXE program now has a developer tool in the TELEMETRY advanced option! You can send/receive packets and test sensors without having to use the cable as described above!

Command Packet Structure

Packets are made up of at least 4 bytes of data, but could contain many bytes depending on the command itself.

Input commands will always have bit 7 set (0x80, 0x81, 0x92, etc.). Output commands will always have bit 7 clear (0x40, 0x41, 0x52, etc.).

The packet structure consists of the Command, the Device ID, the Data Length, the Data, and the Checksum. For example, the 4 byte "InitMode" packet sent by the receiver to initialize all devices looks like this:

0x80, 0xFF, 0x00, 0x80

Command (0x80), Device ID (0xFF), Length (0x00), [Data], Checksum (0x80)

Command is the command being received or sent. In this case, it is the input command "InitMode".

Device ID is the sensor ID. In this example, it is set to 0xFF which means "broadcast packet". A broadcast packet is one that is responded to by ALL sensors. Normally, the Device ID acts as a filter for the incoming commands. Only commands with the sensor's Device ID can be responded to.

Length is the length of the data. In this case, there is no data so the length is zero. Some commands will pass information and the data length is required.

Data is the data that being sent or received, if there is any. In this example, there is no data, so the Data Length is 0 and no Data is present. The maximum length allowed is 77 bytes.

Checksum is the 8 bit CRC calculated by adding all the bytes in the packet, and then taking the low byte and exclusive OR'ing it with 0xFF. The Checksum is calculated as:

Command + Device ID + Length + (n) Data Bytes + Checksum

In our example,

0x80 + 0xFF + 0x00 = 0x17F (masking off the lower byte yields 0x7F)

0x7F XOR 0xFF = 0x80 (CRC)

OUTPUT PACKETS:

0x40 - Reserved

______________________________________________________________________

0x41 - Request Device ID

Request for a Device ID to be assigned to the sensor. This is used
during the initialization mode (0x80).

The Class defines the type of sensor. See Class list below.

Command (0x41), Device ID (0xFF), Length (1), Class (X), CRC
______________________________________________________________________

0x42 - Sensor Data

Sensor data sent by request (0x82).

Command (0x42), Device ID (DevID), Length (3+n), Class (X), Output Type (X),
Output Format (X), Data Bytes * n, CRC

______________________________________________________________________

0x43 - Vendor Info

The sensor's vendor information sent by request (0x83).

Command (0x43), Device ID (DevID), Length (n), Data Bytes * n, CRC

______________________________________________________________________

0x44 - Sensor Configuration Data

The sensor's output type and data format information sent by request (0x84).

Command (0x44), Device ID (DevID), Length (2), Output Type, Output Format, CRC

______________________________________________________________________

INPUT PACKETS:

0x80 - Init Mode

This command puts the sensor into initialization mode, required to
obtain a device ID from the receiver. The device ID is used when
communicating. A broadcast Device ID is used.

Command (0x80), Device ID (0xFF), Length (0), Checksum (CRC)

______________________________________________________________________

0x81 - Assign Device ID

This packet contains the Device ID that is to be used to distinguish
the sensor from any others during communications. The number of
requests per second for the sensor is also given.

Command (0x81), Device ID (DevID), Length (1), Requests per second, CRC

______________________________________________________________________

0x82 - Request Sensor Data

This packet requests the sensor's data to be sent.

Command (0x82), Device ID (DevID), Length (0), CRC

______________________________________________________________________

0x83 - Request Vendor Info

This packet requests the sensor's vendor ID string information.

Command (0x83), Device ID (DevID), Length (0), CRC

______________________________________________________________________

0x84 - Request Sensor Configuration

This packet requests the sensor's output type and output format information.

Command (0x84), Device ID (DevID), Length (0), CRC

______________________________________________________________________

Telemetry Sensor Class Definitions

0x00-0x0F Voltage class
0x00 Receiver voltage (always present)
0x01 Battery 1
0x02 Battery 2
0x03 Battery 3
0x04 Battery 4
0x05 Motor supply 1
0x06 Motor supply 2
0x07 Motor supply 3
0x08 Motor supply 4
0x09-0x0F Not defined

0x10-0x1F Amperage class
0x10 Motor 1
0x11 Motor 2
0x12 Motor 3
0x13 Motor 4
0x14 Servo 1
0x15 Servo 2
0x16 Servo 3
0x17 Servo 4
0x18 Servo 5
0x19 Servo 6
0x1A Servo 7
0x1B Servo 8
0x1C Misc. 1
0x1D Misc. 2
0x1E Misc. 3
0x1F Misc. 4

0x20-0x2F Temperature class
0x20 Ambient
0x21 External 1
0x22 External 2
0x23 Motor 1/Engine 1
0x24 Motor 2/Engine 2
0x25 Motor 3/Engine 3
0x26 Motor 4/Engine 4
0x27 EGT 1
0x28 EGT 2
0x29 EGT 3
0x2A EGT 4
0x2B Battery 1
0x2C Battery 2
0x2D Battery 3
0x2E Battery 4
0x2F Misc. 1

0x30-0x3F Pressure class
0x30 Air tank 1
0x31 Air tank 2
0x32 Air tank 3
0x33 Air tank 4
0x34 Retract 1
0x35 Retract 2
0x36 Retract 3
0x37 Retract 4
0x38 Brake 1
0x39 Brake 2
0x3A Brake 3
0x3B Brake 4
0x3C Misc. 1
0x3D Misc. 2
0x3E Misc. 3
0x3F Misc. 4

0x40-0x4F Level class (liquid level)
0x40 Fuel tank 1
0x41 Fuel tank 2
0x42 Fuel tank 3
0x43 Fuel tank 4
0x44 Smoke tank 1
0x45 Smoke tank 2
0x46-0x4F Not defined

0x50-0x5F G-Force class
0x50 X-axis
0x51 Y-axis
0x52 Z-axis
0x53-0x5F Not defined

0x60-0x6F Position class
0x60 Slider 1
0x61 Slider 2
0x62 Slider 3
0x63 Slider 4
0x64-0x6F Not defined

0x70-0x7F Altitude class
0x70 Altitude 1
0x71 Altitude 2
0x72 Altitude 3
0x73 Altitude 4
0x74-0x7F Not defined

0x80-0x8F Speed class
0x80 Airspeed 1
0x81 Airspeed 2
0x82 Airspeed 3
0x83 Airspeed 4
0x84 Hall Speed 1
0x85 Hall Speed 2
0x86 Hall Speed 3
0x87 Hall Speed 4
0x88 Encoder Speed 1
0x89 Encoder Speed 2
0x8A Encoder Speed 3
0x8B Encoder Speed 4
0x8C Misc. 1
0x8D Misc. 2
0x8E Misc. 3
0x8F Misc. 4

0x90-0x9F GPS class
0x90 GPS1
0x91 GPS2
0x92-0x9F Not defined

0xA0-0xAF RPM class
0xA0 Motor 1/Engine 1
0xA1 Motor 2/Engine 2
0xA2 Motor 3/Engine 3
0xA3 Motor 4/Engine 4
0xA4-0xAF Not defined

0xD0-0xDF Lock class
0xD0 Gear
0xD1 Gear door 1
0xD2 Gear door 2
0xD3 Gear door 3
0xD4 Gear door 4
0xD5 Gear door 5
0xD6 Gear door 6
0xD7 Canopy
0xD8 Top hatch
0xD9 Bottom hatch
0xDA-0xDF Not defined

0xE0-0xEF Special class
0xE0 Turbine GSU Display
0xE1 Stall sensor
0xE2 Attitude sensor

0xF0-0xFF Reserved for XPS

Untitled Document

Untitled Document

home | products | search | checkout | contact