borg

Der Aufbau lief bei mir über 9 Stunden durch. Übers Wochenende hab ich es jetzt aber nicht laufen lassen, aber ich kann es dann am Montag wieder starten. Mh, eher ist was mit dem Master Brick nicht in Ordnung oder? Der Stepper Brick alleine funktioniert ja. Kannst du einmal überprüfen ob vielleicht ein Pin im Bricklet-Stecker krumm ist und einen Kurzschluss macht o.ä. (in einem der Bricks oder Bricklets)? Ist irgendetwas im Stapel-Stecker was dazu führt das der Kontakt nicht gut ist? Aber das alles würde nicht erklären warum du Zeile 0-2 im OLED nicht setzen kannst... Vielleicht einen anderen USB-Port am PC oder ein anderes USB-Kabel? Dein Aufbau ist ja eigentlich recht simpel, dass muss absolut stabil laufen.

Ich bin ratlos. Das macht keinerlei Sinn. Der Brick Viewer nutzt wie gesagt die ganz normalen Python Bindings die wir auch veröffentlicht haben.

Du hast gar nichts geändert an deinem Aufbau und keine Software aktualisiert o.ä.? Ich wüsste nicht warum dann auf einmal die Callbacks nicht mehr funktionieren sollten . Kannst du vielleicht einmal eines der Minimalbeispiele testen die es in der API-Dokumentation gibt? Funktionieren diese auch nicht?

Temperaturmessung ist ein erstaunlich schwieriges Problem. Wenn ein Sensor eine Genauigkeit von +-0,1°C angibt (z.B.) ist das unter Laborbedingungen sicherlich korrekt. Die Ungenauigkeiten entstehen dann durch "self-heating" (der Temperatursensor selbst wird warm wenn er benutzt wird) oder durch eine leicht warme Leiterplatte (auf Grund eines Prozessors der neben dem Temperatursensor sitzt z.B.). Manchmal ist auch die direkte Umgebungsluft wärmer als die eigentliche Raumluft. Eventuell weil sich Hitze in einem Gehäuse staut. Der RPi 3 gibt natürlich auch eine Menge wärme von sich. Daher muss die Temperatur in so einem Aufbau fast immer zusätzlich einmal Kalibriert werden wenn sie auf ein paar Zehntel Grad genau sein soll. Wir bieten aktuell leider keinerlei Wasserdichte Gehäuse. Wenn WLAN nicht in Frage kommt bieten wir aktuell in unserem System nur LAN und natürlich die Outdoor Weather Station mit dem passenden Bricklet dazu (das wäre 433MHz Funk). Wir haben so ziemlich alle Möglichkeiten Sensoren auszulesen im System (digitale Eingänge, 0-10V, 4-20mA, RS232, RS485, etc). Sollte also möglich sein . Ja, der PC ist auch für das Display alleine schon notwendig denke ich. Wenn du nur Daten auf dem Display anzeigen möchtest würde ich mir eine hübsche Graph-Library suchen und die nutzen, OpenHAB brauchst du dafür nicht. Natürlich macht das Vorhaben mit Tinkerforge Sinn. Eine andere Antwort kannst du hier im Forum jetzt aber auch nicht erwarten . Ganz grob: Wenn der Weg Das Ziel ist (d.h. es geht dir darum Löten zu lernen oder zu lernen wie man low-level einen Treiber für einen Sensor schreibt oder so) ist Tinkerforge wahrscheinlich nicht die beste Wahl. Wenn das Ziel das Ziel ist (du möchtest am Ende ein funktionierende Wetterstation nach deinen Vorstellungen haben) ist Tinkerforge genau richtig.

Bezüglich der Geschmeidigkeit der Kurve: Wie schnell war denn die Reaktionszeit und wie hoch die Updaterate? Weil mit der aktuell veröffentlichen Version von BSEC kriegen wir Daten nur mit einer Frequenz von maximal 0.33Hz.

Ich hab das jetzt eine ganze Weile am laufen hier (im Stapel mit Master Brick), bisher kann ich es leider noch nicht reproduzieren . Der Aufbau mit nur Rotary Encoder und Silent Stepper Brick lief die ganze Nacht duch.

