RC4 Rev. F Prototype - Click for close-up detail

RC4 Servo Monitor & Controller
(Revision F)

NOTICE: This document is a work-in-progress.
Last Updated: January 3, 2007

For questions or comments about RC4, please write to rc4@codesmart.com.

Table of Contents

1. Introduction

RC4 can sample up to five PWM inputs and control up to four PWM outputs, independently or simultaneously. Various operating parameters can be specified for the module, and various modes of operation can be specified on a per-channel basis. The fifth input (referred to as "Channel 5") is one of six signal sources that can be used for pulse-width controlled event triggering and is provided as a dedicated input for event triggering.

The Revision F prototype is seen here on its test bed with a Futaba 7-channel receiver (with five channels connected to the inputs) and four standard R/C servos connected to the outputs. This board represents a significant size reduction compared to the Revision A board (see below). There is currently no RC4 board designed to conform to RoboBRiX dimensions, but there may be one on the horizon.

RC4 Revision A vs. Revision F Size Comparison

RC4 Prototype on its Test Bed - Click for larger view

1.1 Features

One primary feature of RC4 is its Fail-Safe mode. This feature provides the core functionality for switching between host control and radio control (R/C) in response to loss of input signal, which is the fundamental reason RC4 was initially created. Fail-safe is an integral part of RC4 and cannot be disabled. However, each channel can be configured independently to ignore Fail-Safe or to respond to it in various ways.

RC4 uses an elegant, yet extremely reliable algorithm for analyzing signal quality to determine when to activate and deactivate Fail-Safe mode, even in environments where a radio signal is susceptible to interference or drop-out. Fail-Safe mode also can be deliberately activated either by issuing a command over the serial port, or by assigning "Fail-Safe On Demand" control to the Trigger Input.

The Trigger Input can be driven by one of two possible input sources, selectable via a jumper block on the board. Typically, the Channel 5 input is used to drive the Trigger Input, although the channel 1 input is an alternative selection. Currently, the only built-in triggering feature is to enable Fail-Safe on demand. However, a host processor can monitor the Trigger Input via the serial interface and provide its own triggering functions as needed in a custom application.

When RC4 is powered up, it comes up with Fail-Safe engaged, by default. If signal is present, Fail-Safe will disengage after RC4 determines a good signal is being received. This signal detection delay is approximately one second long. Once Fail-Safe is disengaged, it will re-engage after input signal is absent for approximately one second. Advanced users can modify these delays to some extent, although it is not recommended unless absolutely necessary.

Each of the four main channels can be configured for various modes of operation. How a channel behaves in Fail-Safe mode is determined by settings that are encoded within its Channel Configuration Byte. The mode of a channel is configured by setting or clearing bits within this byte and writing the byte to RC4 through the Write Channel Configuration command. Four configuration bytes are required for a complete configuration; one for each of the four channels.

For more complete, detailed information about each of the modes in which a channel can operate, refer to the Channel Behavior Table in the Channel Configuration Byte section.

Channel 5 is a special input channel (with no corresponding output) that can be selected as the Trigger Input for various triggering events. Trigger events can be enabled or disabled via the Trigger Enable command. Event triggering is based on the pulse width of the input signal applied to the Trigger Input. Currently, there is only one trigger point, or threshold, that determines when events are to be triggered, and the only built-in trigger event available in RC4 is to force the activation of Fail-Safe, on demand. This feature is better known as Fail-Safe-on-Demand (or FSOD). FSOD can either be assigned to the Trigger Input, or it can be controlled through the RC4 Mode command. These two methods of controlling FSOD are exclusive. If the control is enabled on the Trigger Input, then it cannot be requested via the RC4 Mode command and visa versa.

Regardless of the events enabled on the Trigger Input, the pulse width of the signal applied to the Trigger Input can be retrieved at any time through the Read Trigger Input command. This enables a host controller to establish its own triggering options based on values read from RC4. Note that the Trigger Input does not impose any pulse width restrictions (other than a 16-bit pulse width measurement limitation), so all signals good and bad are equally sampled. However, whenever the Trigger Input is selected as the FSOD trigger and no input signal is present, the Read Trigger Input command will return zero. Normally, the Read Trigger Input returns the value of the last signal sampled (no matter how long ago it was detected) under all other conditions.

1.2 Fail-Safe Operation

Fail-Safe is an integrated function of RC4 that cannot be disabled. However, as noted in the Features section, above, a channel does not have to observe or respond to Fail-Safe.

Fail-Safe is really just a state within RC4 that can be either on (activated, or engaged) or off (deactivated, or disengaged). Channels can be configured to respond to changes in the Fail-Safe state or to ignore the Fail-Safe state all together.

Although channel behavior can be configured to ignore Fail-Safe, the control of Fail-Safe activation and deactivation depends on signals applied to the channel inputs. Fail-Safe does not descriminate between inputs (except when Noise Rejection is enabled - more on that later). If a valid signal appears on one or more inputs - regardless of whether the respective channel is configured to observe Fail-Safe or not - Fail-Safe will disengage once it determines the signal has been present and valid for a certain period of time (typically one second, approximately). Similarly, if there is no valid signal present for a certain period of time, Fail-Safe will engage.

It is important to know that the Fail-Safe state applies to RC4 as a whole (i.e. it is not a per-channel state) and that a signal on only one channel is required to deactivate Fail-Safe, which could affect the remaining channels, depending on their individual configurations.

Note that Fail-Safe engagement/disengagement is based upon only those inputs that are defined to have a physical connection (see the Physical Input Connections command). If RC4 is defined to have no inputs physically connected, then this creates a situation where Fail-Safe can never be disengaged. In the presence of signals, with physical input connections defined, Fail-Safe can be forcibly activated through the mfFAILSAFE and mfFSODNOW bits of the RC4 Mode command, but there is no way to forcibly disengage Fail-Safe. The only way Fail-Safe can be disengaged is through detection of a valid input signal on one of the physical input connections.

There are a number of aspects that define what RC4 considers to be a valid signal. The most fundamental aspect is the pulse width. The pulse width of an incoming signal must be within the MIN and MAX pulse width values that are pre-determined either through the PWM Input Configuration command, or defined explicitly through the Write PWM Configuration command.

Another factor in determining when to activate or deactivate Fail-Safe involves signal continuity. Especially in R/C applications, there can be moments of temporary signal loss. If Fail-Safe were to engage every time an expected input signal did not arrive, RC4 would likely cause its intended application to become unstable, with Fail-Safe spontaneously engaging unexpectedly. Therefore, there are some parameters that allow for momentary gaps in the input signal. This is true when RC4 is in the process of determining when to deactivate Fail-Safe as well as during the process of determining when to activate Fail-Safe.

The Write Fail-Safe Operating Parameters command is provided for advanced RC4 users to specify the parameters that are used by RC4 to descern signal quality. These parameters determine the length of time a signal must be present or absent for RC4 to deem the signal good or bad before altering the Fail-Safe state. They also determine how much of a gap is allowed in a signal to consider its presence valid when determining whether to engage Fail-Safe, or how many consecutive pulses must arrive in order for a signal to be considered when determining whether to disengage Fail-Safe.

It is unwise to indiscriminately alter these values without understanding how they affect Fail-Safe activation and deactivation, but it is safe to experiment under controlled conditions as long as the settings are not saved to EEPROM until their desired effect has been achieved. The integrity of RC4 can become impaired if these settings are not altered correctly.

RC4 offers an enhanced Fail-Safe mode of operation when Noise Rejection is enabled. When Noise Rejection is enabled, all inputs that have been defined as having a physical connection to RC4 must have a valid signal present in order for Fail-Safe to disengage. Also, any and all channels that are configured to recognize changes in Fail-Safe status (R/C Fixed, R/C Fail-Safe, R/C Presets and Command Protected modes) will respond immediately to signal gaps by locking in the last good signal received (for R/C modes) or by switching back to host control (for Command modes). After a short delay, if signal continuity remains valid, control will resume. This is a sort of preliminary Fail-Safe measure that locks in good signals in the event of sudden signal loss while also blocking out any intermittent or "noisy" signals (that may otherwise be considered valid), up until the time when either Fail-Safe engages, or the signal quality returns to normal.

