God i love this channel.

This has all the fundementals of how engine management works for ignition timing.

These fans have two sets of magnetic poles on the rotor, every time north pole* passes Hall sensor you get tach signal (both sensor lines are tied to driver transistors, but only one output to tach line). I was not digging into timer interconnects of ESP32, but you could emulate PLL multiplier with two timers - one in input capture mode, measuring time between pulses - and one running faster, responsible for triggering LED refresh

This is the exact reason why I have kept my Wraith Prism RGB cooler for my Ryzen. There's a specific effect called Mirage you can set up to look like this.

That wheel shot was also a great example of rolling shutter, with one side of the wheel appearing to curve differently from the other

In 2006, a friend and I used this same concept to create a "propeller clock" for a microcontroller college assignment. We used an Atmega32 controller, a bathroom fan motor, a ruler, a photocell, and a battery. I programmed it in uC and my friend put it all together :). We got like B on the assignment. The most memorable part of this experience was that our professor at the time was sharing an office with an author of "Symfonia C++" which at the time was by far the most popular programming textbook in Poland :)

Small point: It is technically not "exactly one revolution per frame" it is one multiple of the angle associated with the objects order of rotational symmetry ..... unless you include the valve stem of course ;) If a wheel has four evenly spaced spokes then any multiple of 90 degrees rotation taking place in the same time period as a single frame will cause the wheel to appear stationary. Gotta love the spectrum!

Divide by 2 works because there is not enough time to process the LED drive in the time available. So halving the number of times, but still running in sync, will give enough time to output the data and still be above 30FPS. A thing to try is to have a loop in main running all the time, that simply times the revolution time , counting up the number of interrupts to say 254, and also using a hardware timer to get a clock, that is the number of clock cycles (probably will need a prescaler so that you have a counter with lsb being a few microseconds) taken to run, and then that adjusts the count timer to the new value per revolution. Now you no longer have to use interrupt from the fan, instead you use another counter that is counting down, and giving a software interrupt that runs the LED flash. This counter gets updated every 254 counts of the main timing loop, to be a time that will give the right number of cycles as blades per revolution. Should then run that code and still not exceed the time between interrupts. With a 9 bladed loop probably can get away with having it run 3 times per revolution as well, leaving more time to have that ADC routine run to read the pot, convert into a PWM value between 64 and 256, and set a PWM for the fan speed control as well. Going to be tricky, now we need at least 3 separate 16 bit hardware counters, but there should be enough in the ESP32 to handle it, though pin assignment will be tricky as some may not be easy to route, and you might need to actually have one or two actually go out and in again, but should be workable, as after all you do have a very fast core there. Not easy on a 8088, but doable, and there you can always add in extra counters till you run out of IO space, but you got entire message displays that ran with software running the multiplexing, on a 4.77MHz part, and they did not flicker except during scrolling, running low on memory because they only had a whole 2k of memory in there, plus another 2k of battery backed Dallas SRAM for the actual messages, which had 32 bytes for the RTC as well. Plus a thermometer that pretty much always showed that the CPU and board were getting well cooked, as the sensor was right next to the linear regulators.

Some have mentioned it already and I totally agree, to sync it with the blades it would need to be done with a Phase Lock Loop (PLL). I've programmed one before, but I talk to FPGAs using VHDL language. I would help code-wise but I'm not skilled in C++ at low level, and I despise dealing with interrupts, they disrupt everything else but them. FPGAs generate their own dedicated hardware for everything you make, like PWMs or Counters. Here's the basics: -run a 32bit Number Controlled Oscillator (NCO), it outputs the pulse at overflow -setting to 1 is slow for overflow -2^31, fast, every 2 counts, !aliases above! -Frequency is completely linear -calculate fan's frequency via the tach -set NCO 'close' if way off -when NCO is clocks, if fan clocks + or - -adjust freq a bit -adjust position as well, or it will be unstable the values for 'close', adj freq and position need to be determined for that project. This could be simulated in Excel, with nice pretty diagrams, if you know anything about that. Keep in mind, if you're pulsing n blades per tech, you need to compare offset once per ever n blades.

Dave, this stroboscopic effect can be dangerous if you're working around power tools. Back in the stone age when I was in college, we were told about a student working in the wood shop with other students and several machines running (i.e., loud). This student was using a table saw and the overhead lighting was made up of fluorescent tubes. The fluorescent tubes flicker(ed) at 60 Hz (here in the North America) and the saw's motor RPM was a multiple of 60. In short, he ended up cutting one of his hands off at the wrist because "his" saw blade appeared to him as being stationary and, due to the noise from other machines, he couldn't tell that his saw was actually running.