Hab gerade kurz in den Code geschaut, es gibt zwei Checks in der Funktion: Der zweite Check ist hier wahrscheinlich das Problem. Die Funktion geht hier davon aus, dass der Kanal zuvor bereits auf Input konfiguriert wurde. Das scheint mir ein wenig strikt zu sein, ich bin mir gerade nicht sicher ob das notwendig ist. Muss ich mir im Detail anschauen.

Das kann ich nicht reproduzieren. Wenn du per Brick Viewer oben Text sendest (line 0, pos 0), funktioniert das? Das ist auch in Python geschrieben und nutzt intern auch write_line.

Die API hat auch einen Callback dafür: https://www.tinkerforge.com/de/doc/Software/Bricks/SilentStepper_Brick_Python.html#BrickSilentStepper.CALLBACK_UNDER_VOLTAGE

Hab das jetzt (inklusive Rotary Encoder) hier aufgebaut und gestartet. Bisher läuft es durch. Das erste was mir bei dem Script auffällt: Du rufst get_count() des Rotary Encoders und get_current_velocity() des Stepper Bricks mehr oder weniger in einer "While-True-Schleife" auf. Du könntest an der Stelle entweder ein sleep von 50ms oder so einbauen um das ganze ein bisschen zu entlasten oder sogar den Count per Callback holen und in der Schleife nur drauf reagieren wenn der Count sich ändert. So wie es gebaut ist lastet das den Stepper Brick und Rotary Encoder voll aus. Deswegen sollte das natürlich nicht abstürzen, nur als Hinweis.

OK, ich werde versuchen das hier zu reproduzieren. D.h. der Minimalaufbau mit dem ich das nachstellen kann wäre ein Silent Stepper Brick mit Schrittmotor und externer Stromversorgung per USB am PC und dazu dein Python-Programm ausführen, richtig?

Läuft das Programm auf dem RED Brick denn noch weiter oder gibt es da eine Exception o.ä.? Eine andere Frage: Ist das RED Brick in dem Aufbau notwendig um den Fehler zu erzeugen? Wenn du einmal testweise den Silent Stepper Brick direkt am PC/Laptop anschließt und das Python Programm dort startest, tritt das Problem dann auch auf? Du könntest auch einmal testweise den RED Brick am PC anschließen und das Python Programm vom PC starten.

Das Bricklet speichert alle 12 Stunden die aktuelle Kalibrierung im Flash und bei Neustart nutzt es die letzte Kalibrierung aus dem Flash (falls eine da ist). Wenn ich das richtig verstehe ist das Laden einer gespeicherten Kalibrierung allerdings aktuell nicht voll funktionsfähig (siehe erster Link zum Bosch-Forum oben). Ich hab hier einen Aufbau seit vielen Tagen bei mir im Büro am laufen: Von oben nach unten ist das: IAQ, IAQ-Genauigkeit, Temperatur, Luftfeuchte und Luftdruck. Grundsätzlich sieht das alles ganz gut aus. Jeder Anstieg bei der Temperatur ist ein Tag und die kleineren Anstiege sind das Wochenende. Jeder der kleinen Ausreißer bei der Luftfeuchte ist wenn sich jemand einen Kaffe aus dem Vollautomaten holt (Kaffeeautomat steht direkt neben meinem Büro). Die Ausreißer bei Luftfeuchte und Temperatur nach unten sind auch alle echt, das ist jedes mal wenn die Putzfrau hier lüftet. Bei den ersten beiden Ausreißern korreliert der IAQ-Wert auch entsprechend (er sinkt wenn gelüftet wird). Beim Dritten Tag in der zweiten Woche hatte ich das Bricklet aus versehen getrennt und erst am Freitag Abend wieder angeschlossen (daher hat diese Woche in den Daten nur 3 Tage). Seit exakt dem Zeitpunkt springt bei mir der IAQ-Wert auch zwischen den Extremwerten hin und her. Was für mich daruf hindeutet das es ein Problem beim übernehmen der eingelesenen Kalibrierung gab. Ich lasse das jetzt erst mal noch ein paar Tage laufen um zu sehen ob es sich wieder fängt. Wenn nicht lösche ich die Kalibrierung um zu sehen ob es sich dann wieder wie zuvor verhält. Eventuell veröffentliche ich dann erst eine Firmware in der die Kalibrierung nicht gespeichert/geladen wird, wenn das aktuell noch nicht funktioniert.

