I've had a couple of
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
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
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
code into all the heads and reassemble them.
Then I made up four adapter cables as Y splitters so that
could plug into a normal DMX cable, as the original Opti
All that remains now is to give them a proper workout under