[vz-dev] Messungenauigkeit

[Jakob Hirsch]

Justin Otherguy, 2010-12-01 09:00:

>> 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

Naja, nicht ganz, soweit ich das sehe. Das Problem ist doch, daß durch
die mangelnde zeitliche Auflösung mal 12, mal 13s zwischen zwei Impulsen
liegen, und somit:
12s-Impuls: 0,5W * 3600s / 12s = 150W
13s-Impuls: 0,5W * 3600s / 13s = 138.46W

Mit besserer Zeit-Auflösung auf dem Controller wäre das schon besser,
z.B. bei 100ms noch 1,14W und bei 20ms (die "ca." 50Ticks/s in der von
dir verlinkten Mail) nur noch 0,23W (jeweils 12,5s und 12,5s+t_d).

Fragt sich nur, was "50 ticks entprechen ca ner sekunde" bedeutet. Nicht
daß wir da eine Auflösung vorgaukeln, die garnicht gegeben ist.
Hab mir den Controller-Code bisher nicht angeschaut, aber was didi
beschrieben hat, hört sich ja nicht so wild an. Oder spricht was dagegen?

> 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.

Sehe ich auch so. Sollte aber evt. einstellbar sein...

> 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

Kann man da nicht RTC nachrüsten? Ansonsten sollte man das evt. auf dem
Controller abfangen. Holt der das dann eigentlich später nach oder läuft
der dann so weiter bis zum nächsten Neustart.

> 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.

Wenn man das Kriterium für b) eher Richtung > 1 oder 10 Jahre oder auch
Jahr < 1971 macht, kann man das über t_delta machen. Besser wäre es
aber, wenn der Controller einfach sagt, daß er schonmal probiert hat,
das einzuliefern (resend=1 oder sowas).