RC4 Servo Monitor & Controller - Fact Sheet

RC4 Prototype - Click for more info RC4 is a 4-channel servo monitor/controller board that provides a variety of rich, robust features that make it ideal for many autonomous and semi-autonomous applications. RC4 can be used as a simple servo controller, or it can be plugged into a standard RC receiver to monitor and respond to five pulse-width-modulated signals and drive four servo outputs. Input or output pulse width measurements can be obtained from each channel during operation via a serial interface. This serial interface can operate reliably at speeds up to 57600 bps without interfering with servo control signals.

RC4 provides the following notable features:

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

More detailed information about RC4 is available here.

General Theory of Operation

RC4 splits its tasks between two PIC microcontrollers, PIC1 (a PIC16F648A) and PIC2 (a PIC16F628).

PIC1 handles all of the communication requirements. It provides a serial port command interface to allow a host system or controller to interact with RC4, as well as a custom high-speed two-wire serial communication interface for exchanging data between PIC1 and PIC2. PIC1 also provides input sampling for the Trigger Input.

PIC2 handles all of the PWM signal sampling and signal generation for each of the four input and output channels (the Trigger Input is processed by PIC1). PIC2 is really the central driving force behind RC4, dictating to PIC1 when two-wire communication cycles can occur, and maintaining a rigorous timing schedule to keep things on track and in synch. It manages all the signal processing dirty work. In fact, PIC2 is so dedicated to its job that it will continue to function, unimpeded, even if PIC1 is completely removed from the circuit (although RC4 would lose the ability to respond to the Trigger Input).

In order for PIC2 to provide the high degree of quality in gathering stable pulse width measurements, there are some built-in limitations. For example, the PWM inputs must be multiplexed such that only one input has a signal on it at any given time. Most standard R/C receivers work this way, delivering signals in sequence from Channel 1 through Channel 4. PIC2 is also limited as to how quickly it can turn around, after sampling input signals and generating output signals, to be ready for the next batch of input signals. Signal sampling begins to break down for input signals that repeat at intervals less than about 17.5ms. This is not a serious limitation, however, as PIC2 will continue to successfully sample input signals; it will merely skip missed input cycles if the frame rate is too short.

Input signal sampling and output signal generation occur at different times. Output signals are generated only after all input signals have been sampled. This means there is a slight delay between the time a signal arrives on the input and the time the signal appears on the output. This delay is different, depending on configuration settings, but typically amounts to approximately half of the selected frame rate.

For example, for an input signal with a period of 18ms, the output generation cycle begins 9ms after the first input signal is detected. Because of this timing, connections to RC4 from an R/C receiver must be grouped by adjacent channels (for example, you cannot connect channels 1,2,3 and 5 from an R/C receiver to channels 1,2,3 and 4 of RC4). The order in which the channels are connected is not restricted, however, as long as it is a grouping of four adjacent channels. For example, channels 1,2,3 & 4 of an R/C receiver could be connected to RC4 channel inputs 2,4,3 & 1 if this configuration was necessary for some reason.

RC4 will not work with some radios - such as some Futaba PCM radios - because they produce signals on multiple outputs, simultaneously. RC4 cannot support these radios, now or in the future.

One primary goal of PIC2 is to keep the output signal generation cycle on track, through thick and thin. If there is a problem with the input signals, PIC2 does its best to maintain a stable output. If no input signal arrives when expected, PIC2 aborts input sampling in favor of getting the output signals out on time.

Although there is a delay between input signal sampling and output signal generation, the period and waveform of the outputs remain unchanged from the input. If the input signals repeat every 18ms, then so do the output signals - they're just delayed 9ms later in time. For an 18ms configuration, if there is no input signal present, then the output signal period will change from 18ms to 19ms. This absent-signal period will always be 1ms longer than the configuration setting. For example, if RC4 is configured for input signals with a 19ms period, the output signals will repeat every 20ms when no input signal is present. This difference is due to how input signal timeouts are implemented in PIC2.

RC4 was primarily designed with servo-based applications in mind, so these minor differences in output signal periods don't amount to much as far as a servo is concerned. However, because of these delays and variances, RC4 may not be well suited for critical applications that rely on when pulses arrive from the source.

Another major objective of PIC2 is to deliver signal data and status information that is in synch with each other over the serial interface, so that status information obtained from PIC2 actually reflects the same signal cycle in which the channel inputs were sampled. This, too, is the reason that the Read Channel Data command has extended data levels available to it. Since PIC2 can interrupt PIC1, asynchronously, to deliver updates, two subsequent reads from PIC1 by the host over the serial interface (one to retrieve signal data and another to retrieve status) could wind up out of synch. This is because it is possible that PIC1 could receive an update from PIC2 between the time it delivers the signal data and the time it delivers the status information. Having a single command return both signal data and status information eliminates this possibility.

As with all systems, the #1 primary objective of RC4 is to survive. An incredible degree of innovation has been implemented to ensure that RC4 not only survives, but also remains functional, within its applied environment.

More detailed information about RC4 is available here.

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