PowerPredictor

die 32 Bit kommen daher ... wenn ich den Timer mit Vorteiler 8 laufen lasse (der ist nicht ganz frei wählbar), dann läuft der Timer bei Systemtakt 16 MHz (Berechnung 16000000 / 65536/8) mit 30 Hz über ... das bedeutet, dass Umdrehungen unter 30 pro Sekunde nicht gemessen werden könnten.
Nun geht man hin und lässt im Timer Overflow Interrupt ne Variable mit hochzählen, ok bei der ersten Berechnung hatt ich irgendwo nen Fehler drinnen, wenn nich da ne Bytevariable (8 Bit) hochzählen lasse, dann komm ich runter auf 0,11 Hz Messung, das wären dann aber insgesamt 24 Bit Daten, einmal die 16 vom Timer in Hardware, und ein höheres Bis für den Überlauf.

Bei Vorteiler 1 würde die Bytevariable nicht reichen, dann würds was 16-Bittiges werden und damit insgesamt 32 Bit mit dem Hardwaretimer zusammen.

Die TImervorteiler sind:
1 , 8, 32 , 64 , 256 oder 1024 in Hardware.

Aber das Timing steht noch nicht fest, evtl. geh ich auf nen Baudratenquarz für Modbus-Slave, damit der Baudratenfehler eben Null wird.

Gestern Nacht hab ich den Wikiabschnitt über die Wetterstation angefangen ... fehlt noch die Templateerstellung:

tools/powerpredictor/wiki/doku…terstation

immer her mit den Fragen, mitunter bringt einen ne Frage auch wieder auf neue Ideen, sehr nützlich ist das

Nen Timer auszulesen dauert nicht lange, 20 Taktyzklen vom Controller sollten reichen, dann steht der Wert im RAM ...

Was wir ja messen wollen ist die Laufzeit des Rädchens für eine Umdrehung und zunächst nicht wieviele Umdrehungen pro Sekunde, die ergeben sich aus der Laufzeit dann zwangsläufig.
Das gleiche gilt natürlich auch für die Generatorfrequenz.
Gleichzeitig wollen wir ne Auslese- und Loggingfrequenz von 1Hz haben vom RaspPi, wobei diese weil ja n OS drauf läuft nur relativ präzise realisierbar sein wird, bin da selber schon gespannt.
Allerdings kann die Drehzahl bei der WIndmessung mitunter unter 1 Hz sein, auch da sollte man denk ich nen Wert ermitteln, also ne Torzeit von 4-5 Sekunden oder anders eben alle 4-5 Sekunden dann nen Messwert, der dann eben so lange fürs logging stehen bleibt sollte schon sein.
Der Controller kann klaro auch Mittelwerte ermitteln, also Sekundenmittel, 10 Sekunden Mittel etc. kein Problem, der Messwert steht aber in jedem Fall dann als quasi Zählwert a x Mikrosekunden zur Weiterverarbeitung im RasPi dann an. Erst dort darf die Umrechnung in Meter/Sekunde erfolgen, damit die Elektronik eben auf diverse Anemometer jeweils angepasst werden kann.
Von der Verarbeitung her wären die reinen Timerwerte von der Programmierung her ideal, weil eben 16 Bit, das geht flott von der Hand sozusagen

ok,rechnen wirs mal präzise aus ... der nächstegelegene Baudratenquarz wäre 14,7456 MHz, also 14745600 Programmschritte oder Zählzyklen je Sekunde.
wenn ich nun als Obergrenze der zu messenden Zeit 4-5 Sekunden nehme und nur die 16 Bit vom Counter verwende, dann komm ich
auf folgende Werte ...
Mit dem Vorteiler von 1024 komm ich auf 14400 Zählschritte je Sekunde, was dann bei 16 Bit eine maximale Laufzeit bis zum Überlauf von rund 4,5511 Sekunden ergibt. Daraus ergäbe sich ein äquivalent pro Bit bzw. Digit von 69,44µs. Die Drehzahl wär dann einfach 1/(Digits * 0,00006944)
oder andersherum hätten wir die Drehzah mit +/- 1/14400 U/s allerdings Programmzyklen und Signallaufzeiten in der Rechnung nicht berücksichtigt.
Wenn das nicht reichen sollte, dann kann man die Vorteiler kleiner wählen, dann wird die minimale Drehzahl kleiner, dann würde ich auf ne Hilfsvariable wechseln und dann eben auf 24 Bit oder 32 Bit gehen ... das würde ich aber vorerst vertagen, bis die Hardware ausprojektiert ist, da bin ich noch dabei, die Wetterstation hat mich etwas aufgehalten.

Der von mir favorisierte Controller ATMega hat quasi ne Liste an Interruptprioritäten. Die wird bei jedem Interrupt angesprungen und die Sprungadresse für den jeweiligen Interrupt ausgelesen, erst dann springt er im Programm in den IRQ bzw. in die ISR. Wenn nun mehrere Interrupts gleichzeitig anstehen, dann wird der, der in der Liste weiter vorne steht als erstes ausgeführt. Die Liste ist von der Reihenfolge her fest vorgegeben, kann nicht umsortiert werden bei dem Controller.
Man kann in einer Interruptroutine die Interrupts wiederum aktivieren, was dann dazu führt, dass er die ISR unterbricht und die Andere zuerst ausführt ... das macht man aber nicht so gerne, da können "interessante" Ergebnisse dabei herauskommen.
Generell gilt, eine Interruptroutine immer so kurz wie möglich zu gestalten, Berechnungen, Protokolle etc. nicht im Interrupt, sondern im Hauptprogramm.
In die IRQs gehören timingkritische Angelegenheitem, wie z.B. das Timer auslesen oder Datenempfang, der REst kommt in die Mainloop. Im Idealfall mach ich in der IRQ nur n Flag, aber das kann ich jetzt noch nicht genau sagen, kommt auf die Aufgaben, die der Controller noch so zu machen hat an.
der ATMega162 hat 1k SRAM, da kann man schon ne Menge reinpacken.

Ja, die RTC kann in Hardware nen Takt liefern, ich meine es wäre 1Hz als Pin ausgeführt.

Den Controller hatte ich vor in Basic und ASM zu Coden ... ASM in den IRQs .... C wäre auch möglich, find die Syntax aber immer irgendwie doof ... hängt damit zusammen, dass ich mir vor Ewigkeiten mit dem C64-Handbuch damals selber das Programmieren beibrachte und der konnte eben Basic 2.0, daher präfferiere ich da noch heute Basic als Syntax ... bin da aber flexibel, nehme immer die Sprache, die für die gestellte Aufgabe passt, das kann Basic, C, PHP, Java Script, C#, VBA oder sonstwas sein. Programmabläufe sind immer prinzipiell gleich, nur die Syntax und n paar Highlevelbefehle variieren.

Was die Speicherung der Originaldaten betrifft:

Ausreichend ist sicherlich den Mittelwert einer Minute zu speichern und nicht tatsächlich jede Sekunde. Das enspricht dann auch eher den geplanten Mittelwertvorgabe zur Leistungskennlinienerfassung für Kleinwindanlagen.

Der Datenlogger von Willmers macht es eigentlich auch ganz raffiniert. Er speichert bis zu 24 Stunden mit Sekundenauflösung in einem seperaten "Ereignisspeicher" als Ringkern. Wenn "voll", dann wird der älteste Wert einfach wieder überschrieben.


Gruß Uwe

dann müsste aber der Controller als Master am Bus hängen ... eher nicht so ideal, würde den schon als Slave laufen lassen und ggf. eben nen 10stufigen Buffer vor den Output hängen, also die Messwerte über 10 Sekunden im Controller vorhalten, bis dann der Pi die ausliest.
Dann würde ich eher sagen, der Pi bekommt vom Controller nen Data Ready Pin Spendiert, der gesetzt wird wenn im Controller neue Daten abrufbar sind. Ist bei AD-wandlern ne gebräuchliche Methode DRDY.

Der ATMega162 hat, ich vermute mal, dass Du das meinst, 3 konfigurierbare und 16 Pin Change Interrupts. Der wesentliche Unterschied, die 3 kann man konfigurieren auf fallende, steigende Flanke oder Status High / Low. Die Pin Change reagieren immer beim Zustandswechsel und als ganzer Block.

Du und auch Andere sind gerne willkommen das Wiki zu ergänzen, ändern überarbeiten, freue mich über jede Unterstützung.

Was die Master-Slave-Geschichte angeht, so darf der Slave nie ungefragt Pakete schicken, sonst wär das Multimaster und nicht einfacher zu implementieren.
Das hängt damit zusammen, dass die Uhr direkt am Pi hängt für die Systemzeit, der Pi muss pollen ... Uhr, Luftdruck ... und Controller.

Der Bus ist I²C:
http://de.wikipedia.org/wiki/I2C

Gruß

Marko

ich denk mir das in etwa so:

Der Controller zieht nen Pin auf High zur Meldung, dass Daten vorhanden.
Der Pi holt sich das erste Paket.
Ist der Controllerpuffer dann leer wird der Pin auf Low gezogen.
Hatte der Pi nen Hänger für mehrere Sekunden und Daten sind im Puffer noch vorhanden,
dann bleibt der Data Ready eben High, der Pi holt weiter ab, bis eben Puffer leer und somit Pin auf Low.

