Skipping over a lot of information I will add later, I want to put some oscilloscope diagrams up here and add my notes before I forget important details.
I used my Rigol DS1054Z and this was the first time I used 3 channels.
Channel 1 (yellow) was from a transformer I plugged in alongside the SR800. I wanted to get the AC line without endangering my scope by connecting directly to the mains, and this was a way to do it.
Channel 2 (blue) is the signal that returns from the power board to the logic board via the orange wire. This signal is generated on the power board by an op-amp circuit and ultimately will provide zero crossing information.
Channel 3 (purple) is the logic level signal derived from the orange wire (channel 2). I get this by sampling at the collector of Q6B. This is the signal that goes directly to the PIC controller and clues the controller as to zero crossing timings.
This first capture shows all 3 signals for a full cycle of the 60 Hz mains supply.
The following (second) capture shows the same signals at the rising zero crossing. The important measurement is the delay from the actual zero crossing to the transition on channel 3. This delay was measured as 318 microseconds.
The following (third) capture shows exactly the same information at the falling zero crossing. Again, we are eager to measure the delay from the actual zero crossing to the transition on channel 3 (purple). This delay was measured at 288 microseconds. (Actually the alert reader will note that the measurement is on the screen and is 292 microseconds). Also note that the transition actual comes before the zero crossing.
OK, now the game changes and we are looking at only 2 signals. Given the above, we understand the signal on channel 3 above (the signal they use to tell the PIC when a zero crossing occurs). We make that our channel 1 (yellow) in the two captures that follow.
We add (on Channel 2 -- (blue)) the signal that drives the yellow wire (the heater control). Again I take the signal at the collector of a transistor (Q7B) rather than the yellow wire itself.
This first capture is with a heater setting of 1. Note the tiny down going pulse on the blue trace. This is 14 microseconds in duration and is what causes the heater triac to turn on. The critical thing is the delay after the edge on the yellow signal. Here I measure it at 2.86 milliseconds. Notice also that the delay is the same for the down going and the up going part of the AC waveform, which is as it should be.
This second capture is with a heater setting of 5. Now the delay has been reduced to 2.13 milliseconds.
I also measured the delay for a heater setting of 9 (it was 0.80 milliseconds).
In summary, the heater delays are:
Heater setting 1 - 2.9 milliseconds Heater setting 5 - 2.1 milliseconds Heater setting 9 - 0.8 milliseconds
Triggering the triac earlier means that power is on for a longer part of the half cycle. If we triggered with no delay (and watched out for that 0.3 milliseconds of dead time we learned about), we would get full power, as though the heater were plugged directly into the AC line. It is interesting that power level 9 does not do that.
Note that we can control the heater with almost infinite precision, limited only by how accurately we can time those trigger pulses. We can certainly be more precise that 9 levels (whether that is really important).
Also note that the fan control is done in exactly the same way, but with different delays. I measured those, but did not collect scope diagrams. The fan delays are roughly:
Fan setting 1 - 4.7 milliseconds Fan setting 5 - 3.9 milliseconds Fan setting 9 - 2.0 millisecondsThe observant reader will have noticed that these delays are not linear as a function of the setting 1 through 9. Well, why should they be? One important thought is that the power delivered is given by integrating the area under part of a half cycle of a sinusoid, and that is what we want to make linear. That is if we want to make anything linear, but who knows if the engineers who wrote the SR800 went to that much trouble.
Tom's coffee pages / tom@mmto.org