Looking for "Random flash" in a light

Arduinos always sounded fun, I just haven’t ever tried one. I’d really love to make an arduino floppy orchestra sometime:

An arduino would be a lot better platform if you want more than one “pixel” in the end result. It can drive a bunch of stuff from a single controller, to light up the entire work instead of just one piece. For a single flickering light though, a budget flashlight setup should work fine.

I am reading through all your posts and there is some very helpful impulses and links in there!

I am following your advice and will explore the Arduino route, it seems a bit more safe. (also more expensive though)

The ramping idea is great as well and I will see if I can incorporate it.

Lot’s of knowledge and awesomeness in this forum, cheers to all of you!

Good luck and don’t forget to bring your results back to share, both with the Arduino and with the project overall. As you can see we are at least a little bit interested :wink:

It’s all a matter of time these days for a DIY’er such as yourself. Arduino Pro Mini is OSH and available from China in the $2-3 shipped range - so it’s really just a matter of whether you’ve got time to play with the thing. (FWIW you do need a UART interface such as the FTDI ones in order to talk to the thing, but we’re still talking about <$10 to get started if all you have is a computer and a soldering iron.)

This thread inspired me to make some heartbeat effect... It's greatly inspired by hours of listening to the heartbeats of our children right before birth (cardiotocography), sometimes with the pulse rate going up (usually when the baby moves), sometimes down below good values, which always made my own heartbeat rise... (Fortunately we didn't have much of those... My implementation has more of them.)

It's random, but not as random as the examples above. I sort of shaped randomness to get a less erratic, more organic effect.

-> Youtube

Nice one, a double ramp up/dn. I agree that randomness can be overated for certain things. Say, like RGB color effects, beyond 20-30 colors the differences become imperceptible, at least to my eyes.

Nice, it looks like a heartbeat mode could be fun. :slight_smile:
I think I’d probably make the bpm a little less varied though, to make it more of a relaxing mode instead of encouraging people to get all stressed when it goes fast.

The “heartbeat” on my current light simply makes a brief flash (1ms) twice per second. I might need to make it longer to make it appear brighter, since the effect is a bit weak outside on the road.

I’ve enjoyed the self-ramping strobes though. And it’s kind of fun to walk around in the dark with a 10Hz or 24Hz <1ms strobe. It makes me feel like I’m watching a movie, since life appears to be made of individual frames.

Also, I think I need to get a 4-color XM-L in a host with an e-switch and perhaps try to hook up a MCU with more space. It seems like a lot of fun to play with. I’m not sure, but I think the attiny25/45/85 should fit onto the driver board RMM sells, if I can manage to solder well enough to swap a single chip.

The pads on those boards are for 150mil chips. The 85 isn’t available in 150, only 205. I think the 45 is available in the smaller package.

Someone here posted that you can bend the legs of the 205mil package underneath the package and treat it like a leadless 150mil package.

Thanks! I was just trying to answer that for myself… wasn’t sure if the physical size was compatible or not.

I think a 45 would probably be fine. I mean, all the libc functions and general overhead I’d want are like 700 or 800 bytes, meaning I’d only have ~250 bytes of usable space on the attiny13 but I’d have more like 3300 available on the attiny45. That’s effectively 13 times as much room to grow!

(I could reduce the overhead, of course, by writing smaller versions of what I need… but it’s nice to avoid reinventing wheels)

Then again, I haven’t even picked a host yet. And it occurs to me just now that the attiny45 might not have enough pins to support both the color XM-L and an e-switch. (or perhaps it has just enough? LED 1/2/3/4 PWM, switch, voltage ADC, VCC, and GND?) It also occurs to me that it may not be able to do PWM for more than one or two LEDs at once; I think it has two counters, not four. Hmm.

The Attiny 25 is the one that has the SSU 150 mil SOIC package AFAIK.

Oops. I’m on the road and didn’t look, sorry.

While we’re on the subject, I want to encourage the use of 8k MCUs so we can implement a bootloader. Take a look at micronucleus for example. We’d use a disable jumper or similar of course.

Be aware that the ADC bandgap reference select bits are different in the tiny13 and tiny85 series chips…

The Tiny bootloader project handles PIC’s and AVR’s under 100 words Tiny Multi Bootloader+ / Discussion / Tested Devices. I used this inexpensive USB to ttl Serial adapter to program a PIC16f1822 after the bootloader was downloaded by a PICKit 2. The ATtiny 25, 45, and 85 also look to be supported.

With the tiny bootloader the RST pin can be toggled on the PC side. The PC software would need to re-juggled for a much quicker timeout though for flashlight use. The project is active and the developer(s) seem responsive to requests.

Rather than a timeout I’d recommend a jumper. I know of at least one bootloader which can be configured that way, tinysafeboot.

I did a shorter one some time ago so you don’t even have to include delay_basic.h. I basically just ripped out one of the assembler loops from delay_basic.h. The variable entered does not resemble a nice even millisecond value, like 1 or 10 ms or similar, but I don’t need exact millisecond numbers, I only have to adjust the value until I like what I see.

By the way, how did you post your code? It looks like code, when I try to paste in my code it looks like garbage so I post images instead. How did you get it formatted nicely like that?

Did you try how much smaller program does your variant produce? I faintly remember doing some experimenting back then and didn't notice any significant gain. Then again, I might have been too tired and done something wrong..

The code stays together (after multiple tries) by using advanced editor and "Preformatted" style (left to the Font Family drop down).

To be honest I am not sure how this stuff works. When I replaced the original _delay_ms with my delayms in my firmware version that has it used six times I save a total of 48 bytes, but when I test with a real simple piece of code with just an increase in output and one delay, I loose a couple of bites. Both projects optimized for size. I think it’s a bit weird… I guess results can very when projects are optimized for size, and the compiler can switch between #inline and not as it pleases. I wouldn’t have a clue what else it does when optimizing for size.

If you’re not using the advanced editor, it’s easy to just use the ‘pre’ tag.
<pre>
(insert code here)
</pre>

As for the size differences, I’ve noticed a couple things… First, the default delay function seems to get inserted inline every time it’s called, so the size increase depends on how many places in the code it’s called. If you call it more than a couple times, switching to a regular non-inline function is almost guaranteed to save space. But if it’s only called once or twice, it might be smaller to use the default.

Second, the default delay function seems to change in size based on the value of its parameter. I think it may compile different versions for different delay values.

In any case, I’m pretty happy with _the_'s version. It’s smaller for my purposes, can be tuned so it’s more accurate than the default, can be easily modded for sub-millisecond delays, tends to produce cleaner code overall, and generally just seems like what the default should have been all along.

Hey Dr. Jones, this heartbeat looks very nice!

Would you mind sharing it’s code? and describing the double ramp effect?

I have moved my project to Arduino and am working on a solution over there.

I am using a sonar sensor measuring the distance of an approaching person or
object from 16’ away ($32 sensor) and want the heartbeat to change from regular
to erratic as the sculpture is being approached.

I am using a 12v battery which is recharged daily by a 30w solar panel with 7amp
charge controller to power the whole thing.

I also became a member at Crashspace, an interesting hacker collective in LA with
lots of knowledge and a space that is setup pretty impressively.

Thanks again :slight_smile:

I cleaned it up a bit...

The double pulse is just a ramp up, half a ramp down and up again, then back down to 0.

Nice idea to react on visitors, an anthropophobic statue :)

//NANJG driver, dynamic heartbeat mode

#define F_CPU 4800000 //use fuses low:0x75 high:0xff
#include <avr/io.h>
#include <util/delay.h>

uint8_t rand() { static uint16_t random=1; random=(random>>1)^(-(random&1u)&0xB400); return random>>8; }

int main() {
DDRB=2; //define PB1 as output
TCCR0A=0b00100001; TCCR0B=0b00000001; //PWM setup, 9kHz
uint8_t tic=0, ticlen=100,ticadd=10,beat=0; //ticlen=100 gives a beat of 1s
while(1) { //endless loop
if (tic==0) {
//the dynamics go here… decide about this beat's length
beat++;
ticlen+=ticadd; //make smooth transitions
if (beat==5) {beat=0; ticadd=18+rand()%18-ticlen/5;}
}
tic++;
if (tic<=18) OCR0B=14tic; //double pulse
else if (tic<=27) OCR0B=14
(36-tic);
else if (tic<=36) OCR0B=14*(tic-18);
else if (tic<=54) OCR0B=14*(54-tic);
else if (tic<=100) OCR0B=0;
else tic=0;
for (uint8_t i=0;i<ticlen;i++) _delay_us(100);
}
}