Finally Affortable Snowfall Tubes (FAST)

[chelmuth]

I've been working on an idea for inexpensive snowfall tubes.. What I've come up with so far consists of :
1-PIC 16F688
8-51Ohm 1/8Watt Resistors
1-10KOhm 1/8Watt Resistor
56-Pure White SuperFlux LEDs (Or Any LED, Depending on Vf the 8 resistors value might need to change)
My plan is not to create a PCB for these but take strips of white Formica and drill the holes for components. I know tedious but the idea is inexpensive and I've got time.

My plan is to power 1 tube per Ren48LSD Channel. Simply supply 5V to the tubes and they do a "fall".. I've written some Firmware for the PIC. I have 2 working versions. One is straight forward and loops through 28 times lighting 2 LED's each time through the loop with delays. The second is a variation with a TMR0 interrupt triggering the next run though the loop. Both Firmwares start with the fall going fast and then slowing as it "falls" I'm attaching the Schematic & Firmware for what I have currently working. Ideally I'd like to get it to a point where there are a few configurable options in the firmware such as setting a flag for maybe a "dimming tail" or other ideas. I'd like some input on the software and if possible some help with the code. I'm 1 week into learning assembly, so I know I've got a ways to go.

Here is a video of the LED's on my breadboard..
http://vimeo.com/22587872 (Uploaded at 11pm on 4-18-11.. Vimeo says it might take til midnight to convert. If it doesn't work try back)

[smoothice]

Very cool. Can't wait to see the finished product and total cost as well.

[kychristmas]

Your timing stinks... :) About the time you were waiting for the Video to upload and convert, I was finishing my Taxes and beginning to pull out all my Blinky Flashy stuff. I told myself that I had to get my Taxes done before working on my two new projects: RGB Sparkle Balls and Snow Fall tubes. My tubes were based on BobKeyes design. very similar to yours, but a simple 12 LED solution driven directly off the PIC.

I like the formica idea. For my My prototype I cut a strip of a piece pegboard and pushed the LEDs from the back.

Did you write your code from Scratch? I'm very impressed. Not sure I coudl handle the Matrix stuff.

If you haven't seen it, here's the post where Bob's starts:

http://doityourselfchristmas.com/forums/showthread.php?5870-Falling-snow-lights&p=107970#post107970

No matter what happens, I think most of the DIY designs could use this type of LED. Where did you get yours and what was the cost? Do you think it makes sense to do a Bulk Grup Buy? I struggle at pulling the trigger on LED purchases. I'm never sure on what I'm buying. I have been using a bunch of LEDs that were sold as replacement for LED strings. I bought every replacment pack the 3 Walmarts near me had for like .15 per pack of 5. They are not as bright as any LED I have seen in a tube, and have strange viewing angles, so I would like to use something different.

[tweist]

Very nice. I have been investigating this same type of design, but never finished. I really like the idea and have looked online at some of the pre-made units but did not like the way they were triggered.

I would gladly be up for a group buy on this one. What length are you thinking of obtaining? And to be able to trigger it from Vixen is the best part.

Please keep me informed.

[kychristmas]

Now that I had a chance to look at the Schematic, my brain hurts. It looked like a matrix of some kind, but when I look at the mixed orientation of the LEDs, I don't see it. Can you explain the concept? Sorry, I'm a bit dense.

[chelmuth]

The LED's are CharliePlexed not regular Matrix. Basically you use 8 pins connected to each other as follows with 2 leds one forward biased and one reversed.. so you get 2 LED's per connection then when you reverse the high and low of any pair the other LED lights..so wires go from
1-2, 1-3, 1-4, 1-5, 1-6, 1-7, 1-8
2-3, 2-4, 2-5, 2-6, 2-7, 2-8
3-4, 3-5, 3-6, 3-7, 3-8
4-5, 4-6, 4-7, 4-8
5-6, 5-7, 5-8
6-7, 6-8
7-8...

This gives you 28 paths and when you put 2 LEDs on each path you get 56 total LED's..

The LED's I plan to use are the Pure White SuperFlux LED's for the superstrips that tjeitzer (sp) just did a group buy for.. Since we ordered 10k'ish the price ended up being 4$ for 60.. so for a final cost I'm looking at $4 LEDs, $.10 Resistors, $.14 PIC Socket, $1.50 PIC16F688, Optional RJ45Jack for Power Connection $.80.. Plus what ever the Formica costs if not free. and i'm thinking the 4' Florescent projector tubes which are ~$4.. So I'm thinking easily less the $14 total possibly less that $10 if you only make 2ft tubes..

Yes I did write the code from scratch.. That was a learning process (read "much banging head on wall going why the $#%@ doesn't it do what i'm telling it to) considering I'd never touched Assembly before 2 weeks ago.

My ideal length was either 2 or 4ft depending on how the LED spacing looks once I get the actual LED's i'm going to be using in place..

[WireWrap]

All I know is that I'd like to get ahold of that I&%$#%$^ guy "Charlie" (Charles Allen) and wire his arms and legs up in opposing polarities. It's called Charlieplexing, and it uses a minimal number of output pins to control a large number of LEDs. Theory says you can control N * (N-1) LEDs with N pins. So for 8 pins you control 8 * 7 = 56 LEDs. You only need to keep all potential paths below the forward voltage that will light the LEDs. WIERD guy!!

See this Instructable for a pretty good explanation: http://www.instructables.com/id/Charlieplexing-LEDs--The-theory/



:)

[kychristmas]

Thanks for the great explanation guys. I have heard of Charlie-Plexing, but I didn't understand it like that. My head still hurts! So in your schematic, how are they numbered?

I bought a few extra in TJs GB, but not that many.

[chelmuth]

So in your schematic, how are they numbered?

Looking at the resistors they are in order.. 1-8 .. I used the same pins as the channel outputs for the renard software as I was originally going to mod some renard code but decided against it and rolled my own.. Maybe this schematic is easier to read?

[n8huntsman]

Check out pages 8 and 9 of this for a good schematic and explanation of charlie-plexing. This really helped be get my head around it.
http://downloads.eshepherdsoflight.com/Howidid-MidiTree.pdf

[WireWrap]

Check out pages 8 and 9 of this for a good schematic and explanation of charlie-plexing. This really helped be get my head around it.
http://downloads.eshepherdsoflight.com/Howidid-MidiTree.pdf

Actually, that is just an example of multiplexing, rather than Charlieplexing. With Charlieplexing, the state of each output effects the resultant selection, where in DonJ's megatree, each of 12 outputs controls a branch, while two outputs are used to select one-of-four colors for all branches.

Charlieplexing will light (or not light) one of two LEDs (or strings) for EACH PAIR of outputs. For example, (for two outputs) If A is high and B is low, then D1 lights; if A is low and B is high, then D2 (which is wired back-to-back with D1) lights. If A and B are both high or both low, then neither D1 nor D2 light. Again, the rule is N*(N-1) lights for N outputs. In this example, 2*(2-1)=2. The advantage comes when you build up the number of outputs feeding the matrix.

However, as you increase, you lose discrete control, unless you can tri-state (open-circuit) the outputs. Lacking that capability, for 8 bits of data, you can control 8*(8-1)=56 lights. Since there are 256 possible states (ON or OFF) of 8 bits, there are only two states with all lights off (00000000 and 11111111). All other bit patterns will result in 7, 12, 15, or 16 lights on. Actually 7 occurs 16 times, 12 occurs 56 times, 15 occurs 112 times, and 16 occurs 70 times. Each light is on in 64 of the 256 states.

(Isn't matrix math fun????) :roll: :roll: :roll: :roll:

As usual, I've gone on way too long, but that's me... (see my signature):D

[djulien]

Charlieplexing will light (or not light) one of two LEDs (or strings) for EACH PAIR of outputs. For example, (for two outputs) If A is high and B is low, then D1 lights; if A is low and B is high, then D2 (which is wired back-to-back with D1) lights. If A and B are both high or both low, then neither D1 nor D2 light. Again, the rule is N*(N-1) lights for N outputs. In this example, 2*(2-1)=2. The advantage comes when you build up the number of outputs feeding the matrix.

However, as you increase, you lose discrete control, unless you can tri-state (open-circuit) the outputs. Lacking that capability, for 8 bits of data, you can control 8*(8-1)=56 lights. Since there are 256 possible states (ON or OFF) of 8 bits, there are only two states with all lights off (00000000 and 11111111). All other bit patterns will result in 7, 12, 15, or 16 lights on. Actually 7 occurs 16 times, 12 occurs 56 times, 15 occurs 112 times, and 16 occurs 70 times. Each light is on in 64 of the 256 states.

Also, by adding bipolar transistors across the resistors, you can increase the I/O pin drive capability so that you can turn on multiple LEDs within a "row" of LEDs without burning out the I/O pin. An EDN article about "chipiplexing" a while back described that trick.

don

[ErnieHorning]

Also, by adding bipolar transistors across the resistors, you can increase the I/O pin drive capability Of coarse as you know, using an appropriate optocoupler will allow you to drive nearly anything you want.

[djulien]

Of coarse as you know, using an appropriate optocoupler will allow you to drive nearly anything you want.

I was thinking that optocouplers are used more for voltage isolation, but that's an interesting idea to use them for current protection purposes also. thanks.

don

[griffixdc]

pretty neat :)

[chelmuth]

Ok, I got my LED's in from the group buy and away I go.. Here are some pics of my first one.. Being that I'm lazy and cheap I didn't feel like going to the store and getting any formica to start this project. I had an old screen out of an old rear projection tv in my garage. The diffuser on the front of the fresnel lens has nice groves in it perfectly positioned to run a razor blade down it to score it and snap to the width I wanted. The screen I'm using happens to be around 24" tall If I want different size tubes I just find larger screens. People are always throwing these TV's away now what I nice way to recycle part of them. On a side note the Fresnel lens is very fun to play with but very dangerous. WARNING : It'll make a spot and get it 2000+ degrees.. You can melt glass and or steal or give yourself a nice sunburn.. So here are some pictures of what I've completed so far.. Not pretty but functional and the screen was free.

10260
10259
10258

[tweist]

Looks great so far. Hope to see the finished product by monday, and of course we will need video of it actually working so we can all want to do it.

[dmcole]

Looks great so far. Hope to see the finished product by monday, and of course we will need video of it actually working so we can all want to do it.

+1

\dmc

[wwwgator]

Hi, trying to follow along with the schem.
All the LEDs in both drawngs are labled D?
Although the color "wiring"diagram helps, still not sure what sequence to wire the LEDs.

Oh, btw, I am planning on using 3/4" green plastic Banding tape we use at work. We throw thousands of scrap pieces away daily...
If anybody wants to try ths flexible pcb, pm me

[Aurbo99]

Hi all, been semi-away for a bit.

I just came back from Home Depot after my weekly drool-fest in the store.

Flourescent tube covers.. about 2 bucks each and up to 4 feet long. They are clear and have caps on each end with an opening to allow the prongs to poke through.

Use those and a small pcb board for the hardware and run a ribbon-cable (or even a pair of cat5 cables) off the board and the leds soldered to the ribbon. a small elastic band keeping the ribbon cable taunt at the bottom, in the same fashion as the di-pole antenna tensioner.

