Airport Express

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.

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.