2. Programming

RC4 provides a command interface via the serial port to allow a host to access and control the data and functions available within. The serial port can operate at one of eight selectable speeds, ranging from 1200bps to 57600bps. The factory default setting is 2400bps, for compatibility with RoboBRiX. This, as well as many other operating parameters, can be changed and saved in the internal EEPROM so that power-on defaults can conform to your application.

Commands issued to RC4 consist of one or more bytes and may result in one or more bytes of data returned in response. If a command returns more than one byte of data, this data may be returned in a continuous stream, or one byte at a time, depending on an RC4 Interface Configuration setting. One debug command (not available in the released firmware) consistently delivered 176 bytes of data at 57600bps without a hitch. The serial interface operates in full-duplex mode at all times (which means it can send and receive data at the same time). Although it is not absolutely necessary, it is good practice to wait for results from one command before issuing the next, and to add time delays between successive commands that return no data, for it is possible to overrun the internal command buffers or to miss data if RC4 is driven too hard too fast.

RC4 also provides a means of defining the byte order (or "Endianness") of data read from or written to the device. Some hosts (such as PCs) operate in "Little Endian" mode, which means the lower-value byte is sent and stored first, followed by the higher-value byte, of a two-byte value. Other host processors may operate in "Big Endian" mode, which means the higher-value byte is sent and stored first, followed by the lower-value byte. Some data exchanged between RC4 and the host are two-byte (word) values - especially pulse-width signal data - so these values are delivered in the byte order as specified by the Endianness setting. The factory default setting is Little Endian mode. This setting can be changed and saved in the internal EEPROM to conform to your system specifications.

2.1 RC4 Serial Interface Commands

The following table lists the entire serial interface command set for RC4. All command codes are listed in hexadecimal. It is important to remember this, as all references to command codes in this document are presented in hexadecimal (whether explicitly indicated or not).

In the grouping referred to as "RC4 Normal Commands", command codes 00 through 09 are arranged such that all even-numbered command codes (bit 0 = 0) are read operations, and odd-numbered command codes (bit 0 = 1) are write operations.

Command codes between 0A and 0F are free-form and currently consist of reads for which there is no direct corresponding write command. Many of the values read from this group of commands can be specified through the RC4 Special Commands. RC4 Special Commands either invoke seldom-used, special functions (like saving settings to EEPROM), or define RC4 configuration settings.

All RoboBRiX commands are described in the RoboBRiX Specifications document. RoboBRiX interrupts are currently not implemented in RC4, nor are the clock-related commands.

RC4 Normal Commands
Command Meaning Data Bytes
00 Read Channel Data (plus extended) 8,10,15 or 16
01 Write Channel Data 8
02 Read Channel Configuration 4
03 Write Channel Configuration 4
04 Read PWM (Input) Signal Configuration 4
05 Write PWM (Input) Signal Configuration 4
06 Read Fail-Safe Operating Parameters 4
07 Write Fail-Safe Operating Parameters 4
08-0B Reserved 0
0C Read RC4 Status 8
0D Read RC4 Configuration 7
0E Read Trigger Input Pulse Width 2
0F Read Next Byte 1
10-DF Reserved 0
RC4 Special Commands
E0 RC4 Special Function 1
E1 RC4 Mode 1
E2 RC4 Interface Configuration 1
E3 PWM Input Configuration 1
E4 Physical Input Connections 1
E5 Trigger Enable 1
E6 Enable EEPROM Update 1
E7 Enable Docked Module
(Available only if the docking feature is present) 		1
Unused Command Codes
E8-EE Reserved for RoboBRiX Expansion 0
RoboBRiX Interrupt Commands
EF-F7 Not Implemented 0
RoboBRiX Shared Commands
F8 Clock Decrement (not implemented) 0
F9 Clock Increment (not implemented) 0
FA Clock Read (returns zero) 1
FB Clock Pulse (returns zero) 1
FC Read Next ID Byte 1
FD Reset ID Index 0
FE Glitch Read 1
FF Glitch 0

2.2 RC4 Normal Commands

2.2.1 Read Channel Data (0x00)

The Read Channel Data command returns one of four data sets, depending on the Extended Data Level specified in the RC4 Interface Configuration command. Note that the extended data level is cumulative. For example, extended data level 3 includes the base information, plus the data from level 1, plus the data from level 2, as well as the additional data for level 3. Data is delivered in the order in which is it presented in the table, below.

The table below lists the data values that are returned from the Read Channel Data command, and the number of bytes of data for each value.

00: Read Channel Data
Base Data Bytes
Channel 1 pulse width
Channel 2 pulse width
Channel 3 pulse width
Channel 4 pulse width
2
2
2
2
Extended Data Level 1 adds:
Trigger Input pulse width
2
Extended Data Level 2 adds:
Bit-mapped Channel input enable bits
Bit-mapped Channel input detection bits
RC4 Status Flags Byte #1
RC4 Status Flags Byte #2
1
1
1
1
Extended Data Level 3 adds:
RC4 Error Code
RC4 Mode Settings
1
1

The pulse width values returned for Channels 1 through 4 are sampled either from the PWM inputs, or from the outputs, depending on the mfIOTABLE bit setting specified in the RC4 Mode command. The byte order of each of the two-byte values is determined by the Endianness setting specified in the RC4 Interface Configuration command. These pulse width values are 13-bit values that represent 1/3us increments. Therefore, to translate a pulse width value into microseconds, simply divide the pulse width value by 3.

Note that if a channel is configured for "Pass-Thru" operation (see the Channel Configuration Byte), then its pulse width value will be the value of the signal that was sampled last just before cfPASSTHRU mode was enabled for the channel. If the channel is configured to power up in cfPASSTHRU mode, then the data returned will represent signal presets stored in the internal EEPROM either from the factory or from the most recent execution of the RC4 Special Function command (to save current channel values to Fail-Safe EEPROM).

2.2.2 Write Channel Data (0x01)

01: Write Channel Data
Value Bytes
Channel 1 pulse width
Channel 2 pulse width
Channel 3 pulse width
Channel 4 pulse width
2
2
2
2

The Write Channel Data command is used to provide output signal values to channels 1 through 4. A value written to a channel through this command is applied to the channel output only if the channel is configured for one of the Command modes or for R/C Fail-Safe mode with Fail-Safe engaged (see the channel behavior table within the Write Channel Configuration command detail).

It is important to remember that values written to the channel outputs remain unchanged until new values are written. If a channel switches between R/C and host control, the channel output will revert to the last signal written whenever it switches to host control. If a channel is in Command mode at the time a new value is written, the output will respond immediately. Also note that all channel output values are updated at once following the Write Channel Data command, and only after an output cycle completes. In other words, if RC4 is currently generating output signals based on previous data when new data is written, the new values take effect only after the current output cycle completes. This ensures that all outputs change in unison (i.e. predictably).

Data written via the Write Channel Data command may be saved to EEPROM. An RC4 Mode bit (mfIOEEPROM) is used to select what signal data gets saved to EEPROM when an RC4 Special Function command is issued to save channel presets. If mfIOEEPROM is set, then channel data that was last written via Write Channel Data will get saved to EEPROM when the save operation is executed. These saved presets subsequently can be used by channels that are configured for the R/C Presets mode of operation when Fail-Safe is engaged.

Note that the channel pulse width values represent 1/3us increments. Therefore, to compute the pulse width value for a desired pulse width in microseconds, simply multiply the desired pulse width by 3. For example, for a 1500us pulse, a value of 4500 (or 1194 in Hexadecimal) must be written.

2.2.3 Read Channel Configuration Options (0x02)

02: Read Channel Configuration
Value Bytes
Channel 1 Configuration
Channel 2 Configuration
Channel 3 Configuration
Channel 4 Configuration
1
1
1
1

This command reads the channel configuration bytes for each of the four base channels. See the Write Channel Configuration command, below, for detailed information regarding the format of these bytes.

2.2.4 Write Channel Configuration Options (0x03)

