Issues with Zero Cross Detection #18949
Comments
|
I have inverted the scope trace for the trigger channel - into the ZC detector. This provides a better picture but also implies the trigger is triggering on peak crossing, not zero crossing. The below, with inverted trace would be ideal. At low power - ideal as triggers in late part of cycle At full power - ideal as triggers at beginning part of cycle. |
|
Answer 1: |
|
The front end has been redesigned with us now using two optocouplers - the one to generate a sharp Zero crossing pulse and the other to create a "cleaner" sinewave for voltage measurement. Mains power will however always be dirty. There is no external ZC detector - the ESP32 Wroom is "meant to be" performing the job of detection using its internal ZC detection. This is what we are battling with. "wrong threshold voltage" - We did not realise this was changeable - How does one change the threshold ? This would help. Not found anything in documentation. "correct GPIO pin is assigned" - GPIO25 is used as it also has DAC capability- was seen as best option. Is there a better option ? "GPIO pin you are using for PWM output" - Using GPIO34 - ADC GPIO. Any suggestions as to better one to use. |
|
The ZC detector can be used to synchronize other operations with the mains voltage, such as switching on a load or taking a voltage measurement. The threshold voltage for the ZC detector can be changed by setting the ZC_THRESHOLD value in the user_config_override.h. The default value is 1.5V, but this can be changed to a higher or lower value depending on the needs of the application. There is no universal minimum or maximum value that applies to all cases. The GPIO pin that is assigned to the ZC detector can also be changed by setting the ZC_GPIO value in the console. The default pin is GPIO25, but this can be changed to any other GPIO pin that is available.
The GPIO pin that is used for PWM output can also be changed in the console . The default pin is GPIO34, but this can be changed to any other GPIO pin that is available. |
|
Thanks - I have tried various options for ZC_GPIO - Set ZC_GPIO etc. All get unknown command error. I am playing with the User_Config_Override file and will report back if I can use it to change the detection voltage. My feeling is the ZC voltage is set too high - which is why it is triggering around 50% of the cycle. Ideally it should also be on falling edge. A full 50Hz wave has a period of 20ms. Do you mean microseconds ? The modified front end circuitry is producing a much sharper ZC trigger and the device is now more stable. Also updated to 13.0.0. |
|
Let me bring some light into the discussion as I maintain this driver currently. First please do not add rules or other high CPU loads on the ESP8266 that is doing the dimmer. If you so there will be flickering because it just misses. The Zero-Cross signal coming to counter4 is an input signal. If this is not good or have problems than you need to change your hardware. There is nothing TASMOTA can do. I have good experience with the one shown in the documentation. The pulse on the TRIAC should have a defined length an is shifted a constant time away from the last zero-cross event. The lower the DIMMER value is the more far away it the TRIAC pulse. The PWMFREQUENCY and other stuff is not needed anymore. In the most recent development version the dimmer is using high frequency interrupts. |
|
Explanation: Why is it only a pulse and not a ON signal until the next zero-Cross? |
|
There are some debug messages regarding missed zero.cross events in the xdrv_68_zerocrossDimmer.ino. Line 223 |
we are using esp32 |
|
It's the same with esp32. Same driver. Pls share some logs regarding the flickering. This should not be there. |
Jason2866
added
the
awaiting feedback
|
Stefan - Firstly thanks for the driver. See it has come on in leaps and bounds over the last few months. To clarify:
Some further background - this is a device being built to comply with Australian certifications and is pretty complex. The triac is only one small component. Hope the community likes the outcome in the end !. Thanks once again. |
What you want to do is a falling edge dimmer. With a config option I would trigger the pulse just in the ZERO-CROSS detection. This is the fastet way to set it HIGH. The use the current function to set it LOW instead of HIGH. I assume these will be not more than 5 lines of code and a config option. If it is a compiler option then super easy, if you want to make a variable. we have to reserve a byte in the config holder to store the definition: rising/falling edge and a small function to change it. |
|
Thanks. The pulse is however starting too late after the zero cross. See screenshot. There is at least a 2ms delay with dimmer 99 (100 kills the pwm pulse). At 50Hz this is a material amount of power we are not able to harness - but we do have a work around so not critical now.
The three counterdebounce options look interesting but I need to get my head around them!. They seem to set a validation period after an edge change. Not too keen on straying from standard Tasmota build - was thinking of using override. Any guidance appreciated! Off the top of your head - would a ZC trigger for a rule be AC#pulse ? |
|
I used the ZCDimmerSet command to get good controll over the trigger. Attached an image with 98%. The short yellow pulse from the PWM is still on the falling edge of the ZC-Pulse (blue). This is a 100% on. If going to 99% flickering starts because the pulse is to early. I need a voltage divider to connect to mains and also show the sinus. Maybe this evening. On a 10% the weblog4 shows |
|
I do not know why, but my testbench does not work with "dimmer 10" "dimmer 20" and so on. I got reboots and odd behaviour. There seems something wrong and different. |
Regarding your question about using a ZC trigger for a rule, in Tasmota, the AC#Pulse trigger was previously used for this purpose, but as mentioned earlier, it has been removed in newer versions. If you are using an older version of Tasmota, you can try using AC#pulse as the trigger for your rule. However, in the latest versions, alternative triggers such as MQTT, HTTP, or timers would need to be utilized. |
|
No it works differntly. You connect COUNTER4 to the ZC-Signal. Inside the Trigger counter I have a hook that calls the ZC-Driver: xdrv_68_zerocrossdimmer.ino The hook is in: xsns_01_counter.ino Line: 78ff This is inside an IRAM CACHE function that has high priority. a rule gets called far to late and on an unregular base. This can NEVER work. Rules are on the IDLE Task. For ZC you need hard INTERRUPTS to be in sync. Thats the reason why the function: Using latest dev build, but production build is also fine |
Both are working on my ESP32_Wroom-32 devkit. Dimmer does give a different console response - "Power on, %" whereas ZCdimmerset just gives % but seems to reduce triggering delay to 1ms. My system is stable either way. |
Currently using prod build 13 - did not see many relevant changes in dev 13.0.0.1
The below looks fine on the scope as well. I have been given lots of useful feedback on triggering an ADC after a few ms (for a voltage read). Most of it boils down to "modify the code as rules are not quick enough". I am a "not-so-well-self-taught" coder and it will take me ages, but more to the point dont want to fork a custom of the code - and not even sure another driver will work in conjunction with your driver as using same ports etc. Basically need to read voltage every few cycles after some delay (14ms ?) after the ZC and average it to calculate power. Current measured by more traditional means. Any suggestions ? Shall I close this bug report ? Thanks for the help. If you do need an occasional resource - happy to contribute. |
Jason2866
removed
the
awaiting feedback
|
I did some more investigations on the delay. ZCDimmerset 0.3 is working with some rare one time flicker. The pulse start at 9.8ms and ends 9.9ms after ZC. The flickering happen when the pulse last longer than the 10ms. With 0.1ms accuracy this is mast we can get. CounterDebounceHigh MUST be 0. Anything else give very strange behavior. Looks like the "message" zerocross is deferred by the amount of ms in CounterDebounceHigh. Image1 Image2 Code changes I can offer:
|
|
I made following changes to better support your use case:
Known issues:
|
|
Much appreciated. Stuck out in the field today - but itching to get back and try. Assume download latest dev build ? Did try savedata0 when we were originally testing - nasty. |
|
In have an idea how to overcome the save issue. Let's test today. |
|
No need to hurry. The PR is currently not merged into development. |
|
Thanks - Just got in now after a long day. When do you think you will merge it with dev?. The other issue - still really keen on tiggering an ADC read every 2nd or third cycle to sample voltage - eg 14ms after zero crossing. How hard would that be to build into the driver ? |
|
14ms after zero cross is a strange request because the phase is just 10ms. At least with 50Hz here in Europe. I do not understand the ADC use case. Trimming every half-sine is the best you can do. If you do 50% you just go in when voltage is max. |
|
Unfortunately there is no oscilloscope available, to provide any plot. The hardware is a Robotdyn with a D1 mini. |
|
The flash is caused by the savedata event. This messes around with the interrupts. I may ask Theo for a workaround here. Maybe not a problem anymore. The disco on 0 I will check. Havent seen this here with the same device. Will let you know soon |
|
Hm, interesting. In the previous version there was no flashing and I think the savedata event was also in place. I thought, that the savedata problem was only on ESP32. |
|
|
Stefan - any timeline for the latest version of the driver to make it to dev? I started setting up some new GPIO's and they have killed the pwm pulse. Might blow away and start afresh. |
|
It is already in |
|
@SteWers : I fixed the flashing during change of the brightness. do you use ZCDimmerSet to set the dimmer? In the past it also worked with the normal Dimmer command but this causes a reset currently in my setup. |
|
Yes, I use ZCDimmerSet. And yes, I saw the restarts too, when using the Dimmer command. |
|
I set up another test environment to see the output of the PWM. Therefore I configured PWM1 to the LED-GPIO. Nothing was connected to COUNTER4 (ZC). After setting SO99, I recognized that PWM still worked. I could change the brightness via the DIMMER command. ZCDimmerSet had no reaction. After providing a (pseudo) ZC signal, the LED indicates the unwanted behavior. Should be off on 0, but it flashes. |
|
As you can see I just submitted a change hopefully fixing ALL issues you saw right now. The DIMMER command executed an analogWrite command on the PWM that interfere with the Zero-Cross implementation. This caused the HANG. The Savedata now does not disable the counterInterrupt if there is a Zero-Cross Dimmer enabled. I kill the HIGH signal on the GPIO not later than 99% of the cycle time. This should address the flicker issue. Even if I was not able to reproduce the flickering with my Robodyn. Maybe a different, more accurate version. |
|
Have upgraded to Dev 13.0.0.2 and so far looking good, other than a possible issue with a clash with relay ? I will download latest driver - has the change request been accepted ?. |
|
Thank you very much. No restarts until now. Unfortunately I cannot do a real test before Monday. In my simulation it seems, that the PWM is stable, but high at 0. At 100 it is unstable. But lets wait until I tested it in real next week. |
|
The post was initially started to look at Zero cross detection and subsequent trigger for attached Triac. I believe we have successfully resolved at least that issue and in the interests of a proper closeout of the issue provide screen shots for the use of the community. Note that there are two minor issues but core problems resolved. Minor issues are:
Screenshots below show:
Big thank you to @stefanbode. @SteWers - when you believe your issue is resolved we can close the post. |
|
One further critical issue: The trigger pulse for the Triac is reversed. I.e. it triggers at the ZC. Ideally it needs to trigger after the ZC. For ZCDimmerset 99% - immediately and for 50% half way into the waveform.... I thought pwm_i would resolve but not the case. |
|
@stefanbode Let me report from my tests: |
|
There is a setoption I assume 151 that changes from a leading edge dimmer to a trailing edge dimmer. Both modes are supported now. Should be in the documentation. |
|
Savedata 1 should be the default and then it saves on my site only if changing the value. Will double check. The other option I have to review. The zero cross is not a time it is a period and therefore there must be some silence before and after to be reliable. |
If we have a leading edge dimmer (default) the HIGH will come somewhere during the half sine and kills the power at the next zero-cross. It is mandatory that the HIGH goes LOW before that zero cross. Hardcoded and not willing to change is 99% of time of a cycle. At 50Hz this is 9.9ms after ZC and 0.1ms before the next one. This kill should be fine because it is used for ALL ZCDimmerset. Very low values of ZCDimmerset will not work if the start time after the kill time. But we talk about zcdimmerset 0.2 or something stupid. dimmer 0 and dimmer 100 should work. At least here. Here is "dimmer 1" 1% --> 18micro seconds to late (quite ok, inside tollerance) dimmer 99 -- > switch on at 0.5ms all good. regarding the watchdog: you cannot remove this line. this is absolut mandatory to get on esp8266 the accuracy of the dimmer. the normal INTERRUPT is 75microsec. This is a about: 1000/75 = 13 stops between two zero cross events. 0..100 percent at least require 100 stops. The trick is on esp8266 to change the interrupt time if you come near the "switch HIGH" event. I have no hardware watchdogs here. what is you zcdimmerset testing value. maybe related there. |
|
The webbuttons will work but only if you are in the "dimmer" mode. This does mean |
|
I think you're right. There is an electrical delay caused by my setup. The "normal" one works as designed. |
|
I did a "long time run test" 48h with ESP8266 and had zero reboots and hangs. Something we CAN change is the minumum time for a interrupt. 75 micro second is the default. The highlighted line: |
|
Can you confirm that the updated drivers are uploaded when I update to the latest Dev version please ?
From: stefanbode ***@***.***>
Sent: Tuesday, 25 July 2023 3:29 PM
To: arendst/Tasmota ***@***.***>
Cc: Cactii Engineering ***@***.***>; Author ***@***.***>
Subject: Re: [arendst/Tasmota] Issues with Zero Cross Detection (Issue #18949)
I did a "long time run test" 48h with ESP8266 and had zero reboots and hangs. Something we CAN change is the minumum time for a interrupt. 75 micro second is the default. The highlighted line:
ac_zero_cross_dimmer.actual_tigger_Period = tmin(ac_zero_cross_dimmer.actual_tigger_Period,tmax(5,ac_zero_cross_dimmer.enable_time_us[i] - time_since_zc));
allows a minimum of 5micro seconds. This is very very short. I will check a different method for ESP8266 to ensure the last Interrupt has a reasonable time.
—
Reply to this email directly, view it on GitHub <#18949 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/A2MHKHQZKJIOD3MMX3TMP3TXR5KRLANCNFSM6AAAAAAZSFIDVA> .
You are receiving this because you authored the thread. <https://github.com/notifications/beacon/A2MHKHU7YGRV75JS2DXNR43XR5KRLA5CNFSM6AAAAAAZSFIDVCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTCJP75U.gif> Message ID: ***@***.*** ***@***.***> >
|
|
confirmed. The one in DEV is the one working well here. |
|
As you said "5 µs is very short", I did a few tests and increased the minimal time from 5 µs stepwise to 30 µs. With 20 µs the reboots were already there, but with 30 µs they have gone. The device is now up for 4(!) days without any crash. For testing I changed the ZCDimmerSet from 0 to 100 and back continuously in 0.1 steps every 100 ms via script. |
|
Zcdimmerset should restore after power off if savedata 1 is set. This is default. The 30mirco second is a good catch. I already have a change here where I can guarantee accuracy and do not violate minimum time. Let me submit this later today. Can you check if zcdimmerset survive a reboot if savedata is correct? |
|
Yes, ZCDimmerSet is restored with savedata 1. In my case, I want to start with ZCDimmerSet 0, when device starts. This is the case when savedata is 0. But when savedata is 0 there are other side effects. E.g. script is not (re)stored. So I think, that an option, which is independent from savedata, would be a good feature. |
|
Nice idea but not possible. I removed as many problems with savedata as possible. should not flicker anymore. #19211 just submitted to increase minimum interrupt time from 5mirco to 30 micro seconds. Be aware that zcdimmerset 0 raises the use of DIMMER. Therefore this must also be 0. Otherwise you see side effects. "savedata 1" is the default and should work. @cacengineering : my long run test did work witch 20micros but i changes to your proposed 30micro. |
PROBLEM DESCRIPTION
See attached screenshots showing input AC waveform (GPIO34 set as counter4) and pwm out pin GPIO25 (tried as both PWM and PWM_i) - fundamentally testing the PWM feature with option99 set and PWM frequency set at 100Hz, zero crossing 50Hz rectified mains (100Hz) via optocoupler on GPIO34). (Zero crossing now seems to be mostly working - huge improvement).
Issues are:
Screenshot Stutter,2 - The zero crossing detector is not catching every zero crossing. Not sure if we can rather set a rising or falling edge.The LED connected in lieu of thyrister is not smooth - but has an erratic flicker. Also not sure if triggering at zero or peak crossing ?
PWM waveform - this is a pulse of around 5 - 10us - was expecting a PWM waveform with length set by the pwm slider (but the trigger is useable).
Screenshots PWM trigger point - The trigger point should follow the setting of the slider allowing a full waveform to be created by triggering a thyristor or similar - I have tested with the slider on low (maybe 5%), middle and high (maybe 95%). The low setting trigger point would give full power, the middle point seems to be at random and the high seems to be at midpoint of the waveform. This would only give at best 50% power setting - not 100%.
REQUESTED INFORMATION
Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!
Backlog Template; Module; GPIO 255:Backlog Rule1; Rule2; Rule3:None
Rules output here:
weblogto 4 and then, when you experience your issue, provide the output of the Console log:TO REPRODUCE
Steps to reproduce the behavior:
Ongoing issue
EXPECTED BEHAVIOUR
A clear and concise description of what you expected to happen.
It is expected that the zero crossing detector would trigger consistently for every crossing. Might be noise on the waveform (top is a bit saturated) - but this is on a test bench and real implementation will be noisier. Can we do a rising or falling edge slightly out of the noise ? Falling might be better as allows a short delay before triggering of the next cycle for 100%.
It is expected the PWM waveform will trigger consistently at a specific crossing point.
It was expected that we get a pulse of a certain width from the PWM - but not a serious issue as all we really need is a correctly positioned pulse to trigger power circuitry which switches off at Zero crossing.
Ideally at full power the pulse will start at the zero crossing, and at lower settings start later in the waveform reducing the on time.
Very Low priority - Incidental to this exercise we have noticed the mains frequency swings a fair bit compared to the 100Hz of the PWM. If we implement with fixed triggering delays on variable freq mains the power out will vary. Ideally the triggering delays should be tied to the mains frequency - or % of time between zero crossings which should be accurate enough. Will also allow for auto detection of 50 or 60Hz mains.
SCREENSHOTS
If applicable, add screenshots to help explain your problem.
Two sets of screen shots. Note the scope is triggering on the rectified mains input - rising edge at about 1.7V. Any less and the scope battles to hold the trigger point.
Stutter -
Stutter2 -
Triggering point
Low -
Medium -
High -
ADDITIONAL CONTEXT
Add any other context about the problem here.
We are using MQTT extensively - and are resetting the counter with every MQtt report - 15secs.
I am not really a programmer and only know enough to be dangerous ... but very happy to further test if you need testing done.
(Please, remember to close the issue when the problem has been addressed)
The text was updated successfully, but these errors were encountered: