Getting The Most From Your Mio Modero R-4
62
Mio Modero R-4 Remote - Instruction Manual
Getting The Most From Your Mio Modero R-4
Overview
One of the strengths of the Mio Modero R-4 is its flexibility. Not only may a user change the Mio R-4’s basic functionality, such as
changing presets, but it also has the capacity for upgrades to add or improve other abilities. These upgrades are available by direct
uploading of new firmware via the USB programming jack (see the
Using the Programming Jack on the Mio R-4
on page 26 for
more information).
Getting the Most From the Mio R-4
The Mio R-4 uses a new wireless personal network technology (802.15.4) and protocol (ZigBee) to transmit and receive
information. With the advent of new technologies that surpass previous ones both in speed and in data transmission, the average
user is accustomed to a design philosophy of “smaller, better, and faster”. Because ZigBee and its underlying protocol were
designed for a mesh- type network topology, low power consumption, and interoperability, not for bandwidth, that philosophy
cannot be applied to this technology. WiFi (802.11b/g) products from AMX are wireless Ethernet devices and can sustain speeds in
the tens of megabits per second, while ZigBee was designed for small, low-power devices with minimal bandwidth requirements.
The best way to approach the use of AMX ZigBee devices is to treat them as if they were AMX AXLink devices. AXLink devices can
only handle a specific amount of data at one time due to bandwidth limitations, and ZigBee devices must be treated in the same
way.
To optimize the functionality and extend the battery life of the Mio R-4, several things should be considered when programming its
interface. (For more information on programming the Mio R-4, see the
Programming the Mio R-4
on page 26.)
Installations using standard wireless must adhere to precautions, just as in WiFi installations. Proper placement of the
ZigBee network gateway and repeater(s) is critical for reliable coverage. Just as in WiFi, avoid placing these devices near
large metal objects, behind, under, or on top of metal objects, or any other place where interference could be an issue. Due
to the wireless nature of the ZigBee network, temporary interference (such as leaving a room or having objects pass
between the Mio R-4 and its gateway device) may prevent a command from reaching the NetLinx master.
Because of temporary interference issues (such as leaving a room or large objects passing between the Mio R-4 and its
gateway device) preventing commands from reaching the NetLinx master, special attention must be paid to volume control.
NOTE:
If a remote command is lost while increasing volume, the master may receive the command to increase the volume
but not the command to stop increasing it.
Programmers should consider setting safeguards for volume control (either established volume limits or timeouts with the
NetLinx master, or more interactive adjustment from the Mio R-4 such as direct volume control) to prevent issues with lost
commands.
To avoid a frustrating user experience, a programmer's understanding of the type of device being used and the amount of
data being sent to and from the device is crucial. While a touch panel can handle large amounts of data for functions such
as list boxes, variable text fields, and commands to alter button behavior, the Mio R-4 cannot. The programmer must
always be aware of how many messages will be sent to the remote for any given event (online/offline events, button push/
release, channel updates, variable text field updates, etc.). Sending many commands at one time over a low bandwidth
interface will cause the commands to back up and updates will occur more slowly.
Care should be taken when sending device updates to a remote. For instance, many MP3 players constantly send status
updates: when a song is being played, the time remaining may be updated once per second along with the song title and
artist. The title and artist do not change during the course of the song, so those fields on the remote do not need to be
updated. Likewise, instead of sending updates for time remaining on a song once per second, the updates could be sent to
the remote once every five seconds.
As with any wireless device, the farther away from the receiving point (either gateway or repeater access point), the lower
the available bandwidth. Try to limit the number of hops between the remote and the master, as each hop will increase the
response time (for example, 2 hops = 2x response time, 3 hops = 3x response time, etc.).
“Hops” are defined as the number of gateways or repeaters the data must travel through to get to the master. As an
example, consider a simple system with one gateway. Events on the remote are communicated to the gateway and then to
the master, which constitutes one hop. Two hops would occur if an event must go through a repeater to a gateway, and
then to a master. Limiting the number of hops made greatly improves the user experience.
Levels designed on the Mio R-4 panel pages generate a large number of messages between the R-4 and the master. If other
remotes are in use at the same time, this could limit the bandwidth available for all devices. The amount of messages
generated by a level can be artificially limited by the programmer/designer by adjusting the time up and time down values
in the programming properties for the level button in TPDesign4. For example, assume a volume level ranging from 1-100.
If the time up/time down for this is set to 5 seconds, the remote must generate messages very frequently within that time
span to cover 100 discrete points of volume. If this was spread to 10 or 15 seconds, it would cut in half (10 seconds) or
one-third (15 seconds) the bandwidth required. Another option is to step the volume in increments of two by setting the
level range to 1-50. Whenever a level_event is processed in the NetLinx program, the programmer would multiply the level
value by 2 before it is sent to the volume control device. If the ramp time is left the same, it would cut in half yet again the
bandwidth required.
When loading custom images, use graphic files the same size as the original image button into which it was designed to fit.
Images too large must be scaled to fit and will use more processing power, slowing the loading of pages.
To optimize page loading speed, use JPEG files for images instead of PNG files when possible.
