Beta-Portable Wired/Wireless DMX Tester (See first post for specs and features)

[rob]

dlhoppe
I am sure we can all help with the electronics side of things, just let us know.

On this project

The yet to be completed DMX tester is here:
You are not allowed to view links. Register or Login

The source code and schematics are compleat. the packaging is not.  That is my bad.  The new job has kicked my butt working 12 + hours a day for the past 4 months. Then having to get my own christmas stuff ready before december ate up my weekends. Excuses I know.

I dont know how RJ does it. He is the man.

I do have some code that uses  3 bcd switched to select the address and a pot to adjust level no display needed. if you want it lem me know.

Rob

[dlhoppe]

Thanks Rob.

I'll post a rough draft of a schematic once I get the encoder inputs written and some hardware testing started.

The PIC coding seems be humming right along. That is, once I knocked the rust off my assembler skills. It's been a while....a long while! PIC programming is rather unique stuff. I have most of the software in place; DMX stream, 3-digit LED multiplexing, mode switching (channel select vs. dimmer value), etc. About all that's left is the quadrature encoder interrupt handler/routine to alter my channel and dimmer values. It's looking good in the simulator, but I'm sure I'll have my troubles once I start testing with hardware.

I'm having fun with it though!


Cheers,
Dave

[n1ist]

Dave-
  Would it make sense to use an SAA1064 to drive the displays?  It would simplify the coding a bit.
/mike

[dlhoppe]

Mike,

Thanks for the idea!

If I understand the data sheet, I'd still have to do the work of separating the hundreds, tens and ones digits and then send them serially to the SAA1064. Using the PIC to drive the LED, the digit separation is the only real work I have to do. Multiplexing in the PIC is pretty simple really. It only requires writing the digit segment masks to a port and latching/unlatching one of three output pins in a "round robin" fashion for the three common cathodes. With the SSA1064, I'd still be multiplexing in a way because I'd have to send each digit in sequence serially, also in a "round robin" fashion. To display a value on a 7-segment LED directly from a PIC, I simply get the segment bitmask as a single byte from a jump table and write it to the port. That part couldn't get any simpler or quicker. Staying with the PIC to drive the LED has other advantages as well by keeping the parts count down and the schematic simpler.

Do you happen to have any PIC assembler code that interfaces with the SAA1064? Specifically the "static mode". Using it that way might only require streaming data to it when a value changes rather than continually. I'd like to take a look at an example to see how it works. If it does make things easier than what I have, I'd be interested for sure.


Thanks again,
Dave

[n1ist]

The main advantage of the SAA1064 (or even TLC5916 constant current shift registers) is that you don't have to keep refreshing the displays, which can make things easier if you are trying to get accurate timing or are running out of cycles while processing DMX.  You would only need to talk to the display driver when things change.  Unfortunately, I don't have any code for it as I tend to program AVRs in C rather than PICs.  Maybe RJ has an example?  It's the same chip he used in the Lynx Express.
/mike

[dlhoppe]

Mike,

Yes, I was always a bit worried about running out of cycles to the point where it affects the DMX timing. Right now I only refresh the display while I'm waiting during DMX breaks. However my opportunities will decrease further when I'm processing encoder inputs. If I manage priorities efficiently (DMX first, encoder second, display third), I'm hoping I can do everything on the PIC. It's at least worth a try to keep the hardware simpler and cheaper.

I will search for code examples to drive the SAA1064 in case I need to go in that direction.


Thanks again for your input. Very much appreciated!
Dave

[onesmoothhead]

WOW!

 

[egenoup]

I don't know how far you are into the coding of the PIC, but you may want to take a look at the propeller chip from parallax (You are not allowed to view links. Register or Login).  It has 8 separate processors (called cogs).  You can dedicate cogs to different fuctions.  One cog to read the DMX stream.  Another to handle the inputs and yet another to handle the output.  It is like having 8 pics in one chip tied together via a hub and memory.  All cogs can all access the 32 i/o pins.  Just a thought.  

Egen

[dlhoppe]

Wow! Definitely sounds like a very capable device. More than three times the price, but probably worth it.
Since I'm this far down the "PIC path", I'll reserve this as a "plan B".

I've done some calculations regarding available cycles on the PIC I'm using. With a 16Mhz clock my shortest DMX break time (60us) equates to 960 clock cycles. The longer break time (100us) is 1600 clock cycles. The DMX routines take a very small handful of cycles (less than 20) for each transmit burst. So a vast majority of the cycles are available for driving the LEDs and processing encoder inputs. I'm feeling pretty confident that the PIC is more than capable. The challenge is more related to my ability to get it to do what I want it to do.

