Airport Express

I am not really sure about the specifications of the Airport Express.

But you can connect a WLAN Access point a switch which has both the RVI and Ion connected to it, and if the WLAN Access point is in the same IP Range as the Ion, then it will work.

I am assuming you want to connect the access point so you can control your Ion with the iRFR?

Actually, this has nothing to do with iRFR.

The network switch in our building requires a long cable to the other side of the prosc. opening to get out of the way of the carps during load-in.

If the RVI can be wirelessy connected to the network switch and thus to the Ion, we can move the RVI any where in the stagehouse and keep patching and ringing out during the setup

Since the RVI connects via a Network to the Ion,

then a wireless network solution would work also. I wouldn't recommend this for

running a show, but for patching and focus there shouldn't be a problem.

Just make sure the access point is within the same range as the RVI IP.

This may work, or it may not.  It breaks down into a question of how large your show is, what networking protocols you have running on the network, and the technology of your wireless access point.

Wireless Access Points (WAPs) work best when traffic is relatively slow or moves in bursts. Common wireless traffic is for applications like email or web browsing, where delays are natural and constant transmission is not required. Applications that display streaming video cover network delays by downloading and buffering the stream ahead of the currently displayed frames. Eos/Ion/Element clients/RVIs do not have this luxury, since their displays are updated in real-time.  Many lower-end access points simply cannot handle the continuous high speed of traffic.   The typical symptom of an overworked access point is a client that starts the show transfer process but stops partway through -- often repeatedly.

Using networks with proper wireless coverage and little radio interference, we have found keys for good client/RVI operation include:  minimizing the unnecessary traffic running over the WAP, and using a WAP that can handle the remaining traffic relatively smoothly. We have found the Cisco 1100 and 1200 series WAPs (often with a filtering device like a custom configured managed switch before them) seem to perform acceptably in some situations.

Lacking a higher end access point like one of the Ciscos above, I have once succeeded in getting wireless client working from an Ion system over a typical Linksys WP54g.  That particular system did not use EDMX or sACN (only hard-line DMX from the console) so we were able to turn off both of those protocols in the shell.   Removing that traffic allowed the client to eventually transfer the show file and sync up.

To be very clear about this though, this issue affects client pcs and RVIs because they are also transferring all of the show synchronization data.  We haven't seen these same issues with iRFR.  In our experience (admittedly limited at the moment) that seems to run fine over a properly configured consumer grade WAP.