digital signal från optokopplare förvrängd..?

[jesse]

Jag försöker få två AVR-processorer att kommunicera via en optokopplare, men har misslyckats. Har inte kunnat förstå vad som är fel, men börjat fatta att det har med hårdvaran att göra på nåt vis.

Har gjort en "vanlig" koppling med optokopplare, med "släckt lysdiod" = idle, dvs. logisk etta på ingång/utgång på respektive processor.


(snedstrecken symboliserar kabel - alltså ingen komponent)

När jag skickar en puls på 100µS får jag i andra änden 240µS.
200µS => 340 µS, 1000µS => 1140 µS

pulsen förlängs alltså med ca 140 µS... men jag kan inte förstå hur?
Jag funderade på om det interna pull-up motståndet kanske var inaktiverat eller för högt (enligt databladet ska det ligga mellan 20 och 100 KΩ). Så när jag höll ett 10kΩ motstånd mellan ingång och +5V erhöll jag exakta signaler. När jag lödat dit motståndet visade det sig att exakt samma fördröjning låg kvar, dvs. 140 µS

Jag kom på att den exakta signalen erhöll jag då jag lade fingret på optokopplarens transistorsida, helst om jag nuddade basen på transistorn. Men jag lyckades inte erhålla samma funktion genom att sätta dit något motstånd. Basen ska ju inte heller behövas användas om optokopplaren fungerar som den ska. (jag mätte kontinuerligt pulser på 100, 200, 300 och 400 µS under tiden som jag pysslade) . Manipulering på lysdiodsidan gav ingen förändring.

Har jag gjort något korkat fel, eller är någon komponent (optokopplaren eller processorn?) trasig? Börjar bli smått tokig snart! Mitt projekt blir väldigt mycket försenat om jag inte får igång UART kommunikationen. (jag ska köra med 9600 BAUD)

Jag kan tillägga att jag använt både hårdvaru USART samt mjukvaru-timer och olika programsnuttar att mäta tiden med för att utesluta mjukvarufel. Alla varianter fungerar perfekt i simulator/debugger, men ger samma fel i hårdvaran. Så det kan inte vara mjukvarufel.

Jag har inget oscilloskop eller annat mätinstrument utan jag får förlita mig på processorn. Hjälp! Vad ska jag göra nu? Ska jag testa att byta optokopplaren?

[tecno]

Har du laborerat med satureringen av lysdioden i optokopplaren, hadde strul med drivern i gamla svarven jag byggde om från ABC80 till PC drift och fick då labba med satureringen för att få det hela att fungera.

[rehnmaak]

Vanskligt att göra felsökning på hårdvara utan scope. Enligt databladet (Fairchild) ska du få 2us (max 10) fördröjning med If=2mA och Rl=100ohm och Vcc=10V. Se figur 20 i databladet.

Mao, testa att minska drivningen på dioden och öka lasten på kollektorn.

[jesse]

Jo, men 140 µS ligger ju inte i närheten av dessa data. Och exakt samma koppling i motsatt riktning fungerar perfekt. RL - är det last vid transistorn? Det är ju extremt lågohmigt jämfört med en processoringång med 10k pull-up.

kanske har jag överdrivit nät jag kör If på över 20 mA genom lysdioden? Jag ville ha en säker switchfunktion och tog till rejält med ström. Men optokopplaren tycks ju fungera utmärkt vid 2 mA enligt datablad. Kanske ska sänka strömmen lite.

Det är så besvärligt att jag sitter i ett kontor och programmerar kretsarna, men har elektronikverkstaden på en annan plats i stan dit jag inte hinner åka så ofta just nu. Så det blir ett projekt varje gång jag ska löda en komponent. Och då gäller det att veta vad jag ska göra när jag väl är där.

[Icecap]

Har du 10K som pull-up vid processoringången är det en stor bov i detta.

Och att köra 20mA är på tok för mycket, det ger "total" mättning vilket ger mycket dåliga switchtider.

Om du istället håller kvar 10K pull-up och räknar baklängs med Transfer-ratio (sämsta värdet) och sedan ser vilken ström du ska mata in i LED'n lär du dels spara en transistor på LED-sidan och dels få mycket bättre switchtider.

Självklart ska du mäta DC i båda lägen för att se att den klarar av gränserna.

[xxargs]

Bottnade trissor är långsamma att stänga igen - och du kan bottna dessa med i det här fallet mycket ljus från LED i stället som normalt med för mycket ström via basen.

Dessutom en LED med mycket ström igenom tar tid på sig att tona av, av samma anledning som bottnad trissa - mycket kapacitans och laddningar som skall ledas undan innan det ger någon verkan på dess utgångarna.

mao. skall man köra med nästan helt stängt och nästan helt öppen trissa - dvs alltid mer eller mindre strypt, men inte helt strypt eller helt öppet då 'startsträckan' från helt stängt/helt öppet tills det börja rör på sig är rent tismässigt betydligt längre än själva omslaget när den väl kommer igång.

---

En sak måste man lära sig är att inom analogtekniken att mer effekt != bättre funktion - utan man måste hitta optimal arbetsfönster med lagom effekt/spänning/ström/impedans/dynamik i resp. arbetsläge för snabbast möjliga omslag i det här fallet.

Det är detta som gör att en RF-ingenjör kan sitta i flera månader med en enda RF-transistor för att hitta dess 'sweet spot' (och att kunna upprepa det i produktionsvolymer) medans en digitalingenjör kan hantera miljoner antal logiska grindar på samma tid... - men i slutändan är den där jäkla transistorn/drivsteget i ändan på alla miljoner grindar som avgör om systemet går att använda eller inte - som du har just märkt på ganska hårdhänt sätt

[jesse]

