Please note that this protocol was not fully documented and updated during its original development. As such, it may be prone to errors and future corrections.

Protocol Overview

The cRIO Communication Protocol is a UDP-based network protocol comprised of two independent unidirectional channels. The first is a Control Channel, which sends commands from the fountain server to the cRIO. The second is a Status Channel, which sends status information from the cRIO to the fountain server. For simplicity's sake, both protocols will operate on the same port, 30096. (The port number is the decimal equivalent of "H2O" in everyone's favorite Ultimate Base, 42; note: never mind what symbols are used beyond z :-) ) Both channels utilize binary encodings to represent their data in a concise manner.

Control Channel

The Control Channel is used to command the cRIO from the fountain server. It is based on a simple scheme where commands are represented by a series of bytes of variable total length satisfying these conditions:
  • The first byte of each command identifies the command by a unique number.
  • The remaining bytes are formatted as required for that specific command.
  • Multiple commands may be contained in a single UDP packet without the cRIO losing sync.
  • The maximum length of a packet is 256 bytes, which is the receive buffer length on the cRIO.

It is the responsibility of the fountain server to be sure its commands are properly formatted! No response is given by the cRIO at the completion of a command to indicate a success or failure. The only response received will be the status of fountain components that the server cannot directly control.

Control Channel

These packets can be chained together to update multiple states at the same time. For example, the south end valve states and north valve states are often sent together in one 10 byte packet. They each of these states are independent of each other so when they change, the do not modify the other's state.

A short note about switch bytes and content bytes

In all of these packets, the first byte (byte zero) is a switch that identifies what the packet is expected to do. In order for the packet to be processed, byte zero must exactly match the packet header that is listed else the rest of the packet will be ignored. Everything following the switch byte (i.e. the content bytes) are indicative of the next state. Within these sections are don't cares (marked by X's bellow). It is highly recommended that these be zeros so that in the event that they are used in the future, legacy programs will continue to run without causing any ill side effects. If a developer does place a one in a don't care, the cRIO will ignore it. While technically a valid packet, it does not follow the recommended and safe convention of leaving it a zero.

0x0 Ping

Byte Zero 0 0 0 0 0 0 0 0


This command requests a status packet report from the cRIO without changing the current state.

0x1 - South End Valve State Packet Design

Byte Zero 0 0 0 0 0 0 0 1
Byte One X X X X HC HR H10 H9
Byte Two H8 H7 H6 H5 H4 H3 H2 H1
Byte Three X X X X VC VR V10 V9
Byte Four V8 V7 V6 V5 V4 V3 V2 V1

0x2 - North End Valve State Packet Design

Byte Zero 0 0 0 0 0 0 1 0
Byte One X X X X X X X N24
Byte Two N23 N22 N21 N20 N19 N18 N17 N16
Byte Three N15 N14 N13 N12 N11 N10 N9 N8
Byte Four N7 N6 N5 N4 N3 N2 N1 North Valve State

The North Valve State is usually 1.

0x3 - Weir Packet Design

Byte Zero 0 0 0 0 0 0 1 1
Byte One X X X X X Weir 3 Weir 2 Weir 1

0x4 - Set Administrative State

Byte Zero 0 0 0 0 0 1 0 0

Unused

0x5 - Echo to Serial Port

Byte Zero 0 0 0 0 0 1 0 1

Unused

0x6 - Mister Packet Design (for winter control)

Byte Zero 0 0 0 0 0 1 1 0
Byte One X X X X X X North End Mister South End Mister

0x7 - Light Control Design

Byte Zero 0 0 0 0 0 1 1 1


Byte One Light 1
Byte Two Light 2
Byte Three Light 3
Byte Four Light 4
Byte Five Light 5
Byte Six Light 6
Byte Seven Light 7
Byte Eight Light 8
Byte Nine Light 9
Byte Ten Light 10
Byte Eleven Light 11
Byte Twelve Light 12
Byte Thirteen Light 13
Byte Fourteen Light 14


The lights controller packet is slightly different that the rest of the packets previously listed. When bytes 1-14 are greater than 128, the cRIO will send an "h" to the Arduino lights controller which will flip the lights on. If the bytes are less than or equal to 128, the cRIO will send an "l" to the Arduino lights controller, and the lights will be turned off. Is should also be noted that while the cRIO takes in 14 light bytes, the Arduino code only uses the bytes 1 to 11. The first 10 bytes handle 10 lights and the 11th byte is used as a reset.

Status Channel

Status Code Packet Design

Byte Zero 0 0 0 Bollard 5 Bollard 4 Bollard 3 Bollard 2 Bollard 1
Byte One 0 0 0 0 Pump 4 Pump 3 Pump 2 Pump 1
Byte Two 0 0 0 0 Manhole cover is closed Sidewalk Water Level OK South End HW Disable North End HW Disable


The bollards are reported in here somewhere.

Things NOT Reported

  • HW disabled spillway
  • Wind sensor status

Last edited Dec 8, 2010 at 2:28 PM by Sequence, version 21

Comments

No comments yet.