Von der Reihenfolge her würde ich es so machen wollen, erstes Paket ist dann T-0 Sekunden
, dann T-1, T-2 etc. bis T-10. Dann kann der Pi beim ersten Wert die aktuelle Zeit exakt zuordnen, die anderen ergeben sich automatisch daraus.

Die I2C kennt im Gegensatz zum SM-Bus kein Timeout, allerdings gilt das Timeout normalerweise nur für den Slave, der Master gibt den Takt vor, wenn der Slave zu lange braucht um die Bytes ins Ausgangsregister zu schaufeln, dann stimmt das Bit-Timing nichtmehr und es kommt Schrott heraus.
Die Kommunikation werd ich aus dem Grund auch auf Interrupt legen.

Die I2C kannst Du Dir wie ein Schieberegister vorstellen.

Der I2C hängt von der Geschwindigkeit vom langsamsten Teilnehmer ab, in dem Fall 100kHz Takt, leider, und der Bustakt kommt vom Pi, die Baudrate ist für die USART, da ich dem Controller noch ne RS485-Schnittstelle verpassen will, dann kan man das Modul nämlich auch standalone als Modbus-Slave nutzen ... das ist dann das zweite Protokoll, dass drauf laufen soll.
Damit wär die Geschichte z.B. für die Hausautomatisierung nutzbar, kann dann z.B. an ne SPS angehängt werden.

Beim Leiterplattendesign kostet mich so n Ready-Signal nichts, würde sagen ich designe das mit ein, wenns nicht gebraucht wird kann mans in der Software dann deaktivieren bzw. unbehandelt lassen.
Ich plane ganz gerne Reserven ein, hinterher mit Fädeldraht nacharbeiten ist mühseliger als jetzt in der CAD n Wire einzurouten.

Ein anderer Punkt ist, dass das permanente Pollen auch Prozessorlast bedeutet, das Polling muss ja sowohl vom Pi als auch vom Controller ja verarbeitet werden ... wie schon geschrieben, beim Pi bin ich Neuling, da muss ich mich erst noch einwursteln.

Also das Wichtigste ist wirklich der 1Minuten Mittelwert. Das ist der Wert der über kurz oder lang massgeblich die Maßeinheit im Kleinwindanlagenbereich sein wird zur Leistungskennlinienbestimmung und Ertragsberechnung.

Der zweite wichtige Wert wäre der 10Minuten-Mittelwert. Das ist der bisher weltweit gebräuchlichste Wert wenn es um Leistungs- und Ertragsberechnung in der Großanlagentechnik geht.

Alle weiteren Mittelwerte (Stunden, Tage, Wochen..... etc) sind eher uninteressant und dienen dann doch wohl eher der kleinen Spielerei zwischendurch. Richtig anfangen kann man damit eigentlich nicht viel, bis auf die vergleichende Darstellung von vielen Stationen gleichzeitig in einem Graph. Wenn man da ein ganzes Jahr gegenüberstellen will, würde das mit Minutenwerten nur ein buntes Gemische und da wäre dann die wahlweise Darstellung mit anderen Mittelwerten interessant.

Klasse wäre aber tatsächlich ein paralleler Ringspeicher der die Echtzeitwerte für einen begrenzten Zeitraum aufzeichnet (zB. 1 Tag, 14 Tage oder was auch immer möglich ist) um besondere Böenereignisse mit loggen zu können und so zB. Aussagen zur Böenstabilität und Reaktionsgeschwindigkeiten zu treffen.

Die immer wieder gerne geführte Diskussion (und Anfragen hier im Shop) um den Gesamtspeicher wird meiner Meinung nach völlig überbewertet. Ich empfehle grundsätzlich alle Daten möglichst kurzfristig und regelmässig auszulesen und separat abzulegen. Ein Ausfall des Loggers durch was auch immer (Sturm, Blitzschlag, Diebstahl, Vandalismus ......) hätte immer automatisch den Verlust aller nicht extern gespeicherten Daten zur Folge und wenn das Monate wären .... hätten mich Kunden bisher sicherlich einige Male erst geteert, gefedert und anschließend gevierteilt und erschossen. Wenn auf einer SD-Karte 3-6 Monate Daten Platz haben ist alles gut und ausreichend. ggfl. kann ja auch eine größere Karte eingesetzt werden so den der Controller auch größere Speicheradressen jenseits der 2GB adressieren kann.


Was aber für mich und andere sicherlich interessanter ist, wären die jeweiligen Maximal-, Minimalwerte sowie die Standartabweichung (aus der sich dann der Turbulenzanteil bestimmen läßt) aus jedem Mittelwert. Der einzige Logger im Kleinanlagenbereich der das sehr gut löst ist der AeoLog von Inensus.

Soweit aus Bulgarien

Gruß Uwe


