Vixen/Arduino Standardization HELP WANTED!

**Zeph** · 02-10-2012, 01:21 PM

Originally Posted by Jonpro03

Where should it go from here?

I'm ready to go and buy an ethernet shield which has an SD card slot onboard, so I'll be able to start work on SD sequencing. :D

Well, James is working on a board (shield) which sounds very interesting.

Meanwhile, if we can get access to (or set up) a wiki, maybe we could organize other resources, especially software and documentation. Like gathering and annotating the existing sketches of interest (which ones work?)

**buckanear** · 02-10-2012, 03:22 PM

Originally Posted by Zeph

By the way, my suggested first path (RS485 in/out, control of external quad SSR, ZC + Renard/DMX send/receive and dimming libraries) DOES involve shooting some of my internal engineers. I want pixel control, and audio. But I'm OK with pushing the first off until later because there are so many variants to deal with, and the second because there may be a shield which will work, and it can be complicated.

For my own interest, I'm with Phil - I don't feel a need to reproduce the niche handled by Renard hardware, but I'm excited at the idea of a flexible, expandable, C-programmable standalone controller. I was thinking about a Propellor based controller, but the wide availability of shields and libraries for the Arduino makes that even more attractive.

AND I love that the same shield and same libraries may serve both niches.

For Pixel control

Sparkfun sells a PWM shield for $20 that is based on the TLC5940. There are libraries for that chip already. that gives you 16 channels for LED control. The shield has serial data and clock lines leaving the shield to interface with other boards.

I was thinking of that or a WS2801/WS2803 chip to do for my luminaries. I have twenty of them that I want to convert over to LED. I have some neat ideas as to what i can so with those by dimming and changing colors with music.

It would not be difficult to spin a WS2801/WS2803 shield. Just how many do you want to control per shield. Do you want oen Arduino board with one shield then wire off to several smaller WS2801 boards. Maybe you would be interested in Charlieplexing. There is a library for that in the Arduino Playground. I can't attest for the robustness of the code but it is there for one to examine and modify if needed.

Like I said I was looking at the WS2803 chip to control some piranha chips for my luminaries so that will be in the works soon.

james

**buckanear** · 02-10-2012, 03:38 PM

Okay here is the first pass for a SSR shield with RS485 I/O and RJ45 jacks to 8 SSRs of one's choice.

This is not finalized yet. I want to make a few more changes and reviews before I consider it ready for prime time.

The underside has plenty of ground plane but I may moves some parts around or even redefine some pins to make the layout flow better. This is just to let the group in on the status and progression. As soon as this is done I can turn to a WS2801/WS2803 board.

james

SSR Shield layout.pdf

**P. Short** · 02-10-2012, 04:50 PM

What are the chips on that board?

I'm assuming that the 18-pin chip is a ULN2803, or something like that, and the two 8-pin chips are ST485 chips or something similar. It also appears that the RS485 I/O is on the right, and the LED drivers are on the left.

If I were designing that board, I would make every effort to have all of the signal traces on one side of the board and the other side be an uninterrupted ground plane, as much as that's possible. To that end I would place the LED outputs on the right side, and the serial I/O on the left. Since you don't appear to be trying to tri-state the RS485 outputs, I would also consider replacing the two ST485 (75176) chips with a single 75179 chip. These changes would allow almost every signal trace to be on one side of the board (or maybe even every signal trace).

Further note: if you can't switch the RS485 connectors with the LED connectors, replacing the two RS485 chips would open up enough room so that you have no need to run the signals going into the 18-pin chip on the ground-plane side of the board if you switch the order of the signals on the input side of the 18-pin chip.

**Zeph** · 02-10-2012, 04:58 PM

If you keep ST485 chips, would Dave's "Xbee Snap-in" adapter work to connect this to XBee (replacing the input chip)?

And my pixel interest is in driving pixel strings or strips, like the e68x series, but standalone. I didn't have that in the initial shield desiderata because a screw terminal shield plus external wiring for power might handle them. And RJ's pixelnet or the Pixad style, are not yet standard.

**buckanear** · 02-10-2012, 06:47 PM

Originally Posted by P. Short

What are the chips on that board?

