Can I Freeze a Fan in Time with its RGB Light?
HTML-код
- Опубликовано: 27 сен 2024
- Dave uses PWM lighting on an RGB fan to "freeze frame" a running fan in time. For my book on Amazon, check out: amzn.to/45kWPJC
Note: Contains flashing light elements.
Code: github.com/Plu...
God i love this channel.
I agree, me too. Dave is fantastic 😊
Same here! 😁
dave lets me finish edging
I, too, am autistic
I love the detail. I feel like I'm actually learning something.
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.
Same, when I was in high school, the machine shop equipment had incandescent lights for precisely this reason. 50Hz in Australia.
There was a demo of the lathe setup under a fluorescent light, the keyhole for the chuck appeared stationary.
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 :)
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.
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.
I knew I'd find the answer to this in the comments, and way more explanation. Thx
In reality you don't have to do all that for a short visual recording, you just need a strobe light that you can adjust the frequency with a potentiometer. You can litterally just dial in the speed until it looks right on camera. Also what looks right on camera may not be the same as what looks right to humans, the whole persistance of vision and framerate thing. It's easy to setup without even wiring anything to the sensors. It works as long as the fan stays at the same speed. If you change the fan speed you will have to change the rate obviously
This is not correct. The fans simply output 2 pulses (4 state transitions) per revolution. If you were to open the fan, you'll also see why, it's just the internal field phase control signal or alternatively the Hall signal because the motor is quad-pole, it's simply brought to the outside. Also a 2005 Intel PWM Fan spec says that they must output 2 pulses per revolution.
I can confirm that this is correct. The fan pulses twice per revolution.
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
And maybe reset the PWM timer on each second tach pulse too, to force it into alignment.
Even the PLL route would still be good with variable conditions.
When I choose what to entertain a speaker, this RUclips Creator is on my personal preferance list with recommendation to all others.
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.
Or just a sensor that turns on the led when a blade passes by, like a proximity or opto sensor
would this not unbalance the fan some?
@@PR0XYL1NKif you use an opaque fan blade there is no need for stickers or reflectors to unbalance the fan blade
@Sam-tb9xu nice thats good solve. thank you for the idea haha
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
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.
I played around a bit in the late '80s trying to do something with the flash out of a 110 camera. End result was 1 photo and a lot of broken light bulbs (my target). It would have helped if I knew anything about electronics at the time.
Edgerton, and the technique is called stroboscopy. Stroboscopy existed long before him, but he was the first to employ a flash lamp (which he invented) to do it
I love this geeky “just to see if I can” stuff! Thanks, Dave!
Used to love Top Gear UK episodes that matched framerate to wheel speed.
This is quickly becoming my favorite channel, thank you for sharing!
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 would be an awesome Idea to implement a PLL...
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.
You would need to do a closed loop regulation with the esp32 based on the 2 signals but it wasn't really the point of the project I guess
I had the same idea.
I think the best solution would be to detect the real speed rotation.
But if it works ... :)
PWM signal merely does rough work, high time (pull up resistor to 12V so it runs at full speed when not connected) simply enables the motor drivers, and they in turn are commutated twice per revolution by a hall sensor, to switch the 2 coils, the hall sensor output being sent back out on the tacho line using an open collector driver capable of sinking 1 LSTTL input load, or 10mA roughly, and this is the sum of the loop. PWM needs to be low frequency, under 50Hz, to get smooth speed control. The fan has a starter circuit, that is basically a pulse generated every second or so, that drives the one coil, if there is no tacho pulses detected for a second, which indicated a stalled fan. All done in one 6 pin package, which has all that on a single chip, largest area being the 2 current limited drivers, and catch diodes, and the hall sensor on the one edge of the die.
@@SeanBZAThanks for your very informative comment! 👍🙏
Just out of curiosity: how did you know, if I may ask?
@@Conservator. Taken more than a few apart.......
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.
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!
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.
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.
Wtf
Wouldnt the fundamental be a multiple of fan blade count?
@@RuddODragonFear Good question. I didn't say "fundamental" in my original comment because I'm not sure that this frequency is the fundamental. I might be a little bit too much of a purist here, but as I see it, the fundamental frequency is actually the rotational frequency of the fan because that's when the whole mechanical system "resets" and begins the cycle anew. But because a perfect N-bladed fan has an N-step symmetry, any harmonic that isn't a multiple of N is canceled out. Of course, imperfections in real-world fans will mean that there will be a little bit of amplitude at the non-multiple-of-N harmonics (and a lot more in extreme cases, like a blade being broken off), but under normal conditions, this is one of those rare sounds where the fundamental is much quieter compared to that Nth harmonic and multiples of N.
However, this is a topic on which experts may reasonably disagree. Someone more pragmatic may say, "No, the mechanism that generates sound here is the air jet from the mouth being periodically interrupted by a passing blade. THAT is the system we are analyzing. The fundamental frequency is the rate at which a blade passes and every other harmonic is a multiple of that frequency."
Either way, the result is the same: the peak frequency of the spectrum is the "blade pass frequency," and whether you call that the fundamental or the Nth harmonic of a lower fundamental, you need to divide that frequency by the number of blades to get the rotation frequency and multiply by 60 seconds per minute to get the RPM.
@@CFSworkslove this breakdown. Wish youtube comment allowed pictures so I could see the spectrogram
Intel 2005 PWM PC fan spec says it's 2 pulses per revolution. So if it's more or less, any mainboard will read the fan wrong as well.
Also these fans have quad pole motors, so the internal Hall effect sensor reading and the internal control signal flips 4 times per revolution. This is two positive pulses. One of these signals is simply conditioned a little and brought to the tachometer pin.
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.
This has all the fundementals of how engine management works for ignition timing.
Next episode: Dave builds an engine control system using ESP32
@@andrew2004sydneyI suppose this is not out of the question really, he does have some antique cars that he likes to maintain.
It is definitely funny you mention this... as a cur nut myself, I run a stand alone aftermarket ECU in my racecar. I always wondered why or IF Dave has done this to one of his older cars. It would be right up his alley!!! :)
@@andrew2004sydney It's been done.
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!
This is really damn cool Dave, hope you do more fun projects like these!
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.
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 :-)
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!
Dave, I wish I had you as my neighbor, love your work mate! Stuart from Melbourne AU
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.
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.
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.
The friendly goodbye at the end was awesome.... isn't that right Rusty?
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.
Man you nearly implemented a PLL clock multiplier in software lol
That is really cool! Thank you for this and all the other great videos you're posting.
You would be a great science teacher.
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.
I still love that FG ending. Memories!
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.
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.
Friendly Giant!!! I am also a Canadian of a certain age...
I used to freeze a disc centrifuge spinning at 8000rpm to let me watch particles sedimenting.
Used a Xenon flash.
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.
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.
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! 😳
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.
The "today, im doing some cool stuff" channel! I love it because of the content and getting to shake my fist at WGA at the same time ✊😂❤
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.
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.
Yeah, just set the timer for one colour slightly faster than the fan and the other slightly slower.
Great video as always. Outro brought back soooo many memories. Take care, eh!
@Dave just leave the tach interrupt active and recalculate the rpm every x cycles. Also use is to resync on each pulse
I've always wanted to try this.
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!
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)
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.
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).
YES the chairs are back! Thank you for the chairs!
You know some fan maker is now going to encorporate this into their fan and charge even more money!
Such a awesome idea thanks Dave❤
For PC fan PWM stuff, noctua has a white paper: Noctua PWM specifications white paper
There's also the Intel PWM spec which was last updated in 2005 but is still a good clue. Like, it says fan shall do 2 tachometer pulses per revolution, then all fans better do that and not just Noctua :D
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.
Stage coach wheels in old westerns would often appear to run backwards :-)
Very interesting. I think your query around the divide by 2 has to do with the LED, you have it on for half a second, and off for the other half. Otherwise it will just be on all the time.
The LED only turns on for a split second, not 50%.
God Bless you, Davepl!
The AMD Wraith Prism cooler can do that (strobing for cool effects). I wish all RGB controllers could.
"9 times brighter than...
* "9 times _as bright as..."_ ("brightER than" is multiplied by *that number of times **_plus 1_* [meaning multiply the original number by 1 more than the "x times"] for "as bright as," meaning times 10).
You sound like the sort of person who could understand my pet peeve of people saying "3 times cheaper." What does that even mean?
@@GordieGii: Yeah, heh. Like... are we talking... quality, simply price, or... what, exactly?
@@HelloKittyFanMan I mean what number are we multiplying by three to get the new 'cheapness'? I assume some marketer means one third the price but wants to put 'cheaper' in the sentence, so a little nonsensical math and he says "three times cheaper", but the phrase has no meaning mathematically speaking.
Does that make sense, or am I just blowing smoke up my own ass?
@@GordieGii: The smoke! Because of course there is still a mathematical equivalent of that! Because remember, when it comes to multiples, reducing the count rather than magnifying must call for a fraction or inverse. So of course when making a figure that is x times AS great AS n, then you would obviously multiply the two numbers (nx). So then if you want x times greatER than n, you would multiply your original number by 1 _more_ than your original multiplier: n(x + 1), so n*4 instead of n*3.
So to go in the other direction you _divide!_ In order to get 3 times AS "cheap," and if by "cheap" you actually mean _"inexpensive,"_ then you _divide_ by 3 instead of multiplying by it: n/x, so n/3. Or, in other words, you multiply by the _inverse_ form of the second number: the inverse of that 3, being 1/3: n(1/x), so n(1/3). And then to have 3 times "cheapER" instead of 3 times AS 'cheap', you would either divide by _that number plus 1:_ n/(x+1), so n/4; or you would multiply by the inverse form of the combination of that number plus 1: n(1/[x+1]), so n(1/4).
(And while I was writing this, I realized that I had to edit my OP, so please see the change there.)
So let's say there's something whose normal price is $9 (being n). And then for some odd reason the price skyrocketed to 3 (being x) times AS much, meaning that you would have to pay $27 instead! But if you say it's 3 times _more_ expensive, you're taking that multiple of 3 times that original price and adding it to a 4th occurrence of that price, meaning that -- holy crap(1) -- the price is now $36!
On the other hand, let's say your $9 price just got 3 times as "cheap"! How did you work that out? Well now it's just 1/3 the cost, so $3 instead of 9. But then if it got 3 times cheapER, since you're dividing your price by not only 3 times, but one more copy of that price, you would take your $9 and divide it by 4 instead of the 3, bringing the price way down to an easy $2.25!
But unfortunately too many people use "greatER" and "more," etc. interchangeable with "as... as," so that comparison isn't really as reliable as it should be.
@@HelloKittyFanMan But what if $9 isn't cheap?
What kind of lens are you using?
Love the colors and shallow DOF, I imagine it's fast with a large objective?
Excellent and thought provoking video. Sounds simple, but as you showed, the devil is in the details... anyway I am wondering if the pot could also be used as a fine tune. It should not be too noisy if over its whole range it only changes the frequency by, say, +/- a few microseconds. Thanks for sharing and inspiring.
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!
Recalculating the time with each rotation might eliminate the drift caused by small variations in the speed.
Thank you Dave
Would love to see you make a video demo in C utilizing interrupt 10 (256 color of course).
This would be a huge no-no in a corporate setting. Someone walks in and puts their finger into a spinning fan they thought was stationary.
We call them stumpies.
Done it many times. Still have all my fingers. PC fan blades aren't very massive. It does hurt, but I've never had one break skin.
Certainly wouldn't want that in an industrial setting though. the cooling fan on the ass end of a motor would definitely do damage.
Hello Dave, thanks for the videos. Can you do an episode on Sysinternals, especially procmon. Would love to hear what MS thought about the tools when they first came out.
So cool! I have a question though, is the tach a flip-flop? You read the high time then the low time and take the difference, but shouldn't that only tell you how long it took the magnet to pass the sensor? That stood out to me, I thought you would need to read from one trigger time to the next to get the rotation period. I could be interpreting someone else's code wrong, but maybe that's why you have to divide by 2?
Either way, I love this, I love LEDs and you've already inspired me on so many projects. Thanks for being who you are
hm the controll loop remembers me on plls Pll stands for Phase locked loop. Would be intresting how good it would work if we build it out of fast and deterministic logic.
I know you didn’t ask but I’ve got nightdriver controlling the LED fan on my Home Server rack. 👍
I feel like what's necessary to get it perfectly synced is *right there* but if davepl can't get it then I ain't gonna either 😢
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.
Should have put two strings of LEDs facing opposite directions, in parallel, so each string would be on half the time, but alternating.
DEFINITION ERROR! Hz = Period / 1s (1000000ms)
Thanks for your great vids and for asking to look for an error. 😊
1s is 1000ms, 1000000µs
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.
Did you forget to explain it?
@@DavesGarage sorry, i meant that you disconnect all the wires :p (including power)
@@DavesGarage In light of today's video, i want to say I truly hope my comment inspired nothing other than laughter. You are one of my favourite content creators, and i would hate to think of myself as a hinderance.
I had this happen accidentally the computer that I built and spent an embarrassing amount of time trying to figure out why my fan wasn't spending
Is the pulse width definitely related to the RPM? Or is just the pulse frequency specific to the RPM? (In other words, does the duty cycle vary with RPM or just the frequency?)
Maybe, see Phase Locked Loop (PLL). Use to generate a faster frequency (or upscale) locked to the tach signal.
It might be better to use ‘double’ instead of ‘float’ especially for the var ‘frequency’, and others of course.
Why not continuously adjust to the tach input? Each time around, do the 9x adjust again. should freeze it pretty well i think????
This guy likes RGB
I would assume that getting a non-blurry max speed fan you would have to lower the pulse width of the actual flashes, so it's more like actual strobing. The problem with that is that it very literally is how LEDs are made duller and darker.
Fortunately, as someone pointed out earlier, if you limit the pulse length you can pump a lot more current through a LED. If you're building something from scratch you can find LEDs that have peak conversion efficiency at above their max rated continuous current. Basically they are designed to be pulsed, so you can get more light by running them at 8 times their continuous current but at a 1/8 duty cycle. Not all LEDs are like this; you'd have to check datasheets.
Of course there's no way to do that with addressable LEDs.
Festool does this on some of it's saws, but they cost ALL the money.
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.
Thank you. Friendly Giant? 😊😊
The jitter might be way higher than your code suggests. I wonder if the serial led protocol is not working well during an interrupt
Greta project. And I had no idea you could just get a chip and make it control stuff like that. I thought you’d have to have an actually computer like a raspberrypi.
Just wondering, could this be used to estimate the frame rate of the human eye?
I wonder if dividing the pulse time by the number of blades would have worked
All PC fans emit two tachometer pulses per revolution as of around 2004. See the Intel PWM fan spec. It's actually probably even simpler than that, the motor actually has 4 states per revolution (look at the stator) and there are 4 state changes from positive to negative and vice versa, and the tachometer signal is simply the internal control signal converted to open-drain and brought to the outside. Not easily visible, the rotor also has 4 poles, you can view them with magnetic view film.
Also according to the same spec, the PWM control signal must be between 21 and 28 KHz, and should be 25KHz. But most fans have a wider tolerance range.
Also one should definitely not build a PC fan with a number of blades divisible by 4, absolutely not.
woah.. this is really nice. i also like the effects from 1:30 😯
Just reset the timer when you get a tach pulse?
Wouldn’t the process on the data side all be instant but the reaction of the speed change be on a curve as the blades would need to get up to get up to or slow down to the new speed. Feedback processing from the fan sensor once every rotation wouldn’t take into account the change in speed curve if only perfectly devided by 9. Resulting in the calculated flashes between each flash not being perfectly timed.
Also wouldn’t the LEDs have a dimming curve with the brightest point being just after being triggered and then a slower discharge. Once sped up some of remaing charge from the trigger before would mean the visible on state would be longer or some brightness during the period you would consider as off in your program.
I admit I’m out of my depth in this chat room but I’m enjoying thinking about it. Going to watch the video a second time and google some things. Thanks for the rabbit hole.
Also some great comments on here.
Pure-color LEDs don't have a phosphor and turn on and off effectively instantaneously for the speeds we're talking about here.
Could you call UpdateTimers with an interrupt on the Tach line? Then every revolution, the speed would be gently adjusted. This would require two interrupt service routines. And the code running every revolution may take more time than you have.
Very Cool Video! I love your channel. Always interesting! I am so glad I found it!