True - but then, won't the visualization show it as flickering ?
In Curt's video, it was solid red.
ps : It makes sense that somehow FSD thinks its like a stop sign situation ...
Ah. This is my field, digital signal processing. We may be looking at an aliasing problem.
Thing is, in DSP, when one samples, it's kind of important to sample (in theory) 2X as fast as the highest incoming frequency present. (Official name: The Nyquist Limit.) People who do this kind of thing for real with, say, digital oscilloscopes, typically sample at 3X or 5X the incoming frequency. A 1 GSa/s 'scope is typically rated for 200-250 MHz bandwidth. One can play silly buggers with this (Re: so-called, "Communications Analyzers"), but the general rule is at
least 2X sample rate. Another obvious example is basic, POTS telephony: The audio sample rate is 8 kSa/s, but, to prevent aliasing, the audio before sampling is typically
analog filtered to 2.5 kHz or so before the digital sample. (This is one reason why men tend to sound better than women on POTS phones; their voices are typically pitched lower.)
So, what happens if one samples too slowly? That's where it gets interesting. This is complex, but bear with me, here.
Suppose one has an analog band-pass filter with resistors, capacitors, and such, and no sampling. Take a sine wave, slowly increase it in frequency, and, once one has passed the low-frequency edge of the bandpass filter, the filter passes the signal on through. Then, as one keeps on increasing the frequency of the signal, one hits the upper limit of the bandpass filter, the signal gets attenuated. And, as one goes to infinity on the frequency, the filter continues to kill the signal.
Now.. what if one is sampling? And there's no analog front end filter? Say one is sampling at 100 kSa/s and the digital bandpass filter is, say, between 1 kHz and 2 kHz. So, run the sine wave into the sampler, get digital numbers. Run the digital numbers through the digital filter, which is running at 100 kHz clock frequency. Take the output of the filter (still binary numbers, mind you), and run it into an digital-to-analog converter, also running at 100 kHz.
Start running the frequency up. Nothing below 1 kHz or so; signal gets through at 1.5 kHz; gets attenuated starting at 2 kHz. So far, so good. Now, keep increasing the frequency of the analog input. Keep an eye on the binary numbers after the sampler. Here's where it gets weird: When the analog signal passes 50 kHz,
the binary numbers start looking like they're a sine wave dropping in frequency. This is the aliasing that I was mentioning. When one gets to 98 kHz which, if things were working like the designer intended, the signal wouldn't be present at all, at the output of the digital to analog filter, one will discover a 2 kHz sine wave, coming up in amplitude. At 98.5 kHz, it'll have a 1.5 kHz output at full strength; at 99 kHz, it'll start dropping again, just as if the input signal at that's at 99 kHz was actually at 1 kHz. At 100 kHz, the filter acts as if the incoming signal was at DC (0 Hz) and it doesn't pass.
It gets worse: At 101 kHz, it looks to the digital filter like it's a 1 kHz input and it passes through; at 102 kHz, it looks like a 2 kHz and passes through, and so on.
In theory, with ideal components, samplers, and so on, this repeats every 100 kHz ad infinitum. And this is why EE's building digital filters either put in anti-aliasing analog low-pass filters or sample at $DIETY's own rate where, for whatever reason, the frequency content of the incoming signal is never going to go.
It's not just laypeople that get tripped up on this stuff. I once had the joy and pleasure of explaining to a group of 10-15 or so EE's Who Shoulda Known Better that Aliasing Was A Thing; they were sampling at 1 Sa/s on a signal that had 50 Hz (and up!) signal components and were wondering why their whole highly precise phase locked loop was wandering off into never-never land. Some of them refused to believe me; I had to bring some rather specialized test equipment to their location, show their own people how to use it, then leave, lest I somehow make it fail on purpose. The light did dawn over there. Eventually.
So, back to blinking traffic lights. So, our heroes over at Tesla are trying, say, to detect a blinking red light. I have no idea how fast a blinking red light is supposed to blink; I suppose there's a standard somewhere. Let's say it's a nominal 1 Hz (0.5s on, 0.5s off), and it could be as low at 0.5 Hz (1s on, 1s off) or as high as 2 Hz (0.25s on, 0.25s off).
But.. there is a sample rate. That's how fast the vision is sampling the visual input. Hm. Once every 20 ms or so? That would be 50 Sa/s. Oh! City power is at 60 Hz in the U.S.. Yeah.. if there's no analog filter up front (response time of the cameras to photons) aliasing might truly be real, here. Especially if the LEDs in the red/green/yellow light are either running at 60 Hz (16.666 ms), or some $RANDOM frequency set by the people who built the lights.
And this problem would show up
only if the internal sample rate of the Tesla just happened to be on a harmonic of the blink rate of the light. Whee!
Yeah, bet that's it. And it's going to be a bear to fix.
Um. How does one send a message to the development team at Tesla?
saneryee-studio.medium.com