03: Write Channel Configuration
Value Bytes
Channel 1 Configuration
Channel 2 Configuration
Channel 3 Configuration
Channel 4 Configuration
1
1
1
1

The Channel Configuration Byte

Each of the four channels can be configured for various modes of operation. How a channel behaves in Fail-Safe mode is determined by the mode settings that are encoded in its Channel Configuration Byte. The mode of a channel is configured by setting or clearing bits within this byte, which is written to RC4 through the Write Channel Configuration command. This command requires four channel configuration bytes for a complete configuration, one for each channel.

Note that this command affects all four channels in unison. The channel configuration settings are applied to all channels simultaneously, so there is no sequencing issues to be concerned with. Also, if RC4 is in the middle of sampling input signals or generating output signals when this command is issued, the new settings will not take effect until the beginning of the following input cycle.

Below is a description of the channel configuration byte:
Channel Configuration Byte Bit Assignments
7 6 5 4 3 2 1 0
cfINPUT cfOUTPUT cfSIGNAL cfINITWAIT cfPASSTHRU cfMODE

Channel Behavior Table

The available modes of operation provide a versatile array of behavior patterns that can be creatively applied to many applications. The table below lists the channel configuration modes that RC4 currently provides. It lists the official name for each of the modes, and describes the behavior of each mode when Fail-Safe is engaged or disengaged. Keep in mind that the different modes exist primarily to define how a channel responds to changes in the Fail-Safe state. Therefore, certain states will exhibit the same behavior as other states. In fact, there are only five unique states, or behaviors. Each unique behavior is color-coded in the table for easy identification.
This table does not include the cfINPUT, cfOUTPUT, cfPASSTHRU or cfINITWAIT flags, as their effective behavior is independent of the selected operating mode.

Channel Configuration Byte -- Per Channel
Mode Name Behavior when...
Fail-Safe is Disengaged (Good Signal) Fail-Safe is Engaged (Signal Bad or Absent)
R/C Output responds to input, when present. Output is held at last good signal when signal is absent. Output responds to input, when present. Output is held at last good signal when signal is absent.
R/C Fixed Output responds to input, when present. Output is held at last good signal when signal is absent. Output is held at last good signal received before Fail-Safe engaged. Input signal ignored.
R/C Fail-Safe Output responds to input, when present. Output is held at last good signal when signal is absent. Output responds to host. Input signal ignored.
R/C Presets Output responds to input, when present. Output is held at last good signal when signal is absent. Output reverts to preset values retrieved from EEPROM.
Command Output responds to host. Input signal ignored. Output responds to host. Input signal ignored.
Command Override Output responds to host if no input signal is present. Output responds to input immediately upon reception of input signal. Output responds to host if no input signal is present. Output responds to input immediately upon reception of input signal.
Command Fail-Safe Output responds to host. Input signal ignored. Output responds to host. Input signal ignored.
Command Protected Output responds to host if no input signal is present. Output responds to input immediately upon reception of input signal. Output responds to host. Input signal ignored.

NOTE: The behavior for a channel that responds to input signals is further modified if the Noise Rejection option is enabled. The behaviors listed here do not include Noise Rejection.

The following table presents a more detailed explanation of each of the operating modes:

ModeDescription
R/C This mode is used for a channel that needs to respond exclusively to the PWM inputs (typically for R/C use). Fail-Safe mode is ignored. This means there is no change in how the channel behaves when Fail-Safe is engaged. However, a channel in this mode will exhibit a sort of mock fail-safe behavior, as the signal at the channel output will always reflect the last good input signal received, even after input signal is lost. Keep in mind, however, that if an input signal arrives due to interference or "noise" and the signal falls within valid parameters, this signal will immediately become the new output signal. Therefore, this mode is potentially susceptible to inadvertent changes.
R/C Fixed This mode is a step up from straight R/C mode. The behavior of a channel configured in this mode is the same as a channel in R/C mode, except that this mode responds to Fail-Safe and is far less susceptible to inadvertent signal changes due to "noise". If input signal is lost, the output signal reflects the last good input signal, just as in R/C mode. It is also susceptible to changes until Fail-Safe engages, but as soon as Fail-Safe engages, the output signal is locked in. The output signal cannot and will not change as a result of a new input signal until Fail-Safe disengages.
R/C Fail-Safe A channel configured in this mode responds to changes in Fail-Safe status by switching between R/C (PWM) input control to Command (or "host") control. When RC4 product development began, this was the only mode defined in the specs. In other words, this was the reason RC4 was created. This mode enables an application to switch between radio control (assuming the inputs are connected to an R/C receiver) and autonomous control (to respond to commands from the serial interface). When input signal is present, the channel output in this mode responds to the input signal just as it does in R/C mode. As soon as signal is lost, the last good input signal is held on the output. However, as soon as Fail-Safe engages, the output signal immediately changes to reflect the last pulse width value that was written to RC4 via the Write Channel Data command from the host. As long as Fail-Safe is engaged, the channel output will respond to updates from the host. As soon as Fail-Safe disengages (after detecting a good input signal), the output once again responds to the PWM input signals.
R/C Fail-Safe mode is similar to Command Override and Command Protected modes (see below) but with subtle, yet significant, distinctions.
R/C Presets A channel configured in this mode responds to input signals and changes in Fail-Safe status in the same way as the other R/C modes, except when Fail-Safe engages, the output is fixed at a pre-determined signal value instead of switching to host control. Host control is ignored, entirely, in this mode. This pre-determined signal value comes from values stored in the internal EEPROM either from the factory or from a previous RC4 Special Function command issued via the serial interface from the host.
Command
 A channel configured for Command mode responds exclusively to the host (via the Write Channel Data command). Fail-Safe is ignored in this mode. This means that the behavior of the channel does not change in respect to changes in Fail-Safe status. In this mode, a channel basically behaves how one might expect a channel from any standard serial servo controller to behave.
Command Override In the Command Override mode, the output of a channel remains under host control in its natural state. However, any valid signal appearing on the input will immediately override host control - even if only for a beat. This mode is actually similar in behavior to R/C Fail-Safe mode, except for two distinct differences: 1) Command Override mode does not respond to changes in Fail-Safe status, and 2) switching between host control and R/C control is instantaneous, based on the presence or absence of any valid input signal (irrespective of Fail-Safe status). This means that, at all times, a channel in Command Override mode will respond, immediately, to any valid input signal, and will revert back to host control immediately upon removal of valid input signal. This mode is useful for applications that operate in an autonomous capacity, but need to respond immediately to radio control (or other external signal source connected to the inputs), such as a mobile robot, for example.
Camp Peavy's Springy Thingy from the Home Brew Robotics Club comes to mind as an ideal prospect.
Command
Fail-Safe		 Currently, a channel in the Command Fail-Safe mode behaves identically to a channel in Command mode. This is simply because Command Fail-Safe mode has the same behavior associated with both Fail-Safe states. In other words, technically, internally, this mode recognizes changes in Fail-Safe status, but no change in behavior has been defined.
An alternative behavior may be defined in a future version of RC4. Therefore, it is recommended to use Command mode, instead.
Command Protected This mode is sort of a cross between Command Override mode and R/C Fail-Safe mode, and its behavior is dependent on Fail-Safe status. If Fail-Safe is engaged (i.e. no input signal is present), then the channel remains under host control - just as in R/C Fail-Safe mode. And, unlike Command Override mode, where any input signal will immediately override the host, the output will only respond to the input once Fail-Safe has disengaged. In this respect, the transition from host control to R/C control is the same as in R/C Fail-Safe mode. However, if Fail-Safe is disengaged and the input signal goes away, the channel behaves like Command Override mode in that host control takes over immediately. If signal is regained before Fail-Safe engages, the output will again respond, immediately, to the input signal. However, if Fail-Safe engages before input signal is regained, output will remain in host control once again until Fail-Safe disengages, before responding to input signals again. The net effect of this mode is that the host takes control whenever signal is lost - even if only for a beat - and the host control is protected from spurious input signals when Fail-Safe is engaged.