I am not sure if i understand the question correctly. But, if you call SetTargetPosition while the Motor is currently running, it will immediately try to go to the new target and discard the previous one. There is no queue of targets or similar.

Die "Accuracy" ist hier ganz gut erklärt: https://community.bosch-sensortec.com/t5/MEMS-sensors-forum/BME680-IAQ-accuracy-definition/m-p/5931/highlight/true#M10

Im angehängten Bild kannst du es gut erkennen.

Firmwares: DC Brick 2.3.9, IMU Brick 2.3.9, IMU 2.0 Brick 2.0.14, Master Brick 2.4.10, Servo Brick 2.3.9, Silent Stepper Brick 2.0.0, Stepper Brick 2.3.10 Bricklet-Port Fehldetektion behoben SPI Stack-Timeout erhöht (für RED Brick) Bugs in set/get_spitfp_* Funkionen behoben Download: DC Brick, IMU Brick, IMU 2.0 Brick, Master Brick, Servo Brick, Silent Stepper Brick, Stepper Brick

Firmwares: DC Brick 2.3.9, IMU Brick 2.3.9, IMU 2.0 Brick 2.0.14, Master Brick 2.4.10, Servo Brick 2.3.9, Silent Stepper Brick 2.0.0, Stepper Brick 2.3.10 Fix Bricklet port miss-identification Increase SPI stack timeout (for RED Brick) Fix bugs in set/get_spitfp_* functions Download: DC Brick, IMU Brick, IMU 2.0 Brick, Master Brick, Servo Brick, Silent Stepper Brick, Stepper Brick

Laut den Bildern die ich dazu bei google finde ist der Motor mit 0,6A zu betreiben: https://www.google.com/search?q=PXC43-02A+0.6a&client=ubuntu&hs=nrJ&channel=fs&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiV_vb51dvgAhUFGewKHbPoBM0Q_AUIDygC&biw=1920&bih=1101 Schrittmotoren sind stromgetrieben, daher sollte die Spannung fast immer so hoch sein wie möglich. Also die Maximalspannung die der (Silent) Stepper Brick verträgt nicht überschreiten, aber ansonsten das Maximum was du an Stromversorgung zur Verfügung hast.

Die Doku-Seite zu dem Bricklet wird noch aktualisiert, ich hab da schon ein paar Stichpunkte aufgeschrieben. Generell haben wir festgestellt dass der Sensor eine ganze Weile laufen muss bis er vernünftige Werte liefert. Was man im Bosch Sensortec Forum aktuell findet: * Um einen vernünftigen IAQ Wert zu bestimmen muss sich die Luftqualität regelmäßig ändern: https://community.bosch-sensortec.com/t5/MEMS-sensors-forum/BME680-IAQ-accuracy-definition/m-p/5937 * Die aktuelle BSEC Library (die wir auch verwenden) hat noch Bugs: https://community.bosch-sensortec.com/t5/MEMS-sensors-forum/BME680-state-save-state-load-problem/m-p/5911 Bei uns in der Firma funktioniert das Bricklet erstaunlich gut, da die Luft zwischendurch mal sehr schlecht wird wenn Prototypen mal wieder verbrennen oder der Laser-Cutter lange läuft etc. Dann ist auch mal wieder die Tür länger auf. Das kann man dann in den Daten wiederfinden. Ich hatte es aber auch schon dass der IAQ-Wert auf 500 hochgeschossen ist und da eine längere Zeit geblieben ist und nach dem Lüften auf einmal für ein paar Stunden bei 0 feststeckt... Ich hoffe das Bosch sich langfristig vielleicht doch dazu durchringen kann den Auswerte-Source-Code zu veröffentlichen oder vielleicht jemand selbst was entwickelt und offen stellt.

