Mains voltage zero crossing detector with optical isolated output

So, do you like JF's circuit?

Platitude #1. ...Jim Thompson

Platitudes #2, 3, 4, 5, 6. ...Jim Thompson

Didn't know "platitude" == "right answer"

There's a typo in JF's message ID. John hit the "P" at the same time as the colon.

news: snipped-for-privacy@4ax.com

Since what goes on on the detector side of the opto is inherently galvanically isolated from my circuit by a beam of light, my only concern was with generating a pulse which could drive the emitter side of the opto during/at mains zero crossings.

Hi John,

I think the issue is the supply for the opamp and logic isn't it?

I admit I don't follow quite what it does. But these days once you get above a couple of logic chips I find it can end up easier to do things in a micro.

John Larkins circuit seems well suited as a front-end for that.

I used to design logic that way, asynchronous edges getting anded and ored all over the place. One day an ex-TI guy straightened me out about synchronous logic design... in 1968, roughly. At TI, they weren't allowed to use the presets or clears of flipflops, even at powerup.

But you expect me to be polite to you, when approximately 100% of your replies to my posts are whiney personal nonsense?

Of course it matters; you don't want to see the logic hazards. Even more important, you would have to really work at it to prove there are no hazards. Logic design like this doesn't scale. And it's not necessary.

And they may improperly load the counters. The PEs are a mess.

time in a hundred, or one time in a billion.

What's the width of the PE pulse from Q3? And what's the required width to reliably load the counter?

time in a hundred, or one time in a billion.

try delaying V3 by 11.58us, look at the pulse width on PE for U4 and U5 around 1.4ms

for even more fun try 11.575us

-Lasse

time in a hundred, or one time in a billion.

Did you mean 14.58? That makes a nasty runt on PE.

The 4516 needs 220 ns min PE width. A runt will probably do erratic presets to the various flops. A narrow runt might get missed entirely.

What's also bad is the slow risetime from the comparator, and it drives three separate chips. It's impossible to say what will happen with real-life CMOS parts with different thresholds.

Async logic is just too dangerous to use unless you absolutely have to.

time in a hundred, or one time in a billion.

maybe there's a difference in version, I ran it on a rather old ltspice

at 11.58u I get a pulse less than 100ns wide, at 11.575us it's not even there

yes at the very least there should be synchronizing flop ahead of it all

indeed.

-Lasse

one time in a hundred, or one time in a billion.

Yup, I see the same thing, an arbitrarily narrow runt, at 14.xxx for some reason. But it's an obvious hazard. I've seen this done a lot, probably did it myself once or twice.

One more flop would fix it. Then the actual functionality could be considered.

No, it's not. Asynchronous resets can cause all sorts of grief coming out of reset. Designing in race conditions isn't a good idea.

You're the one who doesn't understand how the circuit *DOESN'T* work. It's typical stuff of hackers.

No proof necessary. The hazard is built in.

time in a hundred, or one time in a billion.

Clueless.

time in a hundred, or one time in a billion.

I can spot a runt-pulse race condition when I see one.

Lasse already spotted one of the specific hazards. Runt pulse on a PE, as expected.

Funny you should describe checking the integrity of your own design as "work against myself in your behalf." Hilarious, actually.

time in a hundred, or one time in a billion.