Slow down my light sensor?

Hello everyone. One of my current projects needs some help. It's an LED signal bar for my car. Rear window mount, inside, WS2812's, Nano, 5V, mounted with 3D printed brackets and magnets.
I've added a light sensor(TEMPT6000) to vary the brightness. One level for daytime and a reduced level for nighttime. Here's the code snippet:

sensorValue1 = analogRead(lightInPin1);
Serial.println(sensorValue1);
outputValue1 = map(sensorValue1, 0, 400, 0, 500); //Using HiLetgo TMT6000 sensor

if (outputValue1>125){
BrightVal=255;
}
if (outputValue1<100){
BrightVal=100;
}

The sensor is very sensitive and so are the read values. Very fast reaction. My problem is, I don't want the LEDs basically flashing with the quick changes in value. Like passing through the shade from a tree for a moment in the daytime or passing under a streetlamp at nighttime. With my desk lamp, holding my hand over the sensor and varying the light(like clouds?) can hit a point where the bar strobes. Is there a way to slow down the read value, or the reaction time of the updated brightness value? I thought about keeping this snippet in the setup and have it set once when the car is started, and that's of course still an option, I just wanted it a little more active, to react to dark foul weather, tunnels, etc.



I would try reading the light sensor once every 10 seconds or so and save those readings to an array. Average the readings over say the last minute and use that to set your led's.

Hi,
I would do as @Hutkikz has suggested and add that you do not sample the ambient light while the indicator is operating.

Is that sort of display legal in your state/country.
What will be controlling it.
You aren't making a Cylon display or turning your vehicle into KITT? :smiley: :smiley: :smiley:

Here in Australia it probably isn't, and ANY flashing light HAS to be AMBER.

Thanks.. Tom.... :smiley: :+1: :coffee: :australia:

Thank you @Hutkikz. I'll have to research that method. I'm trying not to incorporate any delays into the program; I don't have any yet. I don't want the brake light to illuminate when I take my foot OFF of the pedal etc. I have pots to adjust the steps in the for loops to set the on/off "delay", and sequential "timing" of the turn signals to match the cycle of the cars turn signals.

Thank you @TomGeorge. That would work for brake and turn modes, but the parking lights would be tricky.

The lights are legal in Massachusetts as "auxiliary indicators"; can't contain emergency colors and cannot strobe. Lately MA has been a bit loose on DOT stuff; I see purple or green turn signals, colored BMW style halos, and LED headlights in just about everything on the road.

Nope. No Knight Industries 2000 for me. Just tail, brake and reverse indication with sequential amber turn signals. I'm on the road a TON and have been rear ended 4 times in the past 3 years. The factory lights on my Acura TSX are small circles and not very attention grabbing. I'm also looking to make this as a saleable item as well.

Oh sorry, I'm controlling it with a Nano.

@TomGeorge ’s suggestion is the winner for me.
If you’re averaging light levels over 10 second intervals… at night time, if the ignition is off, and the park light should be on, just leave the lights on at reduced brightness…

Even in daylight, it may be preferable to dim the leds after 10 secs to not dazzle cars stopped immediately behind you.
Brake lights at night… bright for five seconds, then dim down as needed.

You’ve got a processor and lots of options, almost nothing is impossible.

1 Like
sensorValue1 = analogRead(lightInPin1);
Serial.println(sensorValue1);
outputValue1 = map(sensorValue1, 0, 400, 0, 500); //Using HiLetgo TMT6000 sensor

if (outputValue1>125){
BrightVal=255;
}
if (outputValue1<100){
BrightVal=100;
}

Firstly, why are you converting the value from the sensor twice?
And wasting all that data to choose just two brightness levels?
You can make your display adapt progressively to light conditions just by eg
brightVal = sensorValue1 / 64;

You also need to smooth the changes in value from the light sensor.
Use millis() to take readings say every second, and smooth the values using a simple "Exponential moving average" (EMA) algorithm such as
EMAnew = R * brightVal + (1-R) * EMAlast.

You can play with the value of R between say 0.01 which will give a VERY slow response; and 0.2 which will give a fast response.

Make sure your sensors will only pick up ambient light, not the headlights of the car behind!

1 Like

Care to translate that into useful integer arithmetic?

You never use "delay()" but you use millis().

What are those three large studs on the outside of the window? :worried:

1 Like

Thank you @johnerrington. I'm really excited at your post like that's exactly what I need! But at the same time, I don't know how to implement what you said. My code should tell you my level of rookie-ness in the coding world. I converted twice because I needed the 2 values/arguments no?
Would you mind elaborating a little bit more? I'd be ever so grateful to learn this.

Hi @Paul_B. The studs on the outside of the window are 18mm neodymium magnets in 3D printed covers. They're epoxied to the window to allow the interior brackets also containing an18mm magnet to attach to the window. The magnets are so strong I think I can get by with one side only containing an 18mm steel washer or 2.

@Paul_B

no. I think the arduino should be able to cope with those values as floats.
Also an EMA filter needs to preserve the precision of EMAlast. Of course you COULD multiply the values all up and work in LONGs ...

I thought they might be. :sunglasses:

With regards to the good advice to use some sort of moving average over a number of points, there are all sorts of ways of averaging of a set of values. Some simple, some complex,e.g., Kalman filtering, In addition, you might want to look into using a circular buffer. I have used averaging in a circular buffer to continuously monitor for motion detection with an utlrasonic sensor with a manually set threshold to trigger a response, The idea can get a bit messy to understand.GaryDyr/HC-SR04_motion_detection but with a bit of effort might help in your case as well.

1 Like

My thoughts are to average over 5 minutes and then never change more than 10%.

Also reductions can be fast but make increases slow and of small increments

=== [ edit add ]

if you want the light to be dynamic and change as fast as the surrounding lights. when you go into a tunnel, it would dim as it passes into the shade, and brighten as it exits into the light, the concept appears to be sound, but the audience is the human eye. the human eye does not react that fast, so your audience is not happy.

General Motors first LED lights had an off and on that was instant. when the brakes lights in the car in front of you went out, it was so fast as to be disturbing. they added a delay to mimic the incandescent lamp so it dims over a few ms.

1 Like

@dave-in-nj I totally agree with you about the audience thing. I will experiment with a few methods that are mentioned here. The sampling thing is key. I just don't want when the parking lights are on which would have the bar at 40%(at night) then pass under a street lamp and immediately switch the bar to 65% giving the initial appearance that the brakes are applied. I like the idea of the incandescent fade too!

When you get to that point research knight Rider fade
Or cylon led. Shows how to fade up or down. Linear to the human eye.