Wireless
technologies have been around in the home and office for many years. Some of
these have even made it on to the factory floor in limited applications. The R&D
challenge before us was to create a fast, robust, industrial wireless
interface. To do that, we had to amp up wireless performance and reliability to the
point where we had a practical signal that could be used for the critical
real-time control demands of discrete manufacturing: deterministic timing, substantial
range, and signal integrity in an electrically hostile environment. Here's how
we did it.
Reality Check
Let's
start with the basics. We were intending to digitize the output from an optical
encoder with a 100kHz bandwidth (two signals in quadrature plus an index) in
real time, send it up to 100m away and then reconstruct the position
information in that signal remotely at a rate of about 1000 times a second.
Since most control loops have a frequency of 100 Hz or less, this gave us
plenty of oversampling to ensure signal integrity and time to reconstruct lost
data. Just like dropped cell phone calls, we had no hopes that our data would
be flawlessly transmitted every time.
|
With
the transmission requirements defined, we had to find the right chip and a
suitable operating frequency. Fortunately, the ISM band has accessible
licensing requirements that are well defined for use with devices like WiFi and
Bluetooth. On the negative side, a lot of the
standard protocols have too much communication overhead and latency for the
application we were
targeting. After some searching, we found a manufacturer who could produce a
2.4 GHz, ISM band-compatible chip with the ability to handle not only the data
latency issues, but the overhead and enough available broadcast power to meet
our broadcast range target of 100m.
Dealing with the
Signal
It's
a given that the factory floor and a whole host of other industrial
environments will be awash in radio signals that could interfere with our
particular broadcast, so we had to devise strategies to ensure that our signals
had the maximum chance to succeed. One of the first strategies we employed was
to set up the transmitter/receiver pair to operate as a one-to-one
communication set. This ensured that the maximum amount of time was available
for this radio pair to communicate without some other device interruption. One-to-many
or many-to-one communication strategies statistically reduce the amount of time
available for each device.
The
2.4 GHz ISM frequency band comes with a requirement for frequency hopping to
ensure that there will not be a lot of devices camping out on a particular
frequency for long periods of time (sort of like CB radio operators taking up
the airwaves for too long). This meant that we had a number of protocols
available to us. We chose an adaptive frequency hopping (AFH) approach that not
only scrolled through the hopping sequence but also "adapted" the available
frequency list by keeping track of which ones were working the best based on
signal integrity ("good" frequencies migrate to the top of the list and "bad"
ones to the bottom). In lab testing next to WiFi enabled laptops, the spectrum
analyzer traces migrated swiftly out of the way of interference when the
computers were turned on.
Signal security was another big issue
we confronted. To ensure that nobody could easily hack into the transmission
signal, we added a robust 40 bit encryption scheme to keep the data secure
while in the air.
With security, agility and range covered,
it was
time to tackle the signal itself. This turned out to be a significant
challenge. Frequency hopping requires that the transmitter/receiver pair need
to be in constant two-way communication about the band they are planning to use
next and whether or not the signal has been received. This high degree of
synchronization means a significant part of the signal is being used just for
this two-way communication. This demanded that we develop a compact and
efficient way to communicate the encoder position information in a way that
could be verified at the receiver end as a "good" piece of data and, if it
wasn't good data, we had to then decide what to do about it. You can only
accept a certain amount of bad data before you have to call it quits.
|
To
deal with the potential for dropped data packets, we developed a patent pending
solution that takes advantage of the fact that encoders are generally attached
to machinery that has a fair amount of inertia. The encoder cannot change
direction instantaneously and therefore its position, velocity and acceleration
are constrained by the physics of moving equipment. This allows the use of a
predictive model of position over short periods of time-a sort of "dead
reckoning" where the equipment is at any given moment. This works up to a
point, which (based on field testing) is about 0.2 second in real-time control
situations. Since we are broadcasting about 1000 times per second, the signal
would have to experience 200 successive lost data packets before we hit this threshold;
an unlikely, but statistically probable event. Should that occur, the radio
pair activates the built-in test flag alerting the controller that possible
suspect data is being transmitted. The system designer can choose what to do
with this flag depending on the system being controlled (shut down, slow down,
idle, or reset for example).
Dozens
of other design activities came into play on this project, including maximizing
power output, grounding, testing antenna types, troubleshooting field tests,
packaging, and connection options. All-in-all, it was a two-year development
effort. Ultimately, the finished radios were enclosed in NEMA 4 boxes with
antennas (see photo) and the communication system was dubbed SWIFTComm, which
stands for Secure, Wireless, Industrial Fast TeleCOMMunications. FCC and CE
approval were acquired for U.S., Canada and Europe and we've gone on to develop
versions that work with an absolute SSI output as well as explosion-proof
packaged versions.
Scott Orlosky is manager of marketing and
strategy at BEI Sensors.
Tweet This
4 
