Welcome, Guest
Username: Password: Secret Key Remember me

TOPIC: STM32 and/or ATMEGA328P as DMX Slaves, RPI as DMX Controller

STM32 and/or ATMEGA328P as DMX Slaves, RPI as DMX Controller 1 week 5 days ago #17983

  • hop
  • hop's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 400
  • Thanks received: 45
Greets all!

I have fallen in love with DMX, at least on paper, but not excited about buying an aftermarket controller or slaves. So I want to build both ends from scratch. The controller and slaves. I am not really concerned about the RS-485, also known as TIA-485(-A), EIA-485 handling. There are modules, dongles, etc that handle all that. My interest is the beginning and the end points. It has been done, but Google searches are not really turning up too many examples. DMX, or even DMX512 is a protocol though, and when you have a signal, embedded systems can work with it.

This is a side project that will use my Node Servers for control. The Node Server will handle the wifi connection and other details, and connect to the controller for guidance and support. The slaves however will be something of a mystery at this point because I want those connected wireless to the controller. So the RS-485, also known as TIA-485(-A), EIA-485 spec is really not needed for hard wiring. I have read about a number of transport protocols, and I have a number of dedicated wireless solutions for that also.

I am just laying the ground work at this point. The finished project will not be completed until my Node Servers are done and deployed.

STM32 and/or ATMEGA328P as DMX Slaves, RPI as DMX Controller 1 week 5 days ago #17984

  • hop
  • hop's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 400
  • Thanks received: 45
I am already looking at using nrf24l01 modules on different channels for the link between the DMX controller and its slaves. I have tons of those modules and already successfully linked two ATMEGA328P Pro Mini boards with them. The test layout will support 3 regions totaling up to 800 WS2812B devices on strips.

Why DMX? Because I want to use patterns data incorporated into media streams that support audio as well. I do not want to mess with spectral triggering, but would rather script it with software and compile it for end use.

DMX protocol (as far as I can see on Wikipedia) does not support error detection or correction, so I think I can package DMX data packets and add CRC and handshaking along with buffering to insure the data is accurate and complete. The load for such implementation is unclear at this point, especially without testing, so I am not sure how much of this the pro mini boards can handle.

More when I test and code it. I am very excited about this project!!

STM32 and/or ATMEGA328P as DMX Slaves, RPI as DMX Controller 1 week 4 days ago #17985

  • jmessina
  • jmessina's Avatar
  • Offline
  • Senior Boarder
  • Posts: 40
  • Thanks received: 184
DMX is meant to be simple. It's a connection-less "protocol" (calling it a protocol might be generous) where the master continuously sends packets of channel data and it's up to the slaves to deal with handling it, sort of like streaming audio over UDP. The 513 byte packets (START code + 512 data) are sent at a rate of up to 22ms (44 packets/sec). For the master it's a "transmit-only" protocol, so it has no idea if slaves get the data, or if there are even any slaves listening period.

If a packet gets dropped, no big deal. The data tends to be very repetitive and there's another packet coming in the next few msecs to replace it. It's almost assumed that the slave won't be able to keep up with the master and will drop packets. The channel data contains the state of the outputs at that moment in time, so the worst-case is the light will stay on for another 22msecs.

Slaves sync to the data stream using a serial UART BREAK signal that indicates the start of a packet, which is rather timing dependent. Without this signal the slave has no idea when a packet begins so things get out of sync quickly. That's the common problem with DMX slaves... implementing the BREAK detect correctly.

The simple nature allows it to run on uC's without much overhead or horsepower. Adding error checking or some sort of handshaking sort of violates the spirit of the protocol, but hey, it's your system.

There were later protocols developed for transporting DMX data over other media (like ethernet) but I don't have much experience with them and don't know how "heavy" they would be running on a small uC.
The following user(s) said Thank You: hop

STM32 and/or ATMEGA328P as DMX Slaves, RPI as DMX Controller 1 week 4 days ago #17986

  • hop
  • hop's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 400
  • Thanks received: 45
Thank you for the inside info Jerry, I appreciate that. Maybe not so much inside info, because I am sure all that is in the spec, but brought forward like you did, it is fairly clear that I need to test first without all that hand-holding to see if error detection and handshaking is even necessary. Sounds like it is not.

One thing for sure is that I do not want any wires other than power, so I will definitely have to carry the DMX signal on something wireless. It is short range so I'm fairly confident I will have strong signals. I do not think I need to worry about an ethernet transport either because the DMX signal will originate from an RPI. Played from a file most likely. And the RF modules will replace the cable normally needed.

Since you seem to know something about DMX, I do have a question or two though. Has DMX been packaged in a wrapper protocol before? I have not researched this but I want to have it as a data track in a wrapper protocol with other channels bundled. Like a MIDI channel. Some audio channels (2 to start), and maybe even video down the line. The idea is to author/edit syncing of light effects along with music, have the whole composition rendered to a file as the wrapper protocol, you know, like MP4 or MKV, or whatever, and just play it from memory like an SD Card. All my RPI Zero WIFI boards have 32gb class 10 microSD cards. I do not know what software I need to look for to compose these compositions though. I'm obviously looking for something open-source. This isn't a concert after all, but just a media and lights composed statically to be played repeatedly, or queued by events.

I appreciate whatever info you could share with me, or source direction for research.

Thank you sir!

STM32 and/or ATMEGA328P as DMX Slaves, RPI as DMX Controller 1 week 3 days ago #17987

  • jmessina
  • jmessina's Avatar
  • Offline
  • Senior Boarder
  • Posts: 40
  • Thanks received: 184
I don't have any experience using DMX over anything other than RS485, but you might checkout sACN (ANSI E1.31/Streaming ACN), which is DMX over UDP. That would run on an 802.11 network. I think the full-blown ACN (Architecture for Control Networks) protocol supports data other than lighting but I don't know the details.

There was another one I've heard of called ArtNet but I think that was just for DMX data and uses broadcasts, so not real appropriate for a wireless setup.

There's got to be a mixed-data protocol out there by now. Hard to image the pro sound/lighting industry pulling off the shows they do without it.

As far as software for generating these shows there's all sorts of stuff available, and some of it's open source. Vixen (www.vixenlights.com) was one I used when testing out my pic18/pic24 DMX slave code. I tried not to get too deep into it... it's a big rabbit hole and all I wanted was something to generate DMX packets.
The following user(s) said Thank You: hop

STM32 and/or ATMEGA328P as DMX Slaves, RPI as DMX Controller 1 week 2 days ago #17988

  • hop
  • hop's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 400
  • Thanks received: 45
I checked out the link and it is promising! Don't talk to me about rabbit holes. I salute you for knowing what the deep ones look like. I for one seem to be the type that has to run EACH RABBIT HOLE through its course, and in the end, I never get anything finished.

I am trying to stay focused on the huge plate of food I dished up for myself, and leave the other delicious dishes aside for another visit to the buffet on another day. I have never been good at that at all. Moderation, it seems, is a strategy that applies to vices, food, drink, AND research behaviors.

Complete the project, and build on it later. I'm trying!! This is the reason I am asking these questions now, because they are for NEXT YEAR. This year is a wash for the holidays. We are travelling for the most part anyway.

Oh by the way, leaving this weekend to the White Mountains in Arizona. Pinetop/Lakeside specifically. I already have my MCU travel kit packed, and plan on taking my somewhat portable RIGOL 1054Z, three laptops (one is my home server), and various parts to experiment. For something to do during breakfast. :)
Time to create page: 0.239 seconds