Jump to content

DMX kits.


Matthew Robinson

Recommended Posts

One thing I would see as a benefit would be the ability to power a system from 24V without additional power supply modules- most industrial control kit- solenoid valves etc work on 24V. This would make a neater, simpler system if you want to integrate industrial control elements

 

Whilst individual 'building brick' modules are great from a development point of view, once you get to a stage of building a project, individual small boards generally add up to more space, more connections and hence more effort to package and less reliable.

 

I'd love to see a DMX EL wire inverter. An inverter with control over radio would also be great for costume specific use.

Link to comment
Share on other sites

  • Replies 60
  • Created
  • Last Reply
Yes, exactly my point. Why send 512 channels of control over a radio link when you're only going to use one or two at the receiving end? Decoding the DMX on the wired end and just sending the few required on a much more robust channel is a far superior solution.
Link to comment
Share on other sites

Yes, exactly my point. Why send 512 channels of control over a radio link when you're only going to use one or two at the receiving end? Decoding the DMX on the wired end and just sending the few required on a much more robust channel is a far superior solution.

 

Well it's a good solution if you're only controlling one thing, but if you've got several receivers each of which need several channels, it's less good. I tried to make a set of battery RGB table lights using this system, with the idea that each table light could be individually controlled, but you just can't get enough data through it.

Link to comment
Share on other sites

If you want a massice practical that needs lots of DMX, then you need to fork out for the proper wireless DMX stuff. If you only want one or two channels, then a lower cost system that doesn't try to send the entire universe is a much better idea. I can see plenty of use for something like that.

 

Tim

Link to comment
Share on other sites

If you want a massice practical that needs lots of DMX, then you need to fork out for the proper wireless DMX stuff. If you only want one or two channels, then a lower cost system that doesn't try to send the entire universe is a much better idea. I can see plenty of use for something like that.

 

Tim

 

Seconded.

 

There are units out there that do it but they are very expensive soley because there isn't any competition. If the kit was cheaper more people could use it. Imagine th possibilities!

Link to comment
Share on other sites

Designing a nice Arduino DMX shield turning DMX into serial for a specified address and block size would be a good start, from that you can extend to pretty much anything.

 

I know there are already ardunio DMX shields already out there, but the general idea of using ardunio as the centre of the kits could mean people can repurpose and reinvent what teh device does which would fit in with the mindset of your target market.

Link to comment
Share on other sites

Designing a nice Arduino DMX shield turning DMX into serial for a specified address and block size would be a good start, from that you can extend to pretty much anything.

 

I know there are already ardunio DMX shields already out there, but the general idea of using ardunio as the centre of the kits could mean people can repurpose and reinvent what teh device does which would fit in with the mindset of your target market.

 

What would be ideal is for the shield to extract the required frames in hardware to give the arduino some time to process them and not have to keep watching the DMX signal. From memory, high framerates can start to really push the arduino processor at 20MHz.

Link to comment
Share on other sites

What would be ideal is for the shield to extract the required frames in hardware to give the arduino some time to process them and not have to keep watching the DMX signal. From memory, high framerates can start to really push the arduino processor at 20MHz.

 

The atmel mega (as used on the arduino) can receive full-flavour DMX with plenty of time to spare for doing other stuff, but you do have to be careful to make the DMX receiving routine efficient, preferably in assembler. I'm not sure how good the "arduino language" is at this.

Link to comment
Share on other sites

Yes, exactly my point. Why send 512 channels of control over a radio link when you're only going to use one or two at the receiving end? Decoding the DMX on the wired end and just sending the few required on a much more robust channel is a far superior solution.

 

In theory, I agree.

 

But now I've done it both ways, full wireless DMX makes life simpler and is a lot easier to make work well. It's not as cheap, I'll grant ye. But if you need more than the odd on-off then just send wireless DMX already.

 

From AliExpress, box transmitter and PCB receiver. Actually, either item can do transmit ot receive, but this I the way round I used them. Box to box DMX works well.

 

A couple of pix, on the left a LED controller, and on the right a single channel dimmer for a streetlight practical on wheels. The dimmer was built second, and programming a pin to do PWM to drive a MOSFET took about 10 minutes from start to done and tested. Small processors are now so powerful that the support high level languages, and the Parallax Propellor in particular has multiple processors in one chip ("cogs") so one only need write the application code, the DMX code is available off-the-shelf.

 

http://davidbuckley.name/pix/wdmx1.jpg

 

http://davidbuckley.name/pix/wdmx2.jpg

 

'' Streetlight
'' Configured for wireless
'' See pins!
'' Note Spin Stamp clock frequency 10MHz not 5MHz



CON               'Constants to be located here
'***************************************
'  Hardware related settings
'***************************************
' For SPIN Stamp it's 10MHz x 8 in the PLL to get 80MHz...

 _clkmode = xtal1 + pll8x
 _xinfreq = 10_000_000 


'***************************************
'  Program Definitions     
'***************************************


 PinDmxIn      = 18             ' DIL 24 pin 3, the ATN pin
 PinDmxLed     = 7  
 PinPwmOut     = 8

 period =  500_000 / 256
 
  
VAR               'Variables to be located here

 long StartChannel 

 
OBJ               'Load other objects from other files

 DMX     : "jm_dmxin"


PUB main | on, off

 StartChannel := 66

 dira[PinPwmOut] := 1

 DMX.init(PinDmxIn, PinDmxLed, 0, 0)

 repeat
   on := 0
   if ina[PinDmxLed]
     on := DMX.read(StartChannel)
   off := 256 - on
   on *= period
   off *= period
   if on  
     outa[PinPwmOut] := 1
     waitcnt(cnt + on)
   outa[PinPwmOut] := 0
   waitcnt(cnt + off)  

 

And thats it.

Link to comment
Share on other sites

An idea I had awhile ago.

 

DMX mergers are available and used, 2 desks>1 output.

 

Can you design a circut and software package to take the packet data out of a selected DMX channel? (instead of data for an unused or unpatched channel constantly being sent as 0 the data is just not their?) intergrate it with current DMX mergers.

 

Jonathan Sharpe.

Link to comment
Share on other sites

An idea I had awhile ago.

 

DMX mergers are available and used, 2 desks>1 output.

 

Can you design a circut and software package to take the packet data out of a selected DMX channel? (instead of data for an unused or unpatched channel constantly being sent as 0 the data is just not their?) intergrate it with current DMX mergers.

 

 

You can't do this, the only way you know which channel is which in the DMX packet is by counting the data from the start.

If you took an unused channel out, all the higher channels would move down by one.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.