Hoi fcapri,
Ik ben onderweg dus kan kort reageren. Wanneer je meer wilt weten over NTC zoek bij en.wikipedia.org dan eens op thermistor.
De handigste formule is met een negatief exponentiële kromme, ge karakteriseert door een zogenaamde bèta waarde en een waarde bij een bepaalde temperatuur (vaak 25 graden).
De meest nauwkeurig ia de steinhart -hart vergelijking maar dat is een Draak(je)...
Wat ik makkelijkst vind is een lookup tablet te gebruiken, per 5 graden, en daartussen lineaire interpolatie.
Je krijgt dan de volgende stappen
1. Bereken uit de adc waarde de weerstand waarde.
2. Wandel door de tabel om de twee waarden te vinden waartussen de weerstand zich bevindt.
3. Lineaire interpolatie.
Nog twee opmerkingen :
1Als je de curve door twee moet delen wanneer zet je dan geen twee NTC parallel?
2 Wanneer de spanning over een NTC hoger wordt krijg je zelf opwarming. Typisch school 1-20mW per Kelvin, dit hangt af van de grootte van de keramiek.
3 je kunt de drie stappen van bovenstaande algoritme ook comprimeren door de stappen op een pc door te rekenen en dan direct van adc waarde naar temperatuur. Nadeel is dat compensatie van afwijking wat lastiger is.
Mocht je nog vragen hebben...
Groeten,
Cor
Op 6 januari 2017 21:39:35 schreef blackdog:
Kan je geen 18DS20 toepassen?
het is het digitale dashboard van mijn golf. die gebruik ik voornamelijk om de brandstof tot op de liter nauwkeurig te meten (werkt tamelijk goed, enkel wat afwijking door het vriesweer. ipv 48-0liter kan ik nu van 50liter tot -2liter rijden.
ik gebruik de originele temperatuursensor die in het motorblok zit, deze wordt aangestuurd door een stroom vanuit het dashboard. ik weet dat de teller zicht gedraagt als een 57,7ohm weerstand.uit de meetspanning kan ik dus de sensorweerstand halen, maar dat is dus die hyperbool. ofwel gooi ik 100waarden in een tabel (0-100°C) maar dan krijg ik problemen bij vriesweer, ofwel moet ik een 'formule uitdokteren' die de hyberbool evenaart waardoor ik ook buiten die grafiek tamelijk correct kan meten.
Op 6 januari 2017 21:46:21 schreef Bert_Camper:
Zet er eens 3,9kOhm aan parallel, dan kom je al dichter bij de waarde die je wil bereiken. Als het verschil nog te groot is, wat experimenteren met de waarde.
sensor zit in de auto, kabelboom van de auto regelt alles. ik krijg een meetspanning van 6-9,9V, bereken daaruit de NTC weerstand en loop dan vast.
op deze grafiek zit ik vanaf 40-100°C PAL erop, maar nu bij het vriesweer zegt mijn auto dat het 5-10°C is, net door de grove afwijking in de linkerkant. (1600ohm is volgens de sensor dus 10°C op de blauwe lijn, mijn arduino berekent de roze lijn en zegt dat het 20°C is)
ik probeer nu en formule te vinden voor die grafiek. ik kom aardig in de buurt
http://www.fordcapri.be/off/pics/eo/grafieken/
die H1-H2-H3... waarde in de formule is die 10-20-30°C op de Xas (excel sheet).
ik gebruik een formule zoals
x / (R + y) + z.
die z waarde schuift de grafiek evenwijdig omhoog en omlaag.
die x waarde bepaald hoe plat of hoe recht de grafiek staat (roteren curve)
de y waarde bepaald waar ergens je in de hyperbool zit (die heeft een knikpunt die dan altijd vlakker wordt)
Op 6 januari 2017 21:46:56 schreef pax:
1Als je de curve door twee moet delen wanneer zet je dan geen twee NTC parallel?
ik moet die curve niet delen. ik heb een curve gevonden van een blauwe bosch sensor die VW gebruikt.
echter heeft die een weerstand van 220-280ohm bij 90°C en de mijne heeft daan 112ohm (de helft dus van de onderste grafiek lijn)
op 10°C heeft die grafiek een weerstand tussen 3250ohm en 4250ohm, ik heb ongeveer 1600ohm. exact de helft dus. als ik de Yas halveer, heb ik exact mijn NTC curve. aangezien ze dezelfde kromming en curve hebben, moet er toch een 'algemene' formule bestaan die zo een NTC beschrijft. en die zoek ik.
ga nu ff die thermistor gaan lezen
EricP
mét CE
Ik denk dat ik de luie weg zou kiezen en een lookup table zou bakken. Het aantal waarden is beperkt - als je wat voor elke 5 graden maakt en daartussen lineair interpoleert, dan kom je al een heel eind denk ik. Welnu, die look-up table met 30 entries mag het probleem niet zijn...
En mocht dat je te onnauwkeurig zijn, dan kun je ook naar elke 2 graden ofzo toe. Kost alleen wat meer flash, maar ik gok erop dat je daar zat van hebt.
niet echt, de arduino zit al redelijk stampvol. mijn parkeersensoren kunnen er niet meer bij omdat het geheugen vol zit.
mijn geschreven code is 21kb groot, en daar moeten dan nog libraries bijgeladen worden. (arduino nano heeft 30kb geheugen dacht ik)
ik heb wat verder geknutseld en hier een samenvatting gemaakt met de formule die ik gebruik en wat elke waarde van impact heeft
die steinhart -hart vergelijking en alles wat er volgde daarop was echt chinees voor mij. dat wordt te ingewikkeld om nog te begrijpen, laat staan dat ik dat in programmeertaal kan gieten
EricP
mét CE
Dat mag dan wel zijn. Maar als je een lib moet gaan meelinken die een log ofzo implementeert... Of met floats moet gaan werken... Dat is ook niet echt 'gratis' qua code size. Tenzij je dat toch al mee neemt voor wat anders...
Verder ken ik dat Arduino taaltje niet zo. Wat ik ervan gezien heb is dat de meeste libraries van bedroevende kwaliteit zijn, inefficiënt in elkaar zitten... Maar functioneel zal het meestal wel ongeveer doen waar het voor bedoeld is.
21k aan gecompileerde code voor een controller... Is best een hoop. Tenzij het natuurlijk... inefficiënt in elkaar zit (door het gebruik van een veelvoud an libraries). Letwel: het zegt wat over waarin je programmeert, niet noodzakelijkerwijs over wat je zelf verzonnen hebt.
Excel heeft het antwoord. Meet bij een aantal bekende temperaturen de NTC , maak er een (spreiding>lijn) grafiek van en voeg een trendlijn in met de optie 'formule weergeven' aan. Je krijgt dan een mooie formule, en kunt kiezen uit een aantal benaderingen ( lin/log/exp etc ) zodat je ook nog kunt zien hoe mooi de lijn loopt. Geen wiskunde of zo nodig!
Zo kan ik zelfs per ntc/ptc altijd een zo goed mogelijk resultaat halen.
EricP
mét CE
Ik geloof er niks van dat die bij benadering vastgestelde formule in deze nauwkeuriger gaat zijn dan een slimme look-up. Ik geloof wel dat ln() best wel eens duur zou kunnen zijn qua performance en codesize. Al is het alleen maar omdat er met floats gewerkt wordt, en dat zijn nou eenmaal horken van dingen...
Op 7 januari 2017 08:33:24 schreef EricP:
21k aan gecompileerde code voor een controller... Is best een hoop. Tenzij het natuurlijk... inefficiënt in elkaar zit (door het gebruik van een veelvoud an libraries). Letwel: het zegt wat over waarin je programmeert, niet noodzakelijkerwijs over wat je zelf verzonnen hebt.
21k aan geschreven code.
daarna worden die libraries toegevoegd en alles gecompileerd en daarbij zit ik dan aan 28kb gecompileerd of een goeie 92% van de capaciteit van de arduino.
die TFT librarie gaat met heel veel resources lopen.
Op 7 januari 2017 08:35:55 schreef Peter112:
ter info
http://garagelab.com/profiles/blogs/tutorial-using-ntc-thermistors-wit…
die is goed, echter kan ik de librarie niet gebruiken aangezien ze de weerstand zelf aansturen, en ik moet die berekenen uit een gemeten spannint uit de auto (ik heb die 3,3V en die 10Kohm nie in de hand).
heb wel die beta factor methode gebruikt en zit aardig goed
Op 7 januari 2017 10:41:29 schreef EricP:
Ik geloof er niks van dat die bij benadering vastgestelde formule in deze nauwkeuriger gaat zijn dan een slimme look-up. Ik geloof wel dat ln() best wel eens duur zou kunnen zijn qua performance en codesize. Al is het alleen maar omdat er met floats gewerkt wordt, en dat zijn nou eenmaal horken van dingen...
Voor een lookup moet je wel veel meer meetpunten vaststellen, en als je de spanning over de NTC wilt meten wordt het nog een gedoe om steeds op een afgeronde waarde uit te komen. Anders krijg je een lookup van floats immers.
Die Ln ( log bij arduino/C++ ... ) kost in dit geval een paar honderd byte, dus dat valt mee, helemaal als je de math library toch al gebruikt. Resultaat kan meteen naar een int:
int b = -25.618 * log(500) + 196.32;
Een lookup doorlopen zal niet veel minder zijn, want tussenliggende waarden moet je alsnog interpoleren.
(Het wordt pas erg als je een float wilt printen, want de print class van de arduino is nogal groot en inefficient.)
Ik vond het voordeel van een benadering dat je als input iedere waarde kunt gebruiken. Dus ook de in dit geval gemeten spanning over de NTC. Zolanf er maar een verband is.
Ik heb een meter met een aantal NTC's , dompel , aanleg en lucht met een analoge meter . Daar zit een schakelaar op om het meetbereik om te schakelen en de meter heeft twee niet lineaire schalen . Oud ding maar wel mooi en de ntc's zijn goed op eentje na.
Kun je dat niet doen dat je afhankelijk van je meetspanning omschakeld naar een andere formule . Met 1 simpele formule krijg je het niet voor elkaar , met twee simpele formules kom je een heel eind , met lookup nog beter en met de exacte formules helemaal goed .
EricP
mét CE
Voor een lookup moet je wel veel meer meetpunten vaststellen
Veel meer dan wat?? Zoals gezegd... Neem elke 5 graden wat en interpoleer lineair daartussen. Is dat je echt te weinig, dan neem je elke 2 graden wat... Dan heb je denk ik al meer nauwkeurigheid dan de betreffende sensor. Meer dan 'naaldje in het rood' geeft VW daar ook niet weer...
en als je de spanning over de NTC wilt meten wordt het nog een gedoe om steeds op een afgeronde waarde uit te komen.
Dat moet je ff uitleggen... Je input is de waarde van een ADC (en dus per definitie een integer...), de output de temperatuur - al dan niet geïnterpoleerd.
Anders krijg je een lookup van floats immers.
Nee, die krijg je dus niet...
Die Ln ( log bij arduino/C++ ... ) kost in dit geval een paar honderd byte,
duur dus, zoals ik reeds vermoedde...
math library toch al gebruikt.
Zit dat link time zo onhandig in elkaar dat als je 1 functie gebruikt dat je dan meteen alles mee krijgt? Da's ongebruikelijk bij de meeste libs. Een lib is immers niks anders dan een stapel bij elkaar geharkte object files die je met libtool oid. in 1 file harkt. De linker trekt daar uit wat-ie nodig heeft - en als het een beetje handig in elkaar zit, dan heeft vrijwel elke functie z'n eigen object file. Zodat je dus niet mee neemt wat je niet nodig hebt...
Resultaat kan meteen naar een int:
int b = -25.618 * log(500) + 196.32;
Dus toch rekenen met floats - dan heb je dus ook een stuk nodig wat dat kan emuleren. Het controllertje zelf gaat het in tegenstelling tot integers niet doen...
Een lookup doorlopen zal niet veel minder zijn, want tussenliggende waarden moet je alsnog interpoleren.
Wel dus. Die interpolatie is niks anders dan een paar integer berekeningen. Het staat of valt met de table - en hoeveel entries je daar in wilt frutten (cq. denkt nodig te hebben).
(Het wordt pas erg als je een float wilt printen, want de print class van de arduino is nogal groot en inefficient.)
Een print is altijd groot. Dat kan ook niet anders, al die formattering die je als parameter mee kan geven, moet natuurlijk wel een achterliggend stuk code hebben. En er zijn nogal wat mogelijkheden... Duh...
Overigens weet ik niet of ze het zo slim in elkaar gezet hebben dat de print voor floats in een ander object file (in dezelfde library) zit als de integer print. Je zou het wel verwachten, anders heb je alle 'kennis' van floats ook aan boord als je alleen maar integers nodig hebt. Zo dom heeft men het vast niet verzonnen.
Ik vond het voordeel van een benadering dat je als input iedere waarde kunt gebruiken. Dus ook de in dit geval gemeten spanning over de NTC. Zolanf er maar een verband is.
Dat lijkt me erg onhandig... Om de spanning van de NTC te gebruiken. Moet je eerst de output van de ADC gaan converteren, om daar vervolgens weer een dure benadering op los te laten. Niet handig, veel afronden, en duur qua code.
ik heb die beta factor methode gebruikt en kwam aardig in de buurt.
die coeffient op 3400 en als 'fabriekspunt' had ik 30°C genomen bij 730ohm (de enige waarde van fabriek die ik heb is die 112ohm bij 90°C maar krijg enorm afwijking als ik die gebruik)
°C - ohmse R - berekende °C met arduino
-2 2700 -1,4
10 1600 10,5
20 1100 19,7
40 500 40,98
70 200 70,03
90 112 91,4
100 95 98
ik was al dik tevreden met de resultaten, alles in de arduino gepompt, direct de auto een update gegeven, ik zet contact aan en ik krijg -17°C op het dashboard ipv -2°C (met de vorige berekening had ik +6°C).
heb ik een heleboel moeite gedaan om het exact te berekenen, en krijg ik nog slechter resultaat door de opbouw van de auto.
ik heb de weerstand gemeten en die zat op 2803 ohm deze morgen, iets kouder dan -2°C dus. wat gebeurt er nu:
de spanningsregelaar van 10V stuurt een stroompje door 2803 ohm + 57,7ohm. daar komt dus een spanning uit van 9,9V.
als ik daaruit de weerstand bereken:
R = ( (57,7 * 9,9) / (10V - 9,9) = 5712ohm ipv 2800ohm.
ik zit veel te dicht tegen de voedingsspanning aan (door het grote verschil in weerstanden) de arduino meet te onnauwkeuring daar en met de berekeningsafrondingen krijg ik enorme verschillen.
als ik bv met 9,89V zou rekenen dan is mijn weerstand al 600 ohm kleiner.
ik heb dan maar deze formule in mijn oude code gegoten en kreeg instant 3°C op het display (de auto was wel al eens gestart, ik ga vanavond in de koud nog eens checken wat die meet). probleem is ook dat die spanningsregelaar van 10V bij stilstaande motor ook geen 10V output meer geeft waardoor ik nog meer fouten krijg (die geeft bv maar 9,3V af omdat de voedingsspanning in de auto maar 11,5V meer is en dat komt overeen met 30°C)
Op 7 januari 2017 13:28:34 schreef EricP:
[...]Veel meer dan wat?? Zoals gezegd...
Tja, als je niet wilt hoeft het niet. Je hebt niet duidelijk niet alleen een hekel aan LED's maar ook aan floats. Een lookup met resolutie van twee graden en bereik -10 tot 100 is ook 55 x 2 waardes = 110 x 2 bytes ( 16 bit int ) = 220 bytes. En daar komt de code nog bij.
En 55 meetpunten is heel wat meer dan pakweg 5 bij een regressie formule.
Overigens hoeft de adc alleen waardes te geven zoals je zelf al zegt. Dus omrekenen is niet nodig. Maar de temperatuur moet je wel op een tiende doen. Of je moet natuurlijk die met een factor 10 vermenigvuldigen om op een integer uit te komen.
EricP
mét CE
Tja, als je niet wilt hoeft het niet.
Dat is geen antwoord op de vraag. Of heb je dat niet?
Je hebt niet duidelijk niet alleen een hekel aan LED's maar ook aan floats.
Nee, ik heb de kennis om te snappen dat die dingen op een controller helemaal niet prettig zijn. En ja, het kan, nee, niet doen als het niet nodig is.
Een lookup met resolutie van twee graden en bereik -10 tot 100 is ook 55 x 2 waardes = 110 x 2 bytes ( 16 bit int ) = 220 bytes. En daar komt de code nog bij.
En die code stelt nou juist geen reet voor. Dus zelfs met een resolutie die veel hoger is dan de sensor ooit aan reproduceerbaarheid gaat halen, komt je nog gunstiger uit.
Tienden heb je niet nodig (zeker niet bij een benadering), dus je red het met 1 byte. Je zou het zelfs nog als een signed 8 bit int kunnen doen - genoeg voor de temperaturen van koelvloeistof en je hoeft niks om te rekenen...
En 55 meetpunten is heel wat meer dan pakweg 5 bij een regressie formule.
Dat klopt. Dus daar introduceer je al een stuk onnauwkeurigheid waar je om de een of andere reden niet aan wilt. En juist de functies die die formule gebruikt, maken het ding onhandig op het moment dat memory een issue is. Uiteraard is er een formule voor. Maar dat is niet altijd de handigste oplossing...
Je zou eens kunnen kijken hoe groot de afwijking van de realiteit is met elke 5 graden een punt. Dat zou nog wel eens verbazend goed kunnen gaan.
Overigens hoeft de adc alleen waardes te geven zoals je zelf al zegt.
Nou ja, jij liep te piepen over een lookup table van floats... Blijkbaar had je het concept toen nog niet helemaal door...
Dus omrekenen is niet nodig.
Dat moet je wel, want die waardan gaan nooit handig 'mappen'. Maar da's allemaal simpele integer trucjes - kost nauwelijks code en geen library voor nodig...
Maar de temperatuur moet je wel op een tiende doen.
Wie zegt dat en waar staat dat? Zelfs bij een 1-Wire sensor is dat meestal zinloos, omdat die nauwkeurigheid toch niet gehaald wordt. Leuk dat je het zelf verzint, maar ja... non-informatie is ook informatie. Ofzo.
Of je moet natuurlijk die met een factor 10 vermenigvuldigen om op een integer uit te komen.
Als dat zinvol zou zijn, dan zou je dat kunnen doen. En je moet niet met 10 vermenigvuldigen, je moet door 10 delen - als het zinnig zou zijn. En dat doe je het handigst door botweg in je presentatie de punt neer te zetten. Wederom geen libraries of floats voor nodig...
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
Op 7 januari 2017 18:11:00 schreef gart_nl:
[...]Je hebt niet duidelijk niet alleen een hekel aan LED's maar ook aan floats.
Nou hij is niet de enige. Op een 8 bit controller floats gebruiken is een regelrechte ramp. Heb je ooit gezien hoeveel zooi aan code daar uit komt?
Dat is leuk voor een PC of ARM embedded bordje waar een FP coprocessor in zit. Op een kleine uC dus onbruikbaar.
Effe on topic: Als je de spanning van de sensor al niet nauwkeurig genoeg kunt meten hoef je nog niet eens te discussieren over een fit-curve.
Ik zou dus eerst eens zorgen dat je de spanning op de sensor analoog conditioneerd tot een fatsoenlijk bruikbare waarde (desnoods via een non-lineair circuit) die je wel met een bruikbare resolutie kunt meten.
De meeste toepassingen gebruiken een simpele LOG curve (geen hyperbool dus) met de beta waarde om de temperatuur terug te rekenen.
Om een goede fit curve te maken heb je eigenlijk een 3-de orde polynoom nodig (ipv alleen de beta waarde). Maar dan hebben we het over 0.1% resoluties. In dit geval kom je nog niet eens met je ADC waarde in de buurt daarvan. Dus zinloos om daar zoveel effort in te steken.
Hier staat een stukje over de formules:
http://www.vishay.com/docs/29053/ntcintro.pdf
Zie pagina 3 hoe de beta waarde is gedefinieerd. En een verdere uitleg over een 3-de orde polynoom.
beter meten kan gewoon niet.
als je het contact over haalt, begint de voorverwarming van de dieselmotor te werken waardoor de accuspanning naar 11,5V zakt.
de spannningsregelaar op het dashboard maakt een 10.0V maar bij dermate lage accuspanning zakt die zijn spanning ook.
ik zou een lagere spanningsregelaar kunnen steken (bv 7809 misschien) maar dan zal het originele dashboard foutief gaan meten,
of ik trek kabels bij waarbij ik dan de outputspanning van die regelaar ook apart ga meten met de arduino en die meeneem in de berekening.
beetje nutteloos vind ik voor die 20sec dat de motor nog niet is gestart
met die benaderde formule vind ik het aardig goed werken. ik krijg tenminste al geen +6°C op het dashboard als het aan het vriezen is.
het zou volgens buienradar -1°C zijn buiten, en heb net ff de auto gestart. op het dashboard kwam er -1°C met 13,2V accuspanning, en deze sprong naar -2°C bij 13,7V accu spanning. die zit dus kantje boordje op -1,5°C met zijn meting.
ik vind het goed genoeg zo, heb weeral veel bijgeleerd over die 'curve'. het blijft ingewikkelde materie.
ik krijg namelijk de vraag of mijn ontwerp ook te koop komt, er zijn nogal wat oldtimerliefhebbers die ook wat meer info willen over hun auto. waaronder een exactere temperatuur/brandstofniveau en accuspanningsmeting.
ik ben van het bovenste naar het onderste gegaan door de jaren heen
http://fcapri.homelinux.com/off/pics/eo/arduinodash/640/dashboards.jpg
het brandstofprobleem heb ik opgelost.
je rijd de auto compleet leeg en ga naar een tankstation, je kan dan in een menu gaan bij de arduino (via 1 drukknop) waarbij je de huidige waarde als 'leeg' instelt, daarna tank je vol, ga je weer in het menu en neem je de nieuwe tankwaarde als 'vol', bijkomend geef je ook het aantal liters in dat je tankte. op deze manier kan je de arduino in éénder welke auto steken en aansluiten.
ik hoef zelf niet om te rekenen naar spanningen, ik kan gewoon de binaire waarde van de adc rechtstreeks gebruiken in de map.
het blijft alleen onmogelijk om dergelijk te integreren voor de temperatuursensoren, tenzij ik extra sensoren meelever om bij te steken in het koel/olie circuit
rew
four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
Op 8 januari 2017 01:15:05 schreef henri62:
Heb je ooit gezien hoeveel zooi aan code daar uit komt?Dat is leuk voor een PC of ARM embedded bordje waar een FP coprocessor in zit.
Op mijn ARM-zonder-FP kost het me 8K flash om de eerste FP berekening te doen. Ik heb nu even: "mij best, ik ga straks toch nog steeds in de kleinste van de serie passen, dus nu even concentreren op het correct krijgen van de rest". (de berekening in mA wilde even niet lukken, ik meet amperes met een paar cijfers achter de comma).
EricP
mét CE
En dan maar hopen dat de FP lib nog een beetje fatsoenlijk in elkaar zit...
[oude doos]Ooit, heel lang geleden, ergens in de vorige eeuw, kwam ik ooit eens ergens in loondienst. Programmeren kon ik wel, C nog niet (ben begonnen met Pascal, Basic en assembly op 6502 en 8088). Je mag op 'cursus C'. Een van de opdrachten was was financieels in elkaar douwen. Iedereen deed dat met floats, deze eigenwijs niet. Die werkte met ints, waarschijnlijk een tik uit de assembly hoek. Was natuurlijk niet goed volgens de coaches. En er zat nog meer raars in, want de uitkomsten kwamen niet overeen met wat ze zelf hadden.
Afijn, rekenmachine erbij, handmatig narekenen... Mijn uitkomst klopte prima, maar die van hen niet. Bleek dus in de M$ FP lib iets niet helemaal lekker te zitten waardoor de floats die je netjes afrondde toch niet helemaal afgerond bleken te zijn en als je ze nou maar vaak genoeg bij elkaar optelde en wat vermenigvuldigde kwam dat ergens een keer boven. Daarnaast was de door bij geproduceerde executable nog geen 50% in omvang van wat ze zelf verzonnen hadden.
Vanaf toen had ik inderdaad definitief een hekel aan floats 
[/oude doos]
@fcapri: leuk om dat spul te verkopen of 'vrij' te geven. Ik heb die 'fout' ook eens met zoiets gemaakt. En dan verwachten de mensen opeens ook dat je er support op gaat geven. Want een steeksleutel vasthouden, dat lukt nog. En nou iets met draadjes... Ik ben er snel van genezen. Kost veel teveel tijd.
Wel grappig dat je eea. zo behoorlijk aan de gang krijgt. En als het dan nog redelijk werkt ook...
bijgeleerd over die 'curve'. het blijft ingewikkelde materie.
Nou ja, zo ingewikkeld is het niet - analytisch gezien. De implementatie op een 8-bitter maakt het een klein beetje ingewikkelder. Als je je ADC waarden naar bijvoorbeeld 8 bits terug brengt, dan ben je er al met een look-up table van 256 bytes - voor de hele range. En de code is dan echt 'niets'.
Mocht je nog wat met olietemperatuur gaan doen: pas op met veel digitale sensors. Dat houdt meestal bij een dikke 120oC wel op, terwijl olie (als ik de documentatie van een aantal motoren mag geloven) ruimschoots warmer kan worden.
ik heb geen nut aan olie temperatuur, eigenlijk intresseert de watertemperatuur me ook maar weinig, het was bitterweinig verschil met de brandstofmeter. gewoon de spanning aftakken van het metertje achterop de tellerunit en afgelopen. heb je smorgens ook een idee hoe koud het precies is. want ijs afkrabben bij -1 of -10 maakt wel wat verschil. had ik geweten dat het zoveel ellende ging zijn, ik had het nooit toegevoegd.
accuspanning is wel essentieel. vroeger had ik 5 ledjes op het dashboard,
meer dan 10V - 12V - 13V - 14V - 15V.
de eerste en de laatste waren rood, 12V was oranje.
13 en 14V was rood.
op een dag reed ik naar het werk (266km woon werk verkeer per dag) en het 14V ledje ging uit. kwartiertje later ging 13V ook uit, daarna begon 12V te knipperen...
op het werk aangekomen en de accuspanning gemeten, en idd, de spanning zakte.
savonds thuis de kooltjes uit de dynamo verwijderd en die waren op.
zonder die ledjes zou mijn auto 2-3dagen later door het verbruik van de koplampen enzo ineens niet meer starten. ben ik blij dat ik het op voorhand wist. en nu wou ik het toch iets precieser. want als 14V uitging, is dat dan 13,99V of is die naar 13V aan het zakken (bij de ene laad de accu, bij de andere niet meer).
wat ik zou willen maken is een printje met de spanningsregelaar op (voor het lcd), de arduino erop, een lange kabel (of achterop gemonteerd) naar het scherm en 1/2 of 3 drukknopje(s) om het menu in te stellen. bij brandstof peanuts, bij accuspanning heb je normaal niks te doen, bij temperatuur... miserie weer, de datum/tijd wordt bij mij geprogrammeerd in de RTC via de arduino, en de code reeds geprogrammeerd.
daarna moeten ze enkel zomer/winter uur instellen (zou ik eventueel kunnen automatiseren ook, t is immers altijd de laatste zondag van maart/oktober).
keuze uit 0,96", 1,44", 1,8" LCD of 2x16/4x20 karakter lcd schermen.
maken ze het display/arduino kapot, dan kan ik altijd een andere voorzien tegen betaling (source code niet vrijgeven).
ikzelf ga het toch universeel maken zodat ik het kan inbouwen in mijn oldtimer fords. bij de golf heb ik afgetakt op de tellerunit achterop, maar bij andere autos zou ik het signaal op de tankvlotter willen gebruiken( zodat je niet je halve dashboard eruit moet slopen om de kabeltjes te vinden).
de meeste geintresseerden kunnen hun auto van scratch opbouwen, maar kennen niks van programmeren. die kan ik dus ook niet uitleggen hoe ze zoiets zelf moeten maken
EricP
mét CE
Wel weer grappig hoe iedereen z'n prioriteiten anders legt
De boordspanning interesseert mij nou weer geen biet - als die koolborstels aan hun eind zijn, dan val de bekrachtiging wel weg, gaat vanzelf dat mooie rooie ledje branden (of eigenlijk: in den beginne flauw knipperen, bij hogere toerentallen weer uit, zo leert de ervaring). Toegegeven, je zou wat kunnen missen als de spanningsregelaar zelf de geest geeft.
Brandstofniveau vind ik qua nauwkeurigheid ook niet zo heel interessant. Als in: of er nou nog 1 of nog 5 liter in zit, het is toch wel tijd om te tanken
Zorg in elk geval dat je AVR ingangen een beetje hufter-proof worden uitgevoerd. Bij de VW heb je niet zoveel last van spikes op het boordnet (vrijwel alles wordt door die regelaar op de tellerunit wel opgevreten), maar niet iedereen doet het op die manier.
Overigens is 'support' vaak nog op een veel basaler niveau: de voorruit lekte, en nu doet-ie het niet meer (koop maar een nieuwe). Of: waarom wordt het koelwater warmer dan de olie? (nou, als je de sensor waar 'olie' op staat in de carterpan monteert en die waar 'water' op staat in de kop, dan klopt het). *Ik* had dat soort dingen van tevoren niet verzonnen...
Voor wat betreft dat dashboard... Ik kan het mis hebben, maar eh... volgens mij moet dat klokken paneel er toch voor een groot deel uit om het display te kunnen monteren, niet?
Maar goed, succes. Wel leuk dat mensen dit soort dingen in hun oldtimer toelaten en niet altijd 100% 'origineel' willen...
ik doe nogal veel km's met de oldtimer en had in de week echt geen tijd om eraan te werken.
een falend laadcircuit hoef ik echt niet te hebben en een auto die om 4h smorgens niet start ook niet. ik weet graag 2-3 dagen op voorhand als iets begint te sneuvelen.
dat rode lampjes van de dynamo (bij VW is dat een rode led) doet het pas als de dynamo NIKS meer doet. toen bij mij de spanning terugviel naar 12V en soms zelf eronder, brande het dynamo lampje nog steeds niet, de dynamo genereerde wel nog spanning, maar leverde geen stroom meer.
dus tenzij je dynamo naar 0V valt, zal het lampje anders niks doen. dat zwak branden zou pas beginnen als je laadspanning naar 6V terug valt (12V van de accu en 6V van de dynamo over de 2 lampaansluitingen is een zwak brandend lampje).
brandstofniveau vind ik heel intressant. aangezien ik 120km lang op de autosnelweg rijd en ik weiger die dure brandstof te tanken, wil ik graag weten of ik smorgens nog naar het werk geraak of eerst moet tanken.
als je naaldje op 1/4de staat, kan je dan nog 250km rijden, of 270 km (met 266km woon-werk maakt dat wel uit of je thuis geraakt of niet).
men broer werkte bij VW en zei me ooit: "bij die golfjes mk2 mag de naald tot onder het rode gebied gaan, die blijft nog rijden".
dat heb ik ooit getest en toen het naaldje net op het onderste van het rode stond, viel de auto uit. om 2h snachts op een zaterdag wil je dat niet meemaken. gelukkig stond ik heel hoog en was er onder de berg een tankstation. ben ik naar daar gebolt. er was iemand aan het tanken en die trok wel een raar gezicht toen die zo een stille golf zag aankomen
ivm dat display inbouwen: vele mensen willen een auto origineel houden en gaan de tellerunit niet verknippen. die gaan zo een display inbouwen in één van de ventilatieroosters en met een schakelaar aan/uit schakelen.
en nog mooier als je er een klein lcd inpropt die je kan uitschakelen. dan blijft de look origineel buiten dat ene latje die dicht zit (of je stopt het lcd achter je originele latjes)
ik daarentegen.... ik zorg dat ik een reservetellerunit heb en dan gaat de eerste eraan.
hier zit een canbus aangestuurde toerenteller van een ford fiesta 1.4 uit 1998 in een tellerunit van een escort mk2 1.3 uit 1978
kostprijs: 10€ ofzo op de sloop.
of je spendeerd een fortuin aan een echt RS dashboard
(in england vind je wel eentje rond de 300-400€, maar daar zitten kmteller en toerenteller verkeerd om en heb je een mijlenteller)
dat is de volgende die bij mij een display krijgt. als ik het uitschakel is het dash origineel. zet ik het aan wil ik daar een grafische toerenteller in (achtergrond zwart, cijfers wit en naaldje geel), en dan met een drukknop een digitaal menu met alle gegevens die ik wil
Arduino is een raar ding, dus ik zou zeggen probeer het zelf eens uit. Dat is wat ik heb gedaan en de versie met floats is echt kleiner dan de versie met LUT. Dus met die FP lib zit het wel goed.
Printen van een float kun je wel beter zelf doen, want daar heeft ie anders bijna 1,5 k voor nodig.
Afrondingsfouten bij FP zijn er altijd, helaas.
Je kunt uiteraard zelf voor een NTC de beta en coëfficient berekenen met twee metingen. B = ln(r1)-ln(r2)/ (1/t1)-(1/t2) met t in Kelvin.
coëfficient = r1 / exp(B/t1). Liefst t1 en t2 een flink eind uit elkaar.
Maar datasheets zijn leuk en specs zijn prachtig maar gewone NTC's zoals in thuisthermometers en auto's zijn niet zo netjes als het grafiekje doet vermoeden. Veroudering en zelfopwarming zitten ook in de weg.
Dus met een aantal meetpunten en een berekende benadering zit je echt niet zo verkeerd.
Dat support verhaal ken ik ..... 'hij doet het niet' > 'je kunt ook niet solderen' etc. Daar moet je echt mee uitkijken. Geldt ook voor software: gratis webtooltje uit 1998 dat het niet doet in IE11 ... of het even hersteld kan worden, liefst vandaag nog.
EricP
mét CE
dat rode lampjes van de dynamo (bij VW is dat een rode led) doet het pas als de dynamo NIKS meer doet. toen bij mij de spanning terugviel naar 12V en soms zelf eronder, brande het dynamo lampje nog steeds niet, de dynamo genereerde wel nog spanning, maar leverde geen stroom meer.
Eh... Het ding zit tussen een het knooppunt van een aparte set dioden en de + van de accu. Dat zou impliceren dat jouw failure mode zo is dat de dynamo onbelast precies zoveel spanning levert als de accuspanning. En dat dat over tijd nog stabiel is ook... Daar geloof ik dus geen moer van .
Dan zou dat hele lampje geen zin hebben - in elk geval in auto's waar dynamo een V-snaar deelt met wat anders. De stuurbekrachtiging mis je ruim voordat je accu plat is en een evt. koelwaterpomp ook wel... Maar goed, andere discussie.
brandstofniveau vind ik heel intressant. aangezien ik 120km lang op de autosnelweg rijd en ik weiger die dure brandstof te tanken, wil ik graag weten of ik smorgens nog naar het werk geraak of eerst moet tanken.
Jij hebt daar na een paar keer geen 'gevoel' voor opgebouwd? Ik heb ook een tijdje forse afstanden gereden (voor woon-werkverkeer dan). Ik redde precies 5 dagen op 1 tank - dan was er inderdaad nog tussen de 1 en 5 liter over. Dus je weet dat als je voor de 2de dag op rij achter aan mag sluiten dat je als je thuis komt toch ff moet tanken, anders haal je de week wellicht niet
als je naaldje op 1/4de staat, kan je dan nog 250km rijden, of 270 km (met 266km woon-werk maakt dat wel uit of je thuis geraakt of niet).
You like to live dangerously? Als er nog voor 200km in de tank zit, dan wordt het tijd om een slang te vinden. Het verschil tussen 250 en 270km is tenslotte ook nog een keer 'achter aansluiten' of niet. En zonder brandstof langs de kant van de weg staan... is op z'n minst een hoop gedoe...
men broer werkte bij VW en zei me ooit: "bij die golfjes mk2 mag de naald tot onder het rode gebied gaan, die blijft nog rijden".
dat heb ik ooit getest en toen het naaldje net op het onderste van het rode stond, viel de auto uit. om 2h snachts op een zaterdag wil je dat niet meemaken. gelukkig stond ik heel hoog en was er onder de berg een tankstation. ben ik naar daar gebolt. er was iemand aan het tanken en die trok wel een raar gezicht toen die zo een stille golf zag aankomen
Ah, die ervaring heb je dus al Tsja, eigen schuld he... Meer kan ik er niet van maken (en eh... het is mijn ook wel eens overkomen. Niet omdat ik niet wist dat het 'op' was, maar ff niet opletten (shit, pomp gemist), pomp dicht (daar waren ze ff met een overval bezig, zo hoorde ik achteraf) en de volgende niet meer gehaald... kan ik die auto of z'n meter niet verwijten... Wel verbaasd hoe ver ik op een 'lege' tank nog gekomen ben )
dat is de volgende die bij mij een display krijgt. als ik het uitschakel is het dash origineel. zet ik het aan wil ik daar een grafische toerenteller in (achtergrond zwart, cijfers wit en naaldje geel), en dan met een drukknop een digitaal menu met alle gegevens die ik wil
Je bent lekker bezig. Meer eerlijk is eerlijk: netjes.
Dat is wat ik heb gedaan en de versie met floats is echt kleiner dan de versie met LUT. Dus met die FP lib zit het wel goed.
Of je hebt dat ding om een andere reden al mee natuurlijk... (of... je code zit gewoon onhandig in elkaar... ook met een loouk-up table kan ik de wereld aan flash verspillen als me dat leuk uit zou komen ).
zelfopwarming
Voor een verwarminsthermostaat... soit. Voor een sensor die min of meer in de koelvloeistof zit? Hahahahaha. Leuk theoretisch verhaal. De praktijk is anders.
Op 8 januari 2017 12:02:04 schreef EricP:
Eh... Het ding zit tussen een het knooppunt van een aparte set dioden en de + van de accu. Dat zou impliceren dat jouw failure mode zo is dat de dynamo onbelast precies zoveel spanning levert als de accuspanning. En dat dat over tijd nog stabiel is ook... Daar geloof ik dus geen moer van
Dan zou dat hele lampje geen zin hebben - in elk geval in auto's waar dynamo een V-snaar deelt met wat anders.
hier had ik een electrisch probleem, waarbij de toerenteller raar deed (die meet de frequentie van de dynamo wisselspanning). het acculampje knipperde maar op mijn eigen voltmeter begin 15V te branden. ik had overspanning dus
https://www.youtube.com/watch?v=R1ClJyu9dbw
toen zag ik aan de toerenteller ook wel dat er iets mis was.
bij mijn opel vroeger had ik ook een defect laadsysteem. de auto start en leverde iets van 13,8-13,9V.
als ik echter de verwarming, de ruitenwissers, de verlichting en de radio aan had staan, was dit maar 12,5V meer. als je zo een week rond rijd, dan kon je de vrijdag wel eens met een platte accu staan smorgens. daar zei het dynamo lampje ook niks, want de dynamo deed het nogwel (een beetje).
voor de brandstof krijg ik natuurlijk een gevoel, maar als ik morgen de brandstofmeter moet vervangen omdat de oude kapot is (en dat gebeurd wel eens als je auto 29jaar oud is), dan kan die meter ineens hele andere toeren uithalen. ik heb ook meer dan 1 auto en kan ze moeilijk allemaal gaan leren. of overal papiertjes inleggen.
ik moest ooit voor het werk naar luxemburg, dus ik ging daar wat goedkoper tanken met de shell tankkaart van het werk. tot bleek dat het een BE kaart was en geen benelux.
heb toen 200km gereden tot het eerste shell tankstation op mijn weg (overijse). er ging 63liter in een auto die op papier een 55liter tank had. nog nooit zo zuinig gereden.
ik rijd met alle voertuigen regelmatig eens tot de laatste liter leeg, zo blijft er geen vuil in de tank die je dan allemaal binnenkrijgt de eerste keer dat je leeg rijd.
moest ik wat slimmer zijn, ik zou mijn gehele dashboard vervangen door een klein scherm, en er zelf GPS in programmeren. maar een rpi in de auto inbouwen, daar heb ik geen zin in.
een auto dient om in te rijden, en daarvoor moet die betrouwbaar zijn. oldtimer of niet. als ik morgen een trip van 5000km moet doen, vertrouw ik mijn oude barrel boven onze mercedes vol electronica. tot grote ergernis van mijn vrouw, is mijn golf de betrouwbaarste auto die we hebben. 6jaar geleden aangekocht voor 200€ met 361 000km op de klok (en die km teller was kapot), heb die teller vervangen en sta al vrolijk op 498 000km nu. en als het kan wil ik daar wel wat gebruiksgemak in (betere zetels, recentere ophanging, deftige muziekinstallatie, zuinigere motor en een dashboard met nuttige info en niet van die tellers die onzin uitkramen.
zoals bv mijn capri: die heeft een 'accu'meter aan boord, alleen staat die ALTIJD in het midden, ook zonder accu. is eigenlijk een soort van amperemeter die voor geen meter werkt.
(links boven)
weg ermee en een echte voltmeter erin van een porche 924
mijn dodge uit 1977 kreeg dan de overige stukken uit die porsche
2 analoge brandstofmeters als gasmeters (stukken beter dan die 4ledjes) en een echte voltmeter ipv zijn uitgefikte amperemeter (hier vond de fabrikant dat je alle stroom zonder problemen door een kleine connector kan sturen door het schutbord. met als gevolg dat de connector uitfikt en de hele auto stroomloos valt. ja ook autofabrikanten maken wel eens fouten)
deze auto heeft het bij mij tot zijn 38jaar geschopt en hierbij +320 000km op gas gelopen