Renard Wireless Converter: Difference between revisions

From doityourselfchristmas.com
Jump to navigation Jump to search
Line 48: Line 48:
== '''Signal Propagation Delay''' ==
== '''Signal Propagation Delay''' ==


:An XBee module can require up to 6ms to process received data. While this is a very short period of time, consider that the delay is cumulative when multiple Ren-W nodes are configured in repeater mode. For example, in a Ren-W network of 5 nodes, the last SS controller could be nearly 30ms late in reacting to Vixen control commands. This may not be very perceptible in some situations but in others, it could become quite noticeable and the delay should be factored into the general design of a Ren-W network, and possibly during the light sequencing design as well. Note that in global broadcast mode, the delay is not cumulative as all receiving Ren-Ws would receive the Vixen commands simultaneously and each unit would only be 6ms (or less) late. In actual testing, the delay was virtually undetectable to the naked eye.
:An XBee module can require up to 6ms to process received data; normally it's 2-3ms. While this is a very short period of time, consider that the delay is cumulative when multiple Ren-W nodes are configured in repeater mode. For example, in a Ren-W network of 5 nodes, the last SS controller could be nearly 30ms late in reacting to Vixen control commands. This may not be very perceptible in some situations but in others, it could become quite noticeable and the delay should be factored into the general design of a Ren-W network, and possibly during the light sequencing design as well. Note that in global broadcast mode, the delay is [[not]] cumulative as all receiving Ren-Ws would receive the Vixen commands simultaneously and each unit would only be 2-3ms (or less) late. In actual testing, the delay was virtually undetectable to the naked eye.


== '''Selecting the right XBee Modules - Which Do I Need?''' ==
== '''Selecting the right XBee Modules - Which Do I Need?''' ==

Revision as of 00:44, 24 April 2012


Why a Wireless Converter?

Sometimes it's not practical, affordable or maybe even possible to lay physical cable to a particular light controller. For example, trenching beneath your driveway to put a megatree on the other side is a messy, dirty and potentially expensive project. Or let's say you have a pond behind your house and you'd like to put a display on the bank on the other side where there's already an electrical connection for a circulating fountain. Or maybe your neighbor across the street wants you to help him light his house -- trenching beneath a street or suspending cable above it would probably require multiple permits from your local municipality, if it were allowed at all. Maybe you've built a new house and you don't want to leave a window open so all the cables can be routed through it to the outside. Or perhaps you live in an apartment building or rented condo where drilling a hole through the wall isn't even an option. These are just some examples of instances where a wireless connection to your outside Renard controller could very likely be the simplest and most affordable choice. That's why the Ren-W was invented.


Overview

Ren-W is an inexpensive, compact (3”H x 2.5”W), easy-to-build and configure plug-in wireless adapter for Renard controllers and 595/Grinch systems that use Ren-C (see Ren-C note below). It can also be used with other Renard controllers with very slight modifications to the controllers to tap +5v power for the Ren-W. The Ren-W functions as a transparent serial connection between Renard controllers by converting RS-485 serial data into a digital stream, transmitting it wirelessly to another Ren-W where the digital stream is recombined into serial data and fed into the Renard controller’s normal RJ45 input jack (J2) via short cat5 cable, just like it would have been had the computer been hard-wired directly to the controller. In a typical Renard daisy chain design, channel data that a Renard controller can’t use is passed through and out the controller’s data-out RJ45 jack (J1) as RS-485 data, which is then fed back into the Ren-W, retransmitted to the next Ren-W that’s supposed to receive it, where the digital stream is recombined into serial data, etc. and the process is repeated for as many Ren-W adapters as are in the chain. The Ren-W uses inexpensive yet powerful XBee Pro wireless radio modules to perform the actual wireless transmission/reception functions. The cost to build a single Ren-W board varies from about $27 to $73, depending on the various electronic components chosen.

DMX

Ren-W is NOT compatible with DMX systems as DMX requires data speeds upwards of 250kbps. The XBee radio that Ren-W uses for wireless communication cannot support streaming data at that speed; it tops out at around 80kbps, which means that 57,600 baud is the highest communication speed Ren-W can support.

Compatibility with various Renard Controllers

The Ren-W has been successfully tested with the following controllers:
  • WayneJ's Renard SS8, SS16 and SS24
  • Wjohn's Ren-C in either a Ren-C/Olsen 595 or Ren-C/Grinch setup
  • Wjohn's Ren64 ver XC5
  • Frank Kostyun's Ren24, versions 3.0 and 3.3, and the Ren24LV
  • Budude's Ren48LSD v3b
  • Renard Simple24 and Renard Simple32 by Mactayl and TStraub
  • CTMal's RenServo
  • Other Renard boards that use similar serial input/output circuitry should also work.
  • The following serial port parameters are highly suggested: Baud: 57600, Parity: Mark, Stop bits: 2

Renard basics and how they relate to Ren-W

In standard operation when multiple Renard SS controllers are daisy chained from one into the next, each controller uses the first X number of Vixen channels it receives where X is the number of channels the controller is designed to control. This is always a multiple of 8 because of the Renard program code and the PIC16F688 chips used in the SS controllers. The channels it can’t use are passed along to the next controller. Therefore, the order in which you chain one controller into the next can make a difference, and even more dramatically if the controllers have different channel counts. For example, if you had an SS8 and an SS24 (total 32 channels) and the first controller was the SS8 which daisy chained into the SS24, the SS8 will use the first 8 channels (1-8) and the SS24 would get the overflow channels 9-32. However, if the order was reversed and the SS24 was the first controller which daisy chained into the SS8, the SS24 will use the first 24 channels (1-24) and the SS8 would get the overflow channels 25-32. The Ren-W simulates the daisy chain concept with “Point-to-point broadcasting” (PTP or Alternate PTP) because the Ren-W boards’ XBee radios are configured to provide exactly the same daisy chain logic, just as if you were connecting the controllers with cat5 cable to daisy chain one into the next, etc.
To make two (or more) Renard controllers respond identically with the same Vixen commands, Vixen users usually replicate the Vixen channel information that controls one Renard to the corresponding channels that control the other Renards. However, what if you could use a “signal splitter” cable that distributed the same serial signal to multiple controllers, not unlike the concept of a “multi-outlet serial plug strip?” (Splitting an actual, stock serial signal to multiple devices without additional amplification is certainly possible but is generally a discouraged practice – the concept is used here for the illustration.) With such a splitter, each SS controller plugged into the “multi-outlet serial strip” would receive exactly the same channel information at the same time, just as if each was connected directly to the computer’s serial port. In the 32-channel example above however, since the SS8 has only 8 channels, it would be able to use only Vixen channels 1-8 while the SS24 would be able to use channels 1-24, and channels 25-32 would not be used by either controller. The “serial signal splitter” concept can be accomplished wirelessly quite easily; Ren-W refers to this as “Global Broadcasting.”
A version of Renard firmware is available that makes "global broadcasting" possible while still retaining individual channel control. The firmware is an ideal match for the Ren-W and uses a "start address" concept where you set the starting channel number for the controller(s). For more information read the configuration guide: Start Address Configuration Guide

XBee Wireless Radio Module Basics

XBee radio modules are essentially addressable wireless serial modems. Ren-W uses XBee radios as a “serial line replacement” to the normal cat5 wiring used to connect Renard controllers. XBees can communicate with one another on a one to one, one to many, or one to all "global broadcast" mode, depending on how each module is configured. The XBee’s configuration flexibility makes it possible to configure a Ren-W network so that multiple Renard controllers respond to the same channels or the network may be configured so that each controller has its own range of channels, which is more in keeping with normal Renard use. XBee radios are designed to accommodate streaming serial data up to 80kbps. Therefore, for best results, set your computer and Renard controllers at 57,600 baud; at 115,200 you may encounter erratic behavior.

