YouTube 'Flashing' traffic lights???

[Ah-Those-Old-Days!]

Often when watching many Youtube Videos of Traffic Accidents etc etc...
The actual 'video' clip shows Traffic Lights actually 'pulsing/flashing'. Ok,,,
I understand, that firstly, they are no longer actual resistive 'Lamps, but are now using L.E.D.'s
And i 'understand' about digital frame rates with camera etc... but I'm sure that they don't just
have 1/2 wave to the LEDS? I can't make sense of it?

[wotnot]

[Uncle Fester]

Those must be still old incandescent traffic lights on those videos, haven't actually noticed.

LED lights are powered with DC or high frequency chopped DC.
The 230V LED lights I took apart all have a diode and a filter cap so a fairly clean DC. The little switched mode supply inside them is clocked at a much higher frequency, where the harmonics are well picked up with an AM radio.

Those who still use 12V (LED or halogen) down lights will have an external emulated 50Hz pulse width modulated AC power supply for compatibility reasons but it makes no sense to do that with LED traffic lights. The cheaper 12V LEDs are internally filtered with a bride rectifier and a filter cap and the better quality have a tiny switch mode regulator too.

Nope, I see no reason for any flicker with LED lights other than a fault.

[wotnot]

You do realize these LED driver ICs operate at a switching frequency of 50kHz to 1 MHz in some designs?

[Uncle Fester]

You do realize these LED driver ICs operate at a switching frequency of 50kHz to 1 MHz in some designs?

Yes that is my point I made about them being clocked at a higher frequency.
That is way to high to create any low frequency intermodulation with 30Hz frame rates.

[wotnot]

..yes, and it extends to the image sensor as well.... 30fps does not reflect the actual scan rate of the sensor...

...I've actually got a 'coincidental' video example of this at play....err...'coincidental' in that it was video evidence to an ebay seller wrt some LED drivers I bought which were -supposed- to be all running @ 200kHz switching frequency (fixed internally), but when you get rid of human eyes pov and view them using a fixed scan rate image sensor, you can see (courtesy of the flicker) that each driver IC is actually running at a slightly different switching frequency....

I'll link the video in when I get home again....

[Uncle Fester]

In your youtube search they are referring to frame rate.
You are likely talking about something comparable to horizontal scan.
That will sometimes cause moire effects on a large surface under such pulsed lighting (although all decent illumination LEDS would have filter caps to avoid such effects) but getting a light to look like it is going entirely on and off at an optically visible frequency <15Hz like in the OP, means it would have to be pulsed or modulated with frequency relatively close to the frame rate.

[Ah-Those-Old-Days!]

(Delayed response, sorry...) Thank you to both wotnot and Uncle Fester for your detailed and informative comments!
Just to initially clarify, I wasn't referring to whole screen flicker, or 'banding', but purely in relation to the traffic lights alone.
I get what you have both been saying in latter comments, re: LED's being driven by high frequency chips, using the likes of
'Switching Power Supplies', with many kHz output, but I've found out somewhere that there is more to this tech observation!

Firstly though, there's a link at the bottom of this paragraph, to a YouTube tear-down of such typical LED traffic lights! I was
surprised that there is only about 8 actual LED's, in front of which there are 'Fresnel Lenses' & 'bubble-wrap' looking 'Magnifiers'.
I was also surprised that there was still the full 120v (USA!) on the wiring out to these lights! I thought it would be just 24v etc.
The reason being that all you have to do is change the light 'Head' when upgrading, and nothing else back in the Controller.
Of course, that means that there is a relatively complicated electronic control board, P/S needed within each light 'Head'...


With that in mind, it seems(?), (though not mentioned in the above video), that for safety reasons, loosing an LED due to damage
physically or within its PCB, that you can never lose more than 2 or 3 actual LED's at a time. Therefore 'groups' of LED's within the
'matrix' are driven individually, in a similar way that say a 4-digit 7-segment display is actually driven 1 segment at a time! And we
know what such digital displays can look like on video, as the inter-digit display frequency is really not that high, so it may flash!
Not sure if that is all true, but it would make sense...

[Uncle Fester]

Nope, that group of LED beads are driven with pure clean DC.
You can clearly see a simple 2-pole wire coming right off the large filter capacitor next to it's connector.
For group driven power you need more than just two wires.

They appear to be all in series like a typical mains powered LED bulb, so if one bead dies the lamp goes dark.

