borg

Die "WIFI Bridge" ist aktuell noch ein internes Forschungsprojekt, da gibt es noch keine Informationen drüber . Der Silent Stepper Brick wird in der Tat ein Stepper Brick sein welcher einen Schrittmotor-IC verwendet der extra dafür gedacht ist Schrittmotoren lautlos zu bewegen. Er wird bis zu 1/256 (interpolierte) Mikroschritte machen können. Die WIFI Extension 2.0 wird nicht auf dem RED funktionieren. Wir brauchen im Stack einen WIFI-IC der TCP/IP selbst bereits spricht (da wir keinen Platz für einen TCP/IP Stack auf dem Master Brick haben). Allerdings haben diese ICs alle keine Unterstützung für Linux, da Linux natürlich einen TCP/IP Stack mitbringt und so ein Chip daher keinen Sinn macht. Sie wird dafür aber andere tolle neue Sachen können .

Das ist mit der API nicht möglich und es ist auch nicht implementierbar. Die Ausgänge der IO-4 sind direkt mit den Pinnen des Microcontrollers auf dem Brick verbunden. Microcontroller haben beim Booten für gewöhnlich immer alle ihre Pinne auf "Input Pull-Up" stehen. D.h. den Zustand könnten wir frühestens ändern wenn das Brick gebootet hat und die Bricklet Plugins geladen sind und der erste Tick ausgeführt wird. Bis dahin sind aber schon 2-3 Sekunden vergangen. Zu dem Zeitpunkt kannst du es dann aber auch einfach über die API einstellen.

Für das Video haben wir ein Labornetzteil genutzt.

Das ist komisch. Die aktuell veröffentlichen Bindings unterstützen leider den Error Callback noch nicht, daher können wir nicht überprüfen ob es ein Parity- oder Framing-Error o.ä. ist. Ich würde versuchen das hier nachzubauen (also RED Brick + Master Brick + RS232 + Nachriten alle 250ms). Mal schauen ob ich das reproduzieren kann. Aber ich befürchte das wird durchlaufen. Wenn du meinst es könnte an irgendwelchen Störungen liegen könntest du versuchen das RS232 Bricklet räumlich mehr von den anderen Komponenten zu trennen. Tritt der Fehler denn immer nur auf wenn du etwas mit dem Display machst? Es ist aber nicht so das die Spannung einbricht wenn das Display an ist?

Die Bricks/Bricklets haben leider keine Real Time Clock. Dadurch würde es dort schnell zu großen Abweichungen kommen. Ich befürchte ein PC/RPi/RED kann die Amperestunden viel besser bestimmen als wir es auf dem Bricklet könnten. Daher macht das denke ich keinen Sinn.

Welche Firmware Version hat das RS232 Bricklet?

Ist egal. Die Virtualisierung funktioniert vermutlich effizienter wenn die VM gleich-bittig mit dem Host ist. osboxes@osboxes:~$ du -h tf/ [...] 3.3G tf/ osboxes@osboxes:~$ df -h Filesystem Size Used Avail Use% Mounted on [...] /dev/sda1 48G 8.3G 37G 19% / [...] Also der tf Source Code braucht ca. 3,3G und die ganzen Pakete brauchen ca. 5G. Ich würde mindestens 15G reservieren.

Build environment for Brick firmware development Blogentry

Build-Umgebung für Entwicklung von Brick-Firmwares Blogeintrag

Das sieht leider schlecht aus. Wir haben zwar funktionierende Prototypen hier, haben allerdings jetzt mittlerweile von drei Herstellern Lieferzeiten von je ~6 Monaten für größere Stückzahlen bekommen. Die ganzen "Wearables" die aktuell produziert werden scheinen den ganzen Markt an kleinen OLEDs leer zu kaufen. Wir suchen noch ein bisschen weiter. Falls wir keinen Hersteller mit Lagerbestand (oder kürzeren Produktionszeiten) finden müssen wir mit 6 Monate Lieferzeit bestellen .

So, ich hab eine setBreakCondition-Funktion hinzugefügt: https://github.com/Tinkerforge/rs232-bricklet/commit/2ea5313996fc75d28cc9da159937c9b709960603 https://github.com/Tinkerforge/generators/commit/dc4dd52c24ab470c5582cfaa0d67690490ec5d0c Das steht dann mit dem nächsten Bindings-Release zur Verfügung .

Ne, das siehst du falsch. Es werden einfach Binärdaten als char-Array übertragen. Da wir (auf Grund er generierbarkeit) keine dynamischen Arrays in unseren APIs haben können, musst du immer ein komplettes char-Array der Länge 60 übertragen und zusätzlich eine Länge. Wenn du nur ein Byte schreiben möchtest, musst du also einfach das Byte in das erste Element des Arrays schreiben und die Länge auf 1 setzen.

Yes you do! There are only 5V and 3.3V rails on the Bricklet connector, so the 12V can't be given to the Bricklet.

