borg

I am currently working on the Air Quality Bricklet, there is a bit more API coming too. So this is at the moment simply work in progress and the generator and air quality git are a bit out of sync.

Ich hab das jetzt auf die neueste Bosch-Auswertesoftware aktualisiert und gerade einen Dauertest gestartet. Ich würde das jetzt für mindestens 4 Tage laufen lassen, damit er zumindest einmal die kompletten Daten für die Kalibrierung sammeln kann. Danach dann nochmal 1-2 Tage um zu überprüfen ob die Sensor-Daten dann vernünftig sind. Dauert also noch ca. eine Woche bis es ein neues Release gibt (falls ich nicht noch weitere Probleme finde). Es gibt übrigens auch einen Modus wo das Bricklet die letzten 28 Tage zur Kalibrierung verwendet. Was meint ihr, macht es Sinn auf den 28-Tage-Modus umzusteigen um bessere IAQ-Werte zu bekommen? Ich tendiere aktuell dazu das zu tun. Zusätzlich noch eine Funktion um die aktuelle Kalibrierung zu löschen, damit man nicht 28 Tage warten muss bis man wieder vernünftige Werte bekommt wenn man die Umgebung des Bricklets komplett verändert. Man könnte die Kalibrierungszeit auch zwischen 4/28 Tage konfigurierbar für den Nutzer machen.

Da haben sich zwei Bugs miteinander verzahnt. Es gibt einen Bug im Bootloader der dazu führt das ein Bricklet in seltenen Fällen fälschlicherweise die Position 'Z' bekommt (die eigentlich für Bricklets die an Isolator Bricklets angeschlossen sind vorgesehen ist). Das ist an und für sich erstmal gar nicht so schlimm, dadurch geht nichts kaputt. Es führt aber dazu das im Brick Viewer das Bricklet ohne Parent angezeigt wird und die Auto-Update-Funktion hat dafür keine Unterstützung. Dadurch funktioniert auf einmal die Auto-Update-Funktion nicht mehr . Wird zum nächsten Brick Viewer Release gefixt.

You would need to add a RS232 Bricklet and construct this sentence from the data you get from the GPS Bricklet. The GPS Bricklet does not have API that transfers the NMEA sentences to the PC.

Yes, we would make a complete separate v2 version. We also would like to add .NET Core support if we do a major update of the C# bindings. For that we would have to exchange some of the internals with .NET Core compatible stuff too.

Neues Accelerometer Bricklet 2.0 mit Datenrate bis zu 25,6kHz Blogeintrag

New Accelerometer Bricklet 2.0 with data rate up to 25.6kHz Blog entry

Sweet, looks good! The design of the C# bindings is indeed quite old by now and it shows in the API. We try to always maintain backwards compatibility, so it often is hard to add new programming language features over time. Maybe it would make sense to have some kind of C# bindings 2.0 and maintain the old C# bindings for legacy applications for a while.

You can get the PPS signal as a callback in the API. From your question i assume you want it as a digital output? What is can do is: Use a GPS Bricklet 2.0 and a Industrial Digital Out Bricklet and every time you get the callback you set a digital output on the Bricklet. This will of course have a jitter that depends on the USB stack of your PC. I would expect something around +-1ms.

A synchronization directly on the Brick is unfortunately not possible. You can only get the PPS signal from a GPS Bricklet 2.0 and use that as a trigger to call a getter from a IMU Brick 2.0. What application do you have in mind for the synchronization?

Ich hab mir die Daten über das Wochenende loggen lassen und ich hatte in der Tat auch ein paar "Ausreißer" bei mir war es die Luftfeuchte-Messung mit ungefähr 10% Sprüngen nach oben. Das Air Quality Bricklet muss leider einen Binärblob von Bosch nutzen auf den wir aufsetzen. Seitdem wir das Bricklet veröffentlicht haben gibt es eine neue Version von der Bosch-Software mit etlichen Bugfixes laut Changelog. Bosch hat allerdings die API und ein paar Konstanten und Namen verändert. Daher kriege ich das heute nicht aktualisiert, ich denke am Freitag komme ich dazu, da gibt es dann eine neue Firmware-Version. Ich hoffe die Ausreißer sind damit dann gefixt!

