Ik nog steeds niet hoor  .

 

@Kornelis: Ik heb de turbodrukmeter lay-out ook zoals jij suggereerde, een langer wordende balk, geprobeerd. Ik vond het een goed en logisch idee. Je ziet de turbodruk wat sneller. Het nadeel is dat de hele display lay-out wat out balans raakt met die dikke zwarte balk links. Oogt gewoon wat minder mooi.

Enige probleempje is dat je bij dat soort integer berekeningen wel moet uitkijken voor overflows zo'n term als 389*f bijvoorbeeld kan zomaar te weinig hebben aan 16 bits. Kun je rare uitkomsten door krijgen, meestal krijg je opeens negatieve getallen. Eventueel kun je er nog afronding aan toevoegen door er 50 bij op te tellen voor de deling door 100.

Je waarschuwing is op zijn plaats Jeroen. Gelukkig heb ik hier rekening mee gehouden.
Pas bij een KVS temperatuur van -150 graden kom ik in de buurt van een (signed) integer overflow.
Toch zijn het dit soort zaken waar programmeurs de mist in kunnen gaan. Wordt een absent signaal door een draadbreuk b.v. juist afgehandeld?

Die afronding had ik niet aan gedacht. Meteen toegepast.

In dit geval is een draadbreuk makkelijk te detecteren. Geen signaalverandering voor meer dan, zeg, 100ms en je weet genoeg

Meet je de tijd tussen twee pulsen of het aantal pulsen in een bepaalde tijd?

Over die twee keuzes heb ik even zitten twijfelen.

Het gaat om lage frequenties. 20Hz, 40Hz etc.
Ik tel het aantal hoog-laag overgangen van het temperatuur signaal gedurende een seconde.

Uiteraard via interrupts.

Ja, maar juist door die lage frequentie is de resolutie ook laag... 1Hz als je een periodetijd van 1s gebruikt. Dus, een resolutie van 3,8 graden. Meet je gedurende een periode van 10s kun je de frequentie bepalen tot 0.1Hz; oftewel 0.38 graad.

Ergo, als je drie seconde telt, heb je ongeveer 1 graad resolutie. Beter is nog om gedurende 3889 ms te meten. Dan kan je de omrekening ook simpeler. 175-aantal pulsen. Ik heb overigens gedronken, dus ik kan hier een breinscheet hebben gelaten

  Proest! Wat heerlijk eerlijk Jeroen.
Je laat overigens absoluut geen breinscheten. Deze overweging had ik ook.

Het is een keuze tussen een langzame accurate meting, of een snelle meting met een fout van bijna 4 graden.

Ik heb gekozen voor de laatste omdat ik alarm situaties snel wil detecteren.

Ik zit nu aan een LPG (Lekker Potje Grosch) dus proost!

Je kan ook snel en nauwkeurig meten als je kiest voor meten van de tijd tussen twee pulsen. Ik weet niet of jouw gekozen MCU deze functie heeft, maar AVRs die ik altijd gebruik hebben een hardware functie voor juist deze toepassing (Input Capture).

Bij een puls op de ingang slaat de timer de huidige waarde van de timer op in een speciaal register en geeft dan een interrupt. Kwestie van de nieuwe waarde aftrekken van de vorige, omrekenen en je weet de frequentie tot 1/Ftimer Hz nauwkeurig. Eventueel met de overflow interrupt het aantal bits verhogen. En altijd het compromis tussen resolutie en hoe snel je de timer laat lopen.

Ik heb met deze functie redelijk recent nog een nauwkeurige snelheidsmeter gemaakt met ongeveer 10Hz refresh rate; meting begint bij eerste puls, deze timestampen, dan pulsen tellen tot dat ongeveer 100ms voorbij is, dan wachten op laatste puls en deze weer timestampen, en zo door. Dit is exact hetzelfde principe als nauwkeurige reciproke frequentiemeters gebruiken.

Dingetje is bedoeld om acceleratie te meten, daar kun je - bij benadering - de koppelcurve bepalen. Ik moet het overigens nog steeds aansluiten

Thanx!
-edit- Ik moet inderdaad even checken of dat kan bij de Microchip PIC.

Citaat van: razorx op 31-03-2013 22:04:12
Je laat overigens absoluut geen breinscheten.

Groet.

Nogmaals bedankt Jeroen.
Het lijkt erop dat het kan bij de PIC: Ik laat een timer met een relatief hoog tempo lopen.
Ik vang twee hoog-laag overgangen af van het kvs signaal en meet het tijdsverschil.

Het resultaat is het zelfde, maar ik lees wel uit jouw verhaal dat de Atmel omgeving hier een voordeel heeft. Of ik ken de PIC omgeving niet goed genoeg.
Nu ga ik pitten, als dat lukt met de pijn in mijn schouder.

Je kan het ook 'manueel' doen door in een interrupt de timer waarde uit te lezen en op te slaan. Voor deze toepassing ruimschoots voldoende. Nadeel is dat alles afhangt van de interrupt latency die behoorlijk kan varieren waardoor je meetonzekerheid toeneemt. Met hardware support zijn de eisen aan de software een stuk relaxer en is de meetzekerheid gegarandeerd.

Overigens zijn er behoorlijk veel varianten PICs. ICP functionaliteit zal gegarandeerd aanwezig in 1 van die honderden variaties

Jeroen sprak en aldus geschiedde.

Op de PIC microcontroller bleken meerder opties te zitten om de kvs frequentie nauwkeurig om te zetten naar een temperatuurwaarde op het display.
Ik heb een tweede tellertje geprogrammeerd dat gedurende één clock van het kvs temperatuur signaal met 3200 pulsen per seconden telt.

Hierdoor is de nauwkeurigheid van de meting verbeterd tot 0,5%. Nog preciezer heeft geen zin: Ik geef de temperatuur immers in hele getallen weer. Daarnaast is de kvs temperatuur sensor natuurlijk ook niet heilig.

Uiteraard heb ik voorzorgen genomen om een deling door 0 te voorkomen, want de berekening is nu:

coolanttemp = 175,6 - (3,889 * timerfrequency) / counted_coolant_pulses

Een simpel signaalgeneratorje aan mijn schakeling gehangen om te testen. Dat leverde de volgende plaatjes op:

Goh....nooit geweten dat het koelwatertemperatuur als frequentie word aangeboden 
Wat is daar nu de gedachte achter om het zo te doen?