ArcaneDraconum Geschrieben August 21, 2012 at 16:14 Share Geschrieben August 21, 2012 at 16:14 Hallo an Alle, ich bin gerade dabei meine Wetterstation endlich um die Meßstelle im Garten zu erweitern. Ein Problem für mich stellt der Windmesser dar. Ich möchte mich nicht aus dem Profibereich bedienen, da da schnell €100 nur für den Windgeber fällig werden.... Billige Windmesser haben ein Schaufelrad und daran einen Motor hängen - es muss schon ordentlich blasen, bis sich da was in Bewegung setzt. Noch bezahlbare, leichtgängige Windmesser haben einen Magnet, welcher pro Umdrehung einmal an einem Reedkontakt vorbeifliegt. Da möchte ich ein IO-4 ranhängen. Die Frage, die ich mir stelle: Wie setze ich das um? Die Zeit zwischen 2 Kontaktauslösungen messen, oder eine Zeit lang mitzählen, wie oft ausgelöst wurde. Die erste Methode ist schnell erledigt, aber vermutlich ungenau. Nun die Frage an TF und Kommunity: Hat jemand Erfahrungen, wie schnell das IO-4 reagiert? Bis zu welcher Drehzahl kann ich überhaupt messen? Wird es ein Drehzahlbricklet geben, welches ich komfortabler abfragen kann? Wie haben es die anderen realisiert? Ich danke für rege Diskussionen / Vorschläge / Ratschläge und Tipps. Thomas PS: Der Regenmesser ist ja ähnlich aufgebaut, nur finden ja nicht mehrere Kippvorgänge pro Sekunde statt..... Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
jan Geschrieben August 21, 2012 at 17:13 Share Geschrieben August 21, 2012 at 17:13 Du könntest mit einer Untersetzung arbeiten so 1:10 oder 1:100, dass sollte auf alle Fälle reichen. Ansonsten könnte jemand (TF) die Software anpassen und bei den IO einen weiteren Typ hinzufügen (Input, Output + Input Counter). Dann wird in einem definiertem Zeitrahmen (kann evtl. per SW gesetzt werden) zw. 1/100s und 10s eintreffende Schaltänderungen gezählt (entweder High oder Low). Das kann dann auch gleich für Radencoder genutzt werden. Als 4. Typ (siehe oben) kann man evtl. nur die letzte Differenz zw. zwei Zuständen liefern. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
batti Geschrieben August 22, 2012 at 07:47 Share Geschrieben August 22, 2012 at 07:47 Mit Callbacks kannst du Änderungen mit bis zu 1khz detektieren. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
ArcaneDraconum Geschrieben August 22, 2012 at 07:59 Autor Share Geschrieben August 22, 2012 at 07:59 @jan: Untersetzung geht in diesem Falle nicht, da ich ja etwas fertiges verwende. Sobald Getriebe usw. ins Spiel kommen, habe ich eine Bremse im System. Ich habe es mit einem extrem leichtgängigen Motor probiert, das Dingens läuft einfach sehr spät an. @batti: Das sollte locker reichen, wenn der Wind so stark wird, dass da 1000U/min zusammenkommen, wird es mir es den Windmesser vom Mast reißen. Die Frage ist nur, mit welchen Verzögerungen muß ich rechnen? Bzw. sind die relativ gleich groß? Also kann ich die Zeit zwischen zweit Schaltvorgängen messen, oder soll ich lieber 1 Minute mitzählen? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben August 22, 2012 at 11:42 Share Geschrieben August 22, 2012 at 11:42 Die Zeit zwischen zweien wird dir sehr wackelige Werte geben und hin und wieder nen Ausreißer wenn mal der Prozess nciht sofort drankommt. Ich würde es erstmal mit der Zeit dazwischen probieren und das über ein paar Umdrehungen mitteln, das sollte dann ganz ordentlich sein und nciht zu verzögert. Kommt auch auf den Anwendungsfall an, wenn du Böhen messen willst musst du innerhalb von einigen Umdrehungen ne zahl haben, wenn du nur den typischen Wind brauchst, dann mittlere ruhig über ne Minute oder so... Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
ArcaneDraconum Geschrieben August 22, 2012 at 11:56 Autor Share Geschrieben August 22, 2012 at 11:56 @AuronX: Naja Böhen sind schon auch von Interesse, aber nur Sekundär. (Da ich aber nix zu steuern habe, wie Jalousien etc., ist es mal eher eine Spielerei)Ich betreibe ja keine professionelle Wetterstation und mache auch keine Vorhersagen. Ich dachte eigentlich schon daran über einen gewissen Zeitraum zu mitteln. Ich habe dann ja quasi ein Luftvolumen, welches in dem Zeitraum durchgeströmt ist und daraus eine mittlere Windgeschwindigkeit. Das sollte für den privaten Bereich eigentlich gut genug sein. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben August 22, 2012 at 15:49 Share Geschrieben August 22, 2012 at 15:49 Also ich gehe davon aus, dass du "zwischen" den Umdrehungen die Zeit genau genug bestimmen können solltest, dass das klappt. Die mehreren Messungen würde ich deswegen machen, weil du so toleranter gegenüber ungünstigem Scheduling durch dein Betriebssystem bist (ein hoch-priorer Task der dafür sorgt, dass du die Zeit erst eine Millisekunde später messen kannst usw.). Wenn ich da so drüber nachdenke macht ein arithmetisches Mittel gar keinen Sinn, weil es diese Ausreißer halt nur dämpfen würde. Ich vermute ein Median über n Messungen sollte besser geeignet sein (für die Ermittlung der Momentangeschwindigkeit). Wenn du dir dann die Momentanwerte eine Minute lang notierst, dann kannst du zusätzlich auch noch eine Durchschnittsgeschwindigkeit berechnen. OT: Wenn ich irgendwann über eigenen Grund und Boden verfüge werde ich sowas wohl auch bauen und dann hoffentlich die Erfahrung von euch anderen nutzen können Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
zarquon Geschrieben August 23, 2012 at 06:35 Share Geschrieben August 23, 2012 at 06:35 Hallo zusammen, für timing relevante Aufgaben wären mir in der Signalverarbeitung zu viele nicht deterministische Strecken. Ich würde mir eine Erweiterung der bestehenden IO-4/16 API wünschen. Darin könnte das jeweilige Master brick eine wenigstens gleichmäßig ungenaue Zeitmessung bewerkstelligen. So weit ich weiß hängen die Bricklets am SPI Bus und müssen per Polling abgefragt werden. Bitte korrigiert mich, falls es hier eine dedizierte Interruptleitung zum Brick gibt. Nützlich wäre es, wenn die Interrupt Callbacks der IO Bricklets ein mehrfaches auftreten der Interrupts berichten könnten und gleichzeitig eine Liste der Zeitstempel mitbrächten. Damit wäre man in der Messung unabhängig von der USB Übertragung. Die maximal mögliche Auflösung der Messung hinge dann alleine vom Polling Intervall ab. Also machin wir eine !!FEATURE REQUEST!! draus Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
jan Geschrieben August 23, 2012 at 07:43 Share Geschrieben August 23, 2012 at 07:43 Wie gesagt, hatte ich auch schon die Idee. Müsste sich nur jemand finden, der das mit umsetzt. Ich denke mal der Masterbrick kann da bestimmt bis 10kHz oder mehr gehen. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
ArcaneDraconum Geschrieben August 23, 2012 at 07:54 Autor Share Geschrieben August 23, 2012 at 07:54 Ich hoffe mal, daß das Thema von TF aufgegriffen wird. Somit wäre es im offiziellen Support und würde mit zukünftigen Updates bzw. Erweiterung nicht kollidieren. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
borg Geschrieben August 24, 2012 at 16:06 Share Geschrieben August 24, 2012 at 16:06 Also grundsätzlich wird jedes Bricklet Plugin 1000x pro Sekunde aufgerunfen. Dies macht sehr viel Sinn, da USB auch mit dieser Frequenz abfragt. Um so einen Frequenzmesser zu implementieren müssten wir also echte Hardwareinterrupts vom Microcontroller nehmen. Damit ist das in Theorie ohne Probleme möglich. Aber... Je nach Brick wird das mehr oder weniger gut funktionieren. Zum Beispiel spricht das IMU Brick nahezu durchgängig I2C oder macht Berechnungen die nicht unterbrochen werden dürfen. Dort würde der Interrupt also fast immer unterdrückt und das ganze funktioniert nicht mehr richtig. Alternativ hätte der IO4 Interrupt eine höhere Priorität und das IMU liefert kaputte Daten. Auch nicht gut. Sprich wir hätten auf einmal Funktionalität die nur auf bestimmten Bricks gut funktioniert und vielleicht auch nicht mehr mit anderen Bricklets zusammen usw usw. Die Gedanken intern etwas mit hoher Frequenz Interrupt basiert zu implementieren hatten wir schon oft, allerdings ist das Aufgrund der extremen Modularität nur schwer umzusetzen ohne die Stabilität zu gefährden. Ich schreibe es trotzdem nochmal auf die TODO Liste und gucke es mir nochmal an. Mitzählen wie oft es High->Low oder Low->High Flanken gab könnte man evtl noch irgendwie hinbekommen. Das ganze mit Zeitstempel ist aber sehr schwierig. Wie würde die API dazu aussehen? Denkt dran, dass unsere Nachrichten intern immer eine feste Länge haben. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
ArcaneDraconum Geschrieben August 24, 2012 at 17:49 Autor Share Geschrieben August 24, 2012 at 17:49 Also für mich persönlich wäre ein Zähler schon völlig ausreichend, solange das Zeitintervall in dem gezählt wird immer gleich ist. Quasi ein Ausgabe in Hertz, o.ä.. Vielleicht könnte man noch festlegen, wie lange gezählt wird, z.B. 5 Sekunden..... Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
jan Geschrieben August 24, 2012 at 19:15 Share Geschrieben August 24, 2012 at 19:15 Also ich finde, die "Frequenzmessung" müsste nur am Master funktionieren. Evtl. noch am DC-Brick. Input Counter: Es wird in einem definiertem Zeitrahmen (kann evtl. per SW gesetzt werden) zw. 1/100s und 10s eintreffende Schaltänderungen gezählt (entweder High oder Low): IO4.get_frequenz(zeitraum,High/Low) zeitraum in ms zw. 1 und ~65.000 IO4.get_frequenz_invers(High/Low) Zeitabstand zw. zwei Zuständen (High oder Low) Zwei Möglichkeiten der Erfassung und Verarbeitung im Brick: Entweder die Daten kontinuierlich in ein interne Tabelle geschrieben und dann die Daten aus der "Vergangenheit" abgefragt (Frequenz in den letzten 10 Sekunden, oder der letzte Zeitabstand) oder die Daten werden erst erfasst, wenn der Befehl abgesetzt wird, also "messe ab jetzt 10 Sekunden die Anzahl der High-Signale". Da weis ich nicht was sich besser programmieren läßt. Auf alle Fälle wäre Variante 1 (Daten aus der Vergangenheit) schöner und schneller was die Abfrage betrifft, da die Werte ja bereits da sind. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
zarquon Geschrieben August 24, 2012 at 20:45 Share Geschrieben August 24, 2012 at 20:45 Mit dem Zeitstempel zum Interrupthandler meinte ich im Prinzip den Inhalt eines Hardwaretimers. Das Ganze ziehlt darauf hinaus einen Hardware Timer per Api zur Verfügung zu stellen. Den Ablauf könnte ich mir folgender Weise vorstellen: 1. Ereignismessung wird mit einem Aufruf aktiviert. Hierbei wird die Auflösung bzw. der Teiler des Timers zur Taktfrequenz des Bricks bestimmt. Zusätzlich definiert der Aufrug noch ein Ereignis. Z.B. eine steigende oder fallende Flanke eines IO4/16 Pins. 2. Tritt dieses Ereignis nun ein, wird der aktuelle Wert des Timers an die nächste Stelle eines Arrays mit fest definierter Größe angelegt. Vielleicht reicht hier bereits der Platz für 10 Timerwerte aus. Diese Pufferung dient nur dazu evtl. auftretende Verzögerungen in der Übertragung zum PC zu Puffern. D.h. es ist eher als eine Sende Queue anzusehen in dem die ältesten Werte wieder überschrieben werden sobald kein Platz mehr frei ist. Tritt dieser Fall ein, wird in der Answendung die Callbackroutine mit gesetzen Flag (TIMER_BUFFER_OVERRUN) angestoßen. Die signalisiert dem Anwender, dass die Ereignisse zu häufig auftreten. Das System kommt mit der Übertragung nicht nach. 3. Sind Werte im Array vorhanden, werden Sie per Callback in die Anwendung geliefert. 4. Der Anwender deaktiviert den Timer sobald er mit der Messung fertig ist. Damit erschlägt man meiner Meinung nach eine ganze Reihe an Anwendungsfälle, ist nah an der Interruptverarbeitung der Hardware, garantiert aber eine gleichbleibendes Timing in der Messung. Für die jenigen, die eine Kopplung an den Hardwaretakt zu technisch ist, könnte man auch Zeitscheiben in natürlichen Größen, sprich glatten Frequenzen anbieten. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben August 25, 2012 at 08:37 Share Geschrieben August 25, 2012 at 08:37 Also ich finde, die "Frequenzmessung" müsste nur am Master funktionieren. Evtl. noch am DC-Brick. Das passt aber nicht wirklich zum Konzept von TF. Da sind ja quasi alle Bricks gleich, aber jeder hat eine "Superkraft" die ihn von den anderen bricks unterscheidet. Wenn jetzt plötzlich ein Bricklet nur an manchen Bricks vollen Leistungsumfang aht wäre das doof. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
M4ST3R Geschrieben August 25, 2012 at 09:58 Share Geschrieben August 25, 2012 at 09:58 Nur mal eine Idee... Kann man nicht zusätzliche FW anbieten, für Leute die diese Funktionalität wünschen? Dann können die ihre Brick/lets damit befüllen und es nutzen. Entsprechende Hinweise (funktioniert nicht in Kombination mit IMU o.ä.) können ja dazu geschrieben werden. Könnte das Problem lösen? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
ArcaneDraconum Geschrieben August 25, 2012 at 10:05 Autor Share Geschrieben August 25, 2012 at 10:05 Ich stimme da eher AuronX zu. Wo müsste denn überall die Doku ergänzt werden? Z.B. fängt das schon in Shop an. Natürlich möchte TF alle Funktionen bewerben, aber dann kommt die Ausnahmeliste. Für Neueinsteiger wird es dann extrem kompliziert. Wenn ich sehe, was teilweise für einfache Probleme schon auftauchen.... für die Firmwarepflege wird es auch nicht einfachen. Und vor allem: Es fängt dann mal mit dem IO-4 Bricklet an, ich denke für viele andere Bricklets gibt es dann auch Sonderwünsche. Wer soll da dann den Überblick haben welche Bricklets mit welcher Firmware an welchem Brick (mit welcher Firmware) problemlos funktionieren und welche Funktionen stehen dann zur Verfügung? Da lasse ich doch lieber mal einen Wunsch unerfüllt, kann aber jedes Briclet an jeden freien Port stecken. Denkt mal an die Fehlersuche... Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
jan Geschrieben August 25, 2012 at 11:19 Share Geschrieben August 25, 2012 at 11:19 Ja aber ganz ehrlich, wer benötigt denn an einem IMU-Brick einen "Rotationssensor"? Dieser wird doch nur in Verbindung mit einem DC-, Stepper- oder Servobrick benötigt. Und seine Aufgabe als "normaler" IO würde das Bricklet doch sowieso bringen. Es werden halt nur mehr Funktionen dann an den anderen Bricks zur Verfügung gestellt. Mehrere FW-Varianten find ich nicht sinnvoll. Im Shop kann der IO so verkauft werden wie bisher auch. In der Doku würde dann "einfach" darauf hingewiesen, dass mit Brick xyz noch weiteren Funktionalitäten zur Verfügung stehen. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
AuronX Geschrieben August 25, 2012 at 13:47 Share Geschrieben August 25, 2012 at 13:47 Ja aber ganz ehrlich, wer benötigt denn an einem IMU-Brick einen "Rotationssensor"? Wenn ich die Strömungsgeschwindigkeit abhängig vom Anstellwinkel meines Messinstrumentes bestimmen möchte Ich denke was sich durchaus noch entwickeln könnte wäre eine Sammlung von Mods/Addons/Custom-Firmwares (nennt es wie ihr wollt). Damit wäre sowas dann von TF weg, sofort in die "Profi-Ecke" verschoben und trotzdem könnte man es vielen zugänglich machen die es wollen. LG Jan Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
ArcaneDraconum Geschrieben September 17, 2012 at 07:05 Autor Share Geschrieben September 17, 2012 at 07:05 Ich wollte hier nochmals nachfragen, ob es eine Firmwareergänzung geben wird. Ich habe es unter Python vergeblich versucht, die Zeit zwischen 2 Ereignissen zu messen. Unter 0,2 Sekunden geht nicht. Teilweise habe ich dann eher eine 0 zurückbekommen. Da sind offensichtlich auch zu viele Latenzen drin. Also sowas muss man direkt auf dem Bricklet, oder Stack messen. Wird da was kommen? Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
P4trick Geschrieben June 3, 2013 at 10:45 Share Geschrieben June 3, 2013 at 10:45 Hallo ArcaneDraconum ist das Thema bei dir noch aktuell? Ich möchte mir derzeit auch eine Wetterstation bauen und auch einen Windmesser realisieren. Ich habe woanders eine Formel gefunden für die Berechnung. ich werde sie mal suchen. Sie basierte ganz groß auf dem Radius der Schaufeln deines Windrades. Es wurden dann die Umdrehungen pro Zeit erfasst und daraus anhand des Umlaufs die Geschwindigkeit berechnet.- im grunde alles Recht einfach... ich werde mal die Formel posten wenn ich sie gefunden haben... Gruß Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
pluto Geschrieben June 7, 2013 at 19:27 Share Geschrieben June 7, 2013 at 19:27 Ich habe versucht mit dem Analog In, Signale von einer Infrarot Fernbeiding zu messen. Problem: Die Hardware ist einfach zu Langsam. Die Signale kommen(laut dem Internet) in unter 10 ms rein. Ich denke, beim IO-4 Brick wird es ganz ähnlich sein. Bis jetzt habe ich den Tests noch nicht am IO-16 Brick wiederholt, vielleicht klappt es da. Aber auch bei anderen Gelegenheiten, zum Beispiel wollte ich mit dem Analog In und dem Analog Out Morsen, dass ging auch nicht wirklich. Das Prinzip ging zwar, aber ich konnte gerade mal 5 Zeichen in ca 1,5 Sekunden übermitteln.... Ich habe ein Leser-Pointer verwenden und eine Solapannel, aus dem Taschen Rechner, ich dachte, wird es liegen. Im Internet, hat einer die Signale sogar verlängert, wie das auch immer gehen mag. Zitieren Link zu diesem Kommentar Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.