Could not find a HD sku number online, but here is a UK store (http://www.covershield.co.uk/) with the same items..

http://www.covershield.co.uk/ADrawing/colouredtube.jpg

http://www.covershield.co.uk/ADrawing/Protectedcovers.jpg

[chelmuth]

Ok here is the first fully populated FAST circuit. 1-PIC16F688, 1-14Pin Socket, 8-Resistors (16 in these pictures because i didn't have any 51Ohm Resistors so i doubled up on 100Ohm), 56-LEDs...

10264
10261
10262
10263



http://vimeo.com/23416416 <--- Video of FAST running. Uploaded at 4:15pm EST Vimeo will be converting for the next 30 minutes.

[wwwgator]

great work!!
Video looks good!

[ErnieHorning]

Could not fins a HD sku number online...
HD calls them "Tube Protector" (http://www.homedepot.com/webapp/wcs/stores/servlet/Search?keyword=tube+protector&langId=-1&storeId=10051&catalogId=10053) but no colored one's.

[budude]

Very nice - - the epitome of DIY - especially using some hacked plastic from an old TV screen! Great Job!

The only concern I would have is something djulien touched on earlier - as I recall the 16F688 is rated for a total of 90mA for all I/Os. What is the current for the LEDs?

[chilloutdocdoc]

They're charlie-plexed, only one of them is ever on at a time, I recall him in chat saying he was running them at less than 20mA each.

[budude]

They're charlie-plexed, only one of them is ever on at a time, I recall him in chat saying he was running them at less than 20mA each.

You can have more than one on at a time with charlie-plexing - at least 7 that I can see...?

[chelmuth]

You are correct I could have 7 on at one time. However the firmware is written that only one is ever on at one time.. Plus as Josh stated I didn't have 51Ohm resistors so I originally used 100Ohm which left the LED's running at 9.5ma.. and still plenty bright enough..

wwwgator - If you look at the firmware it tells you what pins are that I used and the order that they fire.. So below the first LED to fire would be Pin3 to Pin13.. If you follow the colored diagram it's exactly how i wired it.. and once you kind of look at how it's done it's really kind of easy.

;1 = RA4 (Pin3)
;2 = RA0 (Pin13)
;3 = RA1 (Pin12)
;4 = RA2 (Pin11)
;5 = RC0 (Pin10)
;6 = RC1 (Pin9)
;7 = RC2 (Pin8)
;8 = RC3 (Pin7)
;
;1-2 Done;1-3 Done;1-4 Done;1-5 Done;1-6 Done;1-7 Done;1-8 Done
;2-3 Done;2-4 Done;2-5 Done;2-6 Done;2-7 Done;2-8 Done
;3-4 Done;3-5 Done;3-6 Done;3-7 Done;3-8 Done
;4-5 Done;4-6 Done;4-7 Done;4-8 Done
;5-6 Done;5-7 Done;5-8 Done
;6-7 Done;6-8 Done
;7-8 Done

[tweist]

Great job. I am impressed. I'm thinking, maybe next year I will make some. This year budget is already spent, and then some.
Really nice job.
Oh and thanks for the video. That really shows how well it works.

[dmcole]

IIdeally I'd like to get it to a point where there are a few configurable options in the firmware such as setting a flag for maybe a "dimming tail" or other ideas. I'd like some input on the software and if possible some help with the code. I'm 1 week into learning assembly, so I know I've got a ways to go.


Corey:

And I absolutely stink at ASM, so I can't be of much help to you there.

I've just spent some time at YT and V looking at videos of snowfall tubes and what I find different about yours is that you're lighting only one pair of LEDs at a time, while most of the others light a larger swath of LEDs.

Also, other tubes seem to ramp-up to full on and then ramp down to off the swaths as they descend; is this the "dimming tail" you mentioned above?

Lastly, yours seem to be rather slow compared to others that are out there.

I think I'd want to build these as only 12- or 14-inches long ... would there be a provision to have a shorter length?

Thanks so much for taking the time and energy to work on this.

\dmc

[chelmuth]

Just a change in the delay routing could make it faster.. currently i have it set to decay so that it falls slower as it gets lower. I had a discussion yesterday that someone thought it should go faster.. I could probably put a setting in there that if you put a 1 in before compiling it would speed up or a 0 would make it slow.. those are kind of the configurable options i was looking for having.. If you wanted shorter yeah you could make it shorter length.... just use less pins and remove the un-used pins from the code..also this was my first attempt and I could probably make it about 5" shorter just by having the LED's closer together also.. It's completely possible. I had just planned on around 24" as I was going to cut the tubes mentioned earlier in half (4') or quarters (8').. Yes the dimming tail was what i was refering to as far as the ramp-up you mention. That would require a re-write of the code that I'm not quite up to that skill level yet. It needs to have some sort of software PWM implemented and I have yet to find a good example that I've been able to hack apart and put into that and I'm not completely comfortable with the interrupt routines which would be required. Which is why i was hoping someone with a little more coding experience could help with. I was just laying the ground work and idea for innexpensive tubes. Currently they should be less than 10$ per tube.. yes they require some work but that's the fun part.

[dmcole]

That would require a re-write of the code that I'm not quite up to that skill level yet. It needs to have some sort of software PWM implemented and I have yet to find a good example that I've been able to hack apart and put into that and I'm not completely comfortable with the interrupt routines which would be required. Which is why i was hoping someone with a little more coding experience could help with. I was just laying the ground work and idea for innexpensive tubes. Currently they should be less than 10$ per tube.. yes they require some work but that's the fun part.

Corey:

I understand your motivation for the tubes -- I agree; it's an element I'd be interesting in adding to my show if it only cost about $10 per tube and I could control each tube individually. I don't mind the hand-work ... I hand-wired more than 3000 individual LEDs last year ;-) ...

The one thing I don't understand is why you decided to write this in assembly ... if it were in C, you'd have folks falling all over themselves to help you. But hardly anyone here writes in assy ...

My guess is that you're seeking to improve your skills, which is cool, but I just don't think there are many here who can help you ...

Maybe you could restart the project in C, get it working and then port it to assy?

\dmc

[chelmuth]

LOL. I've never written anything in C before. so I wouldn't really know where to begin. but with that said I had never written anything in assembly before this either.. I think from the .ASM file someone could identify with what I did and port it to C. I commented it pretty well and like I mentioned earlier the LEDs fire in the order they are wired. I'm sure someone with more experience in C could whip it out in about 10 minutes. It's not really that complicated of a program. And if not I might get around to trying to port it myself eventually..

[budude]

You can try Great Cow Basic also - it's free and is made for the PIC and can be more readable/easier to follow than C code. Then again - if you're happy with what you have - then that's good enough really!

[P. Short]

It might be possible to write it in C if you don't need the dimming (e.g. tails). I don't think that it would be possible to do that if you want dimming ... remember, the processor is only 2 MIPs without an external crystal. I haven't assimilated Cory's firmware yet, so I'm not sure how hard it would be (or if it is even possible) to do dimming even in assembly language without bumping the clock rate. Since I have in mind driving 7 LEDs at once, I may be making it more difficult than it really is, though.

The PIC16F506 might be an alternative to the PIC16F688. It is a lower cost part, and you give up the UART, the EEPROM, two timers and some instructions, but it can source/sink more current than the PIC16F688. It also has less memory (instruction and RAM), which may not matter in this application.

[P. Short]

I've been playing around with some PIC16F506 code to try and get some dimming capability. What I've come up with is something that will drive 8 outputs at a time (seven anodes and one common cathode), for a total of 56 LEDs, refreshing to 32 levels of dimming at about 110Hz. Internally the code has 56 locations that each holds the dimming level for one LED, which can be independently set in some 'background' code. The code is completely based around a couple of loops, without any use of timers or interrupts.

Unfortunately, the algorithmic nature of my coding led to a somewhat different mapping between the pins and the LEDs from what chelmuth has done, as follows:



;; Hardware mapping (somewhat similar to Renard)
;;
;; Output 1 = Pin 3 (RA4)
;; Output 2 = Pin 13 (RA0)
;; Output 3 = Pin 12 (RA1)
;; Output 4 = Pin 11 (RA2)
;; Output 5 = Pin 10 (RC0)
;; Output 6 = Pin 9 (RC1)
;; Output 7 = Pin 8 (RC2)
;; Output 8 = Pin 7 (RC3)

;; LEDs are assumed to be connected as follows:
;; Top seven LEDs
;; Cathodes (all seven) - output 1
;; Anodes (top to bottom) outputs 2,3,4,5,6,7,8
;; Next seven LEDs (from top) (set 2)
;; Cathodes (all seven) - output 2
;; Anodes (top to bottom) outputs 1,3,4,5,6,7,8
;; Next seven LEDs (from top) (set 3)
;; Cathodes (all seven) - output 3
;; Anodes (top to bottom) outputs 1,2,4,5,6,7,8
;; Next seven LEDs (from top) (set 4)
;; Cathodes (all seven) - output 4
;; Anodes (top to bottom) outputs 1,2,3,5,6,7,8
;; Next seven LEDs (from top) (set 5)
;; Cathodes (all seven) - output 5
;; Anodes (top to bottom) outputs 1,2,3,4,6,7,8
;; Next seven LEDs (from top) (set 6)
;; Cathodes (all seven) - output 6
;; Anodes (top to bottom) outputs 1,2,3,4,5,7,8
;; Next seven LEDs (from top) (set 7)
;; Cathodes (all seven) - output 7
;; Anodes (top to bottom) outputs 1,2,3,4,5,6,8
;; Last seven LEDs (from top) (set 8)
;; Cathodes (all seven) - output 8
;; Anodes (top to bottom) outputs 1,2,3,4,5,6,7


One potential advantage of this mapping is that it would be easy (easier???) to divide the 56 LEDs up into smaller 7- or 14-LED strips if you don't want to have one long 56-LED strip.

At the moment the code is untested, since I don't have the hardware for testing it (nor the intention of building it at the moment). However, I think that it would only take me a day or so to bring it up if I had hardware.

Further note - since this firmware drives seven LED cathodes from one output pin at a time, it needs to have booster transistors added outside the PIC similar to what someone else (djulien) has done.

Further note - I wonder if this largely duplicates his work.

[chilloutdocdoc]

Not being a very PIC learned guy (i can program a renard that's about it) but having written a LOT of C code for AVR's, they might be something worth looking at, while a step up in the processor cost, you get a product that can run C a lot faster than a PIC can. (AVR's were made with C in mind).
Just a thought.

P.Short. Is it faster to run the code without timers/interrupts? Or what was your reasoning behind not using them?

[P. Short]

P.Short. Is it faster to run the code without timers/interrupts? Or what was your reasoning behind not using them?

The processor in question doesn't have interrupts, and it's one timer is next to useless. And if you were to ask why I selected such a processor, the problem didn't seem to me to call for using interrupts or a timer. I've done enough PIC assembly language programming for this type of task that it is quite easy for me to visualize and code it up.

[chelmuth]

LOL Where were you when I was hacking this project together.. Tonight I made a basic "tail" of 4 stationary LED's.. Tomorrow after work I'll try and get my "tail" moving. Like you mentioned I made the dimming with just a loop and decreasing variables to call lighting the LED's every so often and resetting the counter for that particular LED which gave me my tail.. Now to add in another variable to make it "fall/move"

[chelmuth]

Ok so it took me 2 nights to figure out how to make my tail work.. WARNING : This code is Ugly but i commented it pretty well I think and it works which is the best part.. I would like to thank P.Short for some how kicking my brain with his comments and making it all of a sudden pop in my head how it could be done or at least how I thought it could be done and obviously it can because I did it :) No timers or Interrupts were harmed in the making of this Firmware.

http://vimeo.com/23618574 Video In Action Uploaded 11:00pm EST will be ready in 30 minutes.
http://vimeo.com/23619063 Video in the dark..

Also I've attached the Firmware for everyone to tear apart..

[mlkren]

I don't care how ugly the code looks. The tails look awesome. Great Job!

[P. Short]

The videos look good.

[ppohlman]

That looks great!!

I'm assuming that you're still using the original PIC 16F688?

I'm thinking that I might have to start making some of these FAST for my display. Thanks for your great work.

[chelmuth]

Correct still using Pic 16F688 seemed like an easy choice since most people have them and most of the boards use them.. This code would probably work on the less expensive chips Phil was talking about with some adjustments or maybe none.. I haven't looked at the data sheet as I don't have any to play with..

[ppohlman]

Correct still using Pic 16F688 seemed like an easy choice since most people have them and most of the boards use them..

That's one of the reasons I really like this project and what you have done. I always have a few of these lying around as backups. Beats having to keep a bunch of different chips on hand.

[mlkren]

I am quoting your comment in the header of your code.

I know this Code is UGLY but it works and I don't think it's bad for only using Assembly for about 4 weeks I am also new to Assembly, what are you using for reference. I have found some old PDF books that mostly use the 16C84. Any advice would greatly be appreciated.

[chelmuth]

The datasheet for the 16F688 and these two websites
http://www.mstracey.btinternet.co.uk/pictutorial/picmain.htm
http://www.piclist.com/techref/piclist/codegen/delay.htm

The second site I didn't use in this version of the firmware but i did use it in the first version for my delay loops..

I think there maybe 1 or 2 commands i didn't learn from there that I used and just happened to think they might be commands and tried them.. I think one was MOVFW and I'm not sure what the other was. The think I found most helpful was Josh (Chilloutdoc) helping me figure out the debugging sim in the MPLAB IDE.. It helped me with me identify that I was having stack overflows at some point. Then I followed my code line by line and used my fingers to count how deep in the stack I was and when I made a call and if I ever returned.. about 3/4 way through my second loop or so I figured out where my error was and that it should have been a goto instead of a call. Trial and Error is mainly how I've been writing the code... There may have been other google searches throughout about PWM and turning off analog pins but nothing I saved mainly because I couldn't make it work or didn't have the chips it was written for anyway.

[P. Short]

The PIC16F510 most likely won't work with chelmuth's code. Apart from the memory map being different, there are a number of PIC16F688 instructions that aren't implemented in the PIC16F510. These include the return instruction (you have to use retlw instead), the addlw and sublw instructions, and TRIS and OPTION registers cannot be explicitly addressed (you have to use special-purpose instructions). Another difference is that the instruction space is rather rigidly paged on a finer level than the PIC16F688, so you have to worry about where the various subroutines are located in program space relative to each other.

As for learning the assembly language, I used Borders as a library, hanging out in the cafe with my laptop when writing my first PIC programs about five years ago. Maybe that is why they are in bankrupcy court now.

[P. Short]

OK, I've got the code working with the PIC16F510. That part is a real pain to program, it has too many gotchas due to how they implemented register banking with that part. At the moment I don't have a decent camera here (the ipod camera didn't work all that well here), but here is an image of the breadboard.

10288

As far as I can tell, Cory's firmware is set up for handling a sparse array, where a small number of LEDs are illuminated at a time. I'm guessing that the practical limit here is perhaps 8-16, with the refresh rate becoming too low above that number. There is only one LED on at a time, with the display multiplexed between the 'ON' LEDs. He has a list of which LEDs are on at a particular time, and what I'll call 'background code' modifies that list to simulate falling snow. Since only one LED is on at a time, the PIC is capable of driving the LED without the need for any external amplifier devices (which is good).

The firmware that I wrote takes a different approach. It is capable of handling the situation where all 56 LEDs are illuminated at once. In this design up to seven LEDs may be 'ON' at a given time in a common-cathode arrangement, so external transistors are needed for driving these cathodes (so-called chipi-plexing). Since there may be 7 anodes driven at once, the PIC needs to be able to source 175 mA if the LEDs are each passing 25 mA of current. This rules out the PIC16F688, although the PIC16F506 is almost good for that current (150 mA). The PIC16F627 is good for the 175 mA, as are a number of other parts.

For now (and perhaps forever) I don't intend to release the firmware. There is already something out there which is just fine, imo. The code for the PIC16F506 is just too delicate, although it wouldn't be too hard to change it to work with one of the mid-range PICs.

[chelmuth]

Here's a Fairly final picture of what I plan on these looking like.. Maybe white caps instead of green when I find them..

[P. Short]

Just out of curiosity, are you going to make a lot of those or just one or two?

[chelmuth]

I plan on making somewhere between 24-48 of these.. my final cost is..

579-PIC16F688-I/P - 16F688 - $1.66
299-51-RC - 51Ohm Resistors - $.72
299-10K-RC - 10K Resistor - $.09
60 SuperFlux LED's - TJ Coop - $4.00
4' Tube Protector cut in half so - $2.00
--------------------------------------
Grand Total $8.47 Per Tube And would go down if you bought more quantity

These pics are of my second board much cleaner start than the first.. also I made a tool to help me make the Superflux holes.. It worked so well I accidently made room for one too many LED's :)

[chilloutdocdoc]

I plan on making somewhere between 24-48 of these.. my final cost is..

579-PIC16F688-I/P - 16F688 - $1.66
299-51-RC - 51Ohm Resistors - $.72
299-10K-RC - 10K Resistor - $.09
60 SuperFlux LED's - TJ Coop - $4.00
4' Tube Protector cut in half so - $2.00
--------------------------------------
Grand Total $8.47 Per Tube And would go down if you bought more quantity

These pics are of my second board much cleaner start than the first.. also I made a tool to help me make the Superflux holes.. It worked so well I accidently made room for one too many LED's :)

buy the resistors in quantity, you can get them in 100-200 for about $.01 and build up your spare parts stock at the same time.

[n8huntsman]

How hard would it be to make another version that has constant power applied and falls at random intervals? Might be even cheaper. I like these but don't really want to sequence them into my show and don't wanna build a low voltage controller or SSR. I think they would look great as background filler just left on.

[chelmuth]

Just hook them Up to a 5v Power supply and they run.. use a computer power supply 5v rail.. Random interval could be implemented I'm sure I'm just not sure how to at the moment.

[P. Short]

Just hook them Up to a 5v Power supply and they run.. use a computer power supply 5v rail.. Random interval could be implemented I'm sure I'm just not sure how to at the moment.

One way would be create a pseudo-random sequence with a LFSR (linear-feedback-shift-register) implemented in software. This is similar to the shift register used for CRC generation/checking. I'm sure that there are lots of examples on the web.

[ErnieHorning]

Just hook them Up to a 5v Power supply and they run.. use a computer power supply 5v rail..The LED's are the biggest draw and since it was previously posted that an LED is using 20mA and only one is on at a time, you could use a 78L05 and almost any low voltage wall wart for power.

[chelmuth]

Ok I have my process working a little better the second time around.. Looks much nicer than my first experiment and the second one went quite a bit faster than the first though it still took several hours.. I might be able to go a little faster if I wasn't using toenail clippers as wire strippers.. :) Here Are some pictures of the new tube along with my first one.. and Some videos of them running and the neatness of the second..

http://vimeo.com/23734734 <-- A look a the second much nicer build..
http://vimeo.com/23734687 <-- Both tubes running next to each other and the effect begins..

Videos uploaded about 5:15pm EST should be ready around 5:45pm EST
Also are attached some high res stills of the new tube..

[dirknerkle]

Better and better, Cory. Looks great. Nice work!

[barbotte]

that is so awsome .. we need a coop for the pcb lol or maybe a wiki on how to do it ....
cheer

[i_wannabe]

This is a real cool project aind I love the effect. The tubes you have for covering your lights are clear and smooth, if you look at the commercial ones they are rough and difuse the light. I was wondering if you wrap the tubes with cellophane like Saran wrap only don't do a good job I mean you make wrinkles in it, if that would give it a look you might like. Not sure of the UV protection if it would turn yellow in the sun or not but it is just a thought. If you don't like it you can just unwrap it. If you like it you might be able to wrap it in packing tape to protect it again just a thought. Keep up the good work and thank you for sharing.

[ppohlman]

that is so awsome .. we need a coop for the pcb lol or maybe a wiki on how to do it ....
cheer
A step-by-step "How To" with pictures would be perfect.

[bluegecko]

This is a real cool project aind I love the effect. The tubes you have for covering your lights are clear and smooth, if you look at the commercial ones they are rough and difuse the light. I was wondering if you wrap the tubes with cellophane like Saran wrap only don't do a good job I mean you make wrinkles in it, if that would give it a look you might like. Not sure of the UV protection if it would turn yellow in the sun or not but it is just a thought. If you don't like it you can just unwrap it. If you like it you might be able to wrap it in packing tape to protect it again just a thought. Keep up the good work and thank you for sharing.

If you wanted a defused look, some rough sandpapering should give you a nice frosted look to diffuse light. Never tried it on those specifically though.

[tweist]

Cory

Thank you for all of your hard work on this. I have been wanting to do this for a long time, but have not put much time into it. Now that you have done all the hard work for us, I may actually get to work and build some of these. I really like the work you put into it.

Thanks again.

[CaptKirk]

I know this is supposed to be something done as "affordable" but I worry about the ruggedness of a hand wired LED strip. Seems like it could be a maintenance nightmare. It seems like a modular setup (to allow flexibility) with inxpensive PCBs (RPM seems to have found a good and inxpensive board house) would be more reliable and quicker to make. I see a control module (Fast-Smart) with an 8 pin header out like you alread have, but then a "dumb" LED PCB (FAST-Dumb) that would hold say 14 LEDS with the 8 pin in at the top and an 8 pin out at the bottom. You could string 2,3 or 4 together for variable length, OR add in an 8 pin cable (or just wires) between so you could have up to 4 individual short FAST tubes connected to the one control module. That is how I would use this. It would be cool if the FAST-dumb LED board could be dual footprint to handle the Pirana's OR 5mm discretes for those of us really cheap. Man I wish I was up to speed on PCB design...

Or does that already exist but I do not know about them??

Kirk

[P. Short]

Capt,

The difficulty wiith that scheme is designing things so that all of the PCB strips that you are stringing together are either identical or easily configured. What you don't want (and is hard to avoid) is having one PCB for the first one in the string, a second layout for the second one, and so forth.

Also the fragility issue is somewhat addressed by placing the LED strings inside of a fluorescent tube protector.

[CaptKirk]

Phil,

Yes, I agree the tube helps, but still, I have wired this sort of thing before, and a bump in the right place will kill it quick- the tubes can be pressed in (especially in storage) then you have a problem. Plus there is a time element also for a typical DIYer (I can handle it but can every one do it?).

My scheme that would be somewhat difficult, but couldn't you have a way using "zero ohm resistors" (wires) to pull out the two or three (? charlie-plexing is still confusing me) signals out of the 8 pin "bus" needed to drive the 14 LEDs per section? It seems this would still be cheap to PCB and infinitely easier to build and much more reliable!

What do you think?

Kirk

[P. Short]

The devil is in the details...

I've been thinking about it for the so-called 'sawyer-star' project for some time, and I think that I know how to do it. I've been avoiding implementing it because of how much time it would take me to re-wire the solderless breadboard with the LEDs on it that I'm using for testing. Of course, the sooner that I bite the bullet the less work it would be in the long run.

As far as Cory's project goes, I don't know how difficult or easy it would be. I haven't looked into the design files in enough depth to figure it out.

[dirknerkle]

I know this is supposed to be something done as "affordable" but I worry about the ruggedness of a hand wired LED strip.

Sometimes a hand-wired setup allows for more physical play than do circuit boards. Circuit boards often don't take too well to being bent... and even less so when the temp drops below zero.

(Just another rhetorical comment from a geezer..."

[CaptKirk]

It would have to be mighty cold to affect a circuit board, wouldnt it? Interesting thought though.

I've attached a mock up of the LED board (not to scale) but I have no idea how many pins are needed in the configuration interconnect to drive each 14 LED section - but his HAS to be possible. I need more time studying charlie-plexing... maybe someone who understands it better could comment?

Is this possible??

[P. Short]

You need someone who is familiar with Cory's work, not with charlie-plexing in general. I could give you information about the design that I'm working on (which is also 8x7 Charlie-plexing), but that won't help you here.

[dirknerkle]

It would have to be mighty cold to affect a circuit board, wouldnt it? Interesting thought though.

Put a strip of plastic in your freezer overnight. The next morning, see how well it bends. Same thing can happen to circuit boards in places were the temperature often gets to -30F. Such as where I live. Even individual strands of wire inside cat5 cable can actually *break* if you bend it when it gets that cold. We often have to build things a little differently up here where wintertime temperatures can easily be 100 degrees colder than it is for you good folks in California. :lol:

[chilloutdocdoc]

"By using tri-state logic, the matrix can theoretically be expanded to any size, as long as pins are available. For n pins, you can have up to n(n-1) LEDs in the matrix. Any LED can be lit by applying 5 V and 0 V to its corresponding pins and setting all of the other pins connected to the matrix to input mode."
~http://en.wikipedia.org/wiki/Charlieplexing

So 14 leds could be done with 5 pins (would be capable of up to 20) led's. I'm not sure on the firmware changes needed to be made, but it would probably just be changing a few lines around.

[barbotte]

if you used polycarbonate plastic also call LEXAN weather will not change caracteristic as it is used on aircraf canopy, window ect ..what is so good about lexan is that it is flexible .. strong ... and will not crack when cut or bend .... best way to do it
cheer

[djulien]

"By using tri-state logic, the matrix can theoretically be expanded to any size, as long as pins are available. For n pins, you can have up to n(n-1) LEDs in the matrix.

For charlieplexing in general, there is a trade-off between duty cycle and # of LEDs on at a time, so with higher counts you would need to turn on multiple LEDs at a time or else they will be too dim, which then gets into max current limits of an individual PIC (but adding driver transistors resolves that). If you only turn on a small number of LEDs at a time, this isn't an issue, though.

There might also be some practical limits due to leakage current of the LEDs. For example, I'm getting quite a few extra LEDs turn on in an 18-pin charlieplexed (chipiplexed) circuit I've been working with (driving 80 RGB LEDs with a 28-pin PIC), but it may just be a wiring error or a bad LED (which is awkward to diagnose in a circuit this size).

EDIT: chipiplexing works okay with 18 pins, after the addition of diodes to prevent leakage

don

[chelmuth]

I get a few extra LEDs too but you can't really notice them from a distance with the blinding brightness of the full on LED's..

[P. Short]

WRT to PCB strips...

On the sawyer-star project I intend to set up the firmware so that I can make 7-LED PCB strips with the following wiring:



Inp-1 to LED1-C to LED2-C to LED3-C to LED4-C to LED5-C to LED6-C to LED7-C to Out-7
Inp-2 to LED1-A to Out-1
Inp-3 to LED2-A to Out-2
Inp-4 to LED3-A to Out-3
Inp-5 to LED4-A to Out-4
Inp-6 to LED5-A to Out-5
Inp-7 to LED6-A to Out-6
Inp-8 to LED7-A to Out-7


where Inp-n is a pin on the input connector and Out-n is a pin on the output connector. These are cascadable up to eight PCB strips with 1-1 wiring between the output connector of one strip to the input connector of the next strip. It is also easy for me to implement in the current version of the sawyer-star firmware. The basic problem is making sure that software can easily map sequential memory locations onto the LEDs in order from the beginning to the end.

[djulien]

The basic problem is making sure that software can easily map sequential memory locations onto the LEDs in order from the beginning to the end.

Couldn't you use a lookup or jump table to map them so the wiring is easier? (Do the shuffling in the plug-in or when the data is first received by the firmware rather that during refresh in order to not slow down the refresh logic).

don

[P. Short]

Yes, although that may slow things down. Things are (or were) somewhat tight in the sawyer-star project.

The other issue is to try and keep the traces on the board simple, and to minimize (or eliminate) jumpers/zero-ohm-resistors on the boards. And, at the same time, try to keep hand-wiring complexity within the bounds of reason for those who aren't using the PCBs.

[ErnieHorning]

On the sawyer-star project I intend to set up the firmware so that I can make 7-LED PCB strips...
I wasn’t totally sure how you were wiring this but the code seemed to indicate that all the LED’s in one direction were number 1-28 and the reverse ones were numbered 29-56. This comment confirms this.

Wouldn’t the wiring be a lot easier if the LED’s were coded 1, 29, 2, 30, 3, 31, 4, 32, etc.? This way every two LED’s would just be in parallel next to each other.

[Aurbo99]

Any thoughts on how to vary the drop speed of the "flakes"

2 input triggers? 1, fast, 1 slow? (2 channel SSR to control off/on)

other method?

[kychristmas]

I was able to build my own prototype based entirely on Cory's design. A lot of wiring and soldering, but the end results worked great except for one issue:

I get some ghosting/dim fliker in man of the LEDS after they have completed the cycle. Its very strange. I saw it on my original 20 LED setup, but figured it would go away when I had all of the LEDs in place. I am using the LED's from Wal-Mart replacement packs. I wonder if its the LEDs or something I'm doing. My Reistor values are not exactly what you had, but I think they are correct for what I have. Any thoughts?

My plan is to have two different tube setups that run at slightly different speeds. If I alternate those to create a curtain of snowfall behind my display, I think they will look good and give the effect I want. I'm going to use a Ren 48LSD to drive them, so I will be able to control when each of the tubes (or columns of multiple tubes) start and stops. If you didn't want to have to control them individually, then you could use different versions of the Firmware that started the sequence at different positions.

Thanks for the design Cory. While the PIC may be a little on the expensive side, its the cheapest and easiest "Falling Snow" setup to play with.

[P. Short]

I wasn’t totally sure how you were wiring this but the code seemed to indicate that all the LED’s in one direction were number 1-28 and the reverse ones were numbered 29-56. This comment confirms this.

Wouldn’t the wiring be a lot easier if the LED’s were coded 1, 29, 2, 30, 3, 31, 4, 32, etc.? This way every two LED’s would just be in parallel next to each other.

I'm replying/discussing over in the sawyer-star thread, so as not to disrupt (any more) what Cory's discussion.

[P. Short]

This was posted in another thread by mistake (I think), and referenced post #81 (above) by ky.


What is causing this ghosting? Is it due to currant leakage on the LED's or something else.

That is hard to say, but there are several possible causes (in random order):

1) wiring error going out to the LEDs.

2) LEDs that have too low a forward voltage (not the case here, I think).

3) Software error, possibly in accessing the TRIS and PORT registers. I haven't looked at the code here, but the following sequence is the best way to do it:



1) tri-state all of the pins going to the LEDs (setting all relevant bits in the TRIS register to '1').
2) output data to the I/O port
3) enabling the two relevant TRIS bits (clearing two bits to '0').


Failure to do step 1 BEFORE steps 2 and 3 might result in ghosting, as would doing step 3 before step 2. I haven't looked at the firmware to see how it is done there.

[kychristmas]

Number 3 sounds likely, but since nobody else mentioned it, I assumed it was me. I think its software because it only happens between cycles. Its not bad with one, but it would really ruin the effect if I had a curtan of these.


This was posted in another thread by mistake (I think), and referenced post #81 (above) by ky.



That is hard to say, but there are several possible causes (in random order):

1) wiring error going out to the LEDs.

2) LEDs that have too low a forward voltage (not the case here, I think).

3) Software error, possibly in accessing the TRIS and PORT registers. I haven't looked at the code here, but the following sequence is the best way to do it:



1) tri-state all of the pins going to the LEDs (setting all relevant bits in the TRIS register to '1').
2) output data to the I/O port
3) enabling the two relevant TRIS bits (clearing two bits to '0').


Failure to do step 1 BEFORE steps 2 and 3 might result in ghosting, as would doing step 3 before step 2. I haven't looked at the firmware to see how it is done there.

[chelmuth]

I'm 99% sure it's not software although i could be wrong. as I believe I have the software working as Phil has mentioned..

Step 1 : Pick output pins.
Step 2 : Turn selected pins high/low
Step 3 : All Pins Low turning off LED's
Step 4 : Back to Step 1

Originally I had a bad problem with the ghosting which turned out to be a bad LED.. but with all good LED's I still get the effect. Though very dim as I don't think you can see it in my videos. So I'm not sure exactly what's causing it. Also as people mentioned before if you difuse the tube I don't think you'd see it at all even up close.. I don't think the ghosting is bad enough you'd see it from any distance over 20' in the dark because the full on LED's are so bright.

Based on a test I juts ran 30 seconds ago.. I believe it's the Vf issue. I hooked the circuit to a 3.7v battery and Zero ghosting..

[mlkren]

This was posted in another thread by mistake (I think), and referenced post #81 (above) by ky.

My bad, I thought we were moving the discussion over to the Sawyer Star Redux (???). After I posted it, I thought better. :grin:

[djulien]

What is causing this ghosting? Is it due to currant leakage on the LED's or something else.

If you step through the LEDs slowly, turning only one and off at a time, does the intended LED come on in addition to the ghosts, and how many/which LEDs are ghosted? (do they have an anode or cathode in common to the intended LED?)

Also, do you get ghosting for all of the LEDs in the circuit when turned on one at a time, or only for a few selected LEDs?

If it happens on all LEDs, then that seems to point to either a mismatch of the type of LEDs used, a voltage problem, or some other problem with the overall hardware (or maybe software).

If it only happens for a few selected LEDs, then there is some kind of problem with the those specific LEDs (or it could still be a software problem). If you are seeing pairs of ghost LEDs and the intended LED does not come on, then the connection to the target LED is open or that LED itself is bad. If the target LED does come on but it's dim and another LED(s) come on also, then the target LED is okay but there's a bad connection.

I probably did not explain that too well - here is a diagram:

10352

don

[chelmuth]

Here's a board design idea.

[erm213]

Here's a board design idea.

Looks clean, do you have a ballpark on the pcb price?

Erik

[CaptKirk]

Nice- if you were to cut that into 4 sections (14 LEDs per) would the bottom three boards be identical??

If so, would you just need to add an 8 pin connector between the sections??

[CaptKirk]

Looks like Phil figured out a way to handle segmenting the strip into 7 LED segments here:
http://www.doityourselfchristmas.com/wiki/index.php?title=File:LEDancer_LED_Module.PNG

To do the effects Phil wants to do it seems like you need each LED to be a channel on DMX where as I would like to trigger the various snowfall effects with fewer DMX channels with your design. DO you think your code and top end could be made compatible with Phil's LED segment board design? That way if one wanted the LEDancer, then you plug in Phils logic section, *OR* if you wanted FAST, you would plug in your logic board but the strip design (and frabrication) would be common?

This would give us increadible flexibility on the design (use a PCB or the lens out of rear projection TV for the LEDs).

I also think it would be great if the LED boards could be done to use the Superflux (4 pin jobbies), OR a 5mm LED for greater flexibility. I for one have a good supply of 5mm bright white LEDs but 0 of the superflux

[kychristmas]

This thread was for simple and inexpensive PIC-based Snow Tube design. It has now become muttled with much more complicated DMX talk and discussions about modular designs. IMO, the beauty of the design was that anyone with a PIC, LEDS and basic soldering skills could make these. Its a bit of work, but its doable.

I believe they moved the discussions to another thread to avoid polluting this thread with the more complicated DMX and Sawyer Star discussions. Cross-Linking makes it even more complicated.


Looks like Phil figured out a way to handle segmenting the strip into 7 LED segments here:
http://www.doityourselfchristmas.com/wiki/index.php?title=File:LEDancer_LED_Module.PNG

To do the effects Phil wants to do it seems like you need each LED to be a channel on DMX where as I would like to trigger the various snowfall effects with fewer DMX channels with your design. DO you think your code and top end could be made compatible with Phil's LED segment board design? That way if one wanted the LEDancer, then you plug in Phils logic section, *OR* if you wanted FAST, you would plug in your logic board but the strip design (and frabrication) would be common?

This would give us increadible flexibility on the design (use a PCB or the lens out of rear projection TV for the LEDs).

I also think it would be great if the LED boards could be done to use the Superflux (4 pin jobbies), OR a 5mm LED for greater flexibility. I for one have a good supply of 5mm bright white LEDs but 0 of the superflux

[P. Short]

I believe they moved the discussions to another thread to avoid polluting this thread with the more complicated DMX and Sawyer Star discussions.

You're right, that was my intention.

[kychristmas]

I certainly wasn't directing criticism towards anyone in particular. I just wanted to make sure that we keep Simple ideas SIMPLE. This is a very DOABLE project for a noob. I'm not a noob, but I play one in real life :) I don't want someone to be scared away from at least trying this when they start reading about Modular PCBs, LED Segments and DMX. Albeit very Time-Consuming, its a great Cheap Project that almost anyone can do.

It's not pretty, but my own Prototype of Corey's design turned out great. He was very correct that once I started soldering, the concept of the Charlie Plexed LEDS becomes very clear and I was able to move through it. Now, understanding the code was a different story, but that wasn't necessary. I was able to change the speed to my liking.

My Snow Fall curtain is a much more achievable project at $500 DIY as opposed to $1500 purchased. I still may not be able to swing the $500 this year, but I'm going to start building. Worst case, I hang whatever I can afford to get done from the trees in mine and my neighbors yard.

BTW... Thank you Corey (and BobKeyes)

[P. Short]

How big is your curtain going to be? I'm curious to see what other people are thinking.

[kychristmas]

Depends on the budget I can sneak in, but ideally I'm thinking about 25 columns of two 4ft tubes spread out across 30 to 40 ft. So I guess that would make it roughly 8ft x 40 ft, but I think the top of the curtain ill be like 10-12 ft in the air. As soon as a I come up with a system for building these, I hope to make a couple dozen of them and then play around with configurations. Playing around with spacing and mixing falling speeds and start delays. I know I have $250 in the budget to play with these and that should be enough to test.

My other idea to find a way to hang tubes of different lengths randomly above my display elements. If would be easy if my Big trees were integrated with my display, but so far, I have nothing in my big trees and they are away from my core display. As for now, I'm thinking this style would require some sort of artificial trees to support them. May just create a grid of support wires above the display. I could use it to hang more than the snowfall tubes.

[P. Short]

Sounds neat.

I'm thinking of an indoor curtain, against one of the living room walls. I would have the columns closer together, perhaps 2-3" apart. Over a 10' wall this would be about 40 columns. The problem here is going to be making them look nice when viewed from relatively close in a interior, lighted situation.

[CaptKirk]

I understand the FAST concept of being affordable and I completely agree with it and want to have that same option. What I was hoping we could accomplish was not to merge this with the Sawer/DMX discussion, but try to get a design that could use the cheap hand solder if desired (original slow to build FAST design), but also make FAST be able to drive the 7 segement strips that Phil is designing so if some wanted a fast to build FAST, you could combine the FAST logic and mate it to the LEDancer strips. That is the only muddling I am talking about. Sorry that confused things but I thought if both projects that need LED strips could use the SAME PCB for the strips, then that would add an economy of scale and give someone flexibility by just stringing more boards together for a long FAST, or seperate them for more dispersed shorter FASTs, or a Sawyer star with THAT logic. My bad for trying to get some common ground. Seemed like a good idea to me...

[P. Short]

Just as a side-note, the ledancer central controller (PIC + RS485 + resistors + transistors) is capable of driving the FAST LED strip with a fairly easy change in firmware. What would be lost is the modularity. This also assumes that the FAST LED strip is separate from the processor board.

[chelmuth]

I could also recode a version of FAST firmware to work with modular boards if they are made I'll order some and make another firmware..

[kychristmas]

Again, I wasn't criticising your efforts. While self-appointed, I consider myself to be a caretaker for the DIYC NOOB. When I see a valid doable NOOB project, I like to protect it. I just said this is a "muddling" and it very well may not be. But for certain, a simple concept that works great was getting confusing due to the mixing. I never said the mixing or the effort to find "Common Ground" wasn't valid, so you shouldn't take offense.

You are clearly a sharp guy and can figure things out. I couldn't even see the relationship between them until you and Phil pointed it out :) However, your Sharp mind is probably why you couldn't be a member of of my DIYC NOOB Caretaker panel :) The shortcomming of simple projects are just too much for you to take, but these shortcommings are what sometimes make these projects great for a beginner or the less engineering minded folks here. Many of us are happy to trade "Slow Build" for simplicity, easy understanding, and low cost of entry.

So I will yield to y'all and with Corey's permission at some point, I will take all of this and put it together in a Simple Snowfall Tube how-to.

Again, please don't take offense. I certainly didn't intend any.

Kelly


I understand the FAST concept of being affordable and I completely agree with it and want to have that same option. What I was hoping we could accomplish was not to merge this with the Sawer/DMX discussion, but try to get a design that could use the cheap hand solder if desired (original slow to build FAST design), but also make FAST be able to drive the 7 segement strips that Phil is designing so if some wanted a fast to build FAST, you could combine the FAST logic and mate it to the LEDancer strips. That is the only muddling I am talking about. Sorry that confused things but I thought if both projects that need LED strips could use the SAME PCB for the strips, then that would add an economy of scale and give someone flexibility by just stringing more boards together for a long FAST, or seperate them for more dispersed shorter FASTs, or a Sawyer star with THAT logic. My bad for trying to get some common ground. Seemed like a good idea to me...

[CaptKirk]

No offense taken, I did not realize how confusing I was making this thread so I do appreciate the perspective. Although it may be confusing initially, I think with coordination, the design owners could make this much simpler in the long haul and definitely keep it affordable.

By getting a common wiring scheme between these two projects, in the long run, I think it will make this easier to adapt the common part of the designs to do everything anyone might want.

You (and I) will still be able to hand wire using the ultra cheap DIY path. Phil will be able to make Sawyers and his other mind control devices, I will be able to make shorter snowfall tubes in mass quantity, etc.

Phil cracked the modular LED part (as well as the very cool, ultra addressable logic section). chelmuth cracked the snowfall effect on the cheap but did not have the way to go modular. It looks like to me (and the much smarter chelmuth will need to verify) that by slightly changing his output order, his logic section would be able to drive Phil's LED modules if anyone wanted to do that (like me). While this is still young, if a wiring change is needed for the basic FAST design, we definitely want to make that change early.

Make sense? Or as usual, am I just plain nuts?? Sometimes having a bigger picture view loses the critial details up close...

Kirk

[kkmm]

Kelly,
Looking forward to the How to

Cheers

I like this idea and The Minister of War and Finance loves it so I might get the funding to build LOL

[P. Short]

If you step through the LEDs slowly, turning only one and off at a time, does the intended LED come on in addition to the ghosts, and how many/which LEDs are ghosted? (do they have an anode or cathode in common to the intended LED?)

Also, do you get ghosting for all of the LEDs in the circuit when turned on one at a time, or only for a few selected LEDs?

If it happens on all LEDs, then that seems to point to either a mismatch of the type of LEDs used, a voltage problem, or some other problem with the overall hardware (or maybe software).

If it only happens for a few selected LEDs, then there is some kind of problem with the those specific LEDs (or it could still be a software problem). If you are seeing pairs of ghost LEDs and the intended LED does not come on, then the connection to the target LED is open or that LED itself is bad. If the target LED does come on but it's dim and another LED(s) come on also, then the target LED is okay but there's a bad connection.

I probably did not explain that too well - here is a diagram:

10352

don

In the 'open joint' situation, you would only get ghosting if the Vf of the LEDs is small (less than 2.5V, or so). If the Vf is greater than that, the power supply voltage (5V) won't be able to forward-bias two LEDs in series. White and blue LEDs should not show ghosting due to opens, other color LEDs might have ghosting due to open solder joints (or reversed/missing diodes).

[chelmuth]

I just did some testing of the superflux LED's from the group buy and 5v will light 2 LED's in series.. Which is why we are having ghosting.. This goes along with my lack of ghosting when I drove the Circuit with a 3.7v battery. So if we want no ghosting we lower the input voltage. I'm not sure how much Cat5 it would take if the tubes were 50-100ft away from the controller the voltage drop might be enough to stop ghosting. other ideas?

[P. Short]

Is there any evidence of an open solder joint or a bad LED (i.e. an LED that never comes on)?

[P. Short]

Also, I don't think that 100 feet of cable would help. The resistance of 24 awg wire is around 0.5Ω (200' round-trip), which translates to a 10 mV drop with a 20 mA of current.

[chelmuth]

No, No open joints or bad LED's everything works as expected just a little bit of ghosting. I'm not concerned about it really as I don't feel it's enough to be noticable. As you can see in my videos you can't even see it I don't believe.

[chelmuth]

YAY!!! Thanks to P.Short and about 5 minutes worth of talk. I made a change to the Firmware in post #39 and have updated it in that post.. Ghosting is gone. Thanks again Phil you are the Ghost Buster and or PIC Guru..

[barbotte]

that cool that you find the problem .... now all i need is a wiki or step by step as i have access to 12 sheet of clear lexan 4x8 1/16 and 1/8 thick and ton of white superflux....all i need is time to do it lol cheer

[P. Short]

Other than the 'idea' on post #88, I haven't seen any PCB design. Are there any plans for one, or to run any sort of coop?

[chelmuth]

Ideally yes.. It's thought that it might be run along with a second Ren48LSD and Ren4Flood and RenFlood boards from Brian. The design I thought would look something like the one I posted.. I made that up in KiCAD but that's all.. I'm not fluent enough in all the parts of the board design process and am trying to get some help with that. I think the bigest problem is finding a board house capable of running boards 50cm long.. I've only found 2 so far though I haven't looked extensively..

[kychristmas]

Cory,
While this will seem like a bit of a fallback from my previous position, but I do think there a great deal of benefit in doing something with that is modular. Phil's modular design would work. The problem with the 50cm boards will be very expensive and I think they are really too close together on that design. I definitely think spacing closer to the 1" is right way to go. Maybe once Phil has his design finalized you could create a version of the Firmware that matched his. I looked at it and was not able to understand it enough to try and convert it.

That said, I would definitely like to see the basic design you created be available for those that want to solder and wired design.

[chelmuth]

With 1" spacing The tubes would end up being 5ft tall. LOL..

[kychristmas]

I believe Phil worked it out so they would be just abourt 4ft. The first tubes I ever saw at a local Shopping Mall were 4 and 6 ft. long. I'm being selfish, but I like the 4 ft length. I realize that others have different uses in mind. My use will have them pretty far away from the viewer. That said, the thing I like about your simple design is that the Implementer can do what he wants. Of course, that means that standardized and inexpensive boards could not be done.

I'm using Pegboard for my prototypes and my current spacing is a bit too wide, but it does look pretty good. My prototype is over 5ft tall.


With 1" spacing The tubes would end up being 5ft tall. LOL..

[P. Short]

On those boards from the other thread I'm putting the LEDs 0.870" apart (just a smidgen under 7/8"). That might still be too big for some, as the tube protectors that I measured at OSH the other day have about 46" of clear space (plus another 1" or so of opaque cap on each end).

[chelmuth]

OK I wired up another Tube tonight with the wiring scheme from Phil's idea of the modular boards with 7 LED's each.. This firmware would work with those boards if Phil decides to make a run of them. You can set the fall_count variable to the number of LED's you have.. i.e. four modular boards chained together you would want to set it to 28. Also if you used my original wiring scheme and my original firmware you could set the same variable to any number of LED's if you didn't want to wire up all 56 LED's.

[kychristmas]

Thanks Cory. Is based on Phil's schematic or his Board layout he later posted. To me, it looks like that Pinout changed significantly when he layed out the second version of his board. I have created a board design to home etch myself based on his schematic, but I don't think it will work. Traces are too close together. I may try to etch one on Monday night when I return from the Rivercamp.

[chelmuth]

It was based on This (http://www.doityourselfchristmas.com/wiki/images/b/bd/LEDancer_LED_Module.PNG) Image where input line 1 rolls to line 8 on output.

[P. Short]

It was based on This (http://www.doityourselfchristmas.com/wiki/images/b/bd/LEDancer_LED_Module.PNG) Image where input line 1 rolls to line 8 on output.

That is true of both PCB designs.

Is it this one http://doityourselfchristmas.com/forums/attachment.php?attachmentid=10375&d=1306105196

or

this one http://doityourselfchristmas.com/forums/attachment.php?attachmentid=10381&d=1306257774.

The first one was 7" long, and had the cathodes connected to pin 1 of the input connector. The second one is 6" long, and has the cathodes connected to pin 5.

Since the second one is even harder to understand than the first one, I'm going to see if I make things work with the first design (compressed down to 6"). The problem that I had with the first one was trace width/spacing. If we go to a PCB coop, the best thing to do would be to go to a two-sided board, and bypass all of the trace width/spacing issues.

[chelmuth]

It was the First where all LED's were tied to line 1.. I like first one better.. Double sided would be cleaner. Ourpcb.com had some really decent pricing in quantity for my 2cm x 50cm design. I bet they would have some decent pricing for your design too. I mean we are probably talking 1000+ boards. for 10 fullsize tubes it would be 80 boards. So I'm sure it'll add up quickly.. especially with people wanted 20+ tubes.. I know I want to have 48ish tubes when i'm done. Maybe a discussion with budude about his manufacturer since he's close to having several board runs I believe. All this together would make a nice offsite Co-op all LED's, boards, PICs at one stop..

[P. Short]

Here is a newer version of the board. It's pinout is the same as the first board in the above post. The trace width is .020", which I think is adequate, and the trace spacing is .015" (except where the traces go underneath the left LED and the dense spot at the bottom of the board).

http://doityourselfchristmas.com/forums/attachment.php?attachmentid=10406&d=1306604796

10406

[P. Short]

Also, I wonder about the practicalities of implementing this as a flex strip, rather than as a PCB.

[chelmuth]

Phil, your image is broken.. My hand made ones with the Rear Protection diffuser are fairly flexible. It seems I read on one of the PCB sites they made flexible PCB's.

[P. Short]

The image is visible here, I'm not sure what the problem is.

[P. Short]

I cleared the cache, now I can't see it either. Let me re-upload it.

[P. Short]

Is that better?

[P. Short]

Advanced Circuit seems to be able to do flex circuits, except they won't let me get a quote. The other question is whether you solder to them, or they are just intended as inter-connects.

[chelmuth]

Perfect.. They look good..

[chelmuth]

Here's a short video of 4 of the tubes running from Vixen Via Ren48LSD.. http://vimeo.com/24368648

[budude]

Wow - that is really nice - I've still got a bajillion red LEDs left over from my LEDTriks - hmm...

[CaptKirk]

RED snow? That would just be wrong... ;-)

[ErnieHorning]

RED snow? That would just be wrong... ;-)Just wait, next year there will be RGB tube and then it will be OK.

[tweist]

Cory or Phil

Any chance of a CO-OP for these. I love all the work you guys have put into it, and if it was a co-op buy I could actually build some this year.
If not, thats ok, I will just have to wait until next year to make some.

Thanks again for all the hard work, even thou we all know you guys love playing with this stuff.

[P. Short]

Cory or Phil

Any chance of a CO-OP for these. I love all the work you guys have put into it, and if it was a co-op buy I could actually build some this year.
If not, thats ok, I will just have to wait until next year to make some.

Thanks again for all the hard work, even thou we all know you guys love playing with this stuff.

Which boards are you thinking of? AFAIK Cory is not using any PCB, just hand-wiring.

As for my designs, any possible coop is at least a month away, as I'm waiting to receive some SuperFlux LEDs. That would be the earliest that a coop could start. I'm not sure that I would want to run the coop myself, though.

[kychristmas]

Let's let their work progress without any pressure. When the time comes, I would be happy to run a Group Buy for Boards and LEDS. For Cory's FAST tubes, I think the boards would just be the LED Strip Segments though. My guess is when it settles out, their will be separate, but related Group Buys for each component and BOM.

I was already discussing the possibility of a Group Buy for the LEDs with TJ.

BTW... For Cory's FAST tube brains, I would recommend building them using some Perf board. You would be surprised how cheap and easy it is. Although I have home etch version for the brain portion, I have made two FAST Brains using Perf-board and other than a little bit large, they are excellent and easy. I would also recommend playing with the setup using the hard-wired method. For my protos, White LEDs from a standard LED string.




Which boards are you thinking of? AFAIK Cory is not using any PCB, just hand-wiring.

As for my designs, any possible coop is at least a month away, as I'm waiting to receive some SuperFlux LEDs. That would be the earliest that a coop could start. I'm not sure that I would want to run the coop myself, though.

[dlovely]

Let's let their work progress without any pressure. When the time comes, I would be happy to run a Group Buy for Boards and LEDS. For Cory's FAST tubes, I think the boards would just be the LED Strip Segments though. My guess is when it settles out, their will be separate, but related Group Buys for each component and BOM.

I was already discussing the possibility of a Group Buy for the LEDs with TJ.

BTW... For Cory's FAST tube brains, I would recommend building them using some Perf board. You would be surprised how cheap and easy it is. Although I have home etch version for the brain portion, I have made two FAST Brains using Perf-board and other than a little bit large, they are excellent and easy. I would also recommend playing with the setup using the hard-wired method. For my protos, White LEDs from a standard LED string.

So not to duplicate efforts... Altho not publicly mentioned, I was planning on running an off-site group buy for the Ren48LSD, Ren4Flood and RenFlood. Cory had mention getting any boards that came of this added since I already have the lead work done with and LED supplier. Samples have been ordered and sent to Brian for testing with his Floods. This is not the same supplier as Todd used, its a direct manufacture due to the fact Todd's supplier changed parts on him I wanted to find a MFG source to reduce change surprises. The parts for these (LEDs and PICs) are common with the above and Cory had mentioned that he uses the Ren48LSD as the triggering board I figured I could add these boards and LEDs to the off-site buy if there is interest and save people some shipping if interested in multiple items. Would also help get the White LED numbers up... Or the Red LEDs for Brian's new Red Snowfalls...

[chilloutdocdoc]

I've thought about this a bit, and would anybody be scared of using an SOIC package 16f688 instead of a DIP? It could save about half the space. I'm seeing a mini board that has a SOIC sized Pic, a 2 pin screw down terminal, an 8pin pin header (right angle?), 8x 1206 resistors, and a 5 pin ICSP header. All of these are sized so that they could be soldered by hand with regular soldering iron as I've done multiple times before.

Any thoughts? Maybe the board could be designed to be compatible with Phil's setup or Cory's?

[P. Short]

My controller also uses transistors...the SOT23 parts are a bit smaller and more difficult to solder by hand (although I do it all the time).

[CaptKirk]

Or use the electric flat grill surface mount method to solder down the SMDs... very easy.

[chilloutdocdoc]

That it does, but it adds a bit of investment in monitoring temperature, and controlling the heat and all that good stuff :) I just hand solder everything, down to LQFN.

[CaptKirk]

Actually, most cheapo electric flat grills just get hot enough to melt solder paste, so if you watch for the paste to go from dull to shiny and then turn off the grill at that point, you tend to NOT overheat things. It is WAY simpler than trying to surface mount by hand- everything SMD solders at the same time. You do need to design with all surface mount stuff on one side (through hole can be either side and is obviously soldered after the SMD stuff...), and I think a solid ground plane (or power plane) on the opposite side of the board from the SMD devices helps get the heat to the SMDs. I've done it!

Kirk

[jrock64]

I still like my coffee/candle warmer and embossing gun.
http://www.youtube.com/watch?v=oEDB70bN7M8
Very easy to control which parts get heated.

Joel

[Blackbeard]

jrock64,

Do you have an explanation anywhere of what you're actually using and how you use it, please?

[jrock64]

Always looking for converts.

http://doityourselfchristmas.com/forums/showthread.php?15092-DIY-Hot-air-flow-SMD-%28rework%29-tool post #6

Joel

[kychristmas]

I had not spoken to Cory and you certainly have the PCB Mfg connections. I wasn't trying to takeover anything at all. Mine started with some exchanages with Todd about a source for RGB and White LEDs. While I knew there were some issues with Pinouts changing, he did not express dissatisfaction with the supplier. You may be better than me for all of it. My concern with Direct MFG for LEDs is the lead time and qtys required.

I purchased 3 additional 48LSDs from your last group buy. These are specifically for running Floods, Strips and Specialty things such as the Snowfall tubes. So I'm in for whatever you are willing to brew.

Worst case, I assumed I would just get the LEDs myself and then go with some sort of oversized Home-etch version for the LED strips and the "FAST Brain"


So not to duplicate efforts... Altho not publicly mentioned, I was planning on running an off-site group buy for the Ren48LSD, Ren4Flood and RenFlood. Cory had mention getting any boards that came of this added since I already have the lead work done with and LED supplier. Samples have been ordered and sent to Brian for testing with his Floods. This is not the same supplier as Todd used, its a direct manufacture due to the fact Todd's supplier changed parts on him I wanted to find a MFG source to reduce change surprises. The parts for these (LEDs and PICs) are common with the above and Cory had mentioned that he uses the Ren48LSD as the triggering board I figured I could add these boards and LEDs to the off-site buy if there is interest and save people some shipping if interested in multiple items. Would also help get the White LED numbers up... Or the Red LEDs for Brian's new Red Snowfalls...

[Skunberg]

Looking at the resistors they are in order.. 1-8 .. I used the same pins as the channel outputs for the renard software as I was originally going to mod some renard code but decided against it and rolled my own.. Maybe this schematic is easier to read?

Yes this colored version is easier to read and I can wire from it. But I don't know the correct order to place the LEDs. Am I missing something again?
I see pic pins 3and 13 go to led 1 which is top by the pic or bottom. Pic pin 3 and 12 to led 2. Pic pin 3 and 11 to led 3, ect ect to Pic pins 8 and 9 to led 28.
Is led 29 pic pin 9 and 8? Or pic pin 13 and 3? Or something else ? Or have I just had too much Lutefish?

Brian

[chelmuth]

Pin 3 to Pin 13 Forward Diode Then Reverse Diode on Same Pins
Pin 3 to Pin 12 Forward Diode Then Reverse Diode on Same Pins
Pin 3 to Pin 11 Forward Diode Then Reverse Diode on Same Pins..
Then when Down to the bottom of first column..
Pin 13 to Pin 12 Forward Diode Then Reverse Diode on Same Pins
Pin 13 to Pin 11 Forward Diode Then Reverse Diode on Same Pins
Then when done with that column
Pin 12 to Pin 11 Forward Diode Then Reverse Diode on Same Pins
Pin 12 to Pin 10 Forward Diode Then Reverse Diode on Same Pins.
Etc..

[Skunberg]

Thank you very much! I'm going to try to make three 56 LED four foot long.

[P. Short]

Cory says that he is tired of hand-wiring the FAST controller, so here is a proposed PCB design. This is a candidate for coop buys for this season.

Here is an image of the proposed board (0.8" x 1.5"):

10597

For reference, here are images of the LED strip (0.62" x 6.0")

10599

and the LEDancer controller as well (1.0" x 3.0"):

10598

Regarding the FAST controller:

1) At the moment all of the traces are on the component side, I intend to move them to the solder side.
2) basic trace width is 0.010" with .015" minimum spaciing (except for a few 0.015" traces).
3) pad size is 0.060", drill size is 0.028" for the IC, resistors and capacitor
4) pad size is 0.060", drill size is 0.036" for the connectors (I will investigate to see if this should be bigger).

You will notice that my general approach is to make the boards as small as I consider reasonable. A lot of the designs by other people spread things out a bit more, making it somewhat easier for newbies to handle and solder. Comments?

I am also thinking of making the LED-module PCB a bit wider, so that a standard 0.100" pitch connectors can be used. I'm not sure how important this is, since I think that most people will be directly soldering wires to the board, rather than using connectors. Again, any comments?

[chelmuth]

For all of you that have been following this and like me after 5-6 hand wired tubes is getting lazy.. There is now an interest thread to see if it's viable to do a co-op this season.

FAST / LEDancer Interest Thread (http://doityourselfchristmas.com/forums/showthread.php?16137-Interest-FAST-LEDancer)

[dmcole]

Cory:

I've reread this thread a couple of times and I don't think I can find an answer to this question:

I don't think I want tubes that are as long as you originally designed ... something more along 12-18 inches would work better in my display ... can I put a header board and two or three LED boards together and it will still work?

Thanks.

\dmc

[chelmuth]

Yes That was the idea behind the modular design. There are provisions in the firmware to set the number of LED's before repeating.. So if you wanted 8 tubes 18" you could get 8 header boards and 3 sets of the segment LED PCB's

[dmcole]

Yes That was the idea behind the modular design. There are provisions in the firmware to set the number of LED's before repeating.. So if you wanted 8 tubes 18" you could get 8 header boards and 3 sets of the segment LED PCB's

Thanks. I thought I'd read that somewhere but couldn't find the original post.

\dmc

[P. Short]

How does all this compare with doing a similar thing using one of the RGB pixel strings? I think that either one of the controller boards pictured above could (with new firmware) create the same effects using one of the pixel strings. I haven't been following the threads in the DMX section discussing the various controllers nor am I familiar with all of the different types of pixel strings available, but I think that it would not be to hard to create the effects that people here are desiring with just a simple controller similar to the FAST or the LEDancer controller. The controller doesn't need to be as fancy as those over the DMX section.

Just a thought, as I don't really have a grasp on the $ numbers for the pixel strings.

It has been a lot of fun working on the LEDancer controller and LED module, but I'm not sure this is the best approach, at least not until I know the numbers.

[djulien]

How does all this compare with doing a similar thing using one of the RGB pixel strings?

I think the only difference would be that you would not need the chipiplexing transistors (unless maybe the signal was being driven a long distance), and the output logic in the firmware would be different.

For example, a similar type of controller can drive a string of LDP6803 pixels, and from what I've heard those are vaguely similar to WS2801 pixels (SPI interface). Here is some sample code I was playing with a while back - sorry for the mess (it just uses bit-banging rather than a PIC with an SPI interface).

10603

EDIT: For larger pixels/strings, this can also be used to drive AC SSRs if you omit the resistor in series with the MOC3023 and maybe adjust the chipiplexing resistors to reduce the current flowing thru the input side of the optos.

don

[CaptKirk]

That solution would be quite a bit more "spendy" than this design which is designed to be ultra cost sensative (and mono-colored).

[CaptKirk]

I still like my coffee/candle warmer and embossing gun.
http://www.youtube.com/watch?v=oEDB70bN7M8
Very easy to control which parts get heated.

Joel

Ah but a griddle does not blow the parts all around requiring intervention with the needle-nose. I've never seen parts fly out of position with the griddle!!!

[Sloanhaus]

New to this thread but am wanting to do some of these at my parents house this christmas. Do these have to be connected to a computer, or are they basically set to do what you want. I really would like to be able to daisy chain them into a tree and not have them connected to a computer.

Thanks

Sloanhaus

[chelmuth]

Just apply 5v and they run.. no need for a computer.. they each draw probably about 30ma.. so a 1amp power supply would do about 30.. There is currently a group buy in progress for these that will be running for about the next 2 weeks..

Here.
http://doityourselfchristmas.com/forums/showthread.php?16456-FAST-Ren48LSD-Ren4Flood-DIYC-Flood-Offsite-Group-Buy

[dlovely]

New to this thread but am wanting to do some of these at my parents house this christmas. Do these have to be connected to a computer, or are they basically set to do what you want. I really would like to be able to daisy chain them into a tree and not have them connected to a computer.

Thanks

Sloanhaus

Yeah they will work without a computer. Cory you should add a config parameter to the firmware so you can configure different delays between 'falls' so they are not all identical when run without a triggering device.

[Sloanhaus]

Alright, so if I am running an extension cord up into the tree, how will they connect to that extension cord (I am a retard when it comes to power)

[n8huntsman]

I too would be in for some of these if there was an easy way to make them fall randomly. I dont have time or money to build a controller for this year...

[chelmuth]

The extension cord would have to connect to some sort of Power Supply that produced 5 Volts DC...

n8 I plan on making a firmware that does random. I just havn't worked out the code yet, but it's possible..

[chelmuth]

Double Tap.. I mean Post.

[jmksparks]

I was thinking of ressurecting an Olson and run them direct ( no ssr ) you say approx 30ma each, this should be within the capabiltys of an Olson per channel would this be correct. ?.

[barbotte]

all i am planning is running a pc power suply .. conected all of my tube to it let them run from dust til dawn ... as i cannot see myself trying to run a sequence to them as they will go down randomly anyway ...way easier that way ...
cheer

[dlovely]

I was thinking of ressurecting an Olson and run them direct ( no ssr ) you say approx 30ma each, this should be within the capabiltys of an Olson per channel would this be correct. ?.

I can't get the Wiki to load this morning to see if it has a per-channel recommendation, but the ULN2803 data sheet says 500mA total, so 30mA per channel with all 8 channels on is only 240mA.

Also, you have to consider if you have indicator LEDs installed, those could add another 20mA. So it would be ~50mA/channel pushing the chip close to its max.

[jmksparks]

My version of the Olson is the one in the file library with the indicator LEDs run of the 595s ( before the ULN2803 ) so its looking good. As for leaving them going, I think in my circumstances people would assume the ( SHOW ) is about to start. Plus I like the idea of complete radomization through programming. Sorry I cannot get the Quote,s to work this morning.

[dlovely]

Someone had asked in the chat about triggering these, and the Ren48LSD has been mentioned, but if you are only looking at a few tubes the Ren4Flood will work too. I just confirmed with Brian that not installing the regulator and jumping the in/out of it will allow a 5v input/output. This would give you 4 channels, with up to 4 tubes on each channel.

[cobraman44]

Any chance a 595 board would directly drive 1(48 inch) of these? I was planning on using a DCSSR but I could save that for something else and I could control each tube separately.

[dlovely]

Any chance a 595 board would directly drive 1(48 inch) of these? I was planning on using a DCSSR but I could save that for something else and I could control each tube separately.

Each strip draws about 25mA regardless of size, as only 1 LED is on full at a time... You may need to add some wiggle room if you add things like a tail ect. Anything that can source that can drive the FAST strips.

[chelmuth]

Actually even with the tail only 1 led is ever on at a time. :)

[lizard050]

any plans for this to be able to do rgb in the future? Thought about just putting 2 or 3 strips with different colors in one tube.

[chilloutdocdoc]

It's possible to do an RGB, not sure if anybody has the plans to do it though. To do it easily, it would have to be done with something like the 5050 RGB led's because they are really the only ones that have individual anodes and cathodes.

[P. Short]

Snowflakes are white.

[chilloutdocdoc]

Snowflakes are white.

So were icicle lights.. until people decided to use multi lights :/

[Skunberg]

Snowflakes are white.

I've seen gray snowflakes in New York .... and in Alaska with the northern lights they sparkle different colors of the rainbow (not a common sight).

Brian

[budude]

I've seen yellow snow... :cool:

[ErnieHorning]

Those radio active snowflakes in Chernobyl probably weren't white either.

Some of the coolest looking snow in my yard was covering Christmas lights. :D

[cobraman44]

I've seen yellow snow... :cool:

Sorry... That was me :)

[LabRat]

Oh.. now you've got me thinking about embedding RGB modules into an "ice rink" on the front lawn...

[djulien]

To do it easily, it would have to be done with something like the 5050 RGB led's because they are really the only ones that have individual anodes and cathodes.

Actually, it's fairly easy to use 4-lead RGB LEDs with charlieplexing as long as they are arranged correctly. The individual R, G, and B leads all need to be in the same row/column, while the shared anode or cathode must be in a different row/column.

If you want to run the R, G and B all at max current then you'll need to group them appropriately (assuming your LEDs have varying voltage drops). OTOH if an average current is acceptable, you can mix them without needing to group them by color.

don

[aususer]

wouldn't RGB move this from being "affordable"? The PCBs would be 3x the size.. the controller 3x the price..

Be "interesting" to program as well - the PIC would need to have a specified programming for the "trickle" effect - unless you are planning to add three dmx channels (and associated electronics et al.) == $$$ F.A.S.T. has become BLOAT :D

Sounds like a whole new project teamsters! ;)

[lizard050]

Not knowing anything about pcb design or pic programming - I was thinking about ordering 60 of these and making 15 each of red , grn, blue and white to cordinate with the rest of my show when it goes throught the color cycles. Then I thought surely some of the smart people here might just come up with a way to get mutliple colors in one tube for less $$ then the 60 seperate tubes. Just thinking/wishing out loud.

[chilloutdocdoc]

Not knowing anything about pcb design or pic programming - I was thinking about ordering 60 of these and making 15 each of red , grn, blue and white to cordinate with the rest of my show when it goes throught the color cycles. Then I thought surely some of the smart people here might just come up with a way to get mutliple colors in one tube for less $$ then the 60 seperate tubes. Just thinking/wishing out loud.

I personally don't see any RGB coming out of my area, i don't think cory has any plans to either. I'd say go with your aforementioned idea, or consider RGB pixels and/or strip.

my $.02

[djulien]

wouldn't RGB move this from being "affordable"? The PCBs would be 3x the size.. the controller 3x the price..

I think it depends on how much control you want over the LEDs, which color combinations are needed simultaneously, etc.

There are various ways to add RGB. For example, if you only need one color at a time, it only needs 2 more control lines to get RGB instead of monochrome (per segment). I think I read that the current FAST firmware only turns on 1 LED at a time, so that limitation would not be a problem in this case.

I guess it also depends on the type of LEDs. For example, 5050 RGB LEDs are pretty small so they would probably not increase the PCB size. The 4-pin Piranha-style RGB LEDs are the same size as the monochrome ones, so the same would be true for those also. OTOH, if using discrete R, G and B LEDs, then I agree that would increase the PCB size significantly.

don

[djulien]

What would be the desired number of pixels in an RGB version? (would it still be ~ 8 groups of 7, or some other quantity?) Would it only need to light a R, a G or a B, or would you want a color mix between R, G, and B?

Also, would it only need to light up 1 pixel at a time, or allow multiple pixels to be lit at the same time?

(sorry if this is straying off topic; it seemed related)

don

[lizard050]

Many displays include waves of color just using red, green, blue and white. So I was thinking of snowtubes that could be included with the color 'waves'. Or just waves among the snowtubes if there were enough of them in one tree. I wasn't so much thinking about color mixing. I like the idea of just applying power to a tube and the effect is created as designed. Simple and a lot of bang for your money. I also liked the idea of turning 1 channel on and getting the snow fall in white, then turning another chanel on and getting the snow fall in red, ect.

[djulien]

Many displays include waves of color just using red, green, blue and white. So I was thinking of snowtubes that could be included with the color 'waves'. Or just waves among the snowtubes if there were enough of them in one tree. I wasn't so much thinking about color mixing.

If you only want one color element of one pixel at a time, then the controller I/O pins can drive the LEDs directly as they do now (with a series resistor). OTOH, if you wanted to mix colors or have more than one LED on a time, that would require the addition of chipiplexing transistors - that's a minor change to the controller side of things and wouldn't increase its cost or complexity substantially.

I'm thinking that 90 RGB LEDs running off a 24-pin or higher PIC might be a good arrangement here, say 6 modules of 15 LEDs each connected in series like how the current version does (see first attachment for an example). If not that many are needed, then a smaller PIC or fewer I/O pins could be used.

EDIT: yes, 6 x 15 seems to work well:
http://doityourselfchristmas.com/forums/showthread.php?16955-Addressable-Dumb-RGB-Pixel-String-(Charlieplexed)


Attached is a schematic for 6 x 15 RGB charlieplexing, with notes for fewer or more LEDs. (second schematic; I had to rotate it to fit within the vBulletin limits, sorry about that). I didn't include the controller schematic, because it's basically the same as what is already documented, just more I/O pins.

don

[CaptKirk]

Cory,

Hi, I've been trying to proto a quick fast controller to try to test out my hand built versions of the tubes but I've run into a bit of trouble generating working code. I cannot get the PIC to control the LEDs. I've verified that I followed the FAST controller board layout from the WIKI by taking the PIC out of the chip then jumpering ground to the PIC output controlling pin 1 of the LED tube then jumpering +5 to the other 7 output pins one at a time and I CAN light the LEDS in proper sequence that way. I am obviously not handling the source code properly.

I downloaded the random version of the ASM code from the WIKI and loaded up a project in MPLAB X (the new one) and loaded up the code. When I tried to initially compile it complained that the CODE and DATA sections were not indicated. I added a CODE statement at where I thought the code started. After that it gave me a bunch of warnings on the codes about proper bank selection for the variables being set. I was NOT able to resolve that but it will still generate a HEX. Using MPLAB to program, nor alternatively using the PICKIT2 code to program the resulting HEX file will NOT result in any blinky. Any ideas what I am doing wrong?

One STRANGE thing is that I followed another WIKI on wiring up a program port for a PIC16F688 but the PIC is not recognized through that connection, but the PIC IS recognized and programs through the ZIF socket that I bought with my after market PICKIT2. I verified that there are no shorts or missing connections. Something really weird going on- do I have the wrong PIC16F688 dips??

THX, Kirk

[mlkren]

I just compiled the 20110813.asm file in MPLAB v8.66 and had no errors. I did not change anything in the asm file, just opened it and compiled it. Have to ask a duh question. Did you config device for PIC16f688 in MPLAB?

[CaptKirk]

Yes, the "wizard" to set up the project asked, and the box that shows the status of the project says 16F688. Good thought though- I could have "boinked" that setting easily. I wonder if the issue is the NEW version of MPLAB that I am trying. It seems to only have something like MPASMWIN (something similar) as the complier.

[rstehle]

Yes, the "wizard" to set up the project asked, and the box that shows the status of the project says 16F688. Good thought though- I could have "boinked" that setting easily. I wonder if the issue is the NEW version of MPLAB that I am trying. It seems to only have something like MPASMWIN (something similar) as the complier.

I have tried the new version of MPLAB on my Win 7 machine and it won't compile the Hex file properly either..............

[chelmuth]

Here are the .HEX's one standard and one Random.

[budude]

Here are the .HEX's one standard and one Random.

Can these be posted in the File Library (if not already) - they will get buried in this thread otherwise.

tx

[CaptKirk]

