My DMX Project

[pscs]

My DMX Receiver Project

Hi, I'm currently using an X2 PICAXE (the 40X2 in my case, but the 28X2 may have been suitable if I'd been less ambitious with other needs) to act as a DMX -> 1-10V converter (to replace a secondary 1-10V fader we have and put that lighting onto our main DMX desk) and I thought I'd share my experiences in case they're of interest to anyone else wanting something similar.

First, I needed a DMX receiver. I'd seen this (http://www.picaxeforum.co.uk/showthread.php?20580-DMX-Data-Receiving-using-28x2-100mhz) which was a good starting point.

But, the problem I saw was that the break detector would give false triggers if it started during a DMX packet. This means that if the timing goes out, rather than waiting for the next packet, it will get bad data before recovering. In our situation that could be bad.

So, my thought was to build a simple hardware break detector (you don't need to detect the 'make after break', because the make is just an idle line) and wire that to one of the hardware interrupt lines on the PICAXE

The attached schematic shows the circuit I used for the break detector. You could possibly use a diode OR gate instead of the 74LS32, but I had another use planned for that IC in the overall circuit, so I decided to use that.



The basic idea is that when the serial in is high, Q1 grounds C1, then when the serial in goes low, the capacitor charges (I needed R6 because the low output of the MAX485 is sometimes just over the base threshold of Q1 so I got some leakage through that for a start). By adjusting the pot (R4) you can get it so that the comparator causes a high signal after the serial in has been low for 48uS (indicating a break, rather than a 0 data byte), then that stays high until just after the break ends. The comparator output can go to a hardware interrupt pin (to detect a rising edge) and is ORed with the serial to make the break shorter and the mark longer

Hopefully this would give enough time for the PICAXE to get ready for the incoming data which follows

 

[pscs]

Unfortunately, after experimenting with the above circuit, while it was detecting the break reliably, and early, unfortunately, the PICAXE hardware interrupt isn't as quick as I'd hoped it would be.

Reading the PICAXE docs I'd assumed the hintX inputs were very quick to respond, but they're not.... (well, not at the speeds I need)

By using another output line to determine the PICAXE timing, I found that the interrupt function took 40 or 50us just to start once the hardware interrupt line went high. This meant that it lost the extra bit of the break signal which I was hoping to use for setup.

I was hoping to have hsersetup doing a constant background read, and simply capture 'hserptr' on the interrupt, so I could look back at the previous packet, eg

interrupt:
w10 = w9
w9 = hserptr
(reset interrupt)
return

(now you'd be able to use w10 as the start of the previous packet of data). I could have the main loop doing loads of stuff, and just get the data as and when it needs it, as it's just coming in in the background.

However doing that I found that often I'd miss the first byte of the DMX data, even though the first two lines are all that are needed before the data starts coming in. The DMX controller would often send over-long break signals which would work fine, but when it did one closer to the minimum spec limit, the first byte or two would be skipped by the PICAXE.

If I wrote my own edge detector in the main loop:

(setup background receive on hserin)

mainloop:
waitforendofbreak:
 if pinb.0 = 1 then goto waitforendofbreak
waitforbreak:
 if pinb.0 = 0 then goto waitforbreak
hserptr = 0

then the data reception was perfect.

Toggling an extra output line to show when the code started, and watching it on my 'scope, I could see that my hand written edge detector took just a few uS to detect the edge, but the interrupt took 40-50uS. This was a disappointment as it meant that my main loop had to spend lots of its time waiting in the edge detector loop, rather than just letting the data come in. However, if that's the way it is...

(I still prefer the hardware break detector because it makes it easy for the PICAXE to detect the DMX break signal, rather than having to keep timing every low pulse. Also, I never need to look at the hserin pin directly, so can leave the background receive mode on all the time, and just reset the background write pointer once the break is detected, rather than having to reinitialise the hserial port)


(I'm not at my PICAXE devel PC at the moment, but when I am I'll post the full (pertinent) source for the DMX receiver)

BTW - the full project is pretty much finished now, with only the output voltage multiplier buffers to do, I've got a 1602 LCD showing bar graphs of the 4 DMX channels I'm capturing (as well as allowing configuration), with digital pots generating a 0-5V output following the DMX signal

 

[BobMcNobby]

Hi there, I would br interested to see how far you have got with this...

I have also been dabbling with DMX reception...

I use background receive and an interrupt that checks the hserinptr every 5ms, if the ptr is the same as last interrupt then the frame is complete, copy the data and reset the hserinptr and start again, it seems to work quite well, although speed is definately the issue as I use 100mhz 28x2. I have made a few assumptions about the break and start byte, but theses always come in at the same place and my data can always be read from scratch each time without dropping frames

When I get an opportunity I shall post the bit of my code

I have recently finished my first pair of DMX rgb pan/tilt scanner and they look awesome !