R/C Fail-Safe is the best mode for the most stable transition between R/C and host control, since Fail-Safe will not disengage until a solid R/C signal is present, and host control will not resume until Fail-Safe engages after a solid loss of signal. Engaging Fail-Safe through the Fail-Safe-on-Demand (FSOD) feature provides an additional level of reliability, because all PWM inputs (except the "Trigger Input") are ignored in this state.

2.2.5 Read PWM Signal Configuration (0x04)

04: Read PWM Configuration
Value Bytes
Minimum Pulse Width
Maximum Pulse Width
2
2

The Read PWM Signal Configuration command returns the current minimum and maximum pulse width values that are used by RC4 to determine whether an input signal is valid or not. A pulse width received on any channel input must be within these limits (inclusive) to be considered valid. Any signal pulse that is shorter than the minimum or longer than the maximum is rejected.

The minimum and maximum pulse width values apply to all channels equally -- there is currently no way to specify a valid signal range for each individual channel. These values defined by the Write PWM Signal Configuration command. The PWM Input Configuration command may affect these values as well (particularly the maximum pulse width value).

2.2.6 Write PWM Signal Configuration (0x05)

05: Write PWM Configuration
Value Bytes
Minimum Pulse Width
Maximum Pulse Width
2
2

The Write PWM Signal Configuration command is used to establish a range, or "window", within which a pulse width arriving on any channel input must fall to be considered valid. A signal having a pulse width that is shorter than the minimum or longer than the maximum will be rejected. The pulse width value for a rejected signal is not available for reading, and no attempt is made to reproduce the signal on the respective channel output.

Write PWM Signal Configuration is typically performed following a PWM Input Configuration command in order to adjust the minimum and maximum values to something that is more meaningful to the application. The PWM Input Configuration command establishes absolute minimum and maximum values, based on the characteristics defined for the specified index. The Write PWM Signal Configuration command can then be used to modify the settings for a narrower pulse width window. However, the range cannot be extended wider than the absolute limits imposed by the PWM Input Configuration command. Any attempt to set minimum or maximum values beyond their absolute limits will result in the respective value being set equal to its absolute limit. The Read PWM Signal Configuration command can be used at any time to determine what the actual settings currently are. Once set, the settings remain unchanged until a subsequent command is issued to change them.

Note that if the minimum value is set larger than the maximum value, then all signals will be rejected. Also, if the input signals for a particular application never fall within the specified pulse width range, then they, too, will be rejected. If all signals are rejected for a period of time equal to that specified for Fail-Safe to engage, then Fail-Safe will engage (see Write Fail-Safe Parameters).

2.2.7 Read Fail-Safe Operating Parameters (0x06)

NOTE: All values are in hexadecimal:
06: Read Fail-Safe Parameters
Value Bytes Default
Cycles to Engagement
Cycles to Disengagement
Signal Continuity Cycles
Signal Gap Cycles
1
1
1
1
35
37
20
5

The Read Fail-Safe Operating Parameters command returns values that are used in the activation and deactivation of the internal Fail-Safe mechanism. These values determine how the input signals are analyzed in order for RC4 to decide when to activate or deactivate Fail-Safe. These values can be changed using the Write Fail-Safe Operating Parameters command. However, this practice is discouraged without full knowledge of how the Fail-Safe mechanism works, since incorrect settings can cause RC4 to malfunction or stop working completely.

For more detailed information regarding the meaning of these values, refer to the Write Fail-Safe Operating Parameters command.

2.2.8 Write Fail-Safe Operating Parameters (0x07)

07: Write Fail-Safe Parameters
Value Bytes
Cycles to Engagement
Cycles to Disengagement
Signal Continuity Cycles
Signal Gap Cycles
1
1
1
1

The Write Fail-Safe Operating Parameters command specifies values that are used in the activation and deactivation of the internal Fail-Safe mechanism. These values determine how the input signals are analyzed in order for RC4 to decide when to activate or deactivate Fail-Safe.

WARNING: The use of this command is discouraged without full knowledge of how the Fail-Safe mechanism works, since incorrect settings can cause RC4 to malfunction or stop working completely!

The values specified by the Write Fail-Safe Parameters command are described below: When considering the Fail-Safe engagement/disengagement mechanism, there are differing conceptual levels regarding "valid input signal." Purely from a channel input perspective, a valid input signal is considered any one signal pulse that has a pulse width that falls within the allowable range (specified by the Write PWM Signal Configuration command). The Fail-Safe mechanism takes a wider perspective, establishing signal validity based on the behavior of a series of consecutive signal pulses, and possibly across all channel inputs, depending on enabled RC4 features (such as Noise Rejection).

Values written by the Write Fail-Safe Parameters take effect immediately, except under rare conditions I won't even try to explain. RC4 is a very dynamic device, so if changes do not take effect immediately, they will take effect within less than 1.2 seconds - usually way less than 1.2 seconds. Probably 99% of the time, changes will take effect immediately.

Be extremely careful with this command! Improper settings can cause RC4 to malfunction or stop working entirely. For proper Fail-Safe operation (desired operation not withstanding) the Signal Continuity Cycles value absolutely must be less than the Cycles to Engagement value. Similarly, the Signal Gap Cycles value must be less than the Cycles to Engagement value.

These values must be altered with care. If RC4 stops working properly after writing new values, use the Write Fail-Safe Parameters command to specify values that are known to work. If RC4 refuses to accept the new values, then reset RC4 by turning it off and turning it back on again. Always test new settings thoroughly before saving them to EEPROM as the default start-up values!

2.2.9 Read RC4 Status (0x0C)

0C: Read RC4 Status
Value Bytes
Error Code
Bit-mapped Channel input enable bits
Bit-mapped Channel input detection bits
RC4 Status Flags Byte #1
RC4 Status Flags Byte #2
PIC2 Watchdog Timeouts
PIC2 Warm Resets
PIC1 Watchdog Timeouts
PIC1 Warm Resets
1
1
1
1
1
1
1
1
1

The Read RC4 Status command returns information about the status of RC4 and signal activity. Much of the information returned by this command is also obtainable from the Read Channel Data command. Be aware that status information retrieved here can be out of sync with signal data, since new signals could arrive between the time the signal data is retrieved and status information is retrieved. The Read Channel Data command returns data and status information, together, for when synchronized data is desired.

Note that the status flags are delivered as two individual bytes and not as a single word value. This is significant when considering Endianness, as the byte order remains the same in Big Endian and Little Endian mode.

The Error Code, if non-zero, indicates that RC4 has detected an error of some kind. If multiple errors occur before the error code is read, only the first error that occurred will be reported. The error code is reset to zero whenever it is read via the Read Channel Data or Read RC4 Status commands.

The following error codes are possible:
Error Codes
CodeMeaning
00No error - all is well
01Receive buffer overrun
02USART Receiver framing error
03USART Receiver overrun error
04Specified command code not implemented
05Transmit buffer overrun
06EEPROM write operation failed
07Docked module not present
(Available only if the docking feature is present)
08Unable to communicate with PIC2
09EEPROM update interrupted by watchdog reset
0AEEPROM update interrupted by another warm reset
0BEEPROM update interrupted by power failure or hard reset
0CEEPROM data corruption detected
0DEEPROM data checksum error
0EBad sense byte on brown-out reset - cold reset performed
0FEEPROM update attempted while EEPROM updates disabled

The Bit-Mapped Channel Input Enable Bits are simply a collection of cfINPUT bits from each of the Channel Configuration Bytes encoded into a single byte. The cfINPUT bit is a read-only bit from the Channel Configuration Byte that indicates whether the channel input is enabled. This information may be useful, depending on the application, and the bits are encoded into a single byte for convenience.

This bit-mapped byte is encoded as follows:
Bit-Mapped Channel Input Enable Bits
7 6 5 4 3 2 1 0
Reserved Channel 4 Channel 3 Channel 2 Channel 1

The Bit-Mapped Channel Input Detection Bits indicate which channels received a valid input signal during the most recent input signal cycle. These bits can be compared with the Physical Input Connections value, which can be retrieved via the Read RC4 Configuration command, to quickly determine if all of the physically connected inputs have received a signal.

This bit-mapped byte is encoded as follows:
Bit-Mapped Channel Input Detection Bits
7 6 5 4 3 2 1 0
Reserved Channel 4 Channel 3 Channel 2 Channel 1
The RC4 Status Byte #1 flags are defined as follows:
Status Byte #1 Bit Assignments
7 6 5 4 3 2 1 0
psDOCKED psLOCKOUT Reserved psEEWRITE psUPDATE psFAILSAFE psSIGNAL psONLINE
The RC4 Status Byte #2 flags are defined as follows:
Status Byte #2 Bit Assignments
7 6 5 4 3 2 1 0
Reserved Reserved Reserved Reserved psERROR psP1EEPROM psRESET psRESTART
The PIC2 Watchdog Timeouts value indicates how many times the "PIC2" microcontroller has reset due to watchdog timer time-outs. A watchdog timer is a timer that counts down and causes the chip to reset when the counter reaches zero. As long as the microcontroller is running properly, the internal program resets this counter to prevent the watchdog timer from reaching zero and resetting the chip. If the PIC2 Watchdog Timeouts value is anything but zero, this could indicate an internal problem.

PIC2 is one of the two microcontroller chips on the RC4 main board - the one that is responsible for all the PWM signal processing. A watchdog reset can only occur in PIC2 if the docking feature is available since the watchdog timer is not used in PIC2 when the docking feature is absent. Use the Read RC4 Configuration command to retreieve the "Features" bytes to determine what features are available. The availability of the docking feature will be indicated in the PIC1 Features byte (yes, the PIC1 features byte - if it's not in PIC1, it's not in PIC2, either).


The PIC2 Warm Resets value indicates how many times the "PIC2" microcontroller has been reset due to a software reset. A software reset can occur as the result of an RC4 Special Function command, either as a result of an EEPROM operation, or as a direct software reset request. A software reset also can occur as the result of a brown-out detection (where the power supply voltage drops to a point where functionality can become unreliable).


The PIC1 Watchdog Timeouts value indicates how many times the "PIC1" microcontroller has reset due to watchdog timer time-outs (for a brief description of what a watchdog timer is, see PIC2 Watchdog Timeouts). PIC1 is one of the two microcontroller chips on the RC4 main board - the one that is responsible for all the communications between the two PICs and the serial interface. A watchdog reset indicates that something abnormal has occurred during processing, usually regarding loss of communication between the two PICs microcontrollers - something that should never happen.

A PIC1 watchdog reset can occur duing a Factory Restore process whereby the hardware method is used to restore settings. To restore factory default settings, a button connected to the proper input must be pressed down before turning on power to RC4, and held down for a few seconds after the power comes on. During this time, communication between the two PICs is disrupted, so PIC1 may reset itself once or twice before the process completes (a lapse of approx. 2.7 seconds is required for a PIC1 watchdog reset to occur).


The PIC1 Warm Resets value indicates how many times the "PIC1" microcontroller has been reset due to a software reset. A software reset can occur as the result of an RC4 Special Function command, either as a result of an EEPROM operation, or as a direct software reset request. A software reset also can occur as the result of a brown-out detection (where the power supply voltage drops to a point where functionality can become unreliable).

2.2.10 Read RC4 Configuration (0x0D)

0D: Read RC4 Configuration
Value Bytes
RC4 Mode Settings
RC4 Interface Configuration
PWM Input Configuration
Physical Input Connections
Trigger Enable
PIC1 Features
PIC2 Features
1
1
1
1
1
1
1

This command returns configuration values that are specified through many of the RC4 Special Commands. For more information about these individual values, click on the corresponding entries in the table, above.

The PIC1 Features byte, also available in the extended ID block in the RoboBRiX ID block, is encoded to reveal what features are implemented into the current firmware version. The byte is encoded as follows:
PIC1 Features
RC4
Version		 7 6 5 4 3 2 1 0
Reserved Reserved Reserved Reserved Reserved fp1DEBUG fp1DOCKING fp1MCLR
F 1 0 0 0 0 0 0 1
The PIC2 Features byte indicates what functionality has been included in the firmware for PIC2. This byte is encoded as follows:
PIC2 Features
RC4 Version 7 6 5 4 3 2 1 0
Reserved Reserved Reserved Reserved Reserved fp2MIXED fp2EEPROM fp2FAILSAFE
F 0 0 0 0 0 1 1 0

2.2.11 Read Trigger Input (0x0E)

0E: Read Trigger Input
Value Bytes
Trigger Input Pulse Width
2

This command returns the pulse width of the signal appearing on the Trigger Input. The Trigger Input works independently of the other four channel inputs, therefore is not governed by the configuration settings that are available to the other four inputs. There is no minimum or maximum pulse width setting for the Trigger Input and there are no built-in features to discriminate between "valid" input signals and "invalid" input signals, and there are no noise rejection features associated with it. Trigger Input pulse width sample values are limited only by the hardware and firmware. The shortest pulse width that can be sampled on the Trigger Input depends on how quickly it can respond to a change in the input signal (this value has not been determined, and would vary somewhat due to its non-deterministic nature). The longest pulse width that can be sampled on the Trigger Input is limited by its internal 16-bit "register" (equating to approximately 21.8ms). Any pulse width exceeding this limit will not be represented correctly (i.e. the value will be undefined).

The Trigger Input is used to trigger events based on the pulse width of a signal, or signals, received on this input. Currently, there is only one, fixed, threshold setting that is used to control event triggering. This threshold is set to 4500 (or 0x1194 in hexadecimal), which equates to a 1.5ms pulse width. Any pulse width shorter than that envokes any events that are enabled, and any pulse width longer than that terminates or cancels any events or event states that may be in effect.

Currently, there is only one built-in event that can be enabled on the Trigger Input, and that is to force-activate the Fail-Safe state (otherwise known as "Fail-Safe on Demand"). For more information on Fail-Safe on Demand (or FSOD), see the RC4 Mode command. For more information about activating trigger events, see the Trigger Enable command.

If the FSOD function is enabled on the Trigger Input, then the Read Trigger Input command will return zero whenever there is no input signal present. Otherwise, the command will return the value of the last signal received.

The two-byte value returned is affected by the Endianness setting (see RC4 Interface Configuration for more information about Endianness).

2.2.12 Read Next Byte (0x0F)

0F: Read Next Byte
Value Bytes
Next Byte from RC4 Transmit Buffer
1

The serial communication interface of RC4 can operate in one of two modes: burst mode or byte mode (see RC4 Interface Configuration). In burst mode (the default), any command issued that asks for data in return, gets the data back in one continuous stream of bytes. If, for some reason, the host cannot receive data as fast as the serial port can deliver it, then data will be lost.

In byte mode, RC4 stores return data in its own internal (16-byte) buffer and will return exactly one byte in response to any command that returns data. If more than one byte of data is expected in response to a command, then issuing the Read Next Byte command will retrieve the next byte of data in the stream. This allows a slow host to retrieve a data stream one byte at a time at whatever rate it needs.

The number of data bytes returned by any given command is always known, so the host should always know how many bytes to expect and should call Read Next Byte only as many times as is necessary to collect all the data bytes. Read Next Byte will return zero if there is no more data available to return.

If another command is issued before all data bytes are read, the internal buffer will be cleared and replaced with any data that is expected from the new command. In other words, any data returned by the new command overwrites whatever is in the buffer, and any unread data from a previous command is lost.

The Read Next Byte command only functions when RC4 is configured for byte mode and will always return zero if used in burst mode. Burst mode or byte mode is established using the RC4 Interface Configuration special command.

Data returned by Read Next Byte is returned in the order determined by the Endianness setting (again, see RC4 Interface Configuration). This applies to any two-byte value(s) that may appear in the returned data.

2.3 RC4 Special Commands

The following commands are "special" commands that either define operating parameters for RC4 in general, or invoke seldom-used operations (such as saving settings to EEPROM).

RC4 Special Commands
Command Hex Bit Number Send/Receive Description
7 6 5 4 3 2 1 0
Special Function E0 1 1 1 0 0 0 0 0 Send Execute a Special Function
f f f f f f f f Send First 8-bit data byte ffffffff of function code
E0 1 1 1 0 0 0 0 0 Send Special Function Command again
s s s s s s s s Send Second 8-bit data byte ssssssss of function code
RC4 Mode E1 1 1 1 0 0 0 0 1 Send Set RC4 Operating Mode.
x r x l e s b f Send Mode Selection Byte
RC4 Interface E2 1 1 1 0 0 0 1 0 Send RC4 Command Interface Configuration
x e d d m b b b Send Define command interface operating parameters
PWM Configuration E3 1 1 1 0 0 0 1 1 Send Select PWM Configuration
x x x x x i i i Send Configuration Index (0-7)
Input Connections E4 1 1 1 0 0 1 0 0 Send Specify Channel Input Connections
x x x x 4 3 2 1 Send Enables physical channel input connections
Trigger Enable E5 1 1 1 0 0 1 0 1 Send Select PWM Configuration
x x x x x x x i Send Trigger Enable Bits
Enable EEPROM E6 1 1 1 0 0 1 1 0 Send Enable EEPROM Updates
A5 1 0 1 0 0 1 0 1 Send Allows EEPROM update functions to work
Docked Module E7 1 1 1 0 0 1 1 1 Send Enable docked FailSafe module
d d d d d d d d Send Selects docked module for access (0=undock)

2.3.1 RC4 Special Function (0xE0)

The RC4 Special Function command is used to invoke infrequently-used features of RC4, mostly for EEPROM save and restore operations.

All RC4 Special Function codes are two bytes long. However, only one byte of a two-byte code can be specified at a time. Therefore, to invoke a special function, the RC4 Special Function command must be executed twice - once to write the first byte of the function code, and again to write the second byte of the function code. The function is executed immediately following the write of the second byte. This is done primariy to protect against accidental executions of special functions.

Only specific Special Function code sequences will evoke actions. A zero data byte is considered invalid and serves to cancel or clear any current or incomplete Special Function command sequence. It is good practice to execute the Special Function command twice with a zero byte before executing a valid Special Function command sequence.
For example: E0 00 E0 00, referred to as Special Function code 00 00.

NOTE: Before issuing a Special Function command to save settings to the EEPROM, the Enable EEPROM command must be issued, first, or the Special Function command will generate an error.

Also, be aware that if the mfRESETCMD bit is set via the RC4 Modes command, any incomplete Special Function command sequence is automatically cleared if more than 5 seconds elapses between the first and second calls to supply the function code.

The table below lists the two-byte function codes required to execute their respective functions. All values are represented in hexadecimal.
Special Function Codes
Data Bytes Special Function
First Second
00 00 Enter normal operating mode (and/or clear E0 expectations)
EE 01 Save current channel values to Fail-Safe EEPROM
EE 02 Save RC4 PIC2 settings to EEPROM
EE 04 Save RC4 PIC1 settings to EEPROM
EE 7F Save all RC4 settings to EEPROM
FA 7F Restore all settings to factory defaults
FA 80 Recall default factory settings without EEPROM update
FF FF Perform software reset

Example: To save RC4 settings to EEPROM, the Special Function command must be performed twice by writing the following four bytes: E0 EE E0 02

The code sequences presented above are described in more detail, below:

EE 01
Saves the current channel values to EEPROM. Depending on the setting of the mfIOEEPROM bit (see RC4 Modes), the values that are saved are either provided by host, or are captured from the channel outputs. If mfIOEEPROM is set, then the values are taken from the last Write Channel Data command. Otherwise, if mfIOEEPROM is clear, then whatever signal values are driving the channel outputs are saved to EEPROM. This establishes the current settings as "presets" for output signal values for channels that are configured for R/C Fixed mode.

EE 02
Saves the current RC4 PIC2 settings to EEPROM, which includes the following:

PWM Input Configuration (1 byte)
PWM Signal Configuration (4 bytes)
Fail-Safe Operating Parameters (4 bytes)
Physical Input Connections (1 byte)
RC4 Mode (1 byte - only bits pertaining to PIC2 are observed)
RC4 Status Byte #1 (1 byte - for the psFAILSAFE bit, only)
Channel Configuration Bytes for Channels 1-4 (4 bytes)

EE 04
Saves the current RC4 PIC1 settings to EEPROM, which includes the following:

RC4 Mode (1 byte - only bits pertaining to PIC1 are observed)
RC4 Interface Configuration (1 byte)
Trigger Enable (1 byte)

EE 7F
Saves all RC4 configuration data (from PIC1 & PIC2) to EEPROM. Essentially combines the EE 01, EE 02 and EE 04 Special Mode command byte sequences.

FA 7F
Restores all EEPROM values to initial factory default settings. Followed by software reset. The Factory Restore operation is not selective. In other words, one cannot selectively restore settings or channel presets, etc. All settings are restored to factory defaults.

FA 80
Configures RC4 with factory default settings (with the exception of serial interface settings). The main difference between this command and FA 7F is that this command does not save factory default settings back to the EEPROM (i.e. the factory default settings are not permanently restored).

FF FF
Performs RC4 software reset, restoring RC4 to its power-up configuration.

2.3.2 RC4 Mode (0xE1)

The RC4 Mode command is used to establish various operating modes that apply to RC4 in general, independent from the various operating modes that can be applied to individual channels. RC4 Mode settings that affect the channels will affect all channels.

The RC4 Mode command must be followed by one data byte. This data byte uses a bit-mapped encoding scheme for specifying the desired modes. In other words, each bit of the byte serves to enable or disable a particular feature.

The RC4 Mode bit settings are encoded as follows:

RC4 Mode Bit Assignments
RC4 Defaults 7 6 5 4 3 2 1 0
Reserved mfRESETCMD Reserved mfLOCKOUT mfIOEEPROM mfIOTABLE mfFSODNOW mfFAILSAFE
F 0 0 0 0 0 1 0 0
RC4 Mode Byte Summary
Bit Meaning
7 Reserved Ignored - not implemented
6 mfRESETCMD Reset incomplete RC4 commands
  0 = Incomplete command reset is disabled
  1 = Incomplete command reset is enabled
5 Reserved Ignored - not implemented
4 mfLOCKOUT Noise Rejection
  0 = Noise Rejection disabled
  1 = Noise Rejection enabled
3 mfIOEEPROM I/O selection for EEPROM saves
  0 = Output signal values are saved
  1 = Commanded signal values are saved
2 mfIOTABLE I/O selection for channel sampling
  0 = Output signal values are read
  1 = Input signal values are read
1 mfFSODNOW Behavior of Fail-Safe-on-Demand
  0 = Fail-safe engages immediately
  1 = Fail-safe engages after a delay
0 mfFAILSAFE Fail-Safe-on-Demand (FSOD)
  0 = Normal RC4 operation
  1 = Forcibly activate Fail-Safe

2.3.3 RC4 Interface Configuration (0xE2)

The RC4 Interface Configuration command is used to establish the settings required for communication over the serial interface. Note that in order to issue this command, the host must be able to talk to RC4 at whatever speed it is currently set to (factory setting is 2400 bps). Also, if the speed setting is altered by this command, the host will need to reconfigure the speed of its serial port to match in order to regain communication with RC4. RC4 does not have an auto-detect speed feature!

The RC4 Interface Configuration command requires only one data byte. The bits of this byte are encoded to specify Endianness, Extended Data Level, Data Mode and Bit Rate selections (see table, below). Note that if only one of these options needs to be changed, the others must be preserved. Therefore, the host should maintain a copy of this byte so that when one or more selections need to be altered, only the bits of interest should be modified and then the new byte written to RC4 by issuing this command again.

The RC4 Interface Configuration byte is encoded as follows:

RC4 Interface Configuration Byte
76543210
Reserved Endianness
0=Little
1=Big		 Extended Data
00=Base Data Only
01=Level 1 Extended
10=Level 2 Extended
11=Level 3 Extended		 Data Mode
0=Burst
1=Byte		 Bit Rate
000=1200 bps
001=2400 bps*
010=4800 bps
011=9600 bps
100=19200 bps
101=38400 bps
110=56000 bps
111=57600 bps
* 2400 bps is the factory default and is also the default RoboBRiX serial interface speed.

Endianness refers to the order in which data bytes are returned, and it applies only to values that are larger than one byte. Some RC4 commands return two-byte values, such as those that return channel input pulse width values. The order in which the bytes of these values is returned is determined by the Endianness setting.

In Big Endian mode, the high byte is transmitted first, followed by the low byte. In Little Endian mode, the low byte is transmitted first, followed by the high byte. This is useful for accommodating a variety of host processors. For example, computers running Windows operating systems operate in Little Endian mode, whereas a MIPS embedded processor may operate in Big Endian mode.

It is important to remember that if a command returns a stream of data (such as the Read Channel Data command configured to return extended data), the order of the values returned is not affected. Only the byte order of any two-byte values within the data stream affected. Therefore, Read Channel Data will always return Channel 1, Channel 2, Channel 3 and Channel 4 values in the same sequence, but the byte order would be high,low,high,low,high,low,high,low in Big Endian mode, or low,high,low,high,low,high,low,high, in Little Endian mode.

Extended Data bits are used to specify what data is returned by the Read Channel Data command.

Since there are separate read commands to retrieve sampled signal data from the channels and status information about the channels, it is possible that the status information could be out of sync with the data, since an update could occur between the two reads. Therefore, a mechanism has been provided to return synchronized data and status information in response to a single command. The Extended Data bits are used to select the data that is returned by the Read Channel Data command.

When these bits are zero, only the signal data is returned for the four input channels (this is the default setting). There are three additional levels of information that can be selected (see the Read Channel Data command for more information).

Note that these bits only need to be set once to affect all subsequent channel data reads. These bits can be changed at any time to change the data reporting level.

Data Mode determines how data is returned by all RC4 commands that return data. If this bit is zero, then this is considered "Burst" mode, and all data in response to a read command is transmitted in a continuous stream at whatever the current bit rate setting is. This is fine for hosts that either collect the data into a buffer or that run fast enough to process each byte as it is returned.

When the Data Mode bit is set, this puts RC4 in "Byte" mode. In this mode, all data that is returned by a read command is kept in a buffer inside RC4 and is delivered one byte at a time. The first byte is returned immediately after issuing the read command. Any and all subsequent bytes are retrieved by successive Read Next Byte commands. This allows a slower host to process the data at whatever speed it can handle.

Burst mode is the default mode of operation.

Bit Rate bits select the speed at which the serial interface operates. The default factory setting sets these bits to 001 to select 2400 bps, which is compatible with RoboBRiX. The table above lists the possible settings for these bits and their corresponding bit rates.

All data transmitted (and received) by RC4 across the serial interface is structured as 8 data bits, one start bit, one stop bit and no parity. Since there is no parity checking, there is no way that RC4 can determine if the data it receives is valid. Whereas RC4 can detect framing errors or overrun errors, it is unable to detect errors that may creep into the data. However, an actual data error is such a highly unlikely event in anything but the most extreme environments, it is of little concern. Nevertheless, the following table is provided to indicate the potential error rates of the various bit rate settings.

Bit Rate Error Rate
1200 0.16%
2400 1.46%
4800 0.16%
9600 0.16%
19200 0.16%
38400 2.8%
56000 3.02%
57600 0.16%

Bear in mind that during extensive RC4 testing, no data errors have ever been recorded, except for the standard 115200 bps setting which was not implemented because the error rate was too high (8.5%). The error rate has a direct relationship with the clock speed of RC4, which runs at 12 MHz. The table provided above should serve only as a guideline for selecting a data transmission rate that is most suitable for your application.

2.3.4 PWM Input Configuration (0xE3)

Configuring the operating parameters for various R/C receivers is a complex task. Therefore, instead of passing that burden along to the end-user, a series of eight pre-defined parameter sets have been defined for RC4 to greatly simplify this set-up process. The PWM Input Configuration command is used to select the desired configuration by simply specifying a number between 0 and 7 (see table, below).

The following table lists the values assigned to MSINPUT, MSOUTPUT, FSTIMEOUT and FSRELEASE when a particular index number is specified. Also listed are the values that are assigned to the PWM MIN and MAX settings following a PWM Input Configuration command. MIN and MAX values can be altered through the Write PWM Signal Configuration command. If you are not familiar with these parameters and how they affect RC4 operation, then this table will be of little use. What is important to note is the "Period" value. Every R/C receiver repeats its signal cycle on a periodic basis - somewhere around 20ms. The correct PWMIDX setting for your receiver is the index that is closest to the signal period of your receiver. For example, if your receiver's signal cycle repeats every 20ms (50.0 Hz), then set PWMIDX to 4.

Index Period Pulse Min Pulse Max MSINPUT MSOUTPUT FSTIMEOUT FSRELEASE
msHz MINusDuty MAXusDuty
0
 18.055.56 0A8C938.75.2% 19002133.311.85% 9688 215819ms 35 37
1
 18.554.05 0A8C938.75.1% 19BB2195.711.87% 939A 1B7C19.5ms 33 36
2
 19.052.63 0A8C938.74.9% 1A772258.311.89% 90AC 15A020ms 32 35
3
 19.551.28 0A8C938.74.8% 1B322320.711.90% 8DBE 0FC420.5ms 31 33
4
 20.050.00 0A8C938.74.7% 1BEE2383.311.92% 8AD0 09E821ms 30 32
5
 20.548.78 0A8C938.74.6% 1CA92445.711.93% 87E2 040C21.5ms 2E 31
6
 21.047.62 0A8C938.74.5% 1D652508.311.94% 84F4 000021.8ms+ 2E 30
7
 21.546.51 0A8C938.74.4% 1E202570.711.96% 8206 000021.8ms+ 2E 2E

FSTIMEOUT and FSRELEASE are chosen to provide an approximate 1-second delay. So, for an 18ms signal cycle, 1/0.018 = 55.555, or about 0x37. FSRELEASE is computed based on the actual signal period of the receiver, when signal is present. FSTIMEOUT is computed based on the MSOUTPUT timeout value, when signal is absent. MSOUTPUT is a time value equal to approximately 1ms longer than the signal period, which is why the FSTIMEOUT values are lower than FSRELEASE. However, in the case of PWMIDX 6 & 7, the maximum limit of RC4 is reached, so the MSOUTPUT value is unable to exceed about 21.8ms. In these cases, the FSTIMEOUT value approaches FSRELEASE values.

The FSTIMEOUT value specifies how many signal cycles must be absent before Fail-Safe mode engages. The FSRELEASE value specifies how many signal cycles must be valid before Fail-Safe mode disengages. The values listed in the table are computed for approximately one second in each case. After specifying a PWMIDX values, the Write Fail-Safe Configuration command can be used to modify these values, although this is not recommended.

Note that the FSREJECT0 and FSREJECT1 values are not listed in this table. If you are not familiar with what these values are and how they affect RC4 operation, then the use of the Write Fail-Safe Configuration command is HIGHLY discouraged!

E3 requires one data byte to specify the PWMIDX value. For example:

E3 04 ; Sets RC4 for a 20ms input signal period

2.3.5 Physical Input Connections (0xE4)

In some RC4 implementations, it may be necessary or desirable to connect less than four of the PWM (R/C) inputs. Under normal (default) operation, RC4 must have signal on all four inputs in order to function. The E4 command provides a way to specify which channel inputs are connected.

E4 requires one data byte to specify input connections. This byte is bit-mapped such that bit 0 refers to channel 1, and bit 3 refers to channel 4. A zero bit indicates that a channel input is not connected, and a one bit indicates that it is connected.

For example:

E4 07 ; Indicates channels 1, 2 & 3 are connected, but channel 4 is not

If a channel is configured as disconnected, any signal that may be physically connected to that input will be ignored. Therefore, a software disconnect is as effective as a hardware disconnect.

It is important to remember that if a channel input is configured as connected, and no physical connection is present, RC4 will not function. RC4 will produce output signals, but no new signals will get through, because it is unable to detect a complete signal set. If one connected input lacks signal, any and all signals present on the remaining inputs are discarded.

2.3.6 Trigger Enable (0xE5)

During the RC4 design process, it was conceived that the Trigger Input could be used for various pulse-width triggering functions. Therefore, the Trigger Enable command was created to provide a means of selecting from the various available triggering options. As it turns out, however, there is currently only one integrated RC4 function available to the Trigger Input, and that is the control of Fail-Safe activation. Or, more specifically, Fail-Safe On Demand (or FSOD).

Since the Trigger Input signal value can be read by the host, the host is free to implement whatever triggering options it desires, externally. Therefore, there is little need for RC4 to carry the extra features that were possibly anticipated by its creator.

The Trigger Enable command accepts one byte of data to select its function. The value of this byte can be either 0 (no function assignment, which is the default) or 1 (Fail-Safe On Demand). All other values will be ignored, leaving the current selection unchanged.

The Fail-Safe On Demand feature is described in more detail in the RC4 Mode description and in various other text within this document.
Two important things to note are:
  1. Enabling FSOD control on the Trigger Input prevents FSOD from being controlled through software via the RC4 Mode command (i.e. FSOD is either under Trigger Input control, or it is under RC4 Mode control).
  2. Reading Trigger Input data will return zero while FSOD is enabled on the Trigger Input and no input signal is present.

2.3.7 Enable EEPROM Updates (0xE6)

In order to prevent accidental EEPROM updates in wake of unexpected events (power disruptions, data synchronization errors, etc.), extra steps must be taken so that RC4 knows you really do want to update the contents of the non-volatile EEPROM memory. Although such events are extremely rare, it is important that the persistent settings stored in the EEPROM remain intact.

Therefore, before issuing an RC4 Special Function command to write data to the EEPROM, the Enable EEPROM Updates command must be issued, first. The Enable EEPROM Updates command byte must be followed by a byte having the hexadecimal value of 0xA5 in order to enable EEPROM updates within RC4. The very next command must be an RC4 Special Function command for an EEPROM write to actually occur. EEPROM updates are then immediately disabled once again.

The Enable EEPROM Updates command must be given immediately prior to any and all EEPROM write operations. Additionally, if a command issued after the Enable EEPROM Updates command does not perform an EEPROM write, EEPROM updates will once again become disabled and any subsequent RC4 Special Function command will fail to update the EEPROM.

If an attempt is made to write to the EEPROM when EEPROM updates are not enabled, an error will be generated (error code 6: EEPROM write operation failed).

2.3.8 Enable Docked Module (0xE7)

RC4 provides a six-pin header that enables a separate (but related) board to be "docked" to the RC4 base board in order to make use of PIC1, the RC4 communications interface chip. Presently, only one dockable module is under evaluation that provides Fail-Safe functionality to four servos in an RC application. However, this particular device may be dropped, and docked module functionality is not yet fully defined, so it is possible this feature will be absent in future versions of RC4.

This feature is not useful without a module to dock, and will cause a PIC1 watchdog reset if an attempt is made to enable an absent module.

2.4 RoboBRiX Interrupt Commands

RoboBRiX Interrupt command codes EF through F7 are not currently supported in RC4. Additionally, RC4 refrains from implementing any command codes between E8 and EE in order to allow room for potential future expansion of the RoboBRiX shared command set.

2.5 RoboBRiX Shared Commands

RC4 supports the RoboBRiX shared commands that are accessible at all times. The RoboBRiX interrupt protocol currently is not supported, although this functionality may be implemented at a later date (in conjunction with Trigger Input event triggering).

RC4 supports the following RoboBRiX shared commands:
Shared RoboBRiX Commands
Command Hex Bit Number Send/Receive Description
7 6 5 4 3 2 1 0
Glitch FF 1 1 1 1 1 1 1 1 Send Increment Glitch Counter
Glitch Read FE 1 1 1 1 1 1 1 0 Send Returns 8-bit gggggggg Glitch Counter value
g g g g g g g g Receive
ID Reset FD 1 1 1 1 1 1 0 1 Send Reset ID Block index
ID Next FC 1 1 1 1 1 1 0 0 Send Returns the next byte from the ID block
i i i i i i i i Receive
Clock Pulse FB 1 1 1 1 1 0 1 1 Send Returns zero - clock feature not implemented
0 0 0 0 0 0 0 0 Receive
Clock Read FA 1 1 1 1 1 0 1 0 Send Returns zero - clock feature not implemented
0 0 0 0 0 0 0 0 Receive
Clock Increment F9 1 1 1 1 1 0 0 1 Send No effect - clock feature not implemented
Clock Decrement F8 1 1 1 1 1 0 0 0 Send No effect - clock feature not implemented
The RoboBRiX identification bytes return information about RC4 in accordance with the RoboBRiX specification. The RoboBRiX ID for RC4 is 30 (decimal).
The complete list of ID bytes provided by RC4 is presented in the table, below.

RC4 RoboBRiX Identification Bytes
Offset Name Description RC4 Value
0 RBMajor ID Block Major Version Number 1
1 RBMinor ID Block Minor Version Number 0
2 BrickID BrickID 30
3 BrickRev Brick Revision (0=A, 1=B, etc.) 6
4 BrickFlags Brick-Specific Flags 4
5 Reserved0 (use 0) Reserved for future use 0
6 Reserved1 (use 0) Reserved for future use 0
7 Reserved2 (use 0) Reserved for future use 0
8-23 UID0-15 128-bit Unique Identifier (Randomly Generated) Random
24 NameLength RoboBRiX Name Length 3
25-27 BrickName Name of RoboBRiX in ASCII "RC4"
28 VendorLength Vendor Name Length 13
29-41 VendorName Vendor Name in ASCII "CodeSmart.com"
42 OptionsLength Size of extended ID block 6
43 MajorVer1 Firmware major version # for PIC1 2
44 MinorVer1 Firmware minor version # for PIC1 2
45 Features1 Features Code for PIC1 Varies
46 MajorVer2 Firmware major version # for PIC2 2
47 MinorVer2 Firmware minor version # for PIC2 2
48 Features2 Features code for PIC2 Varies

3. Hardware

The hardware consists of a circuit schematic and a printed circuit board.

3.1 Circuit Schematic

The RC4 schematic is available here:
rc4f.sch
RC4 was designed using the ExpressPCB tools. You will need the ExpressPCB tools to open this file. These tools are available free from www.expresspcb.com.

3.2 Printed Circuit Board

The RC4 printed circuit board layout is available here:

rc4f.pcb
Note that this PCB file contains the layout for the RC4 revision F board as well as the Brick232 board (Rev. B), the FailSafe board (Rev. A) and the BX-24 Pilot board (Rev. A). Information for these additional boards is not provided here.

RC4 was designed using the ExpressPCB tools. You will need the ExpressPCB tools to open this file. These tools are available free from www.expresspcb.com.

3.3 Parts List

The parts list for RC4 is not yet available.

4. Firmware

The firmware source code for the PIC microcontrollers at the core of RC4 is not available. Pre-programmed chips will be available from the author at a later date, and they will be code-protected. Sorry!

5. Software

Software for testing and controlling RC4 is not yet available.

Here's a few screen shots of alpha software in development:

Note that this software is under development and is actually used as a tool to aid in RC4 development and debugging. Therefore, the features and layout depicted in these screen shots may not represent the features and options available in the actual end product.

6. Issues

Current pending hardware, firmware and software issues are noted here.

6.1 Hardware Issues

The following is a list of hardware design issues regarding the current prototype:

6.2 Firmware Issues

Firmware development for Revision F is currently frozen - no more changes will be made. The following issues will remain to be resolved in Revision G.

The following firmware issues are under consideration (many of these points may not make sense to anyone but me):

High Priority Issues:

Low Priority Issues:

Extremely Low Priority Issues

6.3 Software Issues

No software issues listed [here], yet.

7. Documentation

Documentation for RC4 is not available at this time, but the following is planned:

Copyright (c) 2002-2007 by CodeSmart. All rights reserved.