[timsabre]

So how much would people be prepared to pay for such a radio gadget?

If it used easyradio modules or similar, I reckon it would be about £150 for both ends by the time you've had circuit boards made, if it's a commercial venture. Which sounds quite a lot to me.

[Matthew Robinson]

My apologies, my new modules have started this week with gusto and I've also been busy working for the union's Technical Services Committee.

I like the idea of the wireless DMX link quite a lot. Also, good call on the headers for each thing. I imagine that it'll have to slip somewhere into a radio mic channel? Obviously, we would have to go further down the route of design before we could give a price, but £150 does seem quite steep. Thank you, this post may seem brief and possibly a little vague, but it has given me a lot to think about.

WRT the merging of two DMX lines, that seems very much a cross over of artnet or similar?

[jono9691]

Hi Matthew,

Would need to figure out how to deconstruct 2 seperate DMX sources, then be able to allocate specific channels to only be recieved from source A and the remaining channels recieved from source B.
Then reconstruct the DMX data into a single streem.

Current mergers are only switchers, this would actually merge data or could be used as a switcher as well.

Just an interesting idea

[dosxuk]

jono9691, on 12 February 2012 - 10:04 PM, said:

Hi Matthew,

Would need to figure out how to deconstruct 2 seperate DMX sources, then be able to allocate specific channels to only be recieved from source A and the remaining channels recieved from source B.
Then reconstruct the DMX data into a single streem.

All relatively trivial things. The only complicated bit is making it configurable.

jono9691, on 12 February 2012 - 10:04 PM, said:

Current mergers are only switchers, this would actually merge data or could be used as a switcher as well.

I've not found a "DMX Merger" which can't merge DMX signals based on HTP/LTP rules as well as backup style switching.

Anyway, there are several solutions here - http://www.blue-room...showtopic=19134

[Matthew Robinson]

If the DMX mergers that you're talking about just switch between two lines of DMX, surely all you need is a DPDT switch per universe to switch between the two desks. Thus there seems very little point in making a commercial DMX switcher of that type, given that anyone who needs to do this for an install can just install a switch, and anyone who needs to do this during a tour/ temporarily can do this by plugging or unplugging a cable? The ones that merge due to HTP/LTP channels seem to do exactly what you want (if you don't want one desk to be able to control certain channels, don't patch them on the desk?).

[jono9691]

Right,

I have 1 line of truss among many. I have scanners and heads on it. I have multiple truss lines with both scanners and heads, each line of truss is on its own streem. All run to a single jands dd8.

I have a hog 1k and a scan commander for example.

I want to run 60 percent of the show off the hog (all fixtures). When s**t gets really hectic and demanding effects, I want to run all mirrors off the scan commander and all other fixtures off the hog, all at the same time. I only have one universe of DMX distributing for all fixtures "1" !!!!

I want to push a button and "merge" the 2 control sources into a single streem, specifically allocating channels of both control's to an output and effectively block what ever data a or b source is sending, then be able to push a button and all DMX data comes from a.

Easy to say dont patch, try running 20 different truss lines and the problem solving envolved.

This post has been edited by jono9691: 13 February 2012 - 02:07 PM

[timd]

I can see an "intelligent" merger like that being a workable idea - to teach it each scene, just shove all the channels to be controlled by one console for that scene to a non-zero value, the box remembers this and for that scene runs everything from those channels on that console to the output with the same channels, the remaining channels coming from the other console.

Tim

[Tomo]

ETC's ETCNet2 Nodes and Net3 DMX Gateways have always supported per-channel priority - this is used to choose which source 'wins' control of each individual DMX channel.

Originally the idea was across a network - as it's really common to have two or more sources on a network.
Networked ETC consoles (and some others) can handle this automatically, only taking control of patched DMX channels - thus jono9691's situation 'just works'.

