WIRELESS ROTOCOL IOLab · 2017-01-24 · a. Operate in the 2.4 GHz RF band (allows worldwide marketing) b. Support data payload rate of 40 kbps (per dongle) c. Provide

WIRELESS PROTOCOL IOLab

Document Number 1814E11 Revision 3

Prepared for Macmillan Date: 10-Apr-2013, 8:56 AM

This document is the property of Indesign, LLC and is considered PROPRIETARY.

2012 Indesign, LLC. All rights reserved. 7.3.3-P01-808-T01, Rev 1

Page 1 of 30

WIRELESS PROTOCOL

Indesign, LLC 8225 East 56th Street

Indianapolis, IN 46216

Phone: 317.377.5450 FAX: 317.377.5455

http://www.indesign-llc.com IOLAB

DOCUMENT NUMBER REV Proprietary Page 2 of 30

1814E11 3

Document Change Notes

Rev Description Date Changed by P1 Initial Draft 1-25-2012 jem P2 Updates after call w/ Mats and Tim 1-30-2012 jem P3 Expanding the details of RF Protocol 3-8-2012 Jim Chen 1 Release to Client 3-15-2012 Jim Chen 2 Update after review with client 3-28-2012 Jim Chen 3 Updates based on CC2543/CC2544

implementations 3-20-2013 John Sawyer

IOLAB Wireless Protocol

DOCUMENT NUMBER REV Proprietary Page 3 of 30 1814E11 3

TABLE OF CONTENTS

Table of Contents ...................................................................................................................... 3 1.0 Introduction ........................................................................................................................ 5

1.1 Purpose .............................................................................................................................. 5 1.2 References ......................................................................................................................... 5

2.0 System Overview................................................................................................................. 5 2.1 High Level Requirements .................................................................................................. 5 2.2 RF Range ........................................................................................................................... 6

2.2.1 Range Estimate based on i>clicker .............................................................................. 6 2.2.2 Range Estimate Based on measured Path Loss ........................................................... 7

2.3 General Packet Structure ................................................................................................... 8 2.4 RF Channels ...................................................................................................................... 9 2.5 Packet Collisions ............................................................................................................... 9

2.5.1 Co-Channel Interference .............................................................................................. 9 2.5.2 Adjacent Channels Interference ................................................................................... 9

3.0 Detailed RF Protocol ........................................................................................................ 10 3.1 Polled System .................................................................................................................. 10 3.2 Frame and Sub-Frames .................................................................................................... 10 3.3 Sub-Frame Channels........................................................................................................ 11 3.4 Pairing .............................................................................................................................. 11 3.5 System Synchronization .................................................................................................. 11

4.0 Detailed RF Packet Structure .......................................................................................... 12 4.1 Field – Sync Word ........................................................................................................... 12 4.2 Field - Rev ....................................................................................................................... 12 4.3 Field - Mode .................................................................................................................... 12 4.4 Field - ID 1 ...................................................................................................................... 13 4.5 Field - ID 2 ...................................................................................................................... 13 4.6 Field - Data ...................................................................................................................... 13

5.0 Detailed RF Messages ....................................................................................................... 14 5.1 Pairing .............................................................................................................................. 14

5.1.1 Dongle ....................................................................................................................... 14 5.1.2 Remotes ..................................................................................................................... 15

5.2 Shutdown ......................................................................................................................... 16 5.2.1 Dongle ....................................................................................................................... 16 5.2.2 Remotes ..................................................................................................................... 17

5.3 Configuring ...................................................................................................................... 18 5.3.1 Dongle ....................................................................................................................... 18 5.3.2 Remotes ..................................................................................................................... 19

5.4 Polling without Updating External I/Os .......................................................................... 20 5.4.1 Dongle ....................................................................................................................... 20 5.4.2 Remotes ..................................................................................................................... 21

5.5 Polling and Updating External I/Os................................................................................. 22 5.5.1 Dongle ....................................................................................................................... 22



5.5.2 Remotes ..................................................................................................................... 23 5.6 Channel Sync ................................................................................................................... 24

5.6.1 Dongle ....................................................................................................................... 25 5.6.2 Remotes ..................................................................................................................... 25

6.0 Implementation Update ................................................................................................... 27 6.1 Packet Structure ............................................................................................................... 27

6.1.1 Sync Word ................................................................................................................. 27 6.1.2 Length ........................................................................................................................ 27 6.1.3 CRC ........................................................................................................................... 27

