[vz-dev] Messungenauigkeit

[Roland Kletzing]

Moin,

sehr schön erklärt!

Damit kann man sich jetzt auch gut vorstellen, daß der Ansatz des 
Funk-Loggers von Conrad/ELV mit dem optischen Abtaster für die Drehscheibe 
einfach nur Mist ist. Herkömmliche Dreheisenzähler haben nämlich meistens 
deutlich unter 100 Umdrehungen/kwh. Meiner hat 75imp/u.Da sind die "Stufen" 
bei kleinen Leistungen dann noch ein wenig grösser. Kurzum: Zum Zählen des 
Verbrauchs ok, zum Bewerten der aktuell aufgenommenen Leistung eher für die 
Tonne..... :)

Grüsse
Roland


--------------------------------------------------
From: "Justin Otherguy" <justin at justinotherguy.org>
Sent: Wednesday, December 01, 2010 9:00 AM
To: "Steffen Vogel" <info at steffenvogel.de>
Cc: <volkszaehler-dev at lists.volkszaehler.org>
Subject: Re: [vz-dev] Messungenauigkeit

> Moin Steffen,
>
> Am 01.12.2010 um 00:42 schrieb Steffen Vogel:
>
>> Ich habe hier einen Hutschienenzähler mit 2000 imp/kWh. Ich vermute das
>> die mangelnde zeitliche Auflösung der Impulse der Auslöser dafür sein
>> könnte. Kann das jemand von euch (mathematisch) verifizieren? Ich stehe
>> da gerade etwas auf dem Schlauch.
>
> 150 Watt -> 1 KWh in 1.000/150 h = 6,67 h
> pro KWh erzeugt der Zähler 2.000 Impulse -> 2.000 Imp. in 6,67h
> -> Zeit zwischen 2 Impulsen: = 0,0033 h = 12 s
>
> anders rum: die zeitliche Auflösung des Controllers liegt bei 1s - daraus 
> ergibt sich im Fall von 2.000 Imp./KWh eine Auflösung in der Leistung von
> 150 W / 12s = 12,5 W
>
> Und das sind die Stufen, die man in Deinem Diagramm sieht.
>
> Intervall A hat 12 Impulse -> 12*12,5W = 150 W
> Intervall B hat 11 Impulse -> 11*12,5W = 137,5 W
>
> Die B-Intervalle (137,5 W) kommen häufiger vor -> Deine Leistung liegt 
> also wohl etwas unterhalb der Mitte (143,75 W), schätze 140 W.
>
>> Der ethersex Code kann derzeit nur mit einer Sekundenauflösung loggen.
>
> jein; es geht auch ohne eine höhere zeitliche Auflösung des Controllers - 
> wir brauchen eine höhere Auflösung der Zeitstempel; der Controller ist da 
> eine von zwei Möglichkeiten.
>
> M.E. gibt es 2 Lösungen (an der Stelle haben wir schon so ein paar Runden 
> gedreht, gelle Jens? (c; ):
> - höhere zeitliche Auflösung des Controllers - da gab's mal ne Idee; ah 
> ja, guckst Du [1]
> - den Zeitstempel des Servers verwenden - der hat ja ms und mehr
>
> Dadurch kommt die Latenz im Netz ins Spiel- allerdings halte ich die für 
> vernachlässigbar. Insbesondere bei unserem (inzwischen zum Standard 
> gewordenen) Ansatz des lokalen Backends.
>
> Einen weiteren Aspekt hat das Ganze:
> wenn es einen Netzwerkausfall gegeben hat und der Controller die Werte 
> puffert, werden diese ja anschließend auf einen Rutsch an den Server 
> übermittelt. Wenn diese nun alle den Ankunftszeitstempel bekommen ist das 
> auch nicht optimal...
>
> Es gibt 3 Fälle, die wir serverseitig unterscheiden müssten, dann wären 
> wir eigentlich komplett:
> a) Puffer wird gerade entleert -> es sollte der Zeitstempel des 
> Controllers verwendet werden
> b) Uhrzeit des Controllers geht nach dem Mond (manchmal klappt das Setzen 
> der Uhrzeit per ntp nicht beim Reboot; dann läuft der Controller knallhart 
> bei 1970-01-01 los...) -> das ist sehr einfach zu entdecken (z.B. Delta > 
> 1 Tag) ; dann sollte die Serverzeit verwendet werden
> c) Rest: es sollte die Serverzeit verwendet werden (Latenz, aber höhere 
> Auflösung)
>
> Wenn uns ein gutes Kriterium für den Fall a) einfällt, hätten wir 
> eigentlich alles beieinander.
>
> Oder Du setzt Didis Tipp um.
>
>
> Gruss, J.
>
>> <vz_bug.png>
> der Dateiname ist ja eine Frechheit, also hör mal! ;-)
>
> [1] 
> http://www.mail-archive.com/ethersex-devel@list.zerties.org/msg00337.html
>
> _______________________________________________
> volkszaehler-dev mailing list
> volkszaehler-dev at lists.volkszaehler.org
> https://volkszaehler.org/mailman/listinfo/volkszaehler-dev