MQTT mit Tinkerforge Blogeintrag

MQTT with Tinkerforge Blogentry

Du kannst die 1kg Wägezelle durch eine 5kg Wägezelle austauschen, sie sind von der Größe her kompatibel. Allerdings ist der mechanische Aufbau nicht wirklich für 5kg ausgelegt. Der Durchmesser des Tellers hat nur: 10cm. Uups, Ist gefixt.

Ist geklebt. Wir wollten ursprünglich die Schneidklemmen nutzen, haben aber vorsichtshalber auch Lötpunkte vorgesehen falls das mit den Schneidklemmen nicht funktioniert. Der Durchmesser der Kabel des Sharp-Moduls ist gerade an der Zulässichkeitsgrenze für die Klemmen. Beim zusammenbauen sind uns dann Mehrfach die Klemmen zur Seite hin abgebrochen. Daher haben wir dann alles gelötet um sicher zu gehen das nicht später beim Kunden die Klemmen abbrechen wenn man sie nur anhaucht. Bei der nächsten Bestückung des Dust Detector Bricklet werden wir die Schneidklemmen nicht bestücken. Der Sharp-Sensor ist schon dafür gedacht durchgängig zu laufen. Zusätzlich macht es Sinn sich oft Werte zu holen und Durchschnitte zu bilden. Man denke zum Beispiel an Pollenflug, wenn man da nur jede Minute einmal misst, bekommt man schnell ein falsches Bild (und gerade für Pollenflug ist der Sensor super geeignet). Also lieber einmal pro Sekunde messen und einen Durchschnitt über je 30 Minuten bilden um einen Tagesverlauf zu bekommen als direkt einmal pro 30 Sekunden zu messen . Edit: Ganz allgemein muss der Sensor eigentlich in einem Luftstrom sitzen um gut zu funktionieren. Ich denke wir machen da noch ein Kit für, ähnlich wie das Waagenkit für das Load Cell Bricklet.

Mit der aktuellen Firmware gibt es keine Möglichkeit ein einzelnes "break" zu senden. Es ist allerdings mögliche sowas wie eine send_break() function zur API hinzuzufügen. Ich hab mir das auf die TODO-Liste geschrieben, da werde ich allerdings diese Woche nicht mehr zu kommen. Dauert also ein bisschen.

Ja, die Schwerkraft wirkt sich nur auf die Beschleunigungswerte aus. Du bist einer durchgängigen Beschleunigung von ~9,81 m/s² nach unten ausgesetzt. Genau das misst das Accelerometer Bricklet genauer als das IMU Brick. Vielleicht kannst du Änderungen im Schwerefeld als relative Änderungen erkennen. Die absolute Genauigkeit ist definitiv nicht hoch genug. Du müsstest über viele Werte mitteln und das ganze müsste mechanisch sehr fest angebracht sein.

Also es geht nur um Änderungen in der Beschleunigung? Dafür ist das Accelerometer Bricklet wahrscheinlich besser geeignet als das IMU Brick. Das hat diesbezüglich eine höhere Auflösung (aber misst natürlich nur die Beschleunigung).

Uuuups, das ist ein Bug den ich frisch in die 2.0.1 Firmware eingebaut habe, Sorry ! Bitte auf 2.0.2 aktualisieren.

Plugin: Laser Range Finder Bricklet 2.0.2 Stelle sicher, dass Interrupts nach I2C-Kommunikation in allen Fällen wieder aktiviert werden. Download: Laser Range Finder Bricklet

Plugin: Laser Range Finder Bricklet 2.0.2 Make sure interrupts are enabled after I2C communication in all cases Download: Laser Range Finder Bricklet

Der Fehler sagt, das die SIM-Karte nicht auf eine Anfrage geantwortet hat, vermutlich weil du keine SIM-Karte eingesteckt hast . Die SMS geht an die Nummer, welche in Zeile 15 eingetragen ist (in sms_humidity.py). Dort kannst du auch die PIN der SIM-Karte einstellen. Der Absender hat die Nummer der SIM-Karte die du einsteckst. Nein, siehe oben. Das Plastik-Teil auf dem das CE-Zeichen und die WEEE-Mülltonne ist (auf dem Stick) kannst du aufmachen, dadrunter ist der SIM-Karten-Halter.

Wie wäre es mit einem der wasserdichten Einschraubfühler von hier: https://www.sensorshop24.de/temperaturfuehler/ Also du musst drauf achten das der Sensor Wasserdicht ist und ein Pt100 oer Pt1000. Ansonsten kannst du von dort eigentlich jeden Fühler kaufen. Zum Beispiel https://www.sensorshop24.de/temperaturfuehler/einschraubfuehler-mit-kabel/einschraubfuehler-mit-einem-m6-gewinde/einschraubfuehler-mit-einem-m6x10-gewinde/einschraubfuehler-bis-200-c-wasserdicht/