Net3 DMX Gateways can be used as standalone multi-universe per-channel priority (then HTP) mergers - no network connected.
(The Advanced Input Patch also lets you re-patch any input DMX channel to any output DMX channels.)

The way ETC's sACN per-channel-priority works is shown in sACNView so you could use that if you like.

This post has been edited by Tomo: 14 February 2012 - 08:25 PM

[jono9691]

Nice........... it's been done, next idea anyone?

[boatman]

jono9691, on 14 February 2012 - 10:11 PM, said:

Nice........... it's been done, next idea anyone?

... and to come back down to earth, I quote my own post from five days ago (with a strikeout for the bit which is no longer true):

boatman, on 09 February 2012 - 11:04 AM, said:

I think we should remember that the OP is a student at the University of Sheffield, studying Electrical and Electronic Engineering and, incidentally, hasn't posted in this thread for a week. He asked for guidance on some simple DMX modules which he could build and the latest suggestions, although undoubtedly worthy, are very possibly beyond his abilities.

[jono9691]

Sigh,

Sorry boat man, this is an interesting concept and thread and the OP did enquire.
If the OP and a few of his uni mates can figure out how to make this they can make quite a bit of money.

Just found this:

http://www.etcconnec...-in-v4-0-0.aspx

Also the idea is 3 & 5 pin DMX in and out.

Any clarification from ETC would be greatly appreciated.

This post has been edited by jono9691: 15 February 2012 - 10:28 PM

[Tomo]

That Wiki page is about an ETCNet2 Node.
They could not run standalone, and haven't been manufactured for some years now.

As I said in the post, Standalone Merges can be done using ETC's Net3/ACN DMX/RDM Gateways.
These are a newer product that effectively replaces the old ETCNet2 Nodes.

With regards to 3 and 5-pin XLR-type connectors:
The use of a 3-Pin XLR is prohibited by the ESTA/ANSI E1.11-2004 DMX512-A standard. (I think since DMX512-1990, maybe even 1986)

- The reason the Standard says this is to make it less likely that someone will accidentally use microphone cable or cross-plug a DMX and audio system. Both of these are bad.

However, you are free to use adapters to convert the DMX signal to whatever you like (including wet string).
Just remember that if it's not according to the Standard, nobody can guarantee that it will work properly.

It might well work 'well enough' for your purposes though, and you may be happy to accept the risk - depends what kind of thing you're doing.

(Edit to add links)

This post has been edited by Tomo: 19 February 2012 - 11:54 AM

[jono9691]

Tomo, on 19 February 2012 - 11:36 AM, said:

With regards to 3 and 5-pin XLR-type connectors:
The use of a 3-Pin XLR is prohibited by the ESTA/ANSI E1.11-2004 DMX512-A standard. (I think since DMX512-1990, maybe even 1986)

- The reason the Standard says this is to make it less likely that someone will accidentally use microphone cable or cross-plug a DMX and audio system. Both of these are bad.

(Edit to add links)

Hmmmm.............
Might need to inform Martin and Clay Paky.

[dbuckley]

jono9691, on 19 February 2012 - 11:16 PM, said:

Might need to inform Martin and Clay Paky.

All this means is that Martin and Clay Paky (and about a million other manufacturers) aren't compliant with the current release of the Standard, DMX512-A, which makes it clear beyond any possible doubt that 3 pin XLRs are prohibited.

So as long as they don't try to claim compliance with DMX512-A, they'll be OK.

[Seano]

From another thread:

back_ache, on 21 February 2012 - 11:43 AM, said:

pritch, on 17 February 2012 - 08:56 PM, said:

<snip/>rather than using the serial port to put it into standby, why not use the command to turn the brightness right down, and then turn it back up again when it's needed?

I've always thought it would be a cool thing to do to map the brightness and contrast functions of a display to DMX channels.

you could combine the ides so that the brightness is rededuced as much as possible and then put into standby

DMX controlled programmable infra-red telly remote?