Tack för svaren, Icecap och xxargs, nu tror jag det börjar klarna.

Icecap: 10k pull-up är en stor bov? hur menar du? Har jag valt tokigt värde där? vad skulle du välja istället?

Låt säga att jag kör 2 mA genom optokopplaren istället (enligt databladet en helt acceptabel ström) och sämsta förstärkning är 0.50 dvs minst 1mA. Då bör väl 10k pull-up passa utmärkt, då spänningen över motståndet når +5V redan vid 0.5 mA. (antar att UCE on ≈ 0V)

Får sätta mig och räkna och mäta lite igen

[xxargs]

Utan instrument/oscilloskop får du helt enkelt prova dig fram med olika motståndsvärden, Oftast när UART inte vill ta in sekvensen ordentligt är att man har tappat symmetrin tidmässigt (duty rate) på bitströmen och råkat ut för asymmetrisk pulsbreddning genom optokopplaren av resulterande olika flanktider i upp resp. nedflank (dvs resulterar duty-rate 40/60 för upptid resp nedtid istället för 50/50). En del UART:s kan få verkligen tuppjuck av detta beroende på hur de samplar in datat internt tidmässigt och ev. letar efter 'mitten' i varje bit som kommer in och kalibrerar sig efter det löpande.

- även OP-ampar och speciellt komparatorer med OC-utgång och pullup (och som din driver till LED resp. transistorutgången) ger olika slewrate/flanktider beroende på om flanken går mot plus eller mot GND/minus med beroende av inkopplad (parasit)kapacitans.

Ironiskt brukar en mjukvaru-UART fungera bättre än hårdvaru-UART i sådana sammanhang - prova en sådan för teständamål och felsök med det om du kan.

---

Just det här är en av orsakerna till att i tex. RS485-fallet att man bör använda sig av transformatorer som isolering och mjukvarumässigt kodning av pulståget som är DC-neutral i ganska hög datatakt (över 200 kBit i paketen och med startsekvenser i början av paketen) istället för genom optokopplare just beroende på asymmetrisk pulsbreddning som lätt blir när man går igenom en eller flera optokopplare - förutom att optokopplare är långsamma och enkelriktade rent generellt gentemot vad som går att göra med trafo (se bara på ethernet)...

---

Jag säger nästan 'grattis', du har råkat på problem från i verkliga livet som normalt inte syns i labbbänksuppkopplingar, men väl när man skall implementer ute hos kund och försöka få betalt - skulle inte förvåna mig om du får olika beteende beroende på hur lång kabel/ledare som används till och ifrån optokopplaren på båda sidorna - då även kabel kan vara ganska kapacitiv och i kombination med driver med asymmetrisk drivförmåga (OC + pullup-motstånd) ger olika flanktidsfördröjningar beroende kablellängd för att OC snabbt sänker spänningen med stor strömförmåga och pullupen långsamt höjer spänningen igen för att den har liten strömförmåg etc..

[jesse]

>Ironiskt brukar en mjukvaru-UART fungera bättre än hårdvaru-UART

Jag kör egen mjukvaru-UART på den aktuella processorn och har dessutom lagt in en tidmätarfunktion som skriver ut tiden för varje 'nolla' som kommer in som har en noggrannhet på ett par µS när.

Men timingproblemen förvånar mig då jag kör med så pass låg hastighet (9600 baud) att eventuella up/ner -tider i hårdvaran borde vara helt försunbara även om man har lite konstiga värden (det handlar om 0.5-2 µS max) men jag får ju en fördröjning på uppflanken på otroliga 140 µS. Det är helt obegripligt hur det kan uppstå. Jag ska försöka få lite ledigt till helgen för att testa lite andra konfigurationer.

Tack för att ni tar er tid.

[limpan4all]

Obegripligt?
Inte då, det är mer eller mindre "spot-on" enligt databladen med dina värden på in och utresistanserna.

[sodjan]

> Det är helt obegripligt hur det kan uppstå.

Märkligt, med tanke på vad många har skrivit i tråden

[Icecap]

jesse: de tider tillverkarna anger är vid en optimerat koppling, den du anger är definitivt inte optimerat ur switch-tid synpunkt.

En sak man kan göra som sänker den generella känslighet är att ha ett stort motstånd mellan basen och emittern på optotransistorn, detta är dock ett dåligt sätt då man låsas till en viss typ optokopplare och det är inte "rätt" till att börja med, det är bara en symptombehandling.

[kimmen]

Hur lång är kabeln vid snedstrecken? Du kanske behöver något som laddar ur kabelkapacitansen snabbare. Ett motstånd parallellt med där kabeln går ut kanske? Att köra transistorn som emitterföljare i stället så den aldrig bottnas kanske kan ge lite extra fart också. Det borde inte vara jättemycket men iofs är transistorn ganska körd i botten med 5mA basström och endast 0.7mA för att ladda ur den.

[jesse]

kabeln är just nu bara ca 20 cm, men den kommer att vara mycket längre senare (kanske 2-3 meter)

... men folk använder väl optokopplare regelbundet vid sådan här överföring, det kan inte vara så att man ska behöva ha tur för att de ska fungera. Hur skulle man annars kunna massproducera något? Om jag lyckas med den här grejen kommer jag kanske att tillverka minst ett hundratal enheter. Då gäller det att jag har korrekta värden på komponenterna så att inte var tionde enhet strejkar sedan.

[sodjan]

> men den kommer att vara mycket längre senare (kanske 2-3 meter)

Verfiera designen med det då.

> det kan inte vara så att man ska behöva ha tur...

Så klart inte, och jag tror ingen sa det.
Man måste dock läsa databladen och ha lite erfarenhet i bagaget.
Utan det så behövs det sannolikt en hel del tur...