10
Freescale Semiconductor Communication Protocol Rev. 0.1, 11/2013 Applications Communication Protocol Rev 0.1 © 2013 Freescale Semiconductor, Inc. All rights reserved.

Altimeter and ECG Application Protocol

Embed Size (px)

DESCRIPTION

Altimeter and ECG Application Protocol

Citation preview

Page 1: Altimeter and ECG Application Protocol

Freescale Semiconductor

Communication Protocol Rev. 0.1, 11/2013

Applications Communication Protocol Rev 0.1

© 2013 Freescale Semiconductor, Inc. All rights reserved.

Page 2: Altimeter and ECG Application Protocol

1 Packet Structure

This protocol is implemented in both applications Altimeter and ECG. Packets are of variable length. The first five components in the protocol structure describe the packet and all the remaining bytes are application data. Following image represents the packet structure.

1.1 Class Type

This value describes the class type of the application.

Size: 1 ByteValid Types:

Audio 0x01Sensor 0x02Medical 0x03

1.2 Application Type

This value describes the application type and will be related with the selected class type. For now there are just three applications types.

Size: 1 ByteValid Types:

Audio Class Sensor Class Medical ClassPressure Sensor (Altimeter) 0x01 Electrocardiography

(ECG)0x01

AccelerometerSensor

0x02 Pulse Oximetry (SPO2) 0x02

Heart Rate (BPM) 0x03Glucosimeter (GLU) 0x04

1.3 Packet Type

Communication Protocol, Rev. 0.1 Page 2 of 9

Page 3: Altimeter and ECG Application Protocol

Packet type indicates what kind of packet is being sent or received. There are three possible types of packet.

Request Packet: This type of packet can only be generated by the host GUI. It indicates to the device that host GUI is sending a request (i.e. start sending measurements).

Confirmation Packet: This type of packet can only be generated by the device. It indicates to the host GUI that a request has been received and its status (i.e. start sending measurements request has been received but the device is busy).

Indication Packet: This type of packet can only be generated by the device. It indicates to the host that some event has occurred and needs to send information

Size: 1 ByteValid Types:

Request Packet (REQ) 0x52Confirmation Packet (CFM) 0x43Indication Packet (IND) 0x69

1.4 Command Opcode

It contains the request, confirmation or indication type. Following table shows the hexadecimal codes for the Command Opcodes as well as their function and type of packets that can use them.

Size: 1 ByteValid Types:

Description HEX Code REQ CFM INDRequest to start sending measurements 0x12 X XRequest to stop sending measurements 0x13 X XIndicates that new data is ready and information is in the package 0x14 X

1.5 Data length

This number represents the total quantity of application data received or transmitted in the package.

Size: 2 BytesValid values: 0 - 65535

1.6 Application Data

Communication Protocol, Rev. 0.1 Page 3 of 9

Page 4: Altimeter and ECG Application Protocol

Application Data: This is the information itself. It can contain confirmation codes or application data like graph points or processed measurements (i.e. heart frequency). Application data have different interpretation depending on the application.

Size: max 65535 bytesValid values: Any

Communication Protocol, Rev. 0.1 Page 4 of 9

Page 5: Altimeter and ECG Application Protocol

2 Start and Stop Communication for Application

Device always starts in an idle state. Host GUI must start communications sending a Start Measurement Request. A request packet might look like the following image that is an example of and ECG device.

Once received, the device will confirm to the host that the request has been received. It will generate a confirmation packet with the same Command Opcode and one Application Data byte indicating the device status. Packet might look like the following.

There are three types of status. Table is shown below.

Status HEX CodeOK 0x00

BUSY 0x01INVALID OPCODE 0x02

Once started, the device will send packets containing information. These packets will be of the IND packet type and will be sent every time the device has finished processing information. An example of an IND packet is shown below.

In order to finish the communication, the host GUI musts send a Stop Measurement request to the device otherwise it will keep sending IND packets with information. The Stop Measurement request is represented by the image below.

The device must confirm the request sending a confirmation packet with the same Command Opcode. An example is shown below.

Communication Protocol, Rev. 0.1 Page 5 of 9

Page 6: Altimeter and ECG Application Protocol

Communication Protocol, Rev. 0.1 Page 6 of 9

Page 7: Altimeter and ECG Application Protocol

3 ECG IND packet data

As mentioned before, each application has its own interpretation of the data contained in the IND packets.

Data Length contains the number of Application Data bytes in the packet. The Application Data bytes are divided in three sections: Packet ID, Graph Data and Heart Rate Value

This package will be sent by the accessory to the device 30 times per second and will contain 4 graph points besides the Packet ID and Heart Rate this is to arrange 120 data points per second that will help to have an acceptable ECG graph quality.

Total Data length: 11 bytes

3.1 Packet ID

The first two bytes after the Data Length represent the Packet ID. The Packet ID is a 16-bit ID number that prevents the host GUI of data lost. The packet ID of the current packet must be equal to the packet ID of the previous packet + 1. For example, if the packet ID of the previous packet was 0X00 0XFF, the packet ID of the current packet must be 0X01 0x00.

Size: 2 BytesValid values: 0 - 65535

3.2 Graph Data

After the Packet ID bytes, the following bytes represent the graph points. Each graph point is an unsigned 16-bit value composed by two bytes of the Application data bytes. The first byte of each graph point is the High byte and the second byte is the Low byte. Each point of the graph is considered to be taken each 1mS.

The graph information starts after the Packet ID bytes and each package will have 4 graphs points this means that the Graph Data length for this application will be 8 bytes

Size: 8 BytesValid values: 0 – 65535 per graphical point

3.3 Heart Rate

This is the last byte of the packet. It is a numeric value that corresponds to the Heart Rate value. For example, receiving 0x50 in the last byte means a heart rate of 80bpm.

Size: 1 Byte

Communication Protocol, Rev. 0.1 Page 7 of 9

Page 8: Altimeter and ECG Application Protocol

Valid values: 0 - 511

Communication Protocol, Rev. 0.1 Page 8 of 9

Page 9: Altimeter and ECG Application Protocol

4 Altimeter IND packet data

Due the Altimeter has not a critical timing due the slow changes at least in this application the package does not has a establish timing to send the information.

The application data bytes are divided in two sections Altitude and Temperature separated with a byte these values are signed values that use A2 complement for negative values.

Total Data length: 6 bytes.

4.1 Altitude

The first two bytes after the Data Length was the integer Altitude value, the next one has the fractional Altitude value.

Size: 3 BytesValid values:

4.2 Temperature

After the byte used to separate the values is located the integer Temperature value, the next one has the fractional Temperature value.

Size: 2 BytesValid values:

Communication Protocol, Rev. 0.1 Page 9 of 9