Ren-W Operating Modes

  • Receive only mode: only one XBee module is required, plugged into the XBee RX (right) side of the Ren-W board.
  • Transmit only mode: only one XBee module is required, plugged into the XBee TX (left) side of the Ren-W board.
  • Repeater mode: two XBee modules are needed, one for each side of the Ren-W board. One will receive, the other will retransmit the Vixen commands to the next Ren-W. This applies only to the SMA board, the only board that has space for two Xbee modules.
  • E-mode repeater: only one XBee module is needed to perform the repeater functions, plugged into the XBee TX (left) side of the Ren-W board. Because a single XBee module must perform receive/transmit sequentially instead of simultaneously, small periodic delays in propagating the Vixen commands to the next Ren-W unit may occur. Note also that E-mode requires the use of the alternate PTP configuration scheme, outlined below, as well as a jumper across JP5. Only the SMA board can operate in e-mode.

Signal Propagation Delay

An XBee module can require up to 6ms to process received data; normally it's 2-3ms. While this is a very short period of time, consider that the delay is cumulative when multiple Ren-W nodes are configured in repeater mode. For example, in a Ren-W network of 5 nodes, the last SS controller could be nearly 30ms late in reacting to Vixen control commands. This may not be very perceptible in some situations but in others, it could become quite noticeable and the delay should be factored into the general design of a Ren-W network, and possibly during the light sequencing design as well. Note that in global broadcast mode, the delay is not cumulative as all receiving Ren-Ws would receive the Vixen commands simultaneously and each unit would only be 2-3ms (or less) late. In actual testing, the delay was virtually undetectable to the naked eye.

Selecting the right XBee Modules - Which Do I Need?

XBee RF modules come in a standard and a "pro" version, and they operate in the 2.4ghz frequency spectrum. The modules do not interfere with wireless computer networks that also operate at 2.4ghz. The lower-powered standard version is said to have a line-of-sight transmission range upwards of 300 feet while the more powerful “pro” version is only ¼” larger and has a line-of-sight range upwards of a mile. In actual use, the distances are quite probably less than the stated specifications, especially considering the modules will likely be housed inside a protective non-metallic box of some kind. Mounting inside a metal box is not advised as it will severely hamper effective transmission distance.
The antenna type on an XBee module can make a difference, too. (Be sure to read the pages about antennas!) The short, 1" wire antenna will provide better coverage than the flat, on-chip antenna. A version is also available with an antenna connector, presumably for a external directional antenna and even greater range potential. There is no significant price difference for the different antenna types and all are available for both the standard and pro versions. Suggestion: If using the Ren-W in normal repeater mode, consider using the lower powered, lesser expensive standard module for receiving and the more powerful pro module for transmitting, depending, of course, on the transmission distance needed. A special version of the Ren-W board is available for those who want to try an external antenna, using XBee modules that have the SMA antenna connector. Because of the length of this connector, the board has been reengineered so that the XBee modules point downward:
Other than the power difference and slightly larger physical size of the “pro” version, the modules are interchangeable, pin-for-pin identical, and the configuration settings are identical as well. However, consider that the “pro” version has 10x the transmitting power of its lower-powered sibling, and it has a more sensitive receiver, too. These two factors make it the XBee module of choice for the Ren-W.
It’s important to remember that Ren-W was created to be more of an extension to an existing, wired system than as a complete replacement of it. Wireless connections are never as secure as hard-wired connections are and periodically, data drop-outs can and likely will occur because wireless data transfer is inherently much more complex. But used in the right situations, Ren-W can be an effective solution to a wiring logistics problem.

Ren-C Note: When Ren-W is connected to a Ren-C's RS-IN jack, it is necessary to install a balun on the cable between the Ren-W and the Ren-C. The balun will reduce the EMI interference that the XBee module creates in the cat5 wire. Without the balun, the Ren-C will likely experience framing errors and no communication with the Ren-W. (Radio Shack part# 273-0069)


Additional Ren-W Links