6.2 Packet Payload ................................................................................................................. 28 6.2.1 FIND Command ........................................................................................................ 28 6.2.2 FIND RESPONSE Command ................................................................................... 28 6.2.3 PAIR REQUEST Command ..................................................................................... 28 6.2.4 PAIR RESPONSE Command ................................................................................... 29 6.2.5 CONNECT Command ............................................................................................... 29 6.2.6 CONNECT RESPONSE Command .......................................................................... 29 6.2.7 RADIO SYNCH Command ...................................................................................... 29 6.2.8 COMMAND Command ............................................................................................ 30 6.2.9 DATA REQUEST Command ................................................................................... 30 6.2.10 COMMAND/DATA RESPONSE Command ......................................................... 30



1.0 INTRODUCTION

1.1 PURPOSE This document defines the RF protocol to be used for the IOLab system.

1.2 REFERENCES 1814E01xx Hardware Architecture Document

1814E14xx Wireless Protocol Analysis (Excel File)

1814Fxxxx Sensor ID and Key Value List

Aloha study reference

Multi Access Protocols: ULink 1; Link 2

2.0 SYSTEM OVERVIEW

2.1 HIGH LEVEL REQUIREMENTS Each IOLab system is comprised of one USB-based ‘dongle’ and one ‘remote’. The system can be used with either one or two remotes, as shown below. Data is requested by the dongle with a beacon, and the remotes respond with data they have collected.

PC/Laptop Dongle

Remote 1

Remote 2(optional)

http://books.google.com/books?id=xlKUrdpKAJgC&pg=PA143&lpg=PA143&dq=csma-ca+channel+capacity+aloha&source=bl&ots=GiHe_XjU6X&sig=hAAOjtgi4z6ClEqoC_BMJ-X0yJo&hl=en&sa=X&ei=rZEpT5GWGpS_2QWQsaXkAg&ved=0CDIQ6AEwAg#v=onepage&q=csma-ca%20channel%20capacity%20aloh�

http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.Overview.html�



The following high-level requirements have been identified:

a. Operate in the 2.4 GHz RF band (allows worldwide marketing)

b. Support data payload rate of 40 kbps (per dongle)

c. Provide <1% data loss at 10 m of range

d. Operate in classrooms with 10-25 dongles at a time

e. Provide known, constant latency for the data from both remotes

f. Operate in the presence of WiFi systems

g. Comply with FCC 15.247 or 15.249

h. Comply with EN 300 328 or EN 300 440

i. Dongle should report RSSI of incoming packets

The following assumptions are being made:

a. There is no need for systems involving a dongle communicating to more than 2 remotes

b. There is no need for RF communication between remotes 1 and 2

c. A radio chip with a built-in packet handler will be selected

d. A mode that provides a data payload rate of 80 kpbs to a single remote is not required

e. There are no security or encryption requirements on the data transmitted throughout the system

2.2 RF RANGE

2.2.1 Range Estimate based on i>clicker 1. Switching from 900 MHz to 2.4 GHz will result in about 8 dB of additional loss.

This is generally called “path loss”, and its frequency dependence is related to the fact that a 2.4 GHz antenna, being smaller, gathers less RF power.

2. Increasing the data rate from 150 kbps to, say, 1Mbps results in a receiver having worse sensitivity. Switching from the Semtech’s -100 dBm to something around -90 dBm means losing about 10 dB.

3. The Semtech chip TX power was about 14 dBm. The 2.4 GHz chips we’ve seen max out at about 4 dBm. This results in another 10 dB of loss.



4. The i>clicker base has a nice efficient antenna, located pretty much optimally. This is probably not possible in either the dongle or remote, which results in an estimated 2 dB of loss.

5. i>clicker operates with 3 attempts (2 retries after no ACK). IOLab will operate similarly, using up to 4 attempts. No big difference here.

These total up to about 30 dB less RF power for IOLab when compared to i>clicker. The rule-of-thumb is that a 10 dB reduction results in ½ of the range in indoor environments. A 30 dB reduction then equates to about 1/8 of the range. So, if we agree that i>clicker works pretty well at 100 m, we should be OK at about 12 m, assuming we can keep the interference problems at bay.

If the data rate were to be increased to 2 Mbps instead of 1 Mbps, we’d lose another 3 dB, totaling 33 dB. This equates to about 1/10 of the i>clicker range.

2.2.2 Range Estimate Based on measured Path Loss The path loss was measured between two antennas spaced 10m apart. During the measurement interval, one of the antennas was randomly moved across a 1 meter path, to simulate the use case of a fixed-position dongle, and a moving remote. The measurement was indoors in a large room with few obstructions. The measured path loss was analyzed and a calculation of the expected packet loss was made. The calculation was made assuming that a single bit error in the packet would invalidate the entire packet.



Figure 1 - Estimated Packet Loss vs. radio Performance

The chart above shows that about 81 dB of radio link budget will be needed to achieve a packet loss rate of 1% at 10m of range. The difference between large (256B) packets and small (32B) packets is less than 2 dB.

The radio chips under consideration have link budgets of between 85 and 97 dB at 1 Mbps and between 82 and 92 dB at 2 Mbps. 2Mbps option will be used.

2.3 GENERAL PACKET STRUCTURE The radio chips being considered have built-in packet handlers. Depending on the specific chip, they allow the packet payload length to be between 32 and 256 bytes. A 32B payload length would allow any of the chips to be used, while a 256B payload would limit the radio chip choice as not all of the chips allow payloads longer than 32B. The TI CC25xx chips support 64B payloads with full packet handling functionality or payloads up to 256B with reduced functionality (e.g. no auto-retries)

Longer packets are more efficient because less packet ‘overhead’ is needed for a given amount of data throughput, but smaller packets are a little less susceptible to packet errors in the presence of random bit errors.



Data requirements for the IOLab system show that approximately 40 kbps of data throughput is needed for each remote. Packets could be structured as shown below:

Auto Packet Handler Fields Designer Defined Fields Auto Field

Preamble Sync Word

Length Payload

CRC Rev Mode ID 1 ID 2 Data

4 Byte 4 Byte 1 Byte 3 bit 5 bit 3 Byte 3 Byte 50 Byte 2 Byte Unique for Dongle and Remote 57.0 Byte

68 Byte

The above packet is 68B in length and carries a payload of 50B. Thus, each packet holds 400b payload data. With a throughput requirement of 40 kbps, we’d need a frame rate of 100 fps for each sensor.

The duration of a 68B packet at 2 Mbps is 272 us. With a frame rate of 100 fps, the frame interval of 10 ms will necessitate a sensor TX duty cycle of about 2.7%, assuming no retries. Two sensors would need an aggregate of 5.4% duty cycle, plus some additional TX time for the beacon from the dongle.

2.4 RF CHANNELS 2.4 GHz ISM band is about 80 MHz wide (2.402 to 2.483 GHz). For optimum blocking performance, a 5 MHz channel width shall be selected. This allocates 16 available channels. Assuming other transmitters such as WiFi, Bluetooth, Zigbee, etc. coexist on the same band, we are estimating on average 12 channels will be available.

2.5 PACKET COLLISIONS

2.5.1 Co-Channel Interference If multiple systems are sharing a channel through a random-access scheme, often described as Aloha, the channel can be used to only about 18% of its capacity. Thus, no more than 3 systems could coexist successfully on a channel.

The worst-case combination of requirements, namely 25 systems in range of each other, 12 available channels, and each system having two sensors will allow use of a pure Aloha (random access) method since each channel would have, on average 2 systems, and with each system needing 5.4% of the channel’s capacity, the total usage would be at least 11%, which is under the 18% ‘Aloha’ limit.

2.5.2 Adjacent Channels Interference It is highly likely that multiple IOLab systems can be in close proximity of each other. With short enough distance, these systems will cause interference to each other even when using



different channels. Study showed that if a remote or dongle from another IOLab system was < 0.1 to 0.5 meters, there will likely be interferences.

3.0 DETAILED RF PROTOCOL

3.1 POLLED SYSTEM A polled system will be implemented. In a polled system, the master, dongle, will broadcast a beacon to the slave(s), remotes. The remotes, upon receiving the beacon will respond in predefined time slots. In this particular polled system, if the poll is not successful, the dongle will retry on up to 3 additional times each at a different channel, totaling 4 attempts. Once the dongle successfully receives the message out of any of the 4 attempts, it will not poll that dongle again until the next frame.

Dongle

Sensor

Dongle Poll

SensorResponse

Dongle Poll Dongle RETRY

SensorResponse

3.2 FRAME AND SUB-FRAMES A frame in this protocol will be 10 ms long. The frame will be broken down further into 4 sub-frames, each 2.5 ms long. Each sub-frame will host a channel, and the dongle will use sub-frame 2, 3, and 4 for retries. If the dongle successfully receives data from the remotes during any sub-frame, it will forgo all the remaining sub-frames if any and wait until the next frame until polling the remotes again.



3.3 SUB-FRAME CHANNELS The 4 sub-frame channels are randomly selected from the pool of 16 by the dongle during pairing.

3.4 PAIRING The pairing process will result in exchange of both dongle and remote ID. It will occur on a predefined channel known by both the dongle and the remotes. During which a set of 4 sub-frame channels are randomly selected from the pool of possible sets (sets consist of 4 predefined channels) by the dongle and transferred to the remotes. In addition, necessary sensor scaling or calibration values could be exchanged during pairing.

The dongle will enter pairing mode per request from the PC app, and the remotes will enter pairing mode by pressing the pairing button.

Pairing is a sticky event, meaning the dongle will remember the paired remotes and the remotes will remember the paired dongle. This should be a fairly rare event.

3.5 SYSTEM SYNCHRONIZATION Since the system will utilize 4 different channels and cycle through those channels in a defined sequence, the dongle and remotes must synchronize their channels before any operation. To do so, the dongle will transmit a “Channel Sync” message (details of this message will be stated in section 5.6 Channel Sync) during every sub-frame. During the same time, the remote will dwell on a channel and listen for that message for a duration equivalent to 5 sub-frames. The 5 to 1 ratio of dwell time will guarantee that the remote will be listening on the same channel the dongle is transmitting. If a message is not received during the 5 sub-frame dwell time, the remote will change to the next channel and repeat the 5 sub-frame dwell. While the remote is waiting to be synchronized to the dongle, it will not be actively collecting data.



4.0 DETAILED RF PACKET STRUCTURE The general packet structure is re-illustrated below:

Auto Packet Handler Fields Designer Defined Fields Auto Field

Preamble Sync Word

Length Payload

CRC Rev Mode ID 1 ID 2 Data

4 Byte 4 Byte 1 Byte 3 bit 5 bit 3 Byte 3 Byte 50 Byte 2 Byte Unique for Dongle and Remote 57.0 Byte

68 Byte

The “Auto Packet Handler Fields” will remain the same for all RF messages, only the “Designer Defined Fields” will change under different type of RF messages. For the following sections,

4.1 FIELD – SYNC WORD

only the “Designer Defined Fields” will be discussed.

- Unique Sync Word will be defined for messages to the Dongle and Remote. This approach prevents remotes from receiving message from other remotes and dongles from receiving message from other dongles.

4.2 FIELD - REV - This field is 3 bits, and is reserved for backward compatibility feature in the future

releases. For example, upon releasing millions of V1 IOLab system into the market, a revamped V2 version shall be backward compatible with V1; these bits can be used to differentiate between the 2 systems. 3 bits are assigned, yielding 8 possible revisions.

4.3 FIELD - MODE - The mode field defines different type of RF messages. This field is 5 bits, yielding 32

possible modes for both the dongle and the remotes. The mode field has different meanings for dongle and remotes. The following tables define each mode:



Dongle

Remote Modes Mode Values

Modes Mode Values

Shutdown 0

Shutdown 1 0

Pairing Remote 1 1

Pairing 1 1

Pairing Remote 2 2

Config 1 2

Config 3

Sync 1 3

Poll Both 4

Data 1 4

Poll Remote 1 5

Ack & Data 1 5

Poll Remote 2 6

Reserve 6 to 15

Poll Both & Update I/O 7

Shutdown 2 16

Poll R1 & Update I/O 1 8

Pairing 2 17

Poll R2 & Update I/O 2 9

Config 2 18

Sync 10

Sync 2 19

Reserve 11 to 31

Data 2 20

Ack & Data 2 21

Reserve 22 to 31

- Details of each mode will be explained in section 5.0 Detailed RF Messages.

4.4 FIELD - ID 1 - This field holds the ID of either dongle or remote. It is 3 bytes, which yields 2^24

possible combinations, or 16,777,216 possible combinations.

- When the dongle is transmitting, this field holds the ID of the remote.

- When the remote is transmitting, this field holds the ID of the dongle.

4.5 FIELD - ID 2 - This field holds the ID of remote 2.

- When dongle is transmitting, this field may be used if the 2nd remote is paired to the dongle.

- This field is not used by the remotes.

4.6 FIELD - DATA - This field holds the payload of the message, and directly affects the data throughput. The

size of the data field can be up to 100 bytes in an interference free environment.



5.0 DETAILED RF MESSAGES The “Auto Packet Handler Fields” will remain the same for all RF messages, only the “Designer Defined Fields” will change under different type of RF messages. For the following sections,

5.1 PAIRING

only the “Designer Defined Fields” will be discussed.

The ID of the dongle and remotes are exchanged during pairing; so are the 4 sub-frame channels. A predefined channel is used for pairing.

The pairing event will occur in sequence illustrated below:

Dongle Pairing Request on Pairing Channel

Remote Acknowledges Pairing on Pairing ChannelPairing

5.1.1 Dongle Rev Mode ID 1 ID 2 Parameters 3 bit 5 bit 3 Byte 3 Byte 1 Byte

Pairing Remote Dongle Channel Set

8.0 Byte

- During pairing, the dongle sends the pairing message to the remotes on the predefined channel. The remotes must be in pairing mode to accept this message; otherwise the dongle’s message will be rejected.

- Upon sending this message, the dongle will expect an acknowledgement from the remote it intended to pair. The acknowledgement message may include sensor calibration values.

- Dongle will save the paired remote’s ID and associated calibration values to Flash.

- The PC app will report the status of the pairing request.

Field Definitions:

Mode Binary Decimal Pairing Remote 1 00 00 01 1 Pairing Remote 2 00 00 10 2

ID 1 Hexadecimal Remote ID XX XX XX

ID 2 Hexadecimal Dongle ID XX XX XX



Parameter Hexadecimal Channel Set XX

- Mode: identifies the dongle’s pairing intent. The dongle can pair up to 2 remotes.

o “Pairing Remote 1” pairs the remote as Remote 1

o “Pairing Remote 2” pairs the remote as Remote 2

- ID 1: contains the remote’s ID the dongle intends to pair to, which will be entered by the user through the PC app

- ID 2: contains the dongle’s ID, which will be transferred to the remote - Channel Set: identifies the set of channels dongle and remotes should use

5.1.2 Remotes Rev Mode ID 1 ID 2 Parameters 3 bit 5 bit 3 Byte 0 Byte 7 Byte

Pairing Dongle Calibration Values

11.0 Byte

- The user must set the remote in pairing mode.

- While in pairing mode, the remote will reject all messages except pairing requests from dongles.

- Upon receiving the pairing request, the remote will reply with an acknowledgement message to the dongle.

- The acknowledgement message will include any calibration or scaling values of remote’s sensors.

- Upon successful pairing, the remote will save Dongle’s ID to FLASH.

- The remote will exit pairing mode upon a timeout or upon user intervention.

Field Definitions:

Mode Binary Decimal Pairing Ack R1 00 00 01 2 Pairing Ack R2 01 00 10 18 nAck 1 00 00 00 0 nAck 2 01 00 00 16




Parameters Sensor ID Key1 Length1 Calibration Value1 Cal Details XX 000 00000 XX XX XX XX XX

- Mode: remotes’ acknowledgement to the dongle

o “Paring Ack R1” confirms the remote is paired as the 1st remote

o “Paring Ack R2” confirms the remote is paired as the 2nd remote

o “nAck 1” dongle request rejected by 1st remote

o “nAck 2” dongle request rejected by 2nd remote

- ID 1: contain the dongle’s ID, which will be extracted from dongle’s request message. - Parameters: This field is expected to be 6 bytes long, but could increase depend on how

many sensors are being calibrated or scaled. The parameter field will include the following sub-fields:

o Sensor ID: identifies the sensor, i.e. accelerometer, barometer, etc. 1 byte is reserved for this field.

o Key: identifies the sensor’s parameter to be calibrated, i.e. barometer’s scaling value, etc, or. 3 bits is assigned to this field, yielding 8 possibilities.

o Length: identifies the length of calibration value to come. 5 bits is assigned to this field, yielding longest calibration value length of 32 bytes.

o Calibration Value: holds calibration values, of which the length is reflected by the Length field,

o Refer to the Sensor ID and Key Value List document for details of the above parameters.

5.2 SHUTDOWN This message can be utilized to remotely shutdown the remotes. In shutdown, the remotes are in their lowest power state, which requires user intervention to exit.

The shutdown event will occur in sequence illustrated below:

Channel Sync Dongle Shutdown Command Remote AckShutdown

5.2.1 Dongle Rev Mode ID 1 ID 2 Data 3 bit 5 bit 3 Byte 3 Byte 0 Byte

Shutdown Remote 1 Remote 2

7.0 Byte



- Upon sending this message, the dongle will expect an acknowledgement from the remote it intended to pair.

- The PC app will report the status of the shutdown request.

Field Definitions:

Mode Binary Decimal Shutdown 00 00 00 0

ID 1 Hexadecimal Remote 1 ID XX XX XX


- Mode: identifies the dongle’s intent to shutdown the remote(s)

- ID 1: contains the remote1’s ID the dongle intends to shutdown

- ID 2: contains the remote 2’s ID the dongle intends to shutdown

5.2.2 Remotes Rev Mode ID 1 ID 2 Data 3 bit 5 bit 3 Byte 0 Byte 0 Byte

Shutdown Dongle

4.0 Byte

- Upon receiving the shutdown request, the remote will reply with an acknowledgement message to the dongle.

- The remote will remain in receive mode for an additional frame before shutting down.

- Once shutdown, the remote will no longer be able to respond to dongle’s request until it’s turned back on again by the user.

Field Definitions:

Mode Binary Decimal Shutdown Ack R1 00 00 01 1 Shutdown Ack R2 01 00 01 17 nAck 1 00 00 00 0 nAck 2 01 00 00 16





o “Shutdown Ack R1” confirms the remote 1 will be shutting down

o “Shutdown Ack R2” confirms the remote 2 will be shutting down

o “nAck 1” dongle request rejected by remote 1


ID 1: contain the dongle’s ID, which will be extracted from dongle’s request message.

