borg

Der Wert kommt aus dem Datenblatt des verwendetden Sensors (TCS3472): https://github.com/Tinkerforge/color-bricklet/raw/master/datasheets/TCS34725.pdf Ich vermute im Falle dieses Sensors gibt die "Dynamic Range" das Verhältnis zwischen der größten und kleinsten Lichtstärke (oder Kontrast) an, die unterschieden werden kann.

Alle verbauten Komponenten sollten von -20°C bis +85°C funktionieren. Wir waren mit dem Baukastensystem allerdings nie in einer Umweltkammer und haben diesbezüglich abnahmen machen lassen o.ä.

Puh, ich hab mir gerade den Code diesbezüglich angeguckt: Wir Verbinden uns immer nur auf eine SSID. Wir arbeiten nie mit MACs. Ich befürchte wenn das Verhalten so ist wie du es beschreibst passiert das innerhalb des WIFI Moduls und wir können da nichts gegen machen .

Um die Fragen in dem Thread aufzugreifen: Eine günstigere WIFI Extension 2.0 auf Basis des ESP8266 kommt Anfang nächsten Jahres. Wir haben dafür sogar die Jahres-Abnahmemenge des WIFI-Industriemoduls auf der aktuellen WIFI Extension gekündigt und eine Strafzahlung in kauf genommen . Da ist auch schon eine ganze Menge Code geschrieben: https://github.com/Tinkerforge/wifi-v2-extension/tree/master/software/src Kompatibel zum RED Brick ist die neue WIFI Extension dadurch allerdings leider trotzdem nicht und sie wird auch teurer bleiben als ein WIFI USB Stick. Der USB Stick wird auch weiterhin mehr Durchsatz etc haben. Eine WIFI Extension auf dem RED Brick macht einfach keinen Sinn . Einen Linux-Treiber für eine WIFI-Anbindung mit externem TCP/IP Stack zu schreiben wäre ein immenser Aufwand, das steht in keinem Verhältnis zum Nutzen.

Die Grenze des eingesetzten Sensors auf dem Accelerometer Bricklet ist 1600Hz. Die Grenze von USB sind 1000 Nachrichten pro Sekunde (also 1000Hz oder eine Nachricht pro ms). Wenn du Callbacks nutzt und der USB Bus sonst nicht von anderen Teilnehmern ausgelastet wird würde ich erwarten dass du 1000Hz wirklich erreichen kannst. Wo jetzt genau der Flaschenhals bei der ist bin ich mir nicht sicher. Wahrscheinlich einfach das IO, also das Schreiben in die Datenbank? Hast du irgendwo noch Logging laufen welches in die Console ausgibt? Damit kann man auch schnell einen Flaschenhals erzeugen.

The Dust Detector Bricklet can not be used to determine PM10 or PM2.5. This would require that it can distinguish between many small particles and one big particle, which it can not. E.g. pollen (from flowers) would not be registered in PM2.5, since the pollen particles are quite big. But they would register in the Dust Detector Bricklet.

@Monti: Das ist echt komisch, vor allem wenn er direkt vorher funktioniert hat. Ist der Erase/Reset-Taster vielleicht irgendwie "eingeklemmt", so dass der Taster immer ausgelöst ist? Sonst schreibe bitte eine Email an info@tinkerforge.com mit der Bestellnummer der Bestellung in der der Master Brick war, wir schicken dann einen neuen raus .

Oh, du hast in der Tat einen Fehler in der Firmware gefunden . Bitte auf 2.0.1 aktualisieren, dort sollte es jetzt gefixt sein .

Firmware: IMU Brick 2.0 2.0.1 Fix wrong order of callbacks. Download: IMU Brick 2.0

Firmware: IMU Brick 2.0 2.0.1 Falsche Callback-Reihenfolge repariert. Download: IMU Brick 2.0

Have you tried to use the slow i2c mode with the set_i2c_mode funktion that the Temperature Bricklet API has?

Bitte einsenden. Je nachdem was da genau hochgegangen ist können wir das reparieren. Am besten einen kurzer Hinweis was passiert ist sowie die Rücksendeadresse dabei legen.

Danke für den Hinweis, ist gefixt!

It is currently not planned. There are LoRa USB sticks, perhaps you can get them to work with the RED Brick? That is the best i can think of .

Neue Software: Brick Logger Blogeintrag

New Software: Brick Logger Blogentry

@Stormrider: Das ist kein Problem. Beim Kalibrieren einfach in 10mg rechnen anstatt 1g. Also wenn du mit 500g kalibrierst trägst du halt 50000 ein statt 500. Schon hast du auf 10mg kalibriert anstatt auf 1g.

Batti meinte in der Werkbank, nicht außen. Da sind genug Löcher drin, das sollte nicht zu warm werden. Bricks über Kabel verbinden ist einfach technisch nicht möglich. Wir reden hier von 60 Leitungen auf denen Unterschiedliche Protokolle mit Frequenzen von 400kHz bis 8MHz gesprochen werden. Wie soll das aussehen? Wie soll die Signalintegrität eingehalten werden? Wie soll das CE-Konform bleiben (Störausstrahlung)? Edit: Ganz davon abgesehen haben wir ja schon eine Möglichkeit zwei Stapel per Kabel zu verbinden: Die RS485 Extension.

Tinkerforge Workbench Blogentry

Tinkerforge Werkbank Blogeintrag

The default port should be 4223.

Jeder hat halt seine eigene Anwendung im Kopf, das ist schon OK. Gerade bei Funk gibt es halt viele Richtungen: Reichweite vs Durchsatz vs Stromverbrauch vs Kompatibilität. Das man da jetzt Begehrlichkeiten weckt wenn man über Funk-Produkte redet ist klar, aber wir können mit einem Produkt nun einmal nur in eine Richtung gehen und wir werden zusätzlich vom bestehenden Baukastensystem eingeschränkt . Da werden wir schon einen Kompromiss finden .

Ja, ich meinte oben auch Kunststoff-Spritzguss und kein Metall .

Ja, das Ding verhält sich nach außen genau so wie ein Brick. Es schlägt im Brick Viewer auf wenn du es per USB anschließt, es hat eine API usw. Der aktuelle Prototyp kann das, ja.