borg

Ah verstehe, das geht am besten mit dem Analog In Bricklet (oder auch Voltage/Current Bricklet) mit den "threshold callbacks": http://www.tinkerforge.com/de/doc/Software/Bricklets/AnalogIn_Bricklet_Java.html#BrickletAnalogIn::setVoltageCallbackThreshold__c.short-.short- Da gibt es sogar ein Beispiel für: http://www.tinkerforge.com/de/doc/Software/Bricklets/AnalogIn_Bricklet_Java.html#threshold

Exakt! Es geht dabei einfach nur ums rauschen: Die erste hälfte ist mit Default-Mittelwert-Parametern und die zweite Hälfte hat alle Parameter auf 0. Bei einer Wetterstation will man das ganze rauschen nicht sehen, da ändert sich dann ja ständig der Wert und man kanns kaum noch ablesen. Wenn man jetzt aber die Sensordaten mit den IMU Daten oder anderen Sensoren fusionieren will (z.B. mit einem Kalman-Filter) sind die gemittelten Werte nicht so gut zu gebrauchen, weil sie schon mehrere ms alt sind und gar nicht mehr zu den anderen Sensoren passen.

Worüber bestimmst du denn die Bodenfeuchtigkeit und welches Bricklet nutzt du dafür? Der Master Brick selbst kann ja nicht direkt die Bodenfeuchte messen .

Also die alte Firmware hatte fest einen Mittelwert der Länge 10 und einen gleitenden Mittelwert der Länge 25. Der gleitende Mittelwert wird auf den Mittelwert angewendet. Warten musst du nicht, du bekommst halt solange den alten Wert zurückgegeben bis ein neuer berechnet wurde . Die maximale Länge des gleitenden Mittelwerts ist 25 weil wir nicht mehr Platz auf dem Bricklet haben für mehr. An und für sich wäre für Wetterstationen ein noch größerer gleitender Mittelwert sinnvoll. Mit dem zusätzlichen "normalen" Mittelwert bekommt man halt noch mehr rauschen raus. Einmal als Klarstellung: Die neue Firmware verhält sich genauso wie die alte Firmware wenn man am Averaging nicht rumstellt. Am Averaging rumstellen sollte man nur wenn eine Latenz in der Größenordnung von 20ms zu hoch ist. Welche Werte dann gut sind muss man ausprobieren, ich denke es wird in solchen Fällen meistens Sinn machen alles auf 0 zu stellen.

Wenn z.B. die Länge des Mittelwertes 10 ist, werden 10 Luftdruckwerte aufsummiert und dies Summe wird dann durch 10 geteilt. Anzahl der Werte über die gemittelt wird, genau . Zusaetzlich zu was? Zum Mittelwert? Was ist ein gleitender Mittelwert? Wie kann ich das ohne Mathestudium das verstehen? Wie muessen die Zahlen zueinander stehen? Kann das jemand an einem Beispiel erklaeren? Bei dem normalen Mittelwert summiere ich immer 10 Werte, bilde darüber den durchschnitt, summiere 10 neue Werte, bilde Durchschnitt usw. Bei dem gleitenden Mittelwert speicher ich 10 Werte, bilde den Mittelwert, füge einen neuen Wert hinzu, entferne den letzten Wert, bilde den Mittelwert, füge einen neuen Wert hinzu usw. Wie du das am besten einstellst: Für eine Wetterstation o.ä. einfach auf Default lassen. Wenn die Werte des Barometers in einem "Sensorfusion-Algorithmus", z.B. mit dem IMU Brick verwendet werden sollen, muss die Mittelwertbildung verkleinert werden. Sonst haben wir zuviel Latenz um sehr gute Ergebnisse zu erzielen. Spoiler: Zur Sensorfusion mit den IMU Daten wird es bald ein Beispiel (vielleicht sogar ein Kit) geben .

Firmwares: IMU Brick 2.0.2 Orientierungs-Berechnung an/aus API hinzugefügt I2C Kommunikation synchron Plugins: Barometer Bricklet 2.0.1 API für Konfiguration der Mittelwertbildung hinzugefügt Download Firmware: IMU Brick Download Plugin: Barometer Bricklet

Firmwares: IMU Brick 2.0.2 Add orientation calculation on/off API make i2c communication synchronous Plugins: Barometer Bricklet 2.0.1 Add API for configuration of averaging parameters Download Firmware: IMU Brick Download Plugin: Barometer Bricklet

Das doppelte "connected" im ersten Output kann ich hier nicht reproduzieren, ansonsten ist das so wie ichs erwarten würde. Ganz allgemein zum Enumerate: Wenn ein Enumerate mit "ipcon.enumerate()" getriggert wird, bekommst du von jedem zu erreichendem Gerät eine Enumerierung. Das wird soweit garantiert. Es kann aber jederzeit sein, dass du eine Enumeration-Nachrich bekommst die du nicht getriggert hast. Zum Beispiel weil ein neues Brick verbunden wurde oder auch weil ein anderes Programm eine Enumerierung getriggert hat (z.B. der Brick Viewer). D.h. ein Programm welches die Enumerates nutzt sollte immer damit klar kommen können spontane Enumerate-Callbacks zu zu bekommen.

Das ist soweit richtig. Das Enumerate kommt einmal wenn das erste mal eine Verbindung zum PC aufgebaut wird und das zweite mal wenn du es explizit anfragst. Das Äquivalent wenn du dein Programm über USB betreibst ist wenn du den Stack erst anschließt wenn das Programm schon gestartet ist. Dann bekommst du auch das initiale Enumerate und dann noch eins wenn du es triggerst.

Hi, that is a known bug. The Reached Callback is currently triggered twice on all Bricklets that use analog sensors. We will release firmwares that fix this soon. Sorry!

Wie gesagt, das LCD selbst ist nicht das Problem. Nur wie soll die API aussehen die ihr nutzt? Einfach ein "SetPixel(x, y, color)" wäre trivial, sowas ist schnell zu machen. Aber ist das wirklich sinnvoll? Dann ist halt die Frage was man an primitiven braucht: Text schreiben, Kreise und Rechtecke malen, Bitmaps übertragen, Bargraphen darstellen, Animationen? Was ist da das Minimum, was muss man haben, was ist nice-to-have?

Es muss ein "Rechner" mitlaufen, ja. Dieser Rechner kann aber z.B. auch ein Raspberry Pi oder Cubieboard o.ä. sein. Da könntest du dann auch gleich einen kleinen Monitor dran anschließen für die grafische Ausgabe .

Hier schonmal eine Version die eine HW Version kleiner gleich 1.1 erzwingt: http://download.tinkerforge.com/_stuff/bricklet_lcd_20x4_firmware_2_0_5-force_hw_1_1_0.bin

Ich hab ja auch nicht gesagt man sollte dieses LCD benutzen, an der API von dem LCD könnte man sich inspirieren .

Haben wir auch schon drüber nachgedacht, ist halt viel Aufwand dort eine brauchbare API zu machen. Die Daten pixelweise übergeben wäre ja nicht gerade einfach zu benutzen. Dieses Teil hier hat eine tolle API: http://www.reichelt.de/LCD-Module-Touch-Grafik/EA-EDIP-TFT43A/3/index.html?;ACTION=3;LA=2;ARTICLE=86675;GROUPID=3011;artnr=EA+EDIP-TFT43A Sowas müsste man dann selbst bauen. Das wäre dann natürlich ein Brick, ein Bricklet hat da nicht genug Speicher für.

Der Prototyp ist auch gewölbt, sieht man nur auf dem Foto nicht so.

Also 2,4,5,6 und 7 beziehen sich aufs LCD, das könntst du in der Tat gegen ein anderes austauschen. Das LCD muss diesen Treiber besitzen: http://de.wikipedia.org/wiki/HD44780 (oder einen der kompatiblen, letzter Satz im im ersten Absatz). 1) Ich glaube nicht das sich der zusätzliche Preisaufwand da lohnt. Ich wüsste auch gerade gar nicht wo es so ein kleines Poti was da zwischen Bricklet und LCD passt überhaupt gibt. 4) Die Lötpunkte wurden nachgefragt und kosten nichts, deswegen sind sie da . Man könnte da den Stecker von der RS485 Extension einsetzen (passt von der Höhe und hat 6 Pinne), dann kostet das Bricklet aber wieder 1€ mehr, obwohl die allerwenigsten sich externe Knöpfe dran machen. Ist halt immer ein Kompromiss den man da irgendwo fahren muss. @Hingergrundbeleuchtung einbauen: Da müsstest du mal ein LCD auseinander nehmen, vielleicht kann man die LED auslöten und eine andere einlöten. Vorgesehen ist das bei dem LCD aber nicht . Edit: Hab gerade nachgeguckt, die LEDs kann man definitiv nicht auslöten, die sind fest ihm Rahmen integriert.

Bei tk gibt es "after" um Funktionen nach einer bestimmten Zeit aufzurufen, als Alternative zu Callbacks. Also z.B.: class App(): def __init__(self): self.ipcon = IPConnection() self.master = Master(UID, self.ipcon) self.tempbr = Temperature(UID_tempbr, self.ipcon) self.root = tk.Tk() self.label = tk.Label(text="") self.label.pack() self.update() self.root.mainloop() def update(self): t = self.tempbr.get_temperature()/100.0 self.label.configure(str(t)) self.root.after(1000, self.update) app=App() app.mainloop() (ungetestet)

Ui, das klingt vielversprechend! Also unsere 3mm Platten müssten wir auf 80° erhitzen, dann zwei Stunden die Temperatur halten und pro Stunde wieder um maximal 15° abkühlen. Schade das unser kleiner PID geregelter Lötofen nicht groß genug ist für die Acrylplatten. Am besten wir fragen den Hersteller vom Acryl ob die das vielleicht direkt für uns machen können.

Hmpf, die HW-Versions-Erkennung scheint einfach nicht vernünftig zu funktionieren. Ich kann das hier mit den 1.1er LCD Bricklets die ich noch hier hab nicht reproduzieren. Ich splitte die Firmwares am Montag, dann gibt es eine Firmware für <=1.1 und eine Firmware für >=1.2. Ist vermutlich die beste Lösung. Schonmal Entschuldigung für die Probleme!

Das LCD selbst stellen wir ja nicht her. Das sind standard alphanumerische Displays, ein kompatibles gibt es z.B. auch bei Reichelt: http://www.reichelt.de/Hintergrund-blau/LCD-204B-BL/3/index.html?;ACTION=3;LA=2;ARTICLE=53952;GROUPID=3006;artnr=LCD+204B+BL D.h. die Hintergrundfarbe und Schriftfarbe und Buchstabengröße usw suchen wir uns nicht aus, da können wir also auch direkt nichts dran ändern.

Ah, hatte die Debugger-Ausgabe falsch interpretiert. Dann kann es nur sein, dass dein MinGW aus irgendwelchen Gründen __GNUC__ nicht definiert? Kannst du bei den Compiler-Einstellungen ein "-D__GNUC__" mit einfügen zum testen? Der einzige Grund der mir noch einfällt ist nämlich, dass __attribute__((packed)) im EnumerateCallback struct nicht aktiviert ist. Wobei es da eigentlich einen Compiler-Error geben sollte (siehe ip_connection.c Zeile 37ff).

Hast du das Edit oben gelesen? Bitte probier mal einmal aus leconvert_swap32 durch leconvert_swap16 auszutauschen.

Interessant, ab wann hat er denn dann die 0? Hier ist die Funktion die aufgerufen wird: uint16_t leconvert_uint16_from(uint16_t little) { if (native_endian.value == LITTLE_ENDIAN) { return little; } else { return *(uint16_t *)leconvert_swap32(&little); } } Er sollte in den Little-Endian-Fall springen und die 13 direkt wieder zurückgeben. Selbst wenn er in den Else-Fall springen würde, würde nicht 0 dabei rauskommen können . Edit: Uhhhhhh, *Kopfkratz*. Warum steht denn da leconvert_swap32 und nicht leconvert_swap16? Arbeitest du auf einem Big Endian System? Falls ja, tausch mal einmal das leconvert_swap32 durch leconvert_swap16 aus!

Mh, funktioniert bei mir auch. Wenn du da jetzt ein printf("id: %d\n\n", device_identifier); reinpackst gibt das 0 aus?