When I wrote "Control motors - Part 3: Digital PWM" I thought everything would work fine but time told me different (in German we say: theory is gray but practice is colored).
The first thing I built was the clock. To make development easier I used a slow clock and put a LED at the output to visualize the signal:
The next step was to install the counter. One thing I had to change was to count down instead of up because presetting to 1 by using the cascading output did not work: the signal is high from the beginning of 0 until the end of 14, becomes low in the middle of 15 and high again at the end of 15 (which is equal to the beginning of 0). I had to invert the signal since the preset-pin is low in inactive state but this means that the rising from low to high used to preset a value is in the middle of 15 - not at the end! This shortcuts the last unit.
A possible solution could be preseting the value asynchronously (which means to tell the IC within a clock-cycle to use the presetted value at the beginning of the next clock-cycle) but unfortunately the ICs I bought did not support this feature. Another solution is to delay the signal for the half of a clock-cycle by inserting a capacitor. This didn't work either. Additionally this way seems unstable to me. I always prefer to use things in the way they ment and if an IC does not support a feature I have to find another which does.
At the end I had to count from 15 to 0 and preset the value to 15 once 0 (= minimum-pin active) is reached:
In the last step I added the comparator IC. I simulated the input-values (the percent of the PWMs duty-cycle) which will be given by Raspberry Pi's GPIO-pins by using four microswitches - each for one bit. Let me show you the possible input and output-values:
The LEDs from right to left: Bit 4, bit 3, bit 2, bit 1 and the clock-signal. The IC counts from 15 to 1 and then starts at 15 again.
In the last step I added the comparator IC. I simulated the input-values (the percent of the PWMs duty-cycle) which will be given by Raspberry Pi's GPIO-pins by using four microswitches - each for one bit. Let me show you the possible input and output-values:
| Signal sent by GPIO-pins | Condition | Output-signal | |
|---|---|---|---|
| 0-0-0-0 = 0 | > or = to counter | always 0 (= 0%) | |
| 0-0-0-1 = 1 | > or = to counter | 1 if counter is 1 otherwise 0 (= 6.67%) | |
| .... | |||
| 1-1-1-0 = 14 | > or = to counter | 1 except counter is 15 (= 93.33%) | |
| 1-1-1-1 = 15 | > or = to counter | always 1 (= 100%) | |
As you can see this is a clean PWM-signal from 0% to 100%. And here is the video showing the signal:
In the middle of the breadboard is a blue LED showing the PWM-signal. At the beginning there is no light because no microswitches are pressed which means input 0-0-0-0 (= decimal 0 = 0%). Then I pressed the switch for bit 1 which means 0-0-0-1 (= decimal 1 = 6,67%). Next I pressed the switch for bit 2 which means 0-0-1-0 (= decimal 2 = 13,33%). Afterwards I pressed the switch for bit 3 which means 0-1-0-0 (= decimal 4 = 26,67%). And finally I pressed the switch for bit 4 which means 1-0-0-0 (= decimal 8 = 53,33%). To complete the row I pressed all switches additionally which means 1-1-1-1 (= decimal 15 = 100%). In every state the output-LED shows the proper duty-cycle.
At the end I replaced the big capacitor of the clock by a smaller one and the LED switched from blinking in the rhythm of the PWM to lighten more or less brighter - as expected. But suddenly the 0% stage was not "no light" instead it was slightly lightening even hard to see. Where is this current coming from?
Before I tell you, I have to admit that I had an error in reasoning: For the motors I want to use I have to apply a 2kHz PWM-signal. So I bought a capacitor for the clock-IC (NE555) to produce this frequency. But in fact if the desired PWM-frequency is 2kHz and we divide each cycle into 16 steps the clock for driving the counter-IC has to run at 2*16 = 32kHz.
Finally I could figure out that what I saw was the result of something called glitch. It occurs if the rising from low to high is to slow and the IC is to slow or clock signals delay due to long distances. So rising from 2kHz to 32kHz made glitches visible. As suggested by Stefan (see "Control motors - Part 3: Digital PWM") I replaced all ICs by pendants of the 74LS series. This didn't solve but cleared out the problem as these ICs switch faster:
But what is the solution? Generally it seems (as Google says) that a buffer should remove glitches. A buffer is a combination of two NOT-operations in serial. The resulting signal is the same as the original input-signal. Glitches should be removed because usually logical IC accept voltages below 1/3 as low and above of 2/3 as high. If the glitch is lower than 1.67V (5V * 1/3) than the buffer should clear out the correct signal. But this did not work for me. I assume that my glitch is near to 1/3. So I had to find another solution.
This short video shows the breadboard in the dark. The clock-LED turns on and off so fast that it seems to be turned on continuously. The blue-LED which shows the PWM-signal is slightly lightened although the input-signal is 0-0-0-0 (no microswitches pressed).
Before I tell you, I have to admit that I had an error in reasoning: For the motors I want to use I have to apply a 2kHz PWM-signal. So I bought a capacitor for the clock-IC (NE555) to produce this frequency. But in fact if the desired PWM-frequency is 2kHz and we divide each cycle into 16 steps the clock for driving the counter-IC has to run at 2*16 = 32kHz.
Finally I could figure out that what I saw was the result of something called glitch. It occurs if the rising from low to high is to slow and the IC is to slow or clock signals delay due to long distances. So rising from 2kHz to 32kHz made glitches visible. As suggested by Stefan (see "Control motors - Part 3: Digital PWM") I replaced all ICs by pendants of the 74LS series. This didn't solve but cleared out the problem as these ICs switch faster:
Every time a cycle completed (counter has reached 0 and will be presetted to 15) the glitch is visible by a short blink of the output-visualizing LED.
But what is the solution? Generally it seems (as Google says) that a buffer should remove glitches. A buffer is a combination of two NOT-operations in serial. The resulting signal is the same as the original input-signal. Glitches should be removed because usually logical IC accept voltages below 1/3 as low and above of 2/3 as high. If the glitch is lower than 1.67V (5V * 1/3) than the buffer should clear out the correct signal. But this did not work for me. I assume that my glitch is near to 1/3. So I had to find another solution.
Finally I figured out that this also can be achieved by using a flip-flop. A flip-flop is the mechanism which enables a computer's memory to store binary stages (true or false => 1 or 0 => high or low). They work in this way: You have to provide an input-signal and tell the flip-flop to store that input. From now on, even if the input changes, the stored signal is provided at the output. There are several types of flip-flops but I used the D-type which depends on a clock signal. So the solution is to ignore values (also glitches) within clock-cycles and use the value at the beginning of a cycle (doing a snapshot by using the flip-flop) during the whole cycle. And indeed it works like a charm.
This was the first problem in electronics which I solved on my own. No Google - just thinking. I was very proud at this moment :-)
This was the first problem in electronics which I solved on my own. No Google - just thinking. I was very proud at this moment :-)
The ICs from the left to the right: flip-flop (SN74LS74AN), or (SN74LS32N), comparator (SN74LS85N), counter (SN74LS191N) and time (TLC555). In this version I replaced the microswitches by pull-up-resistors.
In the next weeks I will build a lead frame and a circuit diagram for this. I will update the post by adding these two things as soon as this is done.
