Blocking ‘reverse DMX’

[StuartS]

Trouble with pairing one Chinese moving head with a wireless DMX receiver. When both powered, the receiver flashes green to indicate reception as the moving head stretches its muscles, but as soon as it has initialised the receiver starts flashing red and the head goes into ‘party mode’. The problem is that the only difference between receivers and transmitters of the integral plug type is the gender of the plug. The electronics is the same. If they see DMX electrically they go into transmit. Cheap moving heads are too keen to go into master mode and in this case it seems to override the presence of DMX, perhaps if it happens to initialise between DMX packets. Result - the pair are transmitting a rival wireless signal.

So,  is there any way to prevent signal travelling from the light to ‘receiver’? Diodes?

[alistermorton]

A non RDM splitter would only allow DMX to flow one way. Might be the easiest way. Could mount to the yoke/handle of the lantern, perhaps.

[Tomo]

Diodes won't work, DMX is electrically push/pull so it'd just attenuate the signal in both directions.

One option could be to do some minor surgery on either the head or the wireless receiver and hard-wire the RS485 DMX transceiver chip into the correct direction - basically make it imposisble for the (eg) fixture to ever transmit.

This would of course invalidate the guarantee, so...

[timsabre]

Can't you disable the master mode or standalone mode on the fixture? This is normally an option, though often under some weird menu name.

You could make a little circuit using an SN75176 chip to buffer the incoming DMX signal, that would prevent the fixture sending the other way, it would need a 5V power supply though. Pin 4 as shown below connects to the DMX+ output on pin 3 of your radio receiver device. Pin 5 connects to ground of both DMX and the PSU ground. (You should not generally decode DMX just by taking the DMX+ line and ignoring the DMX- line, but it will work fine in this particular situation of a directly connected wireless receiver)

 

                       1     8--- +5V
               +5V-----2     7--(to pin 2 of fixture DMX)
               +5V-----3     6--(to pin 3 of fixture DMX)
---(from pin 3 of DMX)-4     5---GND (to pin 1 of fixture DMX & incoming DMX)

 

[Stuart91]

We had some cheap and cheerful wireless DMX units that behaved as the OP describes. 

It was usually necessary to turn the transmitter on first, then the receivers. This became a bit of a problem if the transmitter was inadvertently powered down during a show, and you would need to cycle the receivers to regain control. 

Powering up in the order of transmitter, then receiver, then fixtures, might solve the problem. If the units intended as receivers see a DMX signal on the XLR, they automatically start transmitting which causes chaos. 

Ultimately the best solution (which is what we went for) was to replace the wireless DMX units. "Alien" branded ones are still very cheap and don't seem to suffer from the same problems. 

[dbuckley]

On 1/12/2024 at 12:46 AM, timsabre said:

You could make a little circuit using an SN75176 chip to buffer the incoming DMX signal

 

I had this exact problem, and solved it with a pair of these chips wired back to back on a little bit of board, so DMX in, buffered DMX out.

Ugly, and to be fair, it was on the back of a mobile prop, but effective.  Built 2013!  One of the things on the "safe" side of this buffer was a smoke machine, so there was some serious willingness to get this problem out of the way...

 

[sunray]

I can't believe I've only just twigged that this is the issue I've been having with some lights but not including wireless devices.

The units in question will run master slave quite happily and in master mode they will run in DMX. The idea being a whole row of units can be re-addressed by changing just one, in fact any 4 channel fitting can be used as the master outputs the slave data on Add 1,2,3&4 and moves everything else up 4 addresses on their DMX out. (I assume I've posted it here before)

However there have been too many complicated problems with them which has always been blamed on the strange way the addresses get altered as it goes through the universe and the way they power up in master auto mode before detecting DMX. More than once the systems had powered up incorrectly with random LED fittings doing unexpected random sequences and the solution now is to run a master slave system on an exclusive splitter output.

The simple system which finally gave us the space to experiment was this:

Down stage a row of 4DMX channel RGBW LED to flood the stage set to address 6 master and address 1 slaves

FOH 5DMX channel RGB, SL addressed 1 and SR addressed 5 to match, taking account of the conversion by the master.

The 3 clusters of light running on an extension lead to local socket. I can't recall which sequence we had to power them for correct operation but the strangest part being the most corrupted section was SL FOH (ADD1). Fortunately we had some time to play between rehearsals and set construction, adding a splitter with individual line to each cluster made the problems disappear.

It had not occurred to me until now, what we actually achieved by adding the splitter, other than the complexity of of the address changes through the universe.

[sunray]

On 1/11/2024 at 11:46 AM, timsabre said:

Can't you disable the master mode or standalone mode on the fixture? This is normally an option, though often under some weird menu name.

As in my previous post the fixtures would automatically revert to 'Master' in the absence of DMX and a number of us were playing with them. The only thing for sure was to put them into 'Slave' mode but that locks them to address 1.

On 1/11/2024 at 11:46 AM, timsabre said:

You could make a little circuit using an SN75176 chip to buffer the incoming DMX signal, that would prevent the fixture sending the other way, it would need a 5V power supply though. Pin 4 as shown below connects to the DMX+ output on pin 3 of your radio receiver device. Pin 5 connects to ground of both DMX and the PSU ground. (You should not generally decode DMX just by taking the DMX+ line and ignoring the DMX- line, but it will work fine in this particular situation of a directly connected wireless receiver)

 

                       1     8--- +5V
               +5V-----2     7--(to pin 2 of fixture DMX)
               +5V-----3     6--(to pin 3 of fixture DMX)
---(from pin 3 of DMX)-4     5---GND (to pin 1 of fixture DMX & incoming DMX)

 

I used to install AMX/Panja kit to control AV systems and interfacing with RS422/485 was always an expensive exercise as they only provided default RS232 ports. I regularly made an interface with a single transistor and a couple of resisters for each conversion (S/R) inside the DB25 shell (or a large DE9 shell). What I was doing was efectively tying one leg of the RS485 to a high or low state and controlling the other. Or ignoring one leg to go the other way.

Waffle warning.

When we had a problem controlling a Camera (I think Sony) where we had to load parameters into the camera by RS485 everytime it powered on. We didn't realise we had to load all of the parameters everytime the camera was powered, we assumed we only had to load those which weren't default (IE changing one parameter cleared the whole of the defaults) and several phone calls to the tech help line resulted in us being convinced the new camera was faulty. The man on the help line offered to come to our assistance if we waited to 9pm (after the help line closed at 8pm) with another camera on the understanding we could supply the AMX routine on a floppy once it worked, as they had a similar project to engineer.

He quite quickly sussed our mistake  then the programmer took him step by step through the routine, he asked why we forced a signal (something like DTE but I'd have to look in notes from 25 years back) which we used to power the conversion. Rather nicely he issued paperwork for a refund for the interface they'd automatically included (lots of money extra!) and took it with him and we even chucked in a DB25 prepreloaded with components. We'd been there for much of the day trying to sort it, Within the hour it was sorted and eventually we saw the revised manual for the camera had been clearly amended.

 

Anyway, Sorry for the waffle.

Edited January 13 by sunray
Oh yes and our S/E programmer instantly found he was on their books.