HEX files are not- ASM files are. I wonder what changed with the NEW MPLAB to cause the source files in the WIKI to compile improperly!! I am trying to figure out what needs to be changed... maybe someone smarter on PIC ASM can figure it out- I know X86 ASM but I am learning PIC now to try to "give back" with fixes, improvements and features on code...

[erm213]

I was able to compile both asm files in the Wiki with MPLAB and Win 7.

Erik

[CaptKirk]

Which version of MPLAB? I am trying out the new X version (in beta) and it whines like a french school girl when you try to compile Cory's code plus the HEX files do NOT work... Something strange going on there in that new version!!!

[erm213]

I have 8.70, and am upgrading to 8.76. Me thinks the beta version is the problem. File a bug report with Microchip. Also make sure that there isnt a setting like "Treat Warning as Errors" (or something similar) turned on. I did get a few warnings when compiling.

Erik

[budude]

Just tried 8.76 - compiled OK but got lots of warnings:

Message[302] C:\DOWNLOADS\FAST_SNOWFALL_TUBE_WITH_TAIL_(RANDOM) _20110813_.ASM 47 : Register in operand not in bank 0. Ensure that bank bits are correct.

The files are not in the File Library (neither hex or asm) - it would be good to put working .hex files in their in addition to your Wiki entries.

[chelmuth]

They're in the file library.. Coincidentally located here http://doityourselfchristmas.com/forums/dynamics/showentry.php?e=150&catid=6

:)

[CaptKirk]

I guess I should back rev MPLAB if the source should compile and run. I would file bug- I just do not know what to file. WHAT is the bug- that a file that happened to compile and work before does not now even though it does have warnings and is not a "clean" implementation (with segmented data and code and proper setting of the status bits)?

At least using the hex files from Cory showed my hacked together control is working and that I was programming the PIC correctly. I do want to play with the source so I will need to get a working development environment.

It would also be nice to figure out why my added program port does not recognize the chip in the Pickit programming utility (nor in MPLAB). Any ever get this working: http://www.doityourselfchristmas.com/wiki/index.php?title=PIC_Programming_Hints because adding that connector to a FAST does not seem to work (with or without the LED board attached).

Kirk

[chelmuth]

The warnings are just warnings, kind of a 'make sure' type of thing.. There is a line that can be added to ignore them I just didn't add it as I wanted to see any errors during compiling.

[ErnieHorning]

MPLAB X is supposed to allow multiple compilers, so you should be able to redirect it to use your 8.x version.

BTW, they skipped version 9 because they wanted to make a clear distinction between the old and the new methods. 'X' is really version 10.

[CaptKirk]

It would also be nice to figure out why my added program port does not recognize the chip in the Pickit programming utility (nor in MPLAB). Any ever get this working: http://www.doityourselfchristmas.com/wiki/index.php?title=PIC_Programming_Hints because adding that connector to a FAST does not seem to work (with or without the LED board attached).

Kirk

I think I just figured this problem out- I double checked Pickit pinouts and programming connectors and I found an issue in the WIKI. It says:

Pin 1 of Connector - unused
Pin 2 of Connector - Pin 12 of socket
Pin 3 of Connector - Pin 13 of socket
Pin 4 of Connector (GND) - Pin 14 of socket
Pin 5 of Connector (VCC) - Pin 1 of socket
Pin 6 of Connector (VPP) - Pin 4 of socket

But the Pickit connector is LABELED BACKWARDS in this description. It should read:

Pin 6 of Connector (Aux) - unused
Pin 5 of Connector (CLK) - Pin 12 of socket (RA1)
Pin 4 of Connector (Data)- Pin 13 of socket (RA0)
Pin 3 of Connector (GND) - Pin 14 of socket (Vss = 0v)
Pin 2 of Connector (VCC) - Pin 1 of socket (Vcc= +5)
Pin 1 of Connector (VPP) - Pin 4 of socket (RA3)

So I should just need to flip around the pickit connection and have it work "in target". I will verify tonight...

Verified- the WIKI is currently wrong as indicated.... I can program in target now.

Kirk

[CaptKirk]

I have MPLAB X behaving now- it is amazing how much better things work when the program port on a target is working. I've started playing around with Cory's source (thank you for providing it!) and I am starting to understand it. I have run into issues with what I think are likely the way I implemented my own spin of pshort's led boards. I have a "double" (2 x 7 led segments) wired up like the sechmatic on the LEDancer wiki page. When I run either the original FAST code, or the "random" one I do not get what I think is a correct "fall" and I need some ideas of what I may have done wrong. So if we label the LEDs 1-14, when the PIC is powered up, LED 1 lights then turns off, led 8 lights and led 2 lights, 2 goes off and led 8 quickly dims out, then led 3 lights and led 9 and they sequence down in that fashion. I have double checked that the LEDs are individually addressable (charlie-plexed) and I did handle the data line "shift" between the segments (but I may have screwed that up thinking about it now). I also found the "number of LEDS" setting in the code and I set it to 14 to match my curent experimental hardware but I only had two leds on each segment light and I think it was the last 2 on each segment (might have been the first 2 on each segment but it was late).

My questions are:

With the current source, am I supposed to have segement 1 (led 1-7) sequencing at the same time as segment 2 (led 8-14)?

Could that be the reason I am not seeing a "fade tail"?

Has this been tried on one of pshort's LED boards?

Kirk

[CaptKirk]

Cory,

First off, it looks like the CODE directive is needed in the source for later versions of compilers (and is likely just a warning on earlier) so you might want to consider adding it.

Next, playing with the code, I ASSUME you seem to have it set up for the eight Phil segments to operate simultaneously assuming they will all be used seperately. I will be running 4 "double" segments (14 leds in each segment) so I need to have the code think of the strips as four strips instead of 8- is there an easy way that I cannot see to do that in your code? I have even seen people talking about making one big segment out of all 8 segments so maybe handling 1x56 led segment, 2x28, 4x14 and 8x7 might be a good option (if you have not thought of that already). I do not yet understand the logic yet of the PIC code so I am having trouble comprehending how your code works. Any insight or ideas that you can share? THX. Kirk

[chelmuth]

Well you could re-arrange the order that the LED's fire in and instead of 1-2-3-4-5-6-7-8-etc. say you wanted 2 - 28.. still wire the first 4 segments in order then run a longer jumper wire from the bottom of the fourth seqment to the top of the next set of segments.. and then fire the led's 1-29-2-30.. you would only have a 2 LED's on each strip instead of the 4.. but it would work.. I think you're also mis understanding how people are planning to run 2 - 28 segments.. they are not trying to use 1 controller for both each tube gets it's own controller and you set the firmware to 28 led's.. you're trying to run 2 strips off 1 controller and that's not how it was intended.. the segments are modular so you can put 1-8 segments per controller for one tube effect.. not 1-8 per controller for 1-8 tube effects..

[CaptKirk]

One controller per tube is NOT what I thought ogininally. I was going for what I thought the "A" stood for in FAST where one controller and one 5V power supply would control 56 LEDs. I wonder if others are thinking the same thing as I? It seems like we should be able to make it work that way as I was thinking.

I've wired 4 14 led segments as if they were end to end. I woud like to fire off a fall sequence semi-randomly on each 4 segments. Right now with the stock firmware I have 2 LEDs firing on each segment about 7 leds apart on each segment (slightly staggered). If is not an unpleasant effect but I think it would look nicer if each 14 led segement had a single lit LED on it. I was asking advise on how your code is organized to make that change as I have not figured out quite yet how the tables affect the led that gets lit. I am willing to work on it as I now have the hardware but I need a little more info on how the tables are organized.

I also have not yet figured out how to get to work as a two segment single 14 LED fall- I usually end up with just 2 leds flashing back and forth.

Make sense?

Kirk

[chelmuth]

All four tables need to be in line.. The first table entry is just a place holder in the Random code. Ie.. line 2 on every table makes LED 1 fire.. The input / output bits are set by the tables StatusA and StatusC.. They are turned on by BitA and BitC tables.. Line 3 on every table makes LED 2 fire.. so if you want to re-arrange them you have to change each table equally.. if you move like 14 to line 5 in the table you have to do the same for each table. And I'm not sure how many people thought the same as you as Dave and I explained it to anyone who mentioned they were going to make shorter than 56 LED tubes and I believe most purchased accordingly. And I think the "A" still applies.. It might help to start with a single 14 LED tube and get that working with the code as is before you start modifying things. Then you can add a second 14 LED tube to the back end of the first and call tell the firmware it's a 28 LED tube and watch it fall through the first and jump over to the second.. then you can start modifying the firing order to get them both to fall at the same time..

[chelmuth]

Also another Idea might be to build the LEDancer Controller. it's DMX and i think might be more adapt to what your trying to accomplish..

[i_wannabe]

I have tried the new version of MPLAB on my Win 7 machine and it won't compile the Hex file properly either..............

I was having the same problems also so I uninstalled MPLAB from it's default folder (program files(x86)) and reinstalled it into C:\MPLAB and my folder for the firmaware is also in the C:\ directory now everything compiles nicely with no errors.

[ErnieHorning]

I was having the same problems also so I uninstalled MPLAB from it's default folder (program files(x86)) and reinstalled it into C:\MPLAB and my folder for the firmaware is also in the C:\ directory now everything compiles nicely with no errors.I had that same issue/fix with Vixen 2.5 but somehow it magically fixed itself.

[CaptKirk]

Cory,

Thanks- I needed the "secret sauce" to the tables. I am willing to reorganize them for my purposes. One thing that continues to confuse me is if on a single 7 LED segment, it is supposed to have a "tail" to the fall. It seems to me that for each equivilent 7 segement section that there there is only ONE LED lit and I would have thought at least 4 would be on at varying intensities. I am sure I have the right PIC pin to LED in the proper sequence as I have verified the PIC signal to PIN called out in the source and I have a match to the hardware I built. Any ideas there? I've also noticed that certian changes to the equates will cause the lit LED to be much dimmer than I think it should be- what parameters and what code affects that?

The LED dancer is an alternative, however, I want to just turn all these on with a single channel and not try to manually sequence a fall with DMX. Not sure Phil has the canned sequences implemented yet since the LEDancer project seems to be stalled. It is on my list to proto one (I have the parts, just spending my time figuring out your code and hand wiring my version of the LED segements (TIME CONSUMING!!!)).

BTW- made a great score at my HD over the weekend- I went in to get more of the 8' tube sleaves and they had two left but they had run a forklift into the bottom of them. I picked up 2 8' for $3!! You might check your HD if these bigger tubes will work for you.

Kirk

Kirk

[chelmuth]

If you look through the code down near the bottom there are 4 variables..
movlw d'255' ;Sets how many cycles before LED fires
movwf Dim10 ;Move W Register to Dim10 (Dimmest LED)
movlw d'75' ;Sets how many cycles before LED fires
movwf Dim25 ;Move W Register to Dim25 (3rd Brightest LED)
movlw d'3' ;Sets how many cycles before LED fires
movwf Dim50 ;Move W Register to COUNT (2nd Brightest LED)
movlw d'1' ;Sets how many cycles before LED fires
movwf Dim100 ;Move W Register to Dim100 (Brightest LED)

set the numbers lower for brighter and higher for dimmer..
you must also go down to the LED1, LED2, LED3, LED4 Subroutines and change them there also.

The original code was set to fall and have the tail on top.. if you're changing the order to do the first LED's on your "pseudo other" tubes the depending on how you fired off the LED's the tail would be sideways across the row of tubes. Say your table ends up in the order. LED1 Tube1 ... LED1 Tube2 ... LED1 Tube3 ... LED1 Tube4.. LED2 Tube1.. four LED's into the execution of the program. LED1 on Tube4 would be the brightest.. LED1 on Tube3 would be dimmer. LED1 on Tube2 would be dimmer yet.. and LED1 on Tube1 would be the dimmest.. Then the next cycle.. LED2 Tube1 Would be brightest and LED1 Tube4 dimmer then LED1 Tube3 Dimmer yet. LED1 Tube2 Dimmest.. and LED1 Tube1 Off.. In my head what you're trying to do would take a rewrite of the firmware and I'm not sure my level of ASM skill is there...

[CaptKirk]

set the numbers lower for brighter and higher for dimmer..
you must also go down to the LED1, LED2, LED3, LED4 Subroutines and change them there also.


Ah I was only changing the numbers at the start, not also down in the LED routines! I think a variable is in order here....



The original code was set to fall and have the tail on top.. if you're changing the order to do the first LED's on your "pseudo other" tubes the depending on how you fired off the LED's the tail would be sideways across the row of tubes. Say your table ends up in the order. LED1 Tube1 ... LED1 Tube2 ... LED1 Tube3 ... LED1 Tube4.. LED2 Tube1.. four LED's into the execution of the program. LED1 on Tube4 would be the brightest.. LED1 on Tube3 would be dimmer. LED1 on Tube2 would be dimmer yet.. and LED1 on Tube1 would be the dimmest.. Then the next cycle.. LED2 Tube1 Would be brightest and LED1 Tube4 dimmer then LED1 Tube3 Dimmer yet. LED1 Tube2 Dimmest.. and LED1 Tube1 Off.. In my head what you're trying to do would take a rewrite of the firmware and I'm not sure my level of ASM skill is there...

They may be sideways now. I effectively have a single 56 LED tube that just happens to be split into 4 pieces. I can hang it so it looks like one long segment however, I cannot seem to get a single fall out of it- I'm getting the 8 individual falls along the length of the 56 LED tube. I am obviously doing something wrong but I cannot figure what is wrong. Is the code supposed to handle stringing all 8 segements together into one large tube? If so how do I set your code to do it? Onec I get a handle on your logic, I am going to start tweaking it... Thank you for the help so far- I really appreciate the work you have done on your design and your help so far!!!

Kirk

[chelmuth]

Yes it's meant to have a 56LED fall.. That's the firmware that was posted.. It functions on my side.. are you saying that it only lights one LED on each segment? flip your LED polarity (read turn them around)

[CaptKirk]

That would be different from Phil's schematic! Could I just invert the tables instead? I have a bunch built following this schematic:

11180

Or in the wiki here: http://www.doityourselfchristmas.com/wiki/index.php?title=File:LEDancer_LED_Module.PNG

I am not able to just turn the LEDs around! Yikes!!

[chelmuth]

Maybe try a flat roll on the input connection.. ie .. pin1to8 .. pin2to7.. pin3to6.. pin4to5..pin5to4..pin6to3..pin7to2..pin8to1..

[CaptKirk]

When I do a flat roll of the connections, it snows upward. I have something really weird different from Phil's board implementation vs his schematic for the segments! I just cannot figure out what is changed!

[chelmuth]

well since you got the snow upward just reverse the order of the firing and you're done..

[LabRat]

Or just turn the LED strip over... ;)

[chelmuth]

Yes no one ever said your controller had to be at the top.. if you wire it right the controller could technically sit at the bottom too. lol

[dirknerkle]

It's a new piece of anti-gravity legislation that Obama is planning to announce tonite in his speech...

[Greg in Canby]

I've got some of these in the mail from the group buy . . . I am now HORRIFIED.

[chelmuth]

I think you missed the part where he built his own boards and is also trying to do something that they weren't designed to do. the code works with the pcb's..

[Greg in Canby]

I think you missed the part where he built his own boards and is also trying to do something that they weren't designed to do. the code works with the pcb's..

Whew . . . thanks, I did miss that part - - - life is back to good!

[CaptKirk]

No, I get the same multiple pattern as before just falling UP so no joy.

Lets be clear here- the hardware is capable of doing what I want, I just do not have code to do it yet. I need to find out from Phil how his segments are different from the concept schematic on the wiki to be able to change the sequence tables. My guess is people will want to do what I am doing to get the most cost effective "affordable" snow tubes. It makes no sense to put a controller on each segment for segment counts less than 8 and for me, a tube of 8 segments makes no sense either for a maximum snow fall effect. It makes a LOT of sense to be able to put two segments, then an 8 pin ribbon cable, then two segements, etc. That is what I hand wired up- it should work. It will work...

[chelmuth]

There might not be anything different on the PCB.. I may have flipped the LED's in my coding implementation of the design. When I verify this I'll update the wiki.

Large solderless breadboard (http://www.adafruit.com/products/443)

Affordable'er Super Snowtubes (http://doityourselfchristmas.com/forums/newthread.php?do=newthread&f=57)

[erm213]

No, I get the same multiple pattern as before just falling UP so no joy.

Lets be clear here- the hardware is capable of doing what I want, I just do not have code to do it yet. I need to find out from Phil how his segments are different from the concept schematic on the wiki to be able to change the sequence tables. My guess is people will want to do what I am doing to get the most cost effective "affordable" snow tubes. It makes no sense to put a controller on each segment for segment counts less than 8 and for me, a tube of 8 segments makes no sense either for a maximum snow fall effect. It makes a LOT of sense to be able to put two segments, then an 8 pin ribbon cable, then two segements, etc. That is what I hand wired up- it should work. It will work...

Hmmm, I supposed that having one controller for every 8 segments, whether 1 tube, or up to 8 would be a cost savings. The advantage of having a controller for each tube, regardless of the length of it is that it would be individually triggered, and the falling speed of each tube can be controlled. I suppose that could be written into the firmware, but it would be hard to configure. For me, I'll just get the extra controllers, as they are cheap enough, but it is always good to have options.

Erik

[CaptKirk]

Cory,

Again I want to thank you (and Phil) for sharing this design- it is WAY cool and will be a major part of my layout (both the coop boards and my hand-done ones). You have done a fantastic job with your design.

I do have a question- I see in different variations of the control board on the wiki where your pin one seems to change around. What is the final orientation? Is pin one off the R1 or R8? When I did my hand layout, I followed the schematic where pin one out was off R8. Did that change to the top or did you chnge it FROM the top?? I'm guessing pin 1 is off R8 now since that is how I wired up on my iteration of a single 56 LED segment (just broken up into 4 individual pieces), I get the correct direction of snow, (it just happens more or less simultaneously on what would be the 8 individual segments but with no tails and yes I implemented the "shuffle" on the signals)!

I've looked at the layout of what I hope is the current Phil Segment board and my hand wiring seems to match to your board layout and to Phils segment layout (assuming R8 DOES connect to pin 1). I could have screwed up the shuffle between my four segments but the shuffle on the first segment is correct and hard to screw up being hard wired like I did.

Lets look at thise like I have one large 56 LED, 8 segement snow tube with segements labeled 1 to 8 and on each segement I have LED 1 to 7.

My logic assumes pin 1 from the control board (from R8) goes to the common cathode (-) for LED 1-7 of the first 7 LED segment, then because of the data shuffle, that signal then becomes "pin 8" and controlls the Anode of the 7th LED on the second 7-LED segment. That goes on through the 8 segements.

I was a bit tricky becuase I wanted to bridge from the top of my first dual segment instead of off the bottom like the Phil segments, I needed to do a double shuffle from the top of each segment to the next which if my logic is correct simulates the data you would get off the bottom of the second segement in a linear arrangement.

If I am correct, then I should have a "single" 56 LED segemetn wired exactly like 8 of Phils boards, yet I still get all 8 segements firing off at approximately the same time (they are interleaved a bit). It looks like 8 LEDs are on at any time - one on each segement. What the heck am I doing wrong??!?!

It looks cool, but is not the effect that was intended.

Thanks for the help. Kirk

[Materdaddy]

Not sure if anybody has seen similar things in the commercial world, but a couple weekends ago I was in Las Vegas and saw these at the City Center. I immediately thought of the FAST tubes and snapped a quick video:


http://www.youtube.com/watch?v=h0QdBGnii1g

(Nast = Not Affordable Snowfall Tubes)

[P. Short]

At some point in the near past I made a change to the FAST PCB design and the LED strip design at Cory's request, moving pin 1 of the 8-pin connectors from the bottom of the board to the top. I don't remember if I changed the copper traces on the board or not, but the schematic hasn't been changed.

[CaptKirk]

I've rolled all the connections so my controller had pin one on R1 and the only thing that happens is I get the 8 "fall" l patterns going UP my tubes (I really need to try to get a video) which is exactly what I would expect if it I wired my hardware right but there was a software issue. I am really worried that when this stuff ships out Saturday, that there will be a flurry of issues- I am trying to prevent that issue. Fortunately if I am right, it will just be a simple sw tweak. (fingers crossed). If I wired up wrong then I can fix that also, but I cannot figure out what I might have done wrong at this point (but it is ALWAYS a possibility!)

[kychristmas]

That shouldn't be a problem because of all this was Prototyped before going to production. Or at least I thought it was.


I've rolled all the connections so my controller had pin one on R1 and the only thing that happens is I get the 8 "fall" l patterns going UP my tubes (I really need to try to get a video) which is exactly what I would expect if it I wired my hardware right but there was a software issue. I am really worried that when this stuff ships out Saturday, that there will be a flurry of issues- I am trying to prevent that issue. Fortunately if I am right, it will just be a simple sw tweak. (fingers crossed). If I wired up wrong then I can fix that also, but I cannot figure out what I might have done wrong at this point (but it is ALWAYS a possibility!)

[CaptKirk]

Ah so the big question is has anyone actually wired 8 Phil Segments to a Cory FAST controller as one big 56 LED snow fall tube? If not, I wonder if when someone DOES do that, if they will see this same issue. I HOPE NOT but I can't see what I might have done wrong to cause this!! From all the double and triple checks that I have done, it looks like I prototyped it functionally like the designs intended and we have some residual effect of putting Phil's segments with Cory logic/sw.. Again I really HOPE I made a mistake but I am afraid that I am not mistaken. In that case this should be fixable in firmware so no harm/no foul!!

[CaptKirk]

Cory, is the firmware running on the 18" FAST prototype in your videos the same as the HEX you posted here? (if not can I get that?). It looks like you have wired up 3 Phil segements and can get them to fall appropriately across segments which I am unable to do. I'm wondering if the source for the Random version has a boo-boo in the table somehow (like a layout for your handwired one, instead of the Phil Segments)? Arr, its driving me nuts (on a side note: A pirate walks into a bar with a ships wheel sticking out of his pants, the bartender asks "whats up with the wheel?" and the pirate answers.... well you get the idea).

Thanks for putting up with me. Kirk

[chelmuth]

Let me just put all this to bed quickly, and be very clear about this.. The Prototypes of the FAST controller work with the prototypes of the Segment PCBs as displayed in the WIKI video. Additionally a full 56 LED tube has been made up from the production boards, not by me, and I'm told it worked like it was supposed to.... Let me be clear about this.. The FAST Controller wired to the Segment PCB's coming from the group buy work together with the firmware in the Wiki. As soon as I have a production board in my hand I will wire it up, take photos, take video, update both on the wiki

Additionally the handwired Prototype video, the 3 Segment Prototype (Purple Boards), are all using the same firmware that is posted on the Wiki

[dlovely]

I am really worried that when this stuff ships out Saturday, that there will be a flurry of issues- I am trying to prevent that issue.


I guess I have not been following this thread as closely as I should have been... I take it your sent out for the PCBs too or is this a home job? I built the "REAL" version when they arrived and they "FALL" just fine. I noticed one minor issue that I talked to Cory about, a flicker of a random LED, and he noted that he saw that before and is going to address the firmware when he gets his order.

[CaptKirk]

That is reassuring- I'll go back to hardware debugging my hand wired boards... thx.

[cobraman44]

I have a question after reading the Wiki. Can the Resisters that are in the group buy be used with the colors? I bought Red, Blue, and Green. I did not use white.
If not I want to get an order of the correct ones soon so I can build them. Thanks as always and I cannot wait to get these going this year. I think are going to be a hit.

[chelmuth]

The resistors in the Group buy work with White, Green, Blue.. The only one that would need different Resistors is Red. And I Think next size that would be common would be 82 Ohm for the Reds. Good Question.

[CaptKirk]

Cory,

I hand wired a second FAST controller based on your original layout drawing and another segment based on the orginal picture of Phil's original segment layout from the wiki figuring I had screwed up my original builds. It does EXACTLY the same thing as my original hand builds. I now see that the new segement picture on the wiki is radically different from the original pic you had there AND the concept schematic. That could explain my difficulties- I assumed the picture matched the boards being provided in the COOP. Do you have a schematic for the actual board builds? Would Phil? I'd like to get that so I can change my segment board layouts to match the coop boards so I can just drop in my boards or use the COOP boards interchangeably.

I hope you can understand my confusion- it appears the board layout change never got translated to the info on the wiki (until recently). I was sure I had done nothing wrong, and it turns out I had replicated that inaccurate information perfectly. Sorry I suspected the code and frustrated you with my questions. I see now why we had such a disconnect.

Here is what I did based on the schematic and original Phil segment that appears to not match what was made for the coop:

Pic Pin Signal Resistor SEGMENT 1
3 RA4 R8 Common Cathode of all 7 LEDS
13 RA0 R7 LED1 Anode
12 RA1 R6 LED2 Anode
11 RA2 R5 LED3 Anode
10 RC0 R4 LED4 Anode
9 RC1 R3 LED5 Anode
8 RC2 R2 LED6 Anode
7 RC3 R1 LED7 Anode

For the next segment, what was controlling the Common Cathode shifts to be the Anode of LED7 on segment 2 and all the other signals shift around appropriately.

[chelmuth]

Dumb question but did you try what I first suggested and flip the orientation of the LEDs to see what that did?

3 RA4 R8 Common Anode of all 7 LEDS
13 RA0 R7 LED1 Cathode
12 RA1 R6 LED2 Cathode
11 RA2 R5 LED3 Cathode
10 RC0 R4 LED4 Cathode
9 RC1 R3 LED5 Cathode
8 RC2 R2 LED6 Cathode
7 RC3 R1 LED7 Cathode

[jklingert]

Hey Cory,
I just finished my first 4 ft FAST. It looks fantastic!!! Great job. Pretty simple to put together, just a lot of soldering. I need a bigger workbench....

Jack

[P. Short]

At this point I don't have a schematic for the board as it exists, that is something to put on my to-do list for when the schematic computer is setup.

Incidently, it appears that the resistors on the picture of the FAST board in the wiki are 100 ohms, not the 51 ohms that is described. Of course, it could just be my vision these days...

[CaptKirk]

Dumb question but did you try what I first suggested and flip the orientation of the LEDs to see what that did?

3 RA4 R8 Common Anode of all 7 LEDS
13 RA0 R7 LED1 Cathode
12 RA1 R6 LED2 Cathode
11 RA2 R5 LED3 Cathode
10 RC0 R4 LED4 Cathode
9 RC1 R3 LED5 Cathode
8 RC2 R2 LED6 Cathode
7 RC3 R1 LED7 Cathode

Yes, like I answered before, fortunately I used a connector between the control and the segement. When I flip that connector to reverse all the connections, the incorrect pattern goes UP. I get 8 segement sized falls upward instead of the 8 segement sized falls down (or two if I am just playing with one of my dual segements). There may be an issue causing the duplications between some of my sets of segments, but I should at least get a proper fall on the FIRST one of my dual segments.

Maybe I can explain this better- take two Phil segements together as one tube. You would have segement 1 with LED 1-7 and segement 2 with LED 1-7

As far as I can tell:
LED# Seg# State Chg
-----------------------
LED1 - 1 on (First LED on first segment)
LED1 - 2 on (First LED on Second segment)
LED1 - 1 off
LED2 - 1 on (Second LED on first segment)
LED2 - 1 off
LED2 - 2 on (Second LED on second segment)
LED2 - 1 off
LED3 - 1 on
LED2 - 2 off
LED3 - 2 on
etc.

On each dual segment there will be two LEDs lit 5 LEDS apart and sequencing down (or up if you reverse the connection). So obviously I am wired wrong from the actual segment design. But looking at the WIKI, the actual board is different from the layout picture just below (for example, the pin 1 of the Pirahnas are in different places, and traces are different in spots). It could be this went from a common cathod to a comman anode layout and I did not figure out the change. I need Phil's confirmation.

I am just really confused and I have quite a few of these things in various states of build and I need to nail them down to "mass produce" them (hand builds) so I appreciate any help...

Kirk

[CaptKirk]

Phil,

Did the final segement design change from common cathode to common anode like it appears from the picture of the board, or is it totally scattered around (it is really hard to see the traces with the whit silk screen in the picture!)

THX, Kirk

[chelmuth]

so you didn't flip the LED orientation, you flipped the orientation of the connector. which made them fire in the reverse order. nothing more.. if you want to reverse the high and low outputs in the firmware to work with your hand wired tubes.. might also solve your issue without flipping the LED's around..