search

arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
22.01k stars 4.77k forks source link

Issues with Zero Cross Detection #18949

Closed cacengineering closed 1 year ago

cacengineering commented 1 year ago

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: 1) 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 ?

2) 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).

3) 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!

- [x ] If using rules, provide the output of this command: `Backlog Rule1; Rule2; Rule3`:
None
  Rules output here:

- [ ] Set `weblog` to 4 and then, when you experience your issue, provide the output of the Console log:
```lua
  Console output here:
Ongoing issue

TO REPRODUCE

Steps to reproduce the behavior: Ongoing issue

EXPECTED BEHAVIOUR

A clear and concise description of what you expected to happen.

1) 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%.

2) It is expected the PWM waveform will trigger consistently at a specific crossing point.

3) 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.

4) 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.

5) 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 - image Stutter2 - image

Triggering point Low - image Medium - image High - image

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)

cacengineering commented 1 year ago

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 https://github.com/arendst/Tasmota/issues/18949#issuecomment-1649147866 , 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: @. @.> >

stefanbode commented 1 year ago

confirmed. The one in DEV is the one working well here.

SteWers commented 1 year ago

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. Another point to think about is the storage of the ZCDimmerSet and restore it after a power outage / reboot. This is very nice, when there is e.g. wall switch and the light is restored after switching it on again. But in other cases it is better to start with a defined value after an uncontrolled return of power. Therefore a mechanism like PowerOnState would be helpfull.

stefanbode commented 1 year ago

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?

SteWers commented 1 year ago

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.

stefanbode commented 1 year ago

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.