5.3 CONFIGURING This message can be utilized to configure the remotes. Settings of sensors that reside within the remotes, such as sample rate, resolution, etc can be configured using this command. Certain configuration combinations are not possible, and must be prevented by the PC app.

The configure event will occur in sequence illustrated below:

Channel Sync Dongle Config Remote AckConfiguring

5.3.1 Dongle Rev Mode ID 1 ID 2 Parameters 3 bit 5 bit 3 Byte 3 Byte 2 to 50 Byte

Config Remote 1 Remote 2 Configuration Parameters

9 to 57 Byte

- Remotes can be configured individually or, in the case of same configuration parameter, simultaneously.

- Upon sending this message, the dongle will expect an acknowledgement from the remote(s) it intended to configure.

- The PC app will report the status of the configuration request.

Field Definitions:

Mode Binary Decimal Config 00 00 11 3





Parameters Sensor ID 1 Key1 Value1 … Sensor ID 25 Key25 Value25 Config Details XX 000 00000 XX 000 0000

- Mode: identifies the dongle’s intent to configure the remote(s)

- ID 1: contains the remote1’s ID the dongle intends to configure

- ID 2: contains the remote 2’s ID the dongle intends to configure

- Parameters: 1 to 25 bytes long, depends on how many sensor are being configured. Every byte represents the configuration setting for a sensor:


o Key: identifies the sensor’s parameter to be configured, i.e. accelerometer sensitivity, accelerometer sample rate, accelerometer resolution, etc. 3 bits is assigned to this field, yielding 8 possibilities.

o Value: identifies the sensor’s parameter’s setting, i.e. 1g, 3g, 6g, accelerometer sensitivity, etc. 5 bits is assigned to this field, yielding 32 possibilities.

o Refer to the Sensor Key Value List document for details of the above parameters.


Config Dongle

4.0 Byte

- Upon receiving the config request, the remote will attempt to carry out the configuration request. If successful, the remote will Ack the dongle; if unsuccessful, the remote will nAck the dongle.

Field Definitions:

Mode Binary Decimal Config Ack R1 00 00 11 3 Config Ack R2 01 00 11 19 nAck 1 00 00 00 0 nAck 2 01 00 00 16



o “Config Ack R1” confirms the remote 1 configured successfully.



o “Config Ack R2” confirms the remote 2 configured successfully.



ID 1: contain the dongle’s ID, which will be extracted from dongle’s request message.

5.4 POLLING WITHOUT UPDATING EXTERNAL I/OS This message allows the dongle to collect data from the remotes.

The polling event will occur in sequence illustrated below:

Channel Sync Dongle Poll Remote Respond Dongle Poll Remote Respond Polling


Poll Remote 1 Remote 2

7.0 Byte ]

- Remotes can be polled individually or simultaneously. - Upon sending this message, the dongle will expect data from the remote(s) it polled.

- Upon a successful polling, the dongle will relay the data to the PC app.


Field Definitions:

Mode Binary Decimal Poll Both 00 01 00 4 Poll Remote 1 00 01 01 5 Poll Remote 2 00 01 10 6



- Mode: identifies dongle’s polling intent:

o Poll Both: polling both remotes simultaneously

o Poll Remote 1: remote 1 is being polled



o Poll Remote 2: remote 2 is being polled

o Typically, both remote will be polled at same time if present. Remote may be polled individually during retries.

- ID 1: contains the remote1’s ID the dongle intends to configure


5.4.2 Remotes Rev Mode ID 1 ID 2 Data 3 bit 5 bit 3 Byte 0 Byte 2 to 53 Byte

Data Dongle

6 to 53 Byte

- Upon receiving the polling request, the remote transmits the collected sensor data back to the dongle. If no data is available, the remote will nAck the dongle.

Field Definitions:

Mode Binary Decimal Data R1 00 01 01 5 Data R2 01 01 01 21 nAck 1 00 00 00 0 nAck 2 01 00 00 16


Data Sensor ID 1 Length 1 Value 1 … Sensor ID n Length n Value n

Sensor Data XX XX … XX XX …

- Type: identifies the message originator as the remote


o “Data R1” identifies the data is from remote 1

o “Data R2” identifies the data is from remote 2



- ID 1: contains the dongle’s ID, which will be extracted from dongle’s request message.

- Sensor ID Bit Field: optional bit field that identifies originator of the sensor data. However, since the dongle should be aware which sensor is active in each remote, this field can be omitted.



- Data: contains the collected sensor’s data. This field is structured as follows:


o Length: identifies the length of data reported by the remote.

o Value: contains data values collected by the remote

o The total size of the data field must be limited to 100 Byte, or the protocol will need to be adjusted.

5.5 POLLING AND UPDATING EXTERNAL I/OS In addition to polling data from the remotes, this message will also update the status of remotes’ external I/Os.

Remotes have an external header. The remote can drive external devices or receive inputs via this header.

This polling event will occur in sequence illustrated below:

Channel Sync Dongle Poll Remote Respond Dongle Poll Remote Respond Polling

5.5.1 Dongle ]

Rev Mode ID 1 ID 2 Parameters 3 bit 5 bit 3 Byte 3 Byte 2 to 24 Byte

Poll & Update I/O Remote 1 Remote 2 I/O Update Parameters

9 to 31 Byte

- Remotes can be polled individually or simultaneously.

- Upon sending this message, the dongle will expect data from the remote(s) it polled.

- Upon a successful polling, the dongle will relay the data to the PC app.


Field Definitions:

Mode Binary Decimal Poll Both & Update I/O 00 01 00 4 Poll R1 and Update I/O1 00 01 01 5 Poll R2 and Update I/O2 00 01 10 6





Parameters I/O ID 1 Key1 Value1 … I/O ID 12 Key12 Value12 Config Details XX 000 00000 XX 000 0000

- Mode: identifies dongle’s polling intent:

o Poll Both & Update O: polling both remotes simultaneously, both outputs are being updated.

o Poll R1 & Update O1: remote 1 is being polled, and its output is being updated.

o Poll R2 & Update O2: remote 2 is being polled, and its output is being updated. - ID 1: contains the remote1’s ID the dongle intends to configure


- Parameters: identifies which external outputs to enable and disable


o Key: identifies the I/O’s parameter to be updated

o Value: identifies the I/O parameter’s setting, i.e. enable, disable, etc.

o Refer to the Sensor Key Value List document for details of the above parameters.

5.5.2 Remotes Rev Mode ID 1 ID 2 Data 3 bit 5 bit 3 Byte 0 Byte 2 to 53 Byte

Ack & Data Dongle

6 to 53 Byte

- Upon receiving the polling request, the remote transmit the collected sensor data back to the dongle, and update its outputs. If no data is available, or the I/O update is not successful, the remote will nAck the dongle.

Field Definitions:

Mode Binary Decimal Ack & Data R1 00 01 10 6 Ack & Data R2 01 01 10 22 nAck 1 00 00 00 0 nAck 2 01 00 00 16




Sensor ID Bit Field Binary Sensor ID 0000 0000 0000 0000 0000 0000

Data Sensor ID 1 Length 1 Value 1 … Sensor ID n Length n Value n

Sensor Data XX XX … XX XX …


o “Ack & Data R1” identifies the data is from remote 1, and output update succeeded.

o “Ack & Data R2” identifies the data is from remote 2, and output update succeeded.

o “nAck 1” dongle request rejected by remote 1.

o “nAck 2” dongle request rejected by remote 2.


- Sensor ID Bit Field: optional bit field that identifies originator of the sensor data. However, since the dongle should be aware which sensor is active in each remote, this field can be omitted.

- Data: contains the collected sensor’s data. This field is structured as follows:


o Length: identifies the length of data reported by the remote.

o Value: contains data values collected by the remote

o The total size of the data field must be limited to 100 Byte, or the protocol will need to be adjusted.

5.6 CHANNEL SYNC Remote must synchronize with the dongle before the two can communicate. Initially, the dongle will use the “Sync” request to synchronize with the remotes. Afterwards, if remotes ever became unsynchronized, the remotes will re-sync upon receiving the “Polling” request.

This polling event will occur in sequence illustrated below:

Dongle Sync Remote SyncSync or Dongle Poll Remote Sync




Sync/Poll Remote 1 Remote 2

7.0 Byte

- Remotes can be synced individually or simultaneously.

Field Definitions:

Mode Binary Decimal Sync 00 10 10 10 Or any Polls



- Mode: identifies dongle’s intent to sync:

o Sync: request to sync all paired remotes.

o If remote(s) became unsynchronized during polling, the polling messages can resynchronize the remote(s)

- ID 1: contains the remote1’s ID the dongle intends to sync

- ID 2: contains the remote 2’s ID the dongle intends to sync


Sync Dongle

4.0 Byte

- Upon receiving the sync request, the remote will acknowledge the request.

- If the remote received a polling request while in sync mode, it’ll respond with a sync acknowledgement to the dongle.

- If an error has occurred, the remote will nAck the dongle.



Field Definitions:

Mode Binary Decimal Sync R1 00 01 00 4 Sync R2 01 01 00 20 nAck 1 00 00 00 0 nAck 2 01 00 00 16



o “Sync R1” acknowledgment from remote 1, indicating sync was successful.

o “Sync R2” acknowledgement from remote 2, indicating sync was successful.






6.0 IMPLEMENTATION UPDATE The previous sections define the original IOLab wireless protocol. During implementation, many of the original concepts were modified to match the underlying radio hardware and to implement new features identified during prototype testing. This section defines the protocol as it is currently implemented in the IOLab system.

