"Tvätta" digital signal

[Malgoe]

Hej!
Jag läser av en hastighetssignal från min bil med en ESP8266.
Signalen är 0-1.7kHz, 12V. Tidigare har jag kört med en spänningsdelare och zenerdiod som skydd (ESPn vill ha 3.3V). Jag vill nu isolera ESPn bättre från 12V-kretsen. Jag provade att köra med en optokopplare (PC817). Tyvärr blir det skidbackar när signalen går från hög till låg vilket gör att ESPn får problem med att mäta längden på pulserna.

Vad jag kan hitta så borde en schmitt trigger vara en lämplig lösning för att "tvätta" bort skidbacken. Jag kikar på 74HC17. Innan jag beställer en sådan: är det den bästa lösningen? Jag kommer även att köpa nya optokopplare i samma beställning. Finns det kanske optokopplare med inbyggda schmitt triggers? Jag har inte lyckats hitta någon, men erkänner att min google-fu är svag på elektronikområdet.

[Icecap]

Nu är en PC817 inget under av hastighet - men man kan komma en bra bit på vägen vid att faktisk beräkna de olika värden korrekt.

PC817 har en CTR på 50% och om man driver den hårt får man de vanliga problemer med mättning.

Om du t.ex. driver LED'n med 2mA styr den 1mA på utgången. Då bör du ha en pull-up/down (beroende på koppling) på 0,8mA. Detta bör ge mindre mättning och mindre skidbacke.

[persika]

Är det frekvensen som ska mätas?

[butthead]

Optokopplare brukar inte användas i fordonselektronik om det inte finns något alldeles speciellt skäl till isolation, vilket det inte verkar finnas i din applikation. Förmodligen så kör du med interna pull-up, vilket brukar vara i området 22k-100k, vilket skulle kunna förklara skidbacke på stigtiden tillsammans med parasitkapacitansen över c-e på optokopplaren. Plus optokopplarens egna stig och falltider. Prova att sätta ett externt motstånd på kanske 1k och se om det blir bättre. Om du nu måste använda optokopplare alls.

edit: Ladda ner LTspice (gratis) och simulera detta innan du beställer komponenter.

[YD1150]

6N139 är ett exempel på lite snabbare optokopplare.
74HC14 och CMOS-seriens 4093, 40106 är schmitt-trigger för att snygga till flanker med.

[Malgoe]

Ibland ska man ha en knuff i rätt riktning. Du har sparat mig några kronor och väntetid på en onödig beställning. Tack icecap!

Gjorde om min uträkning på motstånden och använde de rätta värdena den här gången. (Jag hade tittat för mkt på ett exempel där de påstod att PC817 hade 115% CTR och matade 4mA på dioden.)
Nu blev signalen riktigt bra

[Malgoe]

Persika: Ja. Jag mäter pulslängden några gånger per sekund och räknar ut frekvensen och sedan hastigheten från det.

Butthead:
Tre anledningar till att jag valt att slänga in optokopplare:

• Jag behöver lära mig (som ses på den här tråden )
• Bilen är 30 år gammal, jag litar inte helt på att insignalen håller sig till specifikationerna till 100%
• Jag vill inte råka introducera störningar i bilens elektronik för att jag kopplat eller programmerat fel

Jag litar inte på att jag alltid kommer ihåg att slå på pull-up i programmeringen, så jag har valt att köra med fasta motstånd utanför ESPn. LTspice ska jag kika på, tack för tipset!

Ibland är svaret så enkelt som att man behöver räkna rätt, och där satte icecap huvudet på spiken.

[ELTompa]

Om du kör med optokopplare i den här applikationen så är inte PC817, EL816 el liknande något bra alternativ. Precis som Icecap säger så kommer du hamna i bottningsträsket och en schmittrigger hjälper inte för du får osäker latency. Jag har labbat mycket med detta för att få budgetoptokopplare att prestera bättre men det slutade med att jag tog en 6N137 och då funkade allt perfekt.
Ni andra i forumet få gärna säga jag har fel för jag är fortsatt nyfiken på trix att få mer speed i PC817 och dess ekvivalenter

