Getting The Most From Your Mio Modero R-4
88
Mio Modero R-4
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.
Minimize the number of borders displayed on a single page. One border will always load
faster than two or three. Consistent use of borders will also make for a better look and feel.
Keep the number of fonts used on the Mio R-4 to a minimum, as each unnecessary font file
takes space in the device's memory that could be used for other files or functions.
Try to use no more than one or two animated images per page. Animations use considerable
amounts of processing power and slow the response time for the user.
Do not set timeouts for popups containing level/bar graph controls tied to external buttons to a
short time limit. If the popup times out before the button is released, the button release is
missed by the control on the popup and the level will continue to be adjusted in the last active
direction. This can be a problem when the popup control is for volume, among other
possibilities.
Sending consecutive listbox update send_commands too closely together can adversely affect
the performance of the data transfer when sending a large number of update commands. Up to