When I choose what to entertain a speaker, this KZfaq Creator is on my personal preferance list with recommendation to all others.

I Dave! This seems like a very good application for a Phase-Locked Loop (PLL). They’re used a lot in microcontrollers to multiply the frequency of the input clock signal :D they’re a weird concept to wrap your head around, though

The Friendly Giant reference...if you know you know!!!

This is quickly becoming my favorite channel, thank you for sharing!

It would be a lot easier with non addressable LEDs. You could use a 555 timer and an IR reflectance sensor to flash the LEDs when each blade passes the sensor.

We do this exact same thing with high powered light when conducting icing test on aircraft engines. It's way cheaper than highspeed camera both money and data wise and it also creates a better comparative image because it's "static"

Dr. Harold Eggerton developed this technique with Xenon flash tube to study synchronous motors nearly 100 years ago. He went on to develop several other high speed photography techniques to stop motion and also developed side-scan sonar imaging which later gave birth to the radar based equivalent.

Instantly thought of an ignition timing light.

An interesting problem and solution. I often wonder how long in "real" time you spend on a project. For me, a project like this becomes an obsession with a scintilla of anxiety, which consumes all my time until solved. Thanks Dave, I always appreciate and learn from your videos.

I have a small led torch that can be dimmed, presumably using pwm. When shone on pc fan, it freezes the motion! Don't be tempted to check with your finger it has stopped, it hasn't. Don't ask how I know.

Well, very nice...you are putting a lot of faith in the power company. Granted, VHF to them is like 60.2 Hz, but it does wander around a bit. It costs too much money to chase it very hard, so it IS going to wander. Ultimately they correct it based on time. Integrating the 60 (+-) signal over time and comparing it to a standard time is the reference. Love your work. Getting the book. Thanks for that too.

Used to love Top Gear UK episodes that matched framerate to wheel speed.

16mm & 35mm film runs at 24FPS. For V, projectors used a special shutter that displays every sixth frame, twice to give your 30FPS. I ran a lot of film on RCA TP66 film chain projectors in the '70s. This required the optical sound head to require a loop of film to provide a continuous feed for stable sound.

I love this geeky “just to see if I can” stuff! Thanks, Dave!

Corsair has this built into iCue. It's called "Time Warp." It's very cool!

Because this is matched to fan speed, it would be really cool to see a fan appearing not to move, but becoming more or less blurry as the speed ramps up or down.

This took me back to both movies and computer tech from when I was a kid, particularly learning about interrupts. :) We didn't have affordable ADCs in those days, but Atari did very well with their paddle controller inputs. The paddle was a variable resistor, a capacitor was charged through it while a fast counter counted how long it took to exceed a certain threshold. Every vblank, the charge was dumped and the charging began anew. It wasn't exactly linear, the voltage of a charging capacitor rises in a distinct curve, but it was good enough. Oof these latency issues with digital systems! ;) Back in the day, I tried and failed to get the hang of phase-locked loops, which basically do all this with entirely analog electronics. They have their own difficulties of course, they're basically PID controllers -- what were known as servo circuits back then. As such, you have to know what you're doing when you set them up.

Ambient light has an effect on your effort. I used to repair engine driven generators. I could set one to 60HZ without a frequency meter. I was using the building lights which were at 60HZ and rotating stuff would sync with those lights and the engine speed was correct. Can’t do that any longer as led and any fluorescent light now operate at 20KHz or other high frequencies.

A hack I've used to determine fan speeds (for determining if it's a 1 or 2 pulse tach line): get the fan up to a speed, blow on the fan while measuring the sound with a spectrum analyzer app on my phone to find the frequency, divide by number of blades, multiply by 60 seconds per minute to get RPM.

Hey Dave. Nice work. The leds are given data at 800kHz. That's 33k leds per second that can be refreshed. If you have say 30 leds, that means you can only refresh them about 1000 times per second. Your on-off will take about a millisecond. If you want to get a crisper still fan, you can take a "dimmable led strip" and use a pulse on the gate of a mosfet. You can then shorten the pulses as much as you like. When driven at such short pulses, once the software works "for sure" you can increase the current through the LEDs. LEDs will happily survive pulses of 8 times their normal current as long as they get to rest most of the time.... Consider using a raspberry pi PICO. For one, you can continually get the "latest period of a full revolution", by putting an interrupt on the rising or falling edge of the tach signal. Just call the us_since_boot function for that. Subtract the last two values, divide by 9 and you know when to set the next timer. That should make it auto-track. You'll see a bit of jitter WHILE the speed changes.

