borg

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.

Das hängt ganz davon ab wie du deinen GUI-Slider nutzen möchtest. Je nach Anwendung ist es möglich auf die Änderung des Sliders direkt im Callback zu reagieren. Falls es in deinem Programm eine Main-Loop o.ä. gibt die alles behandeln soll, kannst du z.B. die Werte des Sliders in eine Queue (oder ein Future) packen und in der Main-Loop regelmäßig schauen ob etwas in der Queue ist.

Ich würde sagen die Messwerte des Air Quality Bricklet sind dafür gut genug.

Sehr komisch. Hast du diese Probleme auch wenn du das Bricklet an Port A anschließt? Oder nur an Port B?

In the database you can save the global value for each day. When you want to display the value you get the value from last day from the database and the value from today and the difference is the amount of rain from the last 24 hours. You can do the same for the amount of rain for the last 1 hour etc, depending on the frequency with which you save data to the database.

Die Air Quality Bricklet Firmware ist 74kb groß. Der Großteil davon ist kommt durch die Integration von "Bosch BSEC".

Das wird eher nicht funktionieren. Da wirst du die meiste Zeit die Entfernung zur Scheibe messen.

Wir haben drei Prozessoren im Einsatz bei den neuen Bricklets XMC1100_Q024x0016: Wenig Pinne, 16kb Flash (wird für alle Bricklets benutzt die nur einen Sensor auslesen o.ä.) XMC1302_Q024x0032: Wenig Pinne, 32kb Flash (wird benutzt wenn es etwas mehr zu berechnen gibt oder die API groß ist (z.B. LCD128x64) XMC1404_Q048x0200: Viele Pinne, 256kb Flash, Support für externen Quarz (wird benutzt wenn wir ganz viel Flash benötigen (z.B. für Floating Point Math) oder viele Pinne benötigen oder eine präzise Clock benötigen)

Das Air Quality Bricklet ist schon hauptsächlich dafür da den IAQ Index zu messen, die anderen Daten werden erhoben um diesen besser bestimmen zu können. Die Temperatur wird automatisch angeglichen wenn der Heater an ist, das ist aber sicherlich nicht 100% perfekt. Ein Temperature Bricklet wird da schon die besseren Ergebnisse liefern. Ein großer Unterschied ist auch die Abfragerate. Das Barometer Bricklet 2.0 kann mit einer Datenrate abgefragt werden die gut genug ist um damit die Höhe von einem Quadcopter zu kontrollieren. Das Air Quality Bricklet erhebt Daten alle 3 Sekunden. Wenn es nur darum geht Umweltdaten zu messen um langfristige Tendenzen zu erkennen (Temperaturunterschied Tag/Nacht, Luftdruckveränderung über die Wochen etc) sind die Messwerte des Air Quality Bricklets meiner Meinung nach gut genug. Die besten Ergebnisse erzielt man sicherlich mit den "Einzelbricklets". Dazu muss man auch sagen: Die Spezifikationen übernehmen wir natürlich von den Sensorherstellern und gehen davon aus das diese stimmen. Jeder Sensorhersteller hat da aber irgendwo im kleingedruckten andere Sache stehen. Ich hab mir z.B. gestern die Spezifikation des neuen Sensirion CO2 Sensors angesehen. Diese ist sehr gut, im Kleingedruckten steht aber das Sie nur garantieren dass diese Spezifikation für 90% der ausgelieferten Sensoren gilt... So richtig toll vergleichen kann man die unterschiedlichen Sensoren anhand der Spezifikation also leider nicht.

Attachment test. Edit: The attachments work fine for me, i tried Firefox and Chrome.

You have to save the value of the last "last_value" and then read the new value for the new day "new_value". The amount of rain for one day can then be calculated by "new_value - last_value".

Firmware: Temperature IR Bricklet 2.0 2.0.3 Use correct wait times during emissivity change Improved error handling in case of invalid read Download: Temperature IR Bricklet 2.0