I have used the candle code but it just flickers the pins, not PWM. I am using BS1 and want a single LED to ramp up and ramp down at random speeds, over and over again. How would this look in BS1, thanks soo much for your help with this
Attached is a circuit you can add to your Stamp to give you PWM control over the LED's brightness. The minimum PWM value that will cause the LED to illuminate is around 30. This is because of the 0.6V drop between the base and collector of the transistor. The current through the LED will equal (Vbase - 0.6) / 220.
If you need more current (brighter LED), decrease the values of both resistors proportionately and increase the cap value.
If you need to do this to a whole string of LEDs, you can connect them in series and apply a higher voltage to the anode end of the string. They will all draw the same current, based on the value of the emitter resistor. Just be sure that the voltage between the transistor's emitter and collector is kept low, so the transistor doesn't overheat — or worse.
Here's a sample program that works on the BS2 for randomly flickering the LED's brightness. You should be able to adapt it for the BS1 and build from there.
' {$STAMP BS2}
' {$PBASIC 2.5}
led PIN 0
rand VAR Word
DO
RANDOM rand
PWM led, rand // 225 + 30, 25
LOOP
Here is a BS1 program to take the brightness on a random walk.
symbol chance = w1
symbol delta = w2
symbol bright = b6
bright = 128 ' half bright
random_walk:
RANDOM chance
delta = chance & $1F - 15 ' delta is -15 to + 16
PWM 0, bright, 1 ' dwell for 5 milliseconds at each brightness level
bright = bright + delta ' change brightness random amount
GOTO random_walk
It might be more interesting to bias the statistics toward longer runs. Light level perception is somewhat nonlinear, and is perceived in relation to ambient light, so PWM output would better take that into account by enforcing a minimum limit for duty and by taking larger steps within higher brightness levels.
I think you can hook the LED and series resistor directly to the Stamp pin to control the brightness with PWM.
If it works, it works. I used the transistor to provide a higher-impedance to the low-pass filter, in case there were gaps between successive PWMs, which would cause the LED to blink. The filter/transistor combo bridges these gaps and also permits the use of several LEDs in series when powered by a voltage higher than 5V.
-Phil
P.S. to Tracy: Watch out for over/underflow with your random walk.
haunteddansion said...
I have used the candle code but it just flickers the pins, not PWM. I am using BS1 and want a single LED to ramp up and ramp down at random speeds, over and over again. How would this look in BS1, thanks soo much for your help with this
Actually it is PWM it's just random intensity ramping up then random intensity down and ramp speed rates are also random - It's intended to imitate a candle.
I re-read your post your looking for this:
'LED connected in series to Pin 0 with 470 ohm resistor
' {$STAMP BS2}
' {$PBASIC 2.5}
Ramp· VAR Byte
speed VAR Byte
x···· VAR Byte
result VAR Word
DO
RANDOM result
speed=RESULT // 16 MIN 1
FOR x=255 TO 0 STEP speed · PWM 0,x,300
NEXT
PAUSE 100
FOR x=0 TO 255 STEP speed · PWM 0,x,300
NEXT
PWM 0,255,1000/speed
LOOP
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun
TR
Post Edited (TechnoRobbo) : 9/20/2007 2:30:46 AM GMT
Hi Phil, I see what you mean about the under/over flows in the random walk. Mod 256. The effect is not bad, a flickering, but I see that flickering is not what hauntedmansion wants. The request was for a BS1 program, and I am so rusty with the syntax that i wouldn't want to hazard anything more elaborate. Leave that to the efx-tek pros! I see what you mean about the transistor and the filtering and increased drive. The gaps between PWMs are not really a problem though. The millisecond or so is bridged by persistence of vision, not perceived as a gap. AC lamps flicker at 120 hertz , and we don't notice, but it can easily be detected by instruments, even the intensity variations of incandescent bulbs at that frequency.
Here is a variation on TR's approach (also on a BS2). Instead of a linear increase and decrease, it uses a proportionality, successive multiplication by */ a factor near unity. The rationale is to sort of match the logarithmic transfer function of the eye. The visual impression is rather different.
chance VAR WORD
delta VAR WORD
level VAR BYTE
upDownLED:
RANDOM chance ' random variable
delta = chance & $3f MIN 5 ' scale factor
delta = delta + 256 ' as */ multiplier
DO
PWM 4, level, 5 ' dwell for 5 milliseconds at each level
level = level */ delta + 1 ' scale level up (1 is necessary against lockup)
LOOP UNTIL level>200
RANDOM chance ' different rate down
delta = chance & $1f MIN 2
delta = 256-delta ' for decreasing level
DO
PWM 4, level, 5 ' dwell for 5 milliseconds at each level
level = level */ delta - 1 ' change down random amount
LOOP UNTIL level<10
GOTO upDownLED
Each pixel contains a Pic 16F688 processor which receives a DMX-512 data signal at 250,000 bps.
If you're not familiar with DMX, it's a data protocol used extensively in the theatre for controlling dimmers and moving lights.
The pixels each have a discrete address and only respond to their assigned portion of the data stream. The pixel also generates 3 channels of PWM at about 100 Hz.
I'm actually a bit proud of the code, as it was my first stab at writing anything in pure assembly.
Each pixel also has an RS-485 (differential mode) receiver. The pixels are daisy-chained with RJ45 (cat5) patch cables.
The DMX data signal is generated by a Pic 18F4550 which drives a matching RS-485 transmitter. It's fast enough that 512 bytes of data can be transmitted 44 times per second.
A group of people have been discussing the project on this forum:
Yesterday when I was searching for flame emulation code, a friend pointed me to this thread. For Halloween I plan to line the roof of my house (above the garage) with pixels. Hopefully they'll be emulating blue / purple / amber flames.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen
' {$PBASIC 2.5}
Ramp· VAR Byte
speed VAR Byte
x···· VAR Byte
result VAR Word
DO
RANDOM result
RAMP=RESULT.HIGHBYTE MIN 64
RANDOM result
speed=RESULT.HIGHNIB· MIN 1
FOR x=32 TO ramp STEP speed
· PWM 0,x,5
NEXT
RANDOM result
speed=RESULT.HIGHNIB· MIN 1
FOR x=ramp TO 32 STEP speed
· PWM 0,x,1
NEXT
Loop
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun
TR
If you need more current (brighter LED), decrease the values of both resistors proportionately and increase the cap value.
If you need to do this to a whole string of LEDs, you can connect them in series and apply a higher voltage to the anode end of the string. They will all draw the same current, based on the value of the emitter resistor. Just be sure that the voltage between the transistor's emitter and collector is kept low, so the transistor doesn't overheat — or worse.
Here's a sample program that works on the BS2 for randomly flickering the LED's brightness. You should be able to adapt it for the BS1 and build from there.
Happy haunting!
-Phil
It might be more interesting to bias the statistics toward longer runs. Light level perception is somewhat nonlinear, and is perceived in relation to ambient light, so PWM output would better take that into account by enforcing a minimum limit for duty and by taking larger steps within higher brightness levels.
I think you can hook the LED and series resistor directly to the Stamp pin to control the brightness with PWM.
PWM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
-Phil
P.S. to Tracy: Watch out for over/underflow with your random walk.
I re-read your post your looking for this:
'LED connected in series to Pin 0 with 470 ohm resistor
' {$STAMP BS2}
' {$PBASIC 2.5}
Ramp· VAR Byte
speed VAR Byte
x···· VAR Byte
result VAR Word
DO
RANDOM result
speed=RESULT // 16 MIN 1
FOR x=255 TO 0 STEP speed
· PWM 0,x,300
NEXT
PAUSE 100
FOR x=0 TO 255 STEP speed
· PWM 0,x,300
NEXT
PWM 0,255,1000/speed
LOOP
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun
TR
Post Edited (TechnoRobbo) : 9/20/2007 2:30:46 AM GMT
Here is a variation on TR's approach (also on a BS2). Instead of a linear increase and decrease, it uses a proportionality, successive multiplication by */ a factor near unity. The rationale is to sort of match the logarithmic transfer function of the eye. The visual impression is rather different.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
The values Tracy included above are the same, I just had to re-organize everything to run on my processor.
Each pixel has it's own set of random numbers which drive the up and down fade times.
The processor is actually calculating values for 170 pixels but only displaying 19.
The first blue/purple section of this video clip shows the results:
www.youtube.com/watch?v=FF1YUCV_JAw
Thanks for a nifty bit of code!
John
Post Edited (JohnC) : 9/27/2007 8:09:47 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
If you're not familiar with DMX, it's a data protocol used extensively in the theatre for controlling dimmers and moving lights.
The pixels each have a discrete address and only respond to their assigned portion of the data stream. The pixel also generates 3 channels of PWM at about 100 Hz.
I'm actually a bit proud of the code, as it was my first stab at writing anything in pure assembly.
Each pixel also has an RS-485 (differential mode) receiver. The pixels are daisy-chained with RJ45 (cat5) patch cables.
The DMX data signal is generated by a Pic 18F4550 which drives a matching RS-485 transmitter. It's fast enough that 512 bytes of data can be transmitted 44 times per second.
A group of people have been discussing the project on this forum:
www.christmasinshirley.com/forum/viewforum.php?f=33
There's more detail about my project, including schematics and source code, at
www.response-box.com/rgblights.shtml
Sorry it's not strictly a Basic Stamp project.
Yesterday when I was searching for flame emulation code, a friend pointed me to this thread. For Halloween I plan to line the roof of my house (above the garage) with pixels. Hopefully they'll be emulating blue / purple / amber flames.