Fictitious Protocol
Fictitious Protocol (FP) is an asynchronous point-to-point protocol that connects a Master (some kind of computer) with a Slave (some kind of equipment, let us say an air-conditioning or refrigeration unit). The Slave has 32 sensors (such as a thermometer) and 32 actuators (such as a thermostat). The protocol comprises commands that the Master sends to the Slave either to set a value in an actuator or to read a value from a sensor. The Slave responds with acknowledgements and sensor readings respectively. The Slave never sends anything except in response to a message from the Master.
The content of each frame is either a command or a response. A command looks like this:
| Command Code | Data | Checksum |
The Command Code is a single-byte field that identifies the command. It is followed by zero or more data bytes. The number of such data bytes is fixed for each command. The last field is a one-byte checksum that is the exclusive of all the other bytes.
A response looks a little different:
| Response Code | Data Count | Data | Checksum |
The Response Code field is a one-byte element that identifies the response. It is followed by a one-byte count of the data bytes that follow.
Here is a list of commands with the data associated with each:
| Code | Command | Data |
|---|---|---|
| 0 | Request Status | (none) |
| 1 | Set Actuator |
One-byte actuator number Two-byte value to set |
| 2 | Read Sensor | One-byte sensor number |
And here is a similar list of responses:
| Code | Response | Data |
|---|---|---|
| 0 | Request Status | (none) |
| 1 | Set Actuator |
One-byte actuator number Two-byte value to set |
| 2 | Read Sensor | One-byte sensor number |
The bit flags returned with the Status response include (in binary):
| Bit | Meaning |
|---|---|
| 00000100 | Alarm: one or more sensors are in the alarm range |
| 00000010 | Power: unit has noted a power disruption |
| 00000001 | Test: unit in diagnostic mode |
Let us look at the simple exchange of one command and one response. The master sends a command to set actuator number 10 and the slave acknowledges this. Here is a snippet from the Frame Display:
We assume that you are familiar with the basic layout and operation of the Frame Display window. If you are not, we suggest you familiarize yourself with it using one of the ComProbe protocol analyzer demos.
In the Summary Pane (the Frame Display subwindow with column headings starting with "Bookmark"), we see a one-line entry for each frame. This pane gives you a view over the succession of frames in the capture with the most important details of each. The columns headed "Bookmark", "Frame#", "Frame Size", "Delta", and "Timestamp" are standard; you will see them in every Frame Display window no matter what protocol is being decoded. The columns labeled "C'sum" and "Command/Response" are inserted by our FP decoder.
You can make your decoder add any columns you choose to the Summary Pane and display whatever you deem useful in those columns. Our "Command/Response" column shows the name of the command or response in the frame. This information, the type of frame (whatever that means in the context of a particular protocol), is certainly the most crucial thing to put in the summary. The other custom column, "C'sum", shows the checksum for the frame. There is enough column space left that we could add even more columns for FP; for example we could have an "Actuator/Sensor" column and display the relevant number for frames that contain such. Deciding what to show in the Summary Pane and how to organize that data into columns is an exercise for the decoder writer ‐ there are no rules about it. By the way, the values in the "Delta" and "Timestamp" columns shown above are not meaningful because we artificially constructed the captures (since FP is not a real protocol) and no timestamps were included.
The frame that is selected (highlighted) in the Summary Pane is displayed in detail in the other panes. The key one is the Decode Pane (at left center). This is the one pane that a decoder has almost complete control over. The logical data panes on the right (Binary, Radix, and Character) show the data in various formats with the data representing the field selected in the Decode Pane highlighted. At the bottom, the Event Pane shows the raw data that comprises the frame including start-of-frame and end-of-frame events (those flag-like symbols) that we will explain later.
As we see in "Set Actuator Command and Response", the Decode Pane starts with a one-line description of the frame ("Frame 3: (DTE) Len=5" in our case). Below this is a tree with one branch at the root level for each protocol represented within the frame. In our example, we have just the one protocol, FP. Everything on the FP branch is generated by the FP decoder. In our example every FP field is shown at the same level but a decoder can construct sub-trees of arbitrary complexity.
Now that we know what type of information we are dealing with, let's create our decoder script.