Besten Dank, ist gefixt. Da fehlten sogar noch zwei weitere Links in der Doku .

@ChrisCA: Klingt interessant, schaue ich mir an. @theo: Ich kann mir nicht so recht erklären warum Mifare Classic funktioniert aber die anderen Typen nicht. Das kann ja dann zumindest kein Hardwaredefekt sein denke ich? Also der State wechselt von Initialization auf Idle bei dir, richtig? Sonst könntest du Mifare Classic ja auch nicht nutzen. Aber von da nicht zu den anderen States wenn du versuchst einen anderen Tag-Typ zu lesen?

Komisch, das ist mir noch nicht aufgefallen obwohl ich für die Tisch-Wetterstation viel mit dem Air Quality Bricklet getestet hab. Ich habs mir auf die TODO-Liste geschrieben da nochmal einen Test zu schreiben und mir das anzusehen.

Das klingt sehr sinnvoll, schreibe ich mir auf die TODO-Liste .

Du kannst die fcstd Dateien mit freecad öffnen: https://www.freecadweb.org/ Die meisten anderen Dateien sind irgendwelche Zwischenformate oder das Format welches unser spezifischer Laser Cutter versteht.

Die Gehäuse sind hier zu finden: https://github.com/Tinkerforge/cases Das ist leider aktuell eine unaufgeräumte Ansammlung, wie man schon an den unterschiedlichen Benennungen sehen kann. Da muss ich mal irgendwann aufräumen und das alles vernünftig benennen und generierte Dateien entfernen usw.

Die Bricklets mit 7-Pol Stecker werden auf dem RED Brick erst seit Brick Daemon Version 2.3.0 unterstützt. D.h. du müsstest entweder den Brick Daemon auf dem RED Brick aktualisieren oder ein RED Brick Image mit Version 1.9 oder höher verwenden.

Das Accelerometer 2.0 kommt Ende Januar/Anfang Februar raus

Du musst die anderen LEDs immer alle auf (0, 0, 0) setzen damit diese auch aus bleiben. Wenn die LEDs 'floating' sind und nicht angesprochen werden, können sie leider beliebige Farben annehmen. Zuschneiden kannst du immer an diesen goldenen Pads. Dort kannst du dann auch jeweils wieder ein neues Kabel anlöten.

Ich hab das gerade ausprobiert und bei mir wird das im 16G-Bereich auch sehr ungenau. Das entspricht allerdings wirklich dem Wert den der Accelerometer-IC den wir verwenden zurück gibt, da ist keine Fehler in der Berechnung o.ä. Es scheint also leider so zu sein, dass der 16G-Bereich ungenauer ist als die anderen Bereiche.

Ja, der Schrittmotor muss zusätzlich mit Strom versorgt werden. Die 5V-Versorgung über USB reicht leider nicht aus um einen Schrittmotor zu betreiben.

Oh man, wie hab ich das denn jetzt wieder hinbekommen... Ist jetzt auch gefixt.

Du hattest exakt recht mit deiner Vermutung! Den gleichen Bug gab es auch noch beim Slider. Neue Firmware ist veröffentlicht, hab das getestet mit: /usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "GK7" # Change XYZ to the UID of your LCD 128x64 Bricklet from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_lcd_128x64 import BrickletLCD128x64 if __name__ == "__main__": ipcon = IPConnection() # Create IP connection lcd = BrickletLCD128x64(UID, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected # Clear display lcd.clear_display() lcd.remove_all_gui() lcd.set_gui_button(0, 100, 50, 28, 14, 'test') lcd.set_gui_slider(0, 0, 0, 128, 0, 50) lcd.set_gui_slider(1, 0, 30, 34, 1, 10) raw_input("Press key to exit\n") # Use input() in Python 3 ipcon.disconnect() Der Button und beide Slider tauchen in 2.0.5 nicht auf, funktionieren aber in der neuen 2.0.6.

Neue Firmware ist veröffentlicht!