The Pro Strobeflower DMX Conversion.

I've had a couple of Optikinetics Pro Strobeflower fixtures for a few years now, after a friend Mick found some up for sale along with some other Opti gear. There were 3 heads and one controller unit, though one of the heads was faulty and considered as spares only.

The dedicated controller unit had been modified heavily, and had a completely new front panel fabricated for it, presumably because the original Opti membrane keypad had worn through, and was no longer available as a spares item.

Having a dedicated controller is a pain in a touring situation, it means either extra long cables (x 4, one for each head) or someone on stage to operate it and trust they do it right.

I had planned to design my own control circuit and replace the Opti one in each head, and had got as far as working out what to do and almost completing the CAD layout. But after a couple of years procrastinating I still hadn't got much closer to completing it. Then I got chance to buy (well, swap) two more Pro Strobeflower heads when we did a gig in Holland (thanks Ralph!), so the desire for getting rid of the dedicated controller was even greater now. I actually got another controller with those two heads, but that one was faulty too, with a damaged membrane keypad.

With a festival approaching I thought again about how to make the Pro Strobeflowers respond to DMX rather than their dedicated controller. I could see that the dedicated controller used a serial data system electrically similar to DMX, just that Opti designers had invented their own protocol to transmit to each head. I wondered about if it would be possible to re-program the microcontroller so that it understood DMX rather than the Opti protocol, but this would mean fully understanding how its program operated.

I don't consider myself much of a 'hacker' when it comes to reverse engineering other peoples code, I have enough trouble understanding code I've written myself sometimes, without having to work out the strange ways other people might have done it. But then one afternoon I downloaded a freeware 8051 microcontroller disassembler and thought I may as well have a look at how difficult it might be. I was pleasantly surprised that there wasn't actually much software code in there, and it was laid out quite logically too. After then downloading a freeware 8051 assembler I managed to successfully re-assemble the disassembled code (yes wrap your brain around that!) and run it to prove it was exactly the same. My trusty old Dataman EPROM emulator could now finally earn its keep after being sat in a box for many years too.

Now I was on a mission to see if I could alter it to receive DMX data. The 'spares only' head that I had was dug out and set up on the workbench, but leaving the dangerous high voltage part disconnected. The first thing that had to be done was to speed up the clock speed from 6MHz to an overwhelming 8MHz so that the DMX data rate of 250,000 was an exact division by 32 of the clock speed. This was simply a case of changing the 6MHz crystal for one of the many 8MHz crystals that are literally left lying around on the floor at work (our staff can be pretty messy...).

After a week or so of working occasionally on it, I had pretty much changed all the code and added a DMX receive part that appeared to work OK. This was where the real problems started though. For testing I had forced the code to respond to DMX address 1, and all seemed OK. The beam and colour motors ran as I wanted them to in response to DMX control so I was happy. Because there is no facility to set the DMX address in the usual way with DIPswitches, I had to choose some fixed addresses and program each head differently. For head number one I chose DMX address 80, but when this was tested, the beam and colour motors started to jump and jerk around when adjacent DMX channels were turned up. I wondered if there was a problem with the DMX termination, or the type of input on the Strobeflower circuit, but that wasn't it. It was the response time of the poor 8051 microcontroller to each DMX data byte that was received. It barely had time to digest each channel before the next one arrived, so was missing channels now and then. The higher the DMX address the more chance there was of it missing one or more data bytes. After a bit of re-writing my code I managed to get it to speed up enough to be reliable so I was happy again.

Now it was time to open up all four heads and reprogram each EPROM with my new code and set the DMX address of each one. This is quite a tedious process as Opti fixed on the top cover of each head with about 20 screws, I was thinking they are sadists to have this many! This took me all day to do and then revealed the next problem. The spare head I had been using to test had an 8051 microcontroller and a 2764 EPROM, and Opti had kindly EMailed me a scan of the circuit which helped enormously. But when I opened up some of the other heads I saw that the circuit was a newer revision, and that it also had a different microcontroller and EPROM. My heart sank as I thought that all the hard work I had done was now useless, as it would not work on a different microcontroller. After finding some details of what an AMD 80321 microcontroller was though I realised that it was a compatible device and only needed a minor modification to my software to make it run the same on that too, so I was still in with a chance of it all working.

After screwing them all back together I found I could control them all together reliably from my Pulsar Masterpiece desk, so again I was happy. That didn't last long though... I often use a radio DMX link at gigs and I found to my dismay that the Strobeflowers would not work at all when plugged into this system. What was wrong now? Looking at the DMX signal on an oscilloscope I saw a perfect DMX waveform, but the heads just sat there doing nothing. When I plugged them directly into the Masterpiece desk they worked perfectly, and now I could see why. The DMX data from the Masterpiece desk has lovely 20 microsecond gaps between each data byte. The DMX data from the radio system has zero time delay between each data byte. The problem of the 8051 not being fast enough to digest the DMX data had returned to bite me badly, with only 44 microseconds  to process each byte, and my code sometimes taking longer than that.

Another few days passed as I wondered what, if anything, could be done about the problem. After some very careful re-writing I shaved another few microseconds off the execution time, which was all that was needed to suddenly make it work again. So finally I could program  the new code into all the heads and reassemble them.

Then I made up four adapter cables  as Y splitters so that they could plug into a normal  DMX cable, as the original Opti pinout was different.

All that remains now  is to give them a proper workout under gig conditions.