Erher dream over Wifi (reliability)

Hi!

Had a really fun gig at a great venue, but (unfortunately, like often so far) FOH wasnt in the back, but on stage. Looking at the beams coming at me gives me such a different perspective, and I think i can estimate the intensity for the crowd way better, as optically lasers appear way less bright when viewed from behind.

I’m guessing ED’s should work over wifi somehow if I connect laptop to the local network the ED’s are connected to on my router? Is this a thing people do? Especially for FOH on a balkony or just general remote access from back of venue it sounds like a doable solution?

Main thing that comes to mind of course, would be reliabilty and safety. E stop would still have to be hard wired, so now that I’m typing this, this does complicate things a lot, but I guess a local network should be quite stable for operation at least.

What are your thoughts/experiences in this area?

wifi within a venue full of cell phones and other wifi radios would probably not be reliable… maybe the venue has built in cat cable?

worst case the data sent over wifi receives in error and the laser beams in a bad location.

Hi @mathijslaser !

Wifi is usually a non starter[1] but it’s very common practice to run a very long ethernet cable from stage to the front of house desk. Or even better, a loom with 2 x ethernet cables in for redundancy or the e-stop[2] link. So invest in a cable reel and get the best quality you can afford! I find a 50m run is long enough for most small / medium sized venues. If you have to go longer than 100m you’ll either need to split the run with a network switch in the middle or use a fibre network link system / cable.

Seb

[1] I had one huge project with a dedicated network crew who used a gigabit P2P wireless system to get the data from one side of a river to the other - about 150m. It was working fine until we fired the lasers - they were convinced that signal was being degraded when it went through laser beams! (I’m not an EM radiation specialist but I remain skeptical!) In the end they routed a really long fibre cable around, over a bridge and back across, a run of a few hundred metres.

The moral of the story is - network set up and management is complicated, if you need a wireless system (and you probably don’t), call the specialists and prepare to write some big cheques :blush:

[2] I have actually been working on an IP e-stop system that gets occasional use (see my last YouTube video for a quick mention of it) but generally I’ll use the 4 spare wires in a network cable for the interlock signal (and I have lots of systems to combine and split these, these splitters just a small part of it). Bear in mind that this limits you to 100Mbps but that should be fine if you’re running fewer than 25 lasers at 30kpps (ask me how I know). For those times when I need more than 25 lasers I’ll send two cables, and then combine them into data / interlock when coming from the switches to the lasers.

Network engineer here (wired & wireless, it’s what I do to afford lasers to play with!).

The beams absolutely did not cause interference with the bridge - they couldn’t. Bridges operate at 900 Mhz (licenced), 2.4Ghz (unlicenced, slow, congested & rarely used now), 5Ghz (most common, unlicenced) and 60Ghz (newish, fast as hell, expensive). All of those are far, far above the visible frequencies where display lasers operate so the basic laws of physics make interference from the beams impossible.

That said, interference from the galvos (more specifically the driver circuits) is a real possibility, especially with multiple units in use. It’d be worth testing with the beam emission blanked but the galvo running - my money is on that being the interference source. Shielding the galvo drivers should limit the problem. A 60Ghz link should also be immune - the beam is way tighter and it’s a far quieter spectrum.

For those looking to use wifi to avoid awkward FOH cable problems, 60Ghz is by far the best option. Needs a bit of work to set it up & align it (a laser can be VERY useful there!) but once done it should be rock solid and easily capable of more than 1Gb/s. We use them for point to point links, often over several km so a few hundred meters is nothing.

As for e-stop I wonder if an electronic e-stop run over ethernet would be acceptable. A continual heartbeat between the switch & the remote to keep the beams active. Loose the heartbeat, beams off so it’s fail-safe network wise. Might be an interesting project…

Jim

@Jim I’ve been contemplating building an IP based e-stop, here is what I am thinking.

Raspberry Pi (or similar powerful node with GPIO) running a simple UDP/socket server that acts as a receiver and is connected to the interlocks on the lasers.

Build a simple UDP/socket server that takes 2 types on input, an “arm” signal (on/off) and a “data” signal that expects to receive packets at a rate of say 15hz. This server acts as a proxy to 2 GPIO pins that are fed into a simple 555 timer circuit which expects an enable (arm) pin to be held low or high (tbd), and a clock signal that expects to clock at 10hz. The output of the 555 timer could then be routed to a mosfet to enable the interlock. The key thing with this system is it has to be reliable, fast to react, and fault intolerant (turns off at the slightest fault).

Then one builds a client IP e-stop which sends 2 signals, the “arm” signal (when the e-stop arm button is pressed) and a 15hz clock/data signal. This could be another raspberry PI or perhaps even an ethernet ESP32 chip or anything that can handle sending a 15hz signal over IP. May be worth doing a similar circuit in reverse with a 555 timer feeding into a GPIO pin, but also might be overkill.

Thus it should work as follows:

  • Arm/enable signal sent to from e-stop to UDP server
  • UDP server enables 555 timer via a GPIO pin going high/low
  • 15hz Clock signal sent from e-stop to UDP server
  • 15hz Clock signal written via a PWM GPIO pin from R-Pi to 555 timer
  • 555 timer output goes high & mosfet is fully open, enabling the interlock on the lasers

In addition to this one could also build a simple HTTP client that handles settings/status info/etc of the remote IP e-stop.

This system should ensure that if the clock signal from the client e-stop gets interrupted (e.g. cable disconnected, client crashes, user hits stop) then the remote end will disable the e-stop.

It also protects against the R-Pi crashing as that would also stop the clock input to the 555 timer causing the mosfet to switch off and interlock disconnect.

I welcome feedback on this general idea. It should work so long as one doesn’t have a very busy networ, but 15hz with less than 1 byte payload should be doable.

1 Like

i would like to recommend you, to buy a combi power cable and network cable. like sommer cable monocat 110. then you are totally indenpendant of what ever the situation provides. but offcause have e-stop in mind.

1 Like