Wireless Remote Controls
Keeping it simple
by Timothy Last, Applications Engineer, Radiometrix Ltd
Many wireless remote control and data acquisition applications require only a simple
on/off, yes/no capability. Literally a logic ‘1’ or ‘0’. To achieve maximum efficiency it
is necessary to reduce the data carried by the communications channel to the minimum
required to perform the task. In the simplest case this would reduce to: RF present = ‘1’ and this would be fine if nobody else used radio. In reality some form of selectivity and data encoding is required so that the application only responds to the controls intended for it. From this straight-forward starting point there is no end of choice and (for the unwary) potential disappointment.
The wireless link can be the weakest part of a system because it is often the most
susceptible to the environment. The receiver could be thought of as a special form of
ADC, re-constituting relatively slow-speed data from a far-field EM carrier wave presented at levels typically 60 – 70dB less than that of the rest of the system. It is a
very sensitive analogue component in any system. When viewed in this way it can make sense to design a system around the RF communications medium, rather than as a bolton afterthought. (The question is asked sometimes: “do I need to connect an antenna?”).
Examining the system and assessing the “must haves” and the “nice to haves” right at
the start can save a major headache later. Marketing the idea that a radio module is ‘plug and play’ may not be helpful in the long run because many people are disappointed when they find that it isn’t, after all, the wire replacement they were hoping for. Modern computer data transfers occur in Gb/s and even simple end application data transfers can be in hundreds of kb/s or many Mb/s – not because the application requires it but simply because it can.
Bandwidth and occupancy limitations, particularly for de-regulated Short Range
Devices (SRD’s) mean that some compromise is inevitable and this is often discovered
only on the point of interfacing to the RF module. Wouldn’t it be better to market RF
communications and bandwidth for what it is, a precious resource to be carefully
employed for best results? There are benefits to slow-speed data transfer in a wireless
data network; the reduction in bandwidth required leads to an effective increase in range and a larger choice of radio frequencies. Many applications only require the transfer of a few bytes at a time, where it is not relevant whether this occurs at 1.2kbps or 250kbps but a point-to-point distance capability measured in kilometres is important.
With this “heads-up” on system design incorporating RF modules, the would-be designer will by now have decided not to incorporate a mesh-network router and embed HTML web-pages into the light bulb to be remotely controlled…. Perhaps.
What are the choices if electing to go the “simple” route? The first decision is whether
you wish to perform your own encoding / decoding and design your own protocol for
the radio communications data. Advantages in doing this are that you will have
complete control and understanding of the radio communications “layer” in your
product. Disadvantages are that it will take longer and burden your (typically
microcontroller based) project with lots of “radio stuff”.
For the designer who is aware of RF modulation principles and the data encoding and
decoding requirements for successful data transfer but without the time to “start from
scratch”, modules such as the Radiometrix PLT/PLR “Packet Link” perform the lowlevel
synchronisation and encoding / decoding of data whilst maintaining an interface in
the form of a data packet for the designer to use as they wish.
When a digital design engineer, who has just been told to “add remote control to it”,
connects a microcontroller UART directly to raw TXD/RXD pins on an RF module the
result is often surprise at the poor range and upon further investigation with an
oscilloscope, the discovery of apparently random data on the RXD pin when there is no
signal present…this being the digital resolution of an FM discriminator output. For the
neophyte designer in this position a module incorporating an encoder / decoder and
built-in data packet organisation (in other words a ‘dumb’ modem) is recommended.
Simple asynchronous data transfers of any length are then handled by the modem for
optimum performance by the module.
Such issues can be illustrated with a diagram relating to the Open Systems
Interconnection (OSI) model:
In the diagram, Host A contains all the processing relating to the sending of data via RF Module A, right down to low-level Manchester encoding, preamble and synchronisation for the raw data stream presented to the modulator in the radio. RF Module B however, has all this processing built in, so Host B does not need to contain the processes required for decoding the radio message and communicates with the radio at a higher level such as the Data Link or Network Layer (or more likely parts of both).
OSI layers are usually not strictly applied to simple low-power radio data links but a point of view that any designer will appreciate is that a radio network could be treated as a separate network, with its own characteristics and optimal configuration in a given
implementation. Where processing for radio network management resides is the choice
of the system designer but it has to be done somewhere. It may be hidden within the
module in the form of a simple addressing byte appended to each transmission or as a
full-blown self-organising mesh network but sometimes it is better to have control of
this in your own design, so that data-transfer can be optimised for your application.
A single point-to-point link may be all that is required and then network protocol is
unnecessary. For example: a remote control for a camera positioned up to 300m away is required. The remote control includes a “flash trigger”. The camera flash must occur
within 0.5ms of the flash command being activated remotely. The remote control must
300m range and low-cost would steer the designer towards low-power licence-exempt
radio modules. A point-to-point single link is indicated. 2.4GHz is rejected in favour of
frequencies at 868MHz or lower, because of range considerations. The 0.5ms flash
response also rules out complex mesh networks, in fact any form of data overhead –
hang-on – it appears to rule out everything doesn’t it? A data transmission from a lowcost module typically contains several milliseconds of preamble and synchronisation, so how is it going to work?
Fortunately, the designer could elect to make use of a Received Signal Strength
Indicator (RSSI) or Carrier Detect (CD) output. For some receiver modules
Radiometrix quote a 100us response time for this output, likewise a 100us dynamic
power-up time is quoted for some transmitters. Using an on-off keying sequence it
should be possible to achieve a sub 500us control signal for the flash. As there is no
such stipulation for other aspects of the remote control the rest can be handled by the
conventional FSK-data capabilities of the modules.
The example demonstrates how basic remote control applications with a specific
requirement can be implemented by designing in RF modules with a comparatively low
“feature count”. All the high-level features offered in complex off-the-shelf radio data
systems would not have helped to meet a fundamental requirement in this case.
It is always worthwhile taking a second look at the core requirements of any application; how many bits will you use to turn that light on?