Ja, da ist ein Stück uninitalisierter Speicher im Bootloader. Wenn dort an einer bestimmten Stelle zufällig 90 drin steht ('Z'), dann wird das beim Enumerate mit zum Master übertragen. Normalerweise setzt der Master Brick den Port in der Nachricht (Das Bricklet weiß gar nicht an welchem Port es angeschlossen ist). Aber bei 'Z' geht er davon aus dass das Air Quality Bricklet an einem Isolator Bricklet angeschlossen ist, da der Port des Isolator Bricklet ist immer 'Z' ist. Hier ist der Fix im Bootloader dafür: https://github.com/Tinkerforge/brickletboot_xmc/commit/bedbb6a29dbd9d4189506aaa4e45238d37a11285 Und hier ist der Code im Master Brick der das Problem verursacht: https://github.com/Tinkerforge/bricklib/blob/master/bricklet/bricklet_co_mcu.c#L244 Der Bootloader wird allerdings nicht aktualisiert wenn du die Firmware aktualisierst. Der wird nur einmal von uns ganz am Anfang geschrieben. Da die Bootphase deterministisch ist, passiert das beim Air Quality Bricklet zumindest am Anfang jedes mal, auch wenn die Chance dass das überhaupt passieren kann eigentlich nur 1 zu 256 ist . Edit: Ha! Jetzt wo ich mir das nochmal in Ruhe angeschaut hab ist die Lösung eigentlich ganz einfach. Die "connected uid" wird von den Bricklets immer als "\0" initialisiert, von einem Isolator Bricklet aber entsprechend auf die UID des Isolator Bricklets gesetzt. D.h. der Check muss einfach if(gir->position != 'Z' || gir->connected_uid[0] == '\0') sein. Dann ist das Stück uninitialisierter Speicher wieder kein Problem mehr . Muss ich mir morgen nochmal genau ansehen, aber ich denke das ist die Lösung.

Der Bug dort liegt im Bootloader des Air Quality Bricklets, da kann der Brick Viewer leider nichts gegen machen.

Das ist aktuell auf 3600 Sekunden konfiguriert (eine Stunde). Wenn du eingeloggt bist solltest der Warenkorb allerdings auch ohne cookie persistent bleiben.

Da muss ein 3.3V <-> 5V I2C-Wandler in die SDA/SCL Leitung. Das lässt sich also leider nicht so ohne weiteres fixen mit dem bestehenden Design. Wenn man das mit einem Fädeldrähtchen oder so fixen könnte hätten wir das hier bereits getan.

Ich hab das nochmal versucht ausgiebig zu testen. Vorweg folgender Hinweis: Wir haben vor einiger Zeit den Prozessor auf dem Master Brick (SAM3S4CA) gegen den Pin-Kompatiblen Nachfolger (SAM4S4CA) ausgetauscht. Ersterer hatte nirgends mehr Lagerbestand und war Mittlerweile auch teurer als der Nachfolger. Folgende Feststellung die ich hier bei meinen Tests hab: Das Bricklet stört den ADC des Prozessors (SAM3 und SAM4) an Port C und D, funktioniert aber. Das Bricklet funktioniert an Port A und B mit dem SAM3 Das Bricklet funktioniert nicht an Port B mit dem SAM4 Meine Vermutung dazu: Auf Grund eines Bugs in der Hardware haben wir über einen Widerstand (I2C Pull-Up) 5V auf einem ADC-Pin liegen der dafür nicht ausgelegt ist. Daher Muss die Schutzdiode die im Prozessor ist durchgängig arbeiten. Die Ströme die da fließen sind sehr gering, daher kann soweit wir das überblicken dort zwar nichts kaputt gehen, aber der ADC wird gestört. Nun sieht es so aus als würde der SAM3 mit diesem Problem besser klarkommen als der SAM4. Die Fehler (falsche Segmente werden angesteuert etc) kann ich hier nämlich nur mit Master Bricks mit SAM4 reproduzieren. Das mag am neuen Prozessor liegen, eventuell aber auch nur an der Produktions-Charge. Das Segment Display 4x7 2.0 befindet sich aktuell bereits in der Produktion und wird in ~2 Monaten veröffentlicht. Dieses hat den Hardware-Bug natürlich gefixt (und einen 7p Stecker etc). Ich befürchte das einzige was ich euch da aktuell anbieten kann ist, dass wir das alte Segment Display 4x7 durch die neue 2.0 Variante austauschen sobald diese Verfügbar ist.