Wireless Client: Ion

Hi Sam,

ETC doesn't offer any hardware options for Wireless connection of your laptop to the Ion, but

it can be configured as you would a Wireless network at your home. Your Ion needs to be connected

via an ethernet cable to a WLAN switch which then will allow your laptop to connect to if your laptop has

a WLAN card inside.

Please keep in mind not to connect your Ion to any networks which are connected to the WWW, or

any other outside networks because they can put your console under unnecessary network

access.

Unknown said:

Your Ion needs to be connected via an ethernet cable to a WLAN switch which then will allow your laptop to connect to if your laptop has a WLAN card inside.

Does the connection from the Ion go to the input of the wireless router?  If so, then how does the console connect to the lighting network?

I am getting the courage up to try this again...I have one of my campus it guys on call!  Hopefully I can get it going!

Pat

Your Ion will not be on the Wireless part of the network directly.

You need to connect your Ion's Ethernet port via an ethernet cable to one of the EThernet Ports that are on the WLAN Switch.

Your Ion will then be treated like a computer connected directly to the WLAN switch.

Your IT guys should be able to help you configure that up.

To ron's Question. I have the exact same problem. Though I have a variety for shows and Each show loads differently. For instance our "Wild Party show loads 3% and then disconnects. 200 lights 400 cues.. etc.. But when I load out opera it will load perfectly it has 200 lights 100 cues... As Ron said too it is only with the wireless, hard wired is fine. Thoughts?

I had the opportunity to speak with a few ETC folks regarding this at USITT last week...it was great to finally meet Anne and Sarah last week!  I will give my overly simplified explanation.

When you just have your laptop connected wireless to your home or work wireless for internet there are often alot of dropped packets (where the information being transmitted is stored).  In the course of any session,  packets are "dropped" all of the time (I can only guess this is due in part ot flaky connections, etc.) but the thing is, is that your laptop is able to deal with these dropped packets.  It just asks that they get resent again...the only example I can think of is when a video on youtube stops playing while more of the file caches.

The same thing happens with our laptops connection to the Ion (or EOS), but in this case, the Ion doesn't know what to do when it gets dropped packets.  It can't ask for the data again, think of hitting go and nothing happens (ok, not the best example, but you get my drift!) while the console keeps waiting for all of the data to arrive.

I dearly want to connect my laptop to the consoles, I think that is like the holy grail...short of asking your fixture, "point *there* and change color to red"...and have it behave!  But I would rather know right up front if it is not liking the connection rather than in the middle of a show or cue.

Somebody else please step in and help me out...not sure how close I am!

Pat

That's a pretty good description for the layman.Here's a bit more for anybody with a bit more networking knowledge.

ETC appears to use multicast UDP to broadcast data between devices. Assuming you haven't glazed over already, it is analagous to dumping a stack of flyers off at the post office and asking to have them delivered to "occupant". It is unreliable, but efficient for spewing data to any network peer that might care to look.

There are a number of proposed protocols like RMTP, MFTP, SRM, and PGM that could solve the reliable UDP problem at the protocol level. Cisco has a pretty good research paper on the topic if anybody from ETC is looking at this posting. In general, they work by giving the "occupant" a way to tell the sender that they didn't get the message.

There are also some message-oriented middleware options that could be used to provide a reliable publish-subscribe backbone to ETC's network. They are based on the TCP protocol (reliable point-to-point) and put a service in the middle of the conversation who's job it is to relay a message to any registered recipients. The analogy would be like a calling a paging service, or subscribing to this forum, except in near realtime. There are design challenges dealing with single-point-of-failure and figuring out which of the peers are capable of hosting such a service. Apache's ActiveMQ which is built on Sun's Java MQ is one example of the technology.

Neither change I proposed is easy to implement and probably not ETC's top priority. In the meantime, ETC could help us by providing a recommended wireless router and corresponding configuration to minimize the risk of dropped packets.

That's a pretty good description for the layman.Here's a bit more for anybody with a bit more networking knowledge.

ETC appears to use multicast UDP to broadcast data between devices. Assuming you haven't glazed over already, it is analagous to dumping a stack of flyers off at the post office and asking to have them delivered to "occupant". It is unreliable, but efficient for spewing data to any network peer that might care to look.

There are a number of proposed protocols like RMTP, MFTP, SRM, and PGM that could solve the reliable UDP problem at the protocol level. Cisco has a pretty good research paper on the topic if anybody from ETC is looking at this posting. In general, they work by giving the "occupant" a way to tell the sender that they didn't get the message.

There are also some message-oriented middleware options that could be used to provide a reliable publish-subscribe backbone to ETC's network. They are based on the TCP protocol (reliable point-to-point) and put a service in the middle of the conversation who's job it is to relay a message to any registered recipients. The analogy would be like a calling a paging service, or subscribing to this forum, except in near realtime. There are design challenges dealing with single-point-of-failure and figuring out which of the peers are capable of hosting such a service. Apache's ActiveMQ which is built on Sun's Java MQ is one example of the technology.

Neither change I proposed is easy to implement and probably not ETC's top priority. In the meantime, ETC could help us by providing a recommended wireless router and corresponding configuration to minimize the risk of dropped packets.

ETC uses reliable multicast which I'm sure you know is a bit like a multiparty TCP connection.  Wireless access points have been seen reshaping the timing of network traffic--hording and bursting large blocks rather than sending packets as they are received.  This misshapen traffic causes timing issues.  We can ultimately do no better than a bad connection will allow, but we are always working to get the best out of even bad connectivity.

We will likely have some information for you that will help in the immediate term available for you shortly.    No information can solve all problems with bad connectivity, but there are some common sense things that can help -- for example, filtering unnecessary network traffic away from wireless connections, and so forth.

Future enhancements to network protocols are likely to make them more adaptive to intermittent connectivity losses and traffic shaping problems like those seen on some wireless systems.

-Daniel