Opto/Echelon neuron problem

How is the FT3150 recognizing the input? Interrupt? Frequent polling? Internal edge detector or hardware counter? Which input? How configured?

It's a photo-transistor, thus Miller gain of the collector-base capacitance.

So I'd design for arbitrarily slow slew rate. ...Jim Thompson

The FT3150 is based on multiple Z80s and has built in firmware for the various timer functions. You call the pulse count function and 0.839 seconds later you get an answer. This is on IO7.

Those are pretty high impedances. The led side could easily pick up enough noise to wiggle the output side through the small hysteresis band, on either edge. The open base of the phototransistor is also a hazard at these low currents. Sounds like your counters are hardware, so are probably nanosecond edge sensitive.

Straight capacitive coupling could be a hazard, too.

The scope probe could easily add enough capacitance to hide some of the problems. How often does it miscount? Has a storage scope observed it long enough to catch several miscounts?

Are the input and output circuits truly floating relative to one another? I've seen lots of systems where both sides were ground referenced and people used optocouplers anyhow, for their magical noise reduction effects, and made things worse, at considerable expense. CTR variations and LED degradation make optos some of the least predictable parts you can buy. Slow as hogs, too.

John

I'm not too enthusiastic about your connection scheme on the LED, given that this opto does not appear to have an internal screen.

Thanks.

I bet it is the open base. And yes the scope affected the problem.

So the latest batch of optos are just more sensitive and lowering the impedances is the solution, not just a "trick".

And both sides are ground referenced. I wouldn't have used optos here at all but the customer had problems with the original boards in China and insisted on a higher spec board with optos for noisy environments.

I was paid to do it against my better judgement (I know it sounds like I work for CRU). The actual problem in China was large differences in earth voltages in different parts of the system.

Debounce in software?

The pulse count function is in the manufacturers firmware.

I'm probalbly wrong as I just design the hardware but from memory the Echelon neurons are basically 3 Z80s. One handles the LON network, one the software and one something else.

The software is event driven and only runs when the schedular allows it, otherwise the 3 cores spend a fair time chatting amongst themselves.

As far as the customer's software guy is concerned it is best to you use the built in functions.

If I had known of a requirement for pulse counting I would have implemented in the PIC I have on the board where I would have had full control.

They used to have a processor with - I think - their own instruction set, with one core that run two effective cpu's on alternate clock phases, one for the network and one for the application. Brutally slow. Weird folks, Echelon.

John

You could try a different optocoupler, such the NEC PS2503. It states a higher coupled capacitance than the one you are using, but that may not be the whole story.

For testing, maybe bias it so that the phototransistor output voltage is about 1V by trickling a bit of current through the LED, and connect a signal generator to the input with a fast rise time square wave and see if you can get it to glitch at the output (as measured by the processor, not with a scope).

IIRC, there was a 6502-derivative like that. Rockwell?

Flash is a bottleneck these days.

Or use one of those Schmitt-trigger logic couplers. Or dump the opto part and just use an RC+Schmitt; he doesn't need isolation!

John

The data on the PS2503 looks good. I'll check availability.

I'll give it a try.

The Commodore 64 used a 6510 CPU from the 6502 family with the MOS Technology 6567 video chip. They shared the memory bus on alternate phases.

Cheers

Phil Hobbs