For redundancy I would have used 3 wires, so 2 groups of 4 in series, but that is clearly not the case.
Each group must be separately driven, so 3 wires with two caps and rectifiers as the forward voltage of each LED bead has tolerance.
You can not simply wire the groups parallel because one group would glow darker.
You can cheat with resistors(lossy with heat) but I see none.

However those low tech USA traffic lights are very different to ours.
Ours have a high LED count that are individually seen (no fresnel lens) and could be matrix driven to form also basic symbols like here:
,
So maybe ours are indeed scanning at a fairly low repetition rate to cover all the individual LEDs and creates flicker on videos with a similar frame rate.

I assume other countries have them too.
I would like to make a video while I am waiting for usually two minutes in front of a red light but there are cameras all over the place watching you if you pick up a phone so they can hammer you with a huge fine whilst 'driving'

[Ah-Those-Old-Days!]

Nope, that group of LED beads are driven with pure clean DC.
You can clearly see a simple 2-pole wire coming right off the large filter capacitor next to it's connector.
For group driven power you need more than just two wires.

They appear to be all in series like a typical mains powered LED bulb, so if one bead dies the lamp goes dark.
..........

Thank you Uncle Fester, and you are right. Don't know how I missed that!!
Maybe though, there are different technologies & brands/designs in various countries, other than in that video...
Thank you for your further explanation though that I surely needed!!

[wotnot]

Nope, that group of LED beads are driven with pure clean DC.
You can clearly see a simple 2-pole wire coming right off the large filter capacitor next to it's connector.
For group driven power you need more than just two wires.

They appear to be all in series like a typical mains powered LED bulb, so if one bead dies the lamp goes dark.

For redundancy I would have used 3 wires, so 2 groups of 4 in series, but that is clearly not the case.
Each group must be separately driven, so 3 wires with two caps and rectifiers as the forward voltage of each LED bead has tolerance.
You can not simply wire the groups parallel because one group would glow darker.
You can cheat with resistors(lossy with heat) but I see none.

However those low tech USA traffic lights are very different to ours.
Ours have a high LED count that are individually seen (no fresnel lens) and could be matrix driven to form also basic symbols like here:
,

So maybe ours are indeed scanning at a fairly low repetition rate to cover all the individual LEDs and creates flicker on videos with a similar frame rate.

I assume other countries have them too.
I would like to make a video while I am waiting for usually two minutes in front of a red light but there are cameras all over the place watching you if you pick up a phone so they can hammer you with a huge fine whilst 'driving'

Yep, depends on how the LEDs are driven, and what imaging sensor is being employed...wrt the video recording being watched that is.

I did a bit of digging (like yourself obviously...looking for clues as to how they were driving the LED discs, and how those discs are wired? =)....and it seems largely 'inhouse' design ..(typical)...and you'd need some visual babelfish to look at every country's design standards related to things like traffic lights....but here in AU, this is under AS/NZS 2144:2005, and one of the criteria is;



That's a tough biscuit using established 'older' LED driver circuits, especially when coupled with another para specifying that each LED element's luminosity (light intensity/time) must not deviate from stated value by more than 3%, so even if you had an 'active' LED chain (switched string), if you had a single LED element loss, you'd likely need to adjust voltage/current on that run, to avoid the good LEDs running too bright/hot...too much bother, right?...-and- you have to hit a minimum MTBF of 10years...

Looking around, the transport dept here in Qld, have gone with this mob - ...there's a vid there from Qld Transport & Main Roads ; the traffic lights don't flicker =)
Granted, one doesn't know what camera/image sensor they used and/or if any video post-processing has taken place....but you lean towards 'no' just due to the fact there's a lot of YT videos and the like, showing traffic lights not flickering.

So...they're doing it, but how?...you think - this a dedicated purpose (like automotive ICs), someone will be making an IC for this as well, dollars to donuts...so go fossicking about in industrial ICs and start finding wee beasties like this...



A 48 channel version LED driver, with individual LED fault recording and PWM control, and in some of the application notes it mentions the use of multi-junction LEDs on each output (instead of a chain/string) to achieve designs with long endurance/high reliability ...which could mean any application really, but certainly has to be part of traffic light designs. Like you say, newer systems are using 48v ELV power distribution, not mains 240vac out to the light posts/gantries anymore. Seeing as these sorts of ICs only started to appear around 2000 onward (previous designs were similar, but relied on discrete anode or cathode drivers)...

Typically speaking as we know, half wave mains rectification (or capacitive dropper/series resistor) flicker atrociously (but understandably =), but wrt image capture (video), the normal 'culprit' as it were, is the LEDs are being driven as part of an array in multiplexed fashion...to the naked eye, thanks to persistence of vision, the LEDs are being switched on/off too fast for one's eyes to see it happening..unless...

.... this is what I typed about earlier...a bit of preface -- what you see in the vid below, is 2 boards ganged together, each board comprising of 4 x 64 LED (8x8) modules, each module/LED matrix driven by it's own LED driver IC (the ubiquitous Maxim MAX7219)...the display scan rate of this chip (genuine Maxim manufacture) is...



...however, 'real' examples of this IC are $10+ per unit, whereas the knockoff max7219 IC is some stupid low price...ie; you can buy 3 or 4 of these modules, assembled, replete with IC & 8x8 LED matrix ..for the cost of a single genuine Maxim Max7219. Note in the image, they come with an IC socket ; there's a reason for that (they don't waste production $$$ including an IC socket without purpose =)...more on this later..

...now, you communicate with the IC(s) using a 3-wire serial bus, that can (or is supposed to) handle 10Mbit of bandwidth, and typically you just bit-bang the ICs with individual LED data/chip-select, however the max7219 has a ROM and a 'display test' function (turn all LEDs ON with a single command), and that's what you see in the video -- the MCU (either arduino or RPi, same result of course =) is just initializing test mode on all 8 driver ICs, not streaming LED data to turn everything on...and all LEDs should bit lit, equally...ie; 'display test'...(aka 'bulb check' in some CN datasheets 8)




To the naked eye, all but 3 of those 8x8 LED matrices appear(ed) as solidly lit squares of 64 red LEDs -- the 3 that were not like that, visibly flickered badly to the naked eye --- when I went 'wtf' and shot the above video, is when I saw what was going on with these elcheapo CN made chips ; the scan rates were all over the place.. I had a couple of 'real' max7219 ICs, and replaced the worst 2 chips with real ones, and hey presto, they started working fine (like the display far right in above video). When I got onto the ebay seller about the problem, they offered to send me replacement ICs..which I accepted..they sent me 10, I found 4 to be working within spec...I got to guessing that's why the IC socket was there ~ they had a whole pile of max7219 ICs of unknown quality, and had to check each IC to see if it actually worked =)

The 'correct' image visual recording here, would be/is the rightmost 8x8 LED module, with a single blank/black horizontal (row) line appearing to 'roll' due to differences between display scan rate Hz and that of the (synthesized) 60Hz video processing. The cause of this, is the way the max7219 does things with the column/row drivers...specifically, the column drivers are the current control, and the row drivers are switches on a 8bit register, and blanks 1 line because it has to be reset to the top - the column (current) drivers are on all the time at the PWM (dimmer) switching frequency.

Of course, the type of camera/imagining sensor used matters as well (and what DSP the sensor is connected to)..ie; some sensors are scanning at a higher rate than the frame rate, and the (over sampled) pixels are averaged ; you see artifacts of this on YT dashcam video versus not a dashcam video of vehicle brakes lights -- some visibly flicker upon video replay, others not...as much depends on the image sensor as it does the LED driver. For example, the image sensor used for the above vid has an actual (physical) resolution of 3264x2448 but it's the (video) DSP that sensor is connected to, that's reasonable for binning the pixels in a manner that results in 720P @ 60Hz...the actual recording above.

[wotnot]

An example of image processor at play ~ watch the following 20 or so seconds of YT video ; keep an eye on the high-mount center brake light of the white car stopped at the lights in the left lane ; watch what happens to the recording of that brake light just after the errant vehicle passes across in front of the dashcam's FOV ~ it flickers for a second or so as the image processor resets it's image sensor binning algorithm...

[Uncle Fester]

At first look I would have said that is just a faulty brake light because it happens only for one second, which is mysterious but if you look at the same time at the double traffic light on top of the Ford truck, the set on the right with the arrows is flickering the same way whole time while the other one for straight ahead does not.
This would indicate that the light showing the arrows is scanning at a refresh rate similar to the video frame rate and the flat round straight ahead light is either way off in the frequency or just running on DC.

I would say the brake light has a variable LED scanning speed. Never heard of the video frame rate changing. You set a camera to 30fps you get 30fps.
In this case the brake light should have flickered all the time with the traffic light, so the brake light must be inconsistent.

[wotnot]

Binning which is adding the charge of 2 or more pixels together can both increase signal to noise ratio (SNR) and frame rate.....I'll see if I can find a datasheet that details this stuff.