Excellent video! I did a similar thing back in the early aughts when case modding and LED fans were starting to be a thing. I worked how many pulses per revolution were sent out of the motor speed wire, used a binary divider to create one pulse per revolution and then a one-shot to flash the LEDs VERY quickly on each received pulse. Presto, stationary fan blades :-)

The issue is that the PWM signal to the fan motor is merely a suggestion for what speed to run. The fan motor generates its own AC phases based on some logic and presumably some kind of time source that may very well just be some cheap resonator circuit, I doubt that there's a crystal in the fan controlling its speed.

reminds me of old record players where the turntable has a pattern illuminated by a little strobing bulb to visually indicate when the speed is correct or drifting

Not only is this a cool thing to do, but the explanation behind how it all works is excellent. Concise, to the point and completely understandable! I would love to see more of these captivating experiments!

I would rather take a sort of PLL approach. Increment a counter to a target of many thousand to get a nice resolution and see at the next tacho pulse how far it got. At the tacho pulse update the led pulse values to multiples of the tacho counter/9. In the main loop keep track of this counter and flash the leds at the determined values. This method basically estimates the blade speed based on the last revolution, which is a good estimate. It is very easy code and keeps things constantly in sync.

Dave, I wish I had you as my neighbor, love your work mate! Stuart from Melbourne AU

Excellent fun project! Thanks Dave! I think I'd make the following changes. First, recalculate the frequency and restart the frequency generator far more often. Potentially every revolution, this would stop any drift. As long as the start is synchronized with the sync pulse you should get a perfect freeze. Next I'd buy more fans to find one where the LED's and more importantly the LED addressing logic chip can survive a higher voltage. Most LED's can handle much higher current if that current isn't on all the time. I believe it's LED heating that determines the maximum brightness/wattage. If you turn on the LED 10% of the time putting 10 times the current through it at that time will be the same power dissipation. But, whether the addressing logic will survive even a 2X higher voltage is an open question. But if you are able to find a fan where this works you could have the LED's be much brighter. And if you double there brightness, you could halve the on time. This would allow the blade to move only half the distance with the LED on. Thereby making the blades look twice as sharp. Now, whether you have any interest in pursuing this further, I have no idea. Personally, I always have more projects I either want to do, or am doing, than I'll ever be able to do.

Dave, I clicked on your video thinking "huh"? Turns out that was one of the most fun and interesting LED videos I have seen! Love your videos! Keep em coming!

I didn't realise until a couple of years ago that LEDs could strobe quickly enough. I used an Android strobe app to use the phone camera flash to check the RPM of my old Atari floppy drive. Just put a white mark on the spindle then set your app to run at the required frequency to match the desired RPM. If the drive is running at it's proper speed, the mark should be stationary.

Thanks Dave. Years ago I bought 2 white confuser fans that displayed a stable LED TEMP and RPM in the blades while spinning. ( I can`t find them anymore) 1 is still working good in my latest box. Shows the out flow box temp.

Dave you're the cool uncle I've always wished for!

That is really cool! Thank you for this and all the other great videos you're posting.

This would be an awesome Idea to implement a PLL...

This is really damn cool Dave, hope you do more fun projects like these!

wouldn't it be better to synchronize it the with the tachometer? Rather than just flashing on a timer based on rpm, it could flash on every second tach pulse then flash on the timer for the rest of the rotation. This would fix the issue where it appears to drift, as the cycle would reset at the same point of rotation. the reason to have it flash on every second tach pulse is because there are 2 pulses per revolution but an odd number of fan blades.

To confirm the number of pulses per rev, place a single mark on the fan (off centre), then run the one flash per pulse version of code: count how many places the mark appears to be on the "frozen" fan.

I really enjoy your content! Even if some topics are a little above my head in the beginning, I'm understanding by the end. Keep 'em coming Dave! Thanks again.

You would be a great science teacher.

If you have a fan without speed feedback, you can glue a small (eg 1mm dia.) magnet near the tip of one of the blades and a Hall effect sensor on the frame (JB Weld is your friend). If not enough output to switch digital levels you can use an analog input and count the peaks. Such a small magnet doesn't affect the balance significantly (I've used it on a 50mm dia. fan).

I can kind of get the effect you're talking about using Corsair ICUE. I use Marque with a deep red color at the slowest speed possible. It doesn't illuminate the entire blades of the fan. I'm also using an adapter that makes the Silverstone 160mm fans I'm using connect to icue. best $5 ever spent.

I used to freeze a disc centrifuge spinning at 8000rpm to let me watch particles sedimenting. Used a Xenon flash.

It seems like in practice you could dispense with the multiplication and division by 60 and make strobe_frequency equal to frequency * 4.5 (since you seem to be getting two pulses per rev, you can bake that division into the multiplication), for an ever so slightly faster code speed. Writing it out is better for the educative aspect though.

I used to have a fan that let you program anything you wanted it to say in the blades.... you could type anything in and it would display the texts on LEDs as the fan spins.

But the Partridge Family was more complicated than that because it was shot on film, so you'd be looking at that as 24FPS _under_ 30FPS.

You need a PID tracking loop to lock onto the fan cycle by cycle and freeze the blades. Measure how much time it takes to do your LED updates-that’s the limiting factor and thus the limit on your update rate. You could build this frequency multiplier in hardware so that it exactly tracks the tachometer but I know you’re not much on building hardware when you can write software… ;-) That’s a PLL and some digital logic…

Another approach is to set the LEDs to less than 100% white. The controller chip in the addressable LED will do its own PWM (presumably at a fixed rate). Use the fan's PWM input and tach output to get the fan speed to a suitable multiple/fraction of the PWM frequency.

7:45 I've made a few USB fan controllers, and AFAIK, it's divide by 2 because the fan has to be balanced. E.g. there's a hall effect sensor in the fan hub, and 2 small magnets in the blade section, if there was only 1 the fan would be unbalanced and vibrate wildly. As for documentation, there's the Noctua fan white paper which is pretty simple to understand and gives examples for resistor values and stuff; or there's the Intel fan specifications (might be confidential idr) which is very detailed and provides proper diagrams, oscillograms, and all that fancy stuff.

Short simple answer as to why there are two pulses per revolution is mechanically simple--balance. There has to be something to count while it spins, hall effect sensor or something. But 1 element would imbalance the fan, leading to noise and shorter lifespan and something Corsair would want to avoid.

Man you nearly implemented a PLL clock multiplier in software lol

Most fans have an pulse-per-revolution feedback channel in them. You could use that to stabilize the drift with some non-linear feedback shenanigans.

I still love that FG ending. Memories!

Very cool. I would add some code that re-calcs and re-tunes the LED Hz every X revolutions. Also, you may want to add in some set delay in the first step of your measurement calc to account for the clock cycles it takes to do the measurement.

One thing to optimize the code is that you only use the rpm when calculating the strobe freq. So combining the rpm calculation to the strobe frequency calculation you could omit the 60's because you first multiply by 60 and then right after divide by 60. Float numbers are rather slow to process even though it seems newer esp32's have some sort of fpu inside.

Really cool Dave, love it! I think my next mod would be using ir leds to detect the blade edge, though how much benefit it might achieve, I don’t know.

Great video as always. Outro brought back soooo many memories. Take care, eh!

You could use a PID to try and keep the rpm at a speed you want. PID controllers are fascinating and I think worth the time to show.

I had to scratch my head at the Friendly Giant reference, scanned my memory banks and remember Dave is Canadian , no wonder he grew up Autistic , as am I, fuck that Rusty the Rooster still creeps into my dreams.

Integrated strobo-tac! I just used a strobotac at work yesterday!

Such a awesome idea thanks Dave❤

The friendly goodbye at the end was awesome.... isn't that right Rusty?

7:50 I think fans typically have a ring shape permanent magnet as the rotor, and a hall effect sensor for the RPM pulse. It's possible that it pulses for both the North and South pole

I remember doing something like this at school with a rotating device of some kind and a strobe lamp, but we only used the variable rate control of the strobe manually to achieve the desired effect. Then I saw my dad’s circular saw appear almost static from the fluorescent lighting of the workshop! 😳

If you didn’t mind adding a bit of hardware to the solution, a phase locked loop and a divide by 9 circuit should let you go back to your original idea of triggering the light pulse on an interrupt and to dispense with trying to figure out the right frequency in software (which, as you said, is necessarily a bit of an approximation)

@Dave just leave the tach interrupt active and recalculate the rpm every x cycles. Also use is to resync on each pulse

Friendly Giant!!! I am also a Canadian of a certain age...

You could freeze it in two positions with 2 different colors. Or even make those two colors counter-rotate so it looks like for example the green fan is slowly spinning clockwise while the red fan is spinning counter-clockwise.

So a copy of the old AMD’s Wraith Prism RGB LED Cooler. They use multi RGB with different frequencies to make it more clearer.

Man…just, just…awesome!

DEFINITION ERROR! Hz = Period / 1s (1000000ms) Thanks for your great vids and for asking to look for an error. 😊

YES the chairs are back! Thank you for the chairs!

God Bless you, Davepl!

If you adjusted the led frequency you could recreate your tape drive effect, only using the actual fan blades.

I've always wanted to try this.

When evaluating LED red lights for traffic signals, in their first iteration, we took pictures to compare a standard incandescent lamp and the LED. Using a standard film camera. To the human eye, both were on, and appeared just as bright. (We had them in signal heads, in the air at the normal height, side by side.) When we developed the film, the LED appeared to not be on. Well, LED's are diodes. (The D in LED stands for diode.) Feeding a 120 VAC, 60 Hz power into a diode results in a half wave rectification. That means the LED light with all it's red LEDs were configured exactly the same, resulted in it actually being off in half of the 60 Hz cycle. The camera's shutter caught it in the off period. To the eye though it was fully on. Your eye has image retention, film, shutter in cameras do not. I had to explain that to the Traffic Signal Engineers who were confused as to why the LED signal appeared off.

In the calculation of rpm and strobe_frequency you can delete the "* 60" and "/60" parts of the calculation as they cancel out (unless you need the rpm value elsewhere in the code).

The problem is we treat time as an absolute reference when it's not. time is relative and so is Math. I would use a small sensor in the frame of the fan to detect the revolutions and trigger the light. My 2c.

Thank you Dave

Be it already known, but AMD/Cooler Master has software for the AMD Wraith RGB CPU cooler that does just that with the fan that can go from 45 Hz to 2 KHz with their Mirage feature. Pretty spiffy stuff if I say so myself!

I was expecting some leds mounted to the blades of the fan, much like the thing in Techmoans intro. But this was fun also. Interupt timing is a fun thing, and you may need to take the time for the division into account for the calculation to work.

If you time the RGB LEDs separately, you could make it look like three different-colored fans spinning independently.

I bet you could fix the drift issue by resetting the timer for flashing the leds once per rotation, or if you compensate for the different parts of the rotation, every interrupt.

yesterday was looking for code on how to control a pc fan with an esp32 and im a total noob soooo big thanks for the vid!

I don't ever understand anything in your videos. I just like them, so , I watch them.

Your math and logic are right on, but I suspect we might be neglecting the response time of the leds lighting up after being hit with the voltage. It seems to me that the latency thus caused would be what results in the “drifting” effect. Introducing a tiny correction factor might be possible.

I'm not sure if you do this in every video, but kudos for the Friendly Giant shout-out at the end!

Dave, i have a very simple way to freeze the fan blades in place, and it requires no wires at all. in all seriousness, this is great, i bet the guys at corsair would love to turn this into a product.

If the tach line is a hall sensor, it would be spinning a small magnet. Use two for a smooth, balanced spin. 😊

In reality its part camera frame rate part harmonics part persistance of vision all synchronizing. You don't even have to have the exact time. You can have an adjustable frequency on a potentiometer and simply dial it until it all synchronizes. And it you put a fine adjustment with a fast enough flash rate you can slow or speed it just slightly and it will look slomotion or go backwards even. All you need is frequency control of a strobe light source.

The algorithm could be more like a "real time" Frequency Lock Loop; or maybe it's better thought of as a Period Lock Loop. Ignoring for the moment any constants like "2", just measure the time between pulses and immediately adjust the setting for the PWM. Use a precalculated table if it helps speed thing up. The loop should track and update once per pulse / revolution. There wouldn't be enough time to see any drift. Also, ignore man-made units, and just work directly in CPU time (clock or whatever milli- or micro-seconds.)

woah.. this is really nice. i also like the effects from 1:30 😯