By the way, I finished the quadrature encoder input routines. I still have a little work to do to make sure that the DMX timing has priority over all other tasks. Other than that, I'm just about ready to start breadboarding the hardware to begin testing.

Out of town for a week starting Friday, so I probably won't post any more progress until after that.


Cheers,
Dave

[dlhoppe]

Ok, I'm back on the job.

I've got all the PIC programming/debugging hardware online and working. Before I start breadboarding the prototype, I'm hoping I can get some feedback from someone with electronics expertise. I'm a little out of my element in the hardware dept, so any help I can get would be appreciated. I'm trying to keep this thing as simple as possible for low parts count and cost.

I'm most concerned about the ST485BN wiring. I took my best shot at it based on what I could dig up via google. Attached is a rough draft of the schematic.


Thanks,
Dave

[RJ]

Ok, I'm back on the job.

I've got all the PIC programming/debugging hardware online and working. Before I start breadboarding the prototype, I'm hoping I can get some feedback from someone with electronics expertise. I'm a little out of my element in the hardware dept, so any help I can get would be appreciated. I'm trying to keep this thing as simple as possible for low parts count and cost.

I'm most concerned about the ST485BN wiring. I took my best shot at it based on what I could dig up via google. Attached is a rough draft of the schematic.


Thanks,
Dave

Caps around the regulator to prevent oscillation. I forget them myself often.

Pull the Mclr pin #1 on the pic high through like a 4.7k or something like resistor to allow it to run.

Put a 4.7 k resistor to ground off of RC0 and RC1 as a pull down so push button  and switch will function reliably. If weak pull ups are avaliable in this pic and port enable them and put switchs to ground instead of High and leave resistors off.

Just a quick glance hope it helps.

RJ

[dlhoppe]

RJ,

Thanks a bunch for taking the time to look at this.

I didn't really understand your advice regarding the regulator caps, but I took a crack at it. The power is supplied by battery pack so I assumed everything would be "smooth". Are you saying the clock might introduce oscillation? That would make sense so I added a cap on the output side of the regulator. Is that the correct way to do it? How big of a cap should I use?

Resistors were added to RC0 and RC1 per your advice. I assume this prevents "noise" from any contact chattering? Port C on this PIC does not support weak pull-ups. Port B does support it, but I would have to rearrange a fair bit of code and port functionality to accomodate it. So I went with the resistors instead.

Also, should I add high value resitors to RC2 and RC3 for the same reasons as done for the switches? I'm using a mechanical encoder so I assume there might be noise there as well.

Attached is an updated schematic.


Thanks again,
Dave

[dlhoppe]

Ok, through research I'm starting to figure some of this stuff out. I'm going through "electronics 101" right now. It's really interesting, but I feel like I'm in kindergarten again. Ugh!

The encoder inputs will definitely need some kind of debounce filter in order to use a cheap mechanical encoder. Even if I go so far as using an MC14490 bounce eliminator, it's still cheaper than an optical or magnetic encoder. I'll explore some bounce filter circuits using caps and resistors first in an effort to keep costs down. The MC14490 is relatively expensive ($5.77), but a good "plan B".

I now understand the uses for pull-up and pull-down resistors. I'll be adding them to the RC2 and RC3 encoder inputs as well.

I also found the info from the regulator manufacturer on proper use of capacitors. That's taken care.


Thanks,
Dave

[RJ]

You can handle the debounce in firmware instead of hardware if you choose. That is what I do.

Basicly accept the input and branch code. Then diable input of the port and pause, then check for the port to swing the other way on a release, Then pause,  then go on your merry way to do what ever need to happen on a push.

This way you get one input per push and allow the contacts to stop bouncing.

Hope this helps.

RJ

[n1ist]

The 100n bypass capacitors need to be close to the regulator and to the Vcc pins of each IC/oscillator.  They prevent oscillations in the regulator, and provide a small local energy storage for each component to handle switching and surge current.  They are usually ceramic, not electolytic.

You will likely need cathode drivers for the LED; I don't think the PIC can handle the current of all segments on at once.  2n3904 are commonly used here.

The ST485 is a 5V part; I am not sure how well it will work on 3.3v

I would add the pulldowns to the rotary encoder too; as for debouncing, you can do that in software with no additional hardware (google "Ganssle debounce" for some algorithms and sample code.

/mike