Major changes to the protocol defined in previous sections are:

• To reduce over-the-air time, two Remote ID fields were replaced with one Dongle ID field

• A Frame number field was added to the structure to provide a data packet counter

• The 3-bit Revision field was removed and replaced with logic in the Connect command

• Many of the separate message modes have been combined into a “Command” message, where the Command is passed from the Remote’s RF micro straight to the Remote’s sensor micro

• A Connect command was added

• A single Sync Word is used in both directions

6.1 PACKET STRUCTURE The packet structure defined by the CC2543/CC2544 radios is presented below:

Preamble Sync Word Length Payload CRC

4 Bytes 4 Bytes 1 Byte 5 – 115 Bytes 2 Bytes

6.1.1 Sync Word For pairing-related messages (FIND, FIND RESPONSE, PAIR REQUEST and PAIR RESPONSE), the Sync Word is fixed to be 0x29 0x41 0x76 0x71. For all other messages, the 32-bit Sync Word is generated from the 24-bit Dongle ID in a pre-determined algorithm that both the Dongle and the Remote use.

6.1.2 Length Payload Length.

6.1.3 CRC Payload CRC.



6.2 PACKET PAYLOAD The Payload is divided into four logical sections. The use of the Payload Length byte is tightly integrated with the Payload, so is included in this section.

Length Payload

Dongle ID Frame Command Data

1 Byte 3 Bytes 1 Byte 1 Byte 0-110 Bytes

A description of each of the possible Commands is listed below.

6.2.1 FIND Command This is used to identify a nearby Remote that is in the Pairing state.

Length Dongle ID Frame Command Data

0x05 0xdh 0xdm 0xdl 0xA2 0x53 0 Bytes

6.2.2 FIND RESPONSE Command Returned by the nearby Remote that is in the Pairing state. Note that if two Remotes are in range and in the Pairing state, then they both send this response at the same time, which means that the Dongle is not likely to receive it properly.


0x08 0xdh 0xdm 0xdl 0xA2 0x53 0xrh 0xrm 0xrl

Where: 0xrh 0xrm 0xrl = Remote ID

6.2.3 PAIR REQUEST Command Sent by the Dongle to initiate pairing with a Remote, and assign a Remote number (1 or 2) to that Remote.


0x09 0xdh 0xdm 0xdl 0xA0 0x51 0xrh 0xrm 0xrl 0xr#

Where: 0xrh 0xrm 0xrl = Remote ID 0xr# = Assigned Remote number



6.2.4 PAIR RESPONSE Command Sent by the Remote to accept the PAIR REQUEST from the Dongle.




6.2.5 CONNECT Command Sent by the Dongle to initiate an RF connection with a paired Remote.




6.2.6 CONNECT RESPONSE Command Sent by the Remote to accept the RF connection with a Dongle.




NOTE: Revision 1 of the RF Protocol returns 0xA1 in the Frame byte. Future revisions of the RF Protocol will return different values in the Frame byte. Values TBD.

6.2.7 RADIO SYNCH Command Used during data mode to synchronize RF timing between the Dongle and the Remote. This is sent by the Dongle on secondary frequencies after data has been received in the current timeslot.


0x05 0xdh 0xdm 0xdl 0xA3 0x54 0 Bytes



6.2.8 COMMAND Command Used by a Dongle to send a command to the Remote. Generally these are passed untouched to the sensor micro in the Remote.


0x05 + Data Len

0xdh 0xdm 0xdl F# CMD CMD Data

Where: F# = current Frame number (when data mode is entered, Frame number is set to zero and increments every 10 msec frame.)

CMD = Command for sensor micro CMD Data = Command Data for sensor micro

NOTE: Commands START DATA and STOP DATA are processed by the Remote radio micro, and then passed to the sensor micro.

6.2.9 DATA REQUEST Command Sent by the Dongle to request data from a Remote (or Remotes).


0x06 0xdh 0xdm 0xdl F# 0x50 0xr#


0xr# = 0x01 : Data from Remote 1 0x02 : Data from Remote 2 0x03 : Data from both Remotes

6.2.10 COMMAND/DATA RESPONSE Command Sent by the Remote back to the Dongle in response to the COMMAND and DATA REQUEST Commands.


0x05 + Data Len

0xdh 0xdm 0xdl F# C Data


C = Command being responded to. NOTE: From Remote 2, the high bit (0x80) of C is set to one Data = Response data from Remote

Documents

WIRELESS ROTOCOL IOLab · 2017-01-24 · a. Operate in the 2.4 GHz RF band (allows worldwide marketing) b. Support data payload rate of 40 kbps (per dongle) c. Provide