I'm assuming that the 18-pin chip is a ULN2803, or something like that, and the two 8-pin chips are ST485 chips or something similar. It also appears that the RS485 I/O is on the right, and the LED drivers are on the left.

If I were designing that board, I would make every effort to have all of the signal traces on one side of the board and the other side be an uninterrupted ground plane, as much as that's possible. To that end I would place the LED outputs on the right side, and the serial I/O on the left. Since you don't appear to be trying to tri-state the RS485 outputs, I would also consider replacing the two ST485 (75176) chips with a single 75179 chip. These changes would allow almost every signal trace to be on one side of the board (or maybe even every signal trace).

Further note: if you can't switch the RS485 connectors with the LED connectors, replacing the two RS485 chips would open up enough room so that you have no need to run the signals going into the 18-pin chip on the ground-plane side of the board if you switch the order of the signals on the input side of the 18-pin chip.

Phil

Correct in that the large chip is an ULN2803. I prefer to buffer the micros chip ports even if they do not need it. Just in case you have to drive long lines. Easier and cheaper to replace the2803 than say a processor chip.

The 485 circuit is lifted right off the RenSS24 schematic. It also appears to be in consensus with the Ren16. Now if there is a better way or if this needs to change that is not a problem. It is setup for receiver and transmitter configuration. If transmitter only is needed then the other can be eliminated.

I have not finalized the layout yet. I just put down the first pass and threw it out for comments. I have the RS485 off to the right so that runs to and from the UART ports are as short as possible. They are in the upper right corner. If there no real set hard coding for the channel outputs, then I plan to reassign some pins to make the layout flow a bit better. Also add silk screen. I do try to keep vias to a minimum. This was hand routed in a rather fast pace with little consideration as to flow and pretty much where the rats nest yielded the easiest routing. I am not really happy with the ULN2803 routing yet. Hopefully tomorrow evening I will be able to finish it.

thanks for the inputs.

james

**buckanear** · 02-10-2012, 07:11 PM

Originally Posted by Zeph

If you keep ST485 chips, would Dave's "Xbee Snap-in" adapter work to connect this to XBee (replacing the input chip)?

And my pixel interest is in driving pixel strings or strips, like the e68x series, but standalone. I didn't have that in the initial shield desiderata because a screw terminal shield plus external wiring for power might handle them. And RJ's pixelnet or the Pixad style, are not yet standard.

So far I have not looked into Xbee simply because there already are several Xbee shields available.

I can revisit that if it is necessary.

The next planned shield is some sort of driver for pixels. I do have a similar interest in that I plan for this Christmas at least 20 Luminaries that will be converted over from C9 bulbs to RGB LED. I anot sure if I will make them stand alone or as a bank of channels off of Vixen. I kind of like the idea of dimming them in concert with music. I can envision some neat sequences with them. If I can find some more or even make my own I may even expand out to 50. Kind of do with luminaries like those that do with the arches.

If and when I do go RF link, I am very seriously leaning to the RFM22B 433MHz modules. There are some very very interesting libraries for it already. What I have read so far it will do what I want. 433 MHz ISM band is less congested than the 2.4GHz band. Besides 433MHz has slightly better building penetration than that of 2.4GHz.

james

**P. Short** · 02-10-2012, 07:12 PM

The 75179 chip has one receive section and one transmit section in an 8-pin package. The transmitter and receiver are both enabled all the time. It is used on the Ren-C board, where the only change is replacing the two chips with one 75179-type chip (everything else is the same). Making this change would open up space for improved routing of the ULN signals.

**Jonpro03** · 02-10-2012, 07:28 PM

I think we should go with the TLC5940 LED driver IC for pixels. It already has a library developed: http://www.arduino.cc/playground/Learning/TLC5940

**buckanear** · 02-10-2012, 07:47 PM

Originally Posted by P. Short

The 75179 chip has one receive section and one transmit section in an 8-pin package. The transmitter and receiver are both enabled all the time. It is used on the Ren-C board, where the only change is replacing the two chips with one 75179-type chip (everything else is the same). Making this change would open up space for improved routing of the ULN signals.

Phil

brain fart. Long day at work today. I thinking 75176 and not 75179 and at first did not comprehend about the part change. Not to familiar with all the various 485 driver chips. Yes that would be far better than 2x75176 or equivalent.

That will make the layout simpler.

james