PS. Soll ich mal Datenblätter von verschiedenen Sensoren auch bei Wiki hochladen? oder wie geht das dort mit solchen externen Daten?

Hallo Marko,


Ok, ich habe es nun - hoffentlich - verstanden, danke
Kurz:
Außer poll geht mit dem I2C nichts. Für den PI kann man so noch sinnvoll machbar auf 100 ms Polling gehen (bei der Datenmenge quasi NULL Last).
Als Grenzwert sind 10 ms .. 30 ms (schwankend, im Mittel) machbar mit ein paar Tricks.
So etwas habe ich schon öfters programmiert.
500 ms oder 300 ms sind kein Thema, alles grün soweit .
Ob nun mit 'DATA READY' oder nicht ('DATA READY' kann dann Polls sparen),
macht es Sinn der PI pollt (zyklisch oder häufig) und der Controller liefert, so denn wenn er Daten hat.
Im 'Protokoll' würde ich noch eine 8 Bit Datenstrom ID spendieren, so kann der Controller
neben den Sekunden Messwerten, z.B. auch Debug Ausgaben machen, oder auch mal 10 s Messwerte liefern ...
Die empfangenen Daten kann der PI dann in gesonderte Dateien schreiben.


Tue ich nicht, man muss hier unterscheiden können:
a) Die Datenrate Bytes pro Sekunde ist vergleichsweise klein.
So etwas schafft der PI locker zu verarbeiten, er muss ja erst mal nur die Daten in Dateien schaufeln,
also nur vorübergehend im RAM halten.
b) Mitteln
Wenn man bei der laufenden Messung Mitteln möchte und Häufigkeitsverteilungen aufnehmen möchte
entstehen etwas mehr Daten, wenn man es geschickt macht, aber auch kaum Erwähnenswertes.
c) Langzeitspeicherung und spätere Analysen auf den Langzeitmessungen
Jetzt wird es kritisch, auch in welcher Form z.B. die Sekunden Daten vorliegen.
Eine riesengroße Datei ist nicht wirklich handhabbar, vor allen Dingen wenn man nur Teile davon braucht.
Eine Datei pro Tag ist dann wieder handhabbar: 86400 Zeilen mit Messwerten, bei z.B. 200 Bytes pro Zeile: ca. 18 MB (unkomprimiert).
Vielleicht auch eine Datei pro Stunde: dann sind es ja nur noch ca. 1MB!
Wie man sieht kommt hier unabhängig von der Organisation im Dateisystem 'nett' was zusammen.
Gerade deswegen macht es Sinn, sich die Ablage im Dateisystem gut zu überlegen und
die Daten soweit wie möglich, schon während der Messwertaufnahme zu analysieren (Mitteln, ...)
und somit eine (reduzierte) Daten Basis für spätere, dann flotte Analysen zu liefern.




Ich hatte für die Strommessung des Akkus, einen Shunt Widerstand verwendet, der 60mV Spannung bei 100A DC lieferte.
Ich denke die Strommessung sollte auf eine Spannungsmessung im mV Bereich reduziert werden.
Über die 'Konfiguration' kann man dann ja vielleicht einen Shunt auswählen oder eine Umrechnung angeben ... und der PI rechnet daraus einen Strom?
Jedenfalls gibt es sowohl DC als auch AC Ströme die interessant sind.
DC +- für den AKKU Strom in und aus dem Akku
AC für den generierten Strom des Windrades.

Und ja, die echten Ströme sollten nicht durch den Controller fließen ...
Wenn man sowohl einen großen Bereich abdecken will, als auch viel Genauigkeit,
wäre ein 12BIT ADU oder besser von Vorteil. Kann man vielleicht einen tollen ADU nehmen und den dann multiplexen?

Jedenfalls ist gleichzeitige und vor allem Echtzeit synchronisierte Leistungsmessung
ein nettes Feature was eigentlich nur mit so einer integrierten Lösung machbar ist.
Aus den Daten kann dann automatisch eine Leistungskennlinie des Windrades ermittelt werden.
Letzteres hilft dann wieder Modifikationen (Wechselrichter Einstellungen ...) besser zu beurteilen,
mehrere Windräder mit einander zu vergleichen
bessere Ertragsprognosen zu erstellen ...

Was hast du vor? Wie viel BIT hat der ADU, wie viele ADUs? Kannst du sinnvoll muliplexen?
Was für eine Spannungs-Range hat so ein ADU? Wie flott misst der ADU?
Wenn der ADU flott ist kann man auch z.B. 4 Messungen machen, zusammenfassen und so, 2 BITs 'relativ ehrlich' dazu 'schummeln'.

Gruß Frank

Nicht ganz. Was du planst ist folgendes:



Meine Lösung sähe so aus: