Hello!
Auch ich plane die Inbetriebnahme eines KS-300. Und hab mal einen anderen Ansatz: Was spricht dagegen, einen WS300-PC am Rechner anzuschließen und die IPS an die Datenbank, die die mitgelieferte Software verwendet, anzubinden?
lg, Gregor.
Jetzt habe ich die Sache nochmal beobachtet und auch, wie von paresy vorgeschlagen, die Min/Max Werte gelöscht.
Ergebnis:
Meine Regenmenge ist bei nur einer einzigen Übertragung vollkommen falsch gewesen. Es kann sich hierbei nicht nur um einen einfachen Bitfehler handeln. Die Regenmenge stand auf 512 (10 0000 0000). Es sind aber zu diesem Zeitpunkt 728 (10 1101 1000) gewesen.
Außerdem waren alle empfangenen Daten vollkommen daneben:
Temperatur: 1 (20,6)
Feuchte: 0 (75)
Wind: 110 (0,5)
Die WS hat davon natürlich nichts mitbekommen. Keine falschen Werte oder Maxima und Minima.
Wie kann das sein, wenn alles durch Checksummen geprüft wird? 
Und nun?
Hallo Fabian,
ich bin z.Z. dabei diese Ausreißer zu sammeln. Rainer (RWN) war so freundlich für mich das Daten-Logging zu übernehmen.
Seit dem 10.06. sind bei seiner KS300 7 Ausreißer in unregelmäßigen Zeitabständen aufgetreten. Ihnen allen gemeinsam ist die Tatsache, dass das untere Byte dabei immer 0 war. Zusammen mit dem oberen Byte traten dabei folgende Werte auf:
0x0000: 0
0x0500: 1280
0x0400: 1024
0x0000: 0
0x0200: 512
0x0000: 0
0x0300: 768
Es ist noch zu früh für Interpretationen. Aber es hat den Anschein, dass es sich dabei nicht um Ausreißer sondern um irgendwelche zusätzlichen Daten handelt, deren Bedeutung wir nicht kennen. Vielleicht sind diese Daten auch im Zusammenhang mit der ominösen Nibble-Vertauschung im unteren Byte zu sehen. Diese könnte evtl. einen Zweck erfüllen.
Gruß
HJH
Hallo HJH,
…es hat den Anschein, dass es sich dabei nicht um Ausreißer sondern um irgendwelche zusätzlichen Daten handelt, deren Bedeutung wir nicht kennen…
Super Ansatz!
Dann werde ich mal mein Loggingscript umbauen und versuchen die direkten KS-Daten hinter dem FTDI aufzuzeichnen.
Bei mir sind die „Ausreißer“ nicht so häufig.
Fabian
Hallo,
um das ganze mal wieder ein wenig aus der Versenkung zu holen, ich habe bemerkt, dass wenn es nicht so heiss ist draussen, ich viel weniger ‚Ausreisser‘ habe. Hat sonst jemand auch so was bemerkt?
Auf jedenfall wertet die Willi-Wetterstation die Regenmenge anders aus, denn die zeigt niemals Negativ-Werte an, das Skript schon. Ich hatte letzte Woche -65,23 mm Niederschlag. Das war schon lustig
mfG Franz
Hallo guyabano,
die Spitzen in den Werten halte ich für Störungen in der Fünkübertragung. Am Anfang hatte ich den Aussensensor relativ weit weg von der FHZ1300 platziert, und den Sensor mit Alkaline Batterien betrieben. Das Ergebnis waren sehr viele Spitzen im WIPS, besonders im Winter. Die Alkaline Batterien hatte ich dann gegen Lithium Batterien getauscht, und siehe da die Spitzen bei niedrigen Temperaturen wurden viel weniger. Die Ursache war scheinbar der Spannungseinbruch bei Alkaline Batterien, bei niedrigen Temperaturen. Dann zog die FHZ1300 noch in die Nähe des Sensors um, und die Spitzen verschwanden fast völlig.
Die nächste Beobachtung konnte ich direkt an der Wetterstation, in Verbindung mit dem Poolsensor PS50 machen. Der Poolsensor befindet sich an der Reichweitengrenze der Wetterstation und meldet je nach Tagesform zeitweise falsche Messwerte, oder meldet sich sogar mit der falschen Sensor ID an der Basis.
Meine Vermutung ist, das Funkprotokoll kann extreme Störungen nicht unterdrücken, und völlig unlogische Werte werden in der Basis selbst unterdrückt.
Ich schätze, das gibt dem Thema einen neuen Anstoß. 
Grüße, Keule
Das sollte durch eine Checksumme eigentlich ausgeschlossen sein.
Aber soviel zum Thema „eigentlich“:
Vor drei Tagen habe ich endlich mal einen Ausreißer erwischt. Hier ein Auszug aus meinem Log:
20:23:06.82637900:> 81 0c 04 68 09 09 a0 01 0a 01 00 00 aa 00
20:23:16.87325500:> 81 6b 04 5a 40 27 a0 01 0a 01 00 00 aa 00 4e ce 71 83 17 66 10 85 4c ce 70 aa 00 32 0a 01 00 b0 53 07 06 aa 09 39 92 08 81 ff 4c 03 41 22 00 0c 02 4b 77 00 45 05 18 fe
20:23:17.10762900:> 00 9d f4 3a 04 08 4b 00 00 00 00 f1 00 00 29 00 35 00 01 00 00 80 c8 00 90 90 c1 00 00 00 00 07 40 00 2b 6c 46 00 00 ee 00 03 bb 76 00 0f 00 0c 00 80 81 40 26
20:23:20.34200400:> 81 0c 04 34 09 09 a0 01 0c 03 42 00 69 c7
20:23:20.54512800:> 81 0c 04 6e 09 09 a0 01 0c 03 43 00 69 00
20:23:20.84200500:> 81 0c 04 74 09 09 a0 01 0c 03 4b 00 67 00
20:23:21.15450400:> 81 0c 04 6f 09 09 a0 01 0c 03 44 00 69 00
20:23:22.23263000:> 81 0c 04 74 09 09 a0 01 0c 03 4b 00 67 00 81 0c 04 a7 09 09 a0 01 0c 03 7e 00 67 00
Erst habe ich versucht, die KS-Daten allein zu loggen, da kam aber bei den Ausreißern nix an. Jetz im kompletten Datenstrom wird es erst richtig deutlich:
Die erste Zeile ist ein FHT mit der Adresse 1201. Danach kommem zwei riesen Datenwörter , welche vom KS stammen müssten (vgl. die Zeiten im Log). Die letzten sind wieder vom gleichen FHT. Anscheinend kommt es hier, diese Vermutung hatte ich schon früher geäußert, zum Garbling, also der Überlagerung von Datenimpulsen.
[BTW:]Wenn man sich in den Logs das muntere FHT-Gequassel so ansieht, ist es kein Wunder, dass es ab einer bestimmten Anzahl zu Problemen kommt. :rolleyes:
Wenn mit Checksumme gearbeitet wird, müsste sowas doch rausfliegen…
Also paresy, ich hoffe, Du liest das hier. Irgendwas scheint da im Argen. Übrigens stammen die Daten wieder direkt vom FTDI, zwischen I/O und FHZ abgegriffen.
Bei Interesse gibts die (hier wg. der Übersichtlichkeit etwas geschönten) Logs auch komplett…
Grüße
Fabian
Hallo Fabian,
Deine Aufzeichnungen sind hochinteressant.
Dass es im Betrieb von Funkkomponenten immer wieder zu Datenkollisionen kommt, ist ein altbekanntes Phänomen und wurde hier im Forum schon ausgiebig diskutiert.
Tatsache ist aber, dass man gegen Datenkollisionen nichts tun kann, da es keine Möglichkeit gibt die am Funk beteiligten Komponenten zu koordinieren.
Auch ist die Prüfung durch eine Check-Summe leider kein Allheilmittel, da die meisten für diese Zwecke angewandten Algorithmen zu schwach sind um alle Fehler zu erkennen. Es ist durchaus möglich, dass einige Ausreißer durch die Check-Summe ausgefiltert werden. Bei manchen anderen hingegen ergibt die vermeintliche Check-Summe zufällig den richtigen Wert, und diese werden dann eben durchgelassen.
Ich habe aus dem Regen-Log von Rainer (RWN) bisher 15 Ausreißer identifizieren können. Auch ich bin inzwischen der Meinung, dass es sich tatsächlich um Falschmedungen und nicht um versteckte Zusatzdaten handelt.
Die Aufgabe „Zuverlässige Erkennung der Falschmeldungen“ wird nicht einfach zu lösen sein.
Da die Check-Summe hierfür offensichtlich nicht ausreicht, müssen weitere Kriterien herangezogen werden wie z.B.:
- die Länge des Telegramms auswerten
- den Inhalt auf charakteristische Byte-Folgen untersuchen
- lieber ein Telegramm zu viel verwerfen
Es gibt sicher noch mehr Merkmale, die geprüft werden können. Aber das ist eher eine Aufgabe für Paresy.
Gruß
HJH
Hast Du das hier mitgelesen, oder sollen wir dazu einen extra Thread im Bug-Bereich aufmachen?
Gruß Fabian
Ich habe mal etwas an der Checksumüberprüfung verändert. Probiert mal, ob die Ausreißer weg sind.
paresy
Splitter.FHZ1000PC.rar (70.6 KB)
Bis jetzt hatte ich keine Ausreißer mehr aber eine Woche will uns noch nicht viel sagen…
Werden sehen was sich noch ergibt.
Hab nach gut einer Woche auch noch keinen Ausreisser !
mfG Franz
Hallo,
ich kann mich dem nur anschließen.
Allerdings habe ich auch vorher schon meherere Wochen ohne Probleme gehabt, daher schiebe ich die Euphorie noch etwas auf… :rolleyes:
Also bis dahin: Good work!!!
so, nach 14 Tagen immer noch keinen Ausreißer. Wenn es die nächsten 14 Tage auch sobleibt, dürfte es in Ordnung sein.
Sonst hatte ich 3-4 pro Woche 
Wie sieht es bei den anderen aus?
Da häng ich mich mit an !
mfG Franz
Hallo Mitstreiter,
kann ebenfalls nur Gutes berichten. Habe gerade meine Logs gecheckt… Gute Arbeit!
Was mich mal interessiert:
Da bei mir wohl eine Datenkollision mit den FHTs aufgetreten ist, was für regelmäßige Sender habt Ihr denn noch? Welche Anzahl an Sendern habt ihr und mit welcher Häufigkeit ist es aufgetreten.
Ev. kann man einen Zusammenhang erkennen…
Bei mir sind es 7 FHTs an nur einer FHZ1300PC.
BTW: Ich habe ein Wathdog Script für die FHTs laufen, dass folgendermaßen funktioniert:
Da ja die Meldungen alle 114 bis 116 Sekunden eintrudeln, lasse ich alle 110 Sekunden ein Skript laufen, welches den Variablentimer abfragt. Ist der letzte Wert älter als 120 Sekunden, wird eine Quality-Variable für den FHT um eins dekrementiert. Kommt im nächsten Zyklus wieder ein Update wird wieder eins hochgezählt. Maximal geht es bis 7, runter bis 0 dann erfolgt ein Logeintrag.
Meine langfristige Beobachtung ist eine regelmäßige Überschneidung der Sendezeiten durch die leichte Drift gegeneinander. Dann bleibt für etwa 10-20 Zyklen das Update aus (meistens bei beiden zur gleichen Zeit). Dann läuft alles wieder wie gehabt. Scheint ganz normal zu sein…
Gruß
Fabian
Das scheint in der tat normal zu sein, das manche FHT’s sich von zeit zu zeit auf ein kleines Nickerchen zurückziehen. Es kommt mal vor das ein FHZ einen halben Tag gar keine Temperatur an die FHZ sendet, obwohl die Ventilpositionen reinkommen.
ich kann damit leben
mfG Franz
Liebes Forum,
ich bin wirklich hier ein Neuling, aber nachdem ich letzte Woche alles über Regenmengen, KS300, oder KS300-2 usw. in diesem Forum gelesen habe, habe ich soweit alles installiert, das Script mit dem Nibble tausch etc. und…
es funktionierte alles …
bis heute, denn nach einem kräftigen Duscher hatte ich -67 mm Regen
wie das ??
Übrigens wie stelle ich fest, ob ich eine KS300 oder KS300-2 habe ? In meiner Anleitung steht immer nur KS300.
Falls es wirklich eine KS300 ist brauche ich dann den Nibble Tausch ? bei mir steht der Wippenzähler jetzt bei 992 und zählt brav weiter (fragt sich nur wie lange :mad: )
Viele Grüße aus Graz, Andreas
Hallo Andreas,
verwendest Du die korrigierte Software von Paresy?
Ansonsten läßt sich ohne Kenntnis Deines Skripts keine Aussage machen.
Gruß
HJH
Hallo HJH,
die neue Software von Paresy hab ich installiert. Zuerst alles heruntergefahren, dann die DLL vertauscht (die alte hab ich umbenannt man weiß ja nie …) und das System wieder hochgefahren. Es läuft soweit !
Hier das Script:
<?
/*
IP-SYMCON Event Scripting
File : KS300_Regenerfassung.ips.php
Trigger :
Interval : OnUpdate
Author : HJH modifiziert von Zimmi
Date : 25.05.07
Das Skript wird mit dem Timer 1 x pro Stunde aufgerufen
„Regenmenge“ ist der Zählerstand, den die KS300 ca. alle 3 Minuten meldet.
*/
define(„UMRECHNUNGSFAKTOR“, 0.2681); // Faktor für die Umrechnung der Wippenschläge in Millimeter
// aktuelle Werte einlesen
$rza = GetValueInteger(„Regenmenge_alt“); // vorausgegangene Messung
$rzn = GetValueInteger(„Regenmenge“); // aktuelle Messung
// zur Fehlerbereinigung die unteren Nibbles vertauschen
$rzn = (($rzn & 0x00f0) >> 4) // oberes Nibble des LSB 4x rechts schieben (entspricht Division durch 16)
+ (($rzn & 0x000f) << 4); // unteres Nibble des LSB 4x links schieben (entspricht Multiplikation mit 16)
// Zählerüberlauf abfangen
if ($rza > $rzn) $rzn += 256;
// Zuwachs (Wippenschläge) seit der letzten Messung
$Zuwachs = $rzn - $rza;
if ($Zuwachs >= 0) // basierend auf max. Regenmenge in 5 minuten, d.h. 5mm was dann beim UMRECHNUNGSFAKTOR gleich (rund) 20 Wippenschläge ausmachen
{
// Zählerstand abspeichern
SetValueInteger(„Regenmenge_alt“, $rzn);
// Berechnung der aktuellen Regenmenge in mm (entspricht l/m²) für den laufenden Tag
$lpd = GetValueFloat("Liter_heute");
$lpd += $Zuwachs*UMRECHNUNGSFAKTOR;
$lps = $Zuwachs*UMRECHNUNGSFAKTOR;
SetValueFloat("Liter_heute", $lpd); // wird mit einem extra Script um 0:05 auf 0 zurückgestellt damit die letzten Daten von Vortag auch vollständig sind
SetValueFloat("Liter_stunde", $lps);
}
?>
Ich hab jetzt beim Zuwachs >=0 eingetragen damit die Negativwerte (falls wieder welche auftauchen) ignoriert werden. Vorher war hier <= 20 eingetragen damit die Spitzen abgefangen werden (die hatte ich daher nie !)
Grüße Andreas