[hcb]

Mycket trevligt med återkopplingen, bra gjort

En möjligen dum fråga: varför mäter du pulslängden om det är frekvensen som är det väsentliga? Eller har jag missförstått?

[Malgoe]

ELTompa: När jag handlar nästa gång kanske en bättre modell hamnar i korgen. Men: vad är måttet på "inte bra"? När jag kopplat rätt så fungerar det. Vid högre frekvenser kan jag absolut tänka mig att jag behöver något bättre, men i det här specifika fallet förstår jag inte varför PC817 inte skulle vara bra när det fungerar? Är det något jag missat att tänka på?

hcb: Nu är jag inte världens bästa programmerare, men för att få ut frekvensen kan jag tänka mig tre varianter:

• Mät längden på en puls och räkna ut frekvensen baserat på det (mitt val just nu)
• Använd en interrupt för att räkna upp en räknare vid varje puls, kolla värdet på räknaren varje sekund och få fram frekvensen
• Ligg aktivt och räkna varje puls under 1s, summera och få fram frekvensen

Tänk på att ESPn ska göra fler saker. Den övervakar strömförsörjning, bränsle och temperaturdata, ska uppdatera en skärm m.m.
Det första alternativet som jag valt har fördelen att det går snabbt och kräver väldigt lite resurser. Jag kan missa snabba frekvensförändringar, men om jag mäter 2ggr/s så är resultatet "good enough" för mig.
Det andra alternativet, med interrupten, kräver att jag kan kolla räknaren exakt varje sekund. Om något annat i min kod snott processortid så kanske jag kollar för sent och får ett felaktigt värde. Dessutom är jag osäker på om en interrupt som ibland körs med en frekvens på 2kHz inte tar för mkt processortid från annat.
Det tredje alternativet låser upp processorn under hela tiden som man räknar, jag kan inte göra någonting annat. Men resultatet borde vara hyfsat noggrant.

Jag är ytterst ödmjuk vad gäller mina kunskaper. Har du förbättringsförslag tar jag glatt emot dem.

[mrfrenzy]

Det finns en inbyggd pulsräknare som ligger och räknar i bakgrunden. Med den kan du mäta frekvenser noggrannt upptill 40 MHz utan problem.
Det finns ingen risk att "missa pulser" för att processorn gör annat.

Här är ett bra exempel https://github.com/DavidAntliff/esp32-f ... aster/main

[hcb]

Icecap som är många tiopotenser bättre än jag på detta förespråkar avbrott för att mäta frekvenser/pulser (precis som mrfrenzy tipsat om). Låt mig knuffa dig i den riktningen

[Malgoe]

mrfrenzy: Hmm koden på länken pratade om ESP32, så jag googlade lite. OM jag fattat rätt så har ESP32 en hårdvaruräknare, men inte ESP8266?

[mrfrenzy]

Mitt fel, jag såg av någon anledning ESP32 i texten fast du inte skrivit det

Rätt sätt på ESP8266 som tidigare skrivit är att använda ett interrupt som räknar upp en variabel varje gång pulsen triggas. Detta tar bara några mikrosekunder sedan fortsätter din kod som tidigare.
I bakgrunden kör du en av dom inbyggda timerna.

Varje gång du vill veta aktuell hastighet kollar du bara tiden på timern och dividerar med antalet pulser i variabeln sedan sist. Du behöver inte "träffa rätt" och göra beräkningen vid något speciellt tillfälle.

[ELTompa]

ELTompa: När jag handlar nästa gång kanske en bättre modell hamnar i korgen. Men: vad är måttet på "inte bra"? När jag kopplat rätt så fungerar det. Vid högre frekvenser kan jag absolut tänka mig att jag behöver något bättre, men i det här specifika fallet förstår jag inte varför PC817 inte skulle vara bra när det fungerar? Är det något jag missat att tänka på? ...

Du har rätt i att det är inte så hög frekvens så det kan fungera. Det jag är orolig för är över temperatur. Om det ska sitta i en bil är det ganska stort tempspan jämfört med att ligga på skrivbordet. Så var vaksam på vad som händer utanför 20-25C.