batti

Hallo Mango, besser ist es denke ich das Bricklet in dem Medium (Erde) zu lassen und darin die Eckpunkte festzulegen. Viele Grüße, Bastian

Hi Delphi, klemmt vielleicht der Reset Taster? Die älteren Master Bricks konnte man z.T. nicht im Stapel flashen, nicht dass das die Ursache ist. VG, Bastian

Zur API: Vielleicht nicht ganz einfach zu lesen, aber prinzipiell schon vollständig: https://github.com/Tinkerforge/generators/blob/master/configs/brick_silent_stepper_config.py

Hallo Mango, das Moisture Bricklet besteht technisch gesehen aus zwei Teilen: 1) Schwingkreis Da ist ein kleiner Schwingkreis drauf der eine feste Frequenz erzeugt. 2) RC Filter (RC Glied) Dieser Filter erzeugt quasi aus der Frequenz eine Spannung. Der Filter besteht einfach aus einem Widerstand ® und einem Kondensator ©. Abhängig von den Werten dieser beiden Bausteine filtert er mehr oder weniger. Der Kondensator ist nun aber kein Bauteil sondern die Leiterkarte. Wird die Leiterkarte in feuchte Erde gesteckt besitzt der so gebaute Kondensator einen andere Kapazität als wenn die Platine in trockene Erde gesteckt wird. Somit erzeugen wir eine unterschiedliche Spannung abhängig von der Kapazität, also der "Umgebung" des Bricklets. Eine Umrechnung ist leider nicht so einfach möglich, da hier Toleranzen, Temperaturabhängigkeiten etc. mit im Spiel sind. Viele Grüße, Bastian

Hallo Dim, es wird in kürze ein Blogeintrag dazu geben. Leider hast du recht, dass es dieses Jahr mit dem Silent Stepper Brick nichts mehr wird.

Wir haben heute das IMU Brick erhalten. In der Tat fehlte das besagte Bauteil. Entschuldige bitte, der Brick geht morgen repariert an dich zurück.

Hallo, das Bricklet besitzt eine interne Stromversorgung, die aus der 5V Systemspannung 12V generiert. Damit wird der 0-10V Spannungsausgang und auch der Stromausgang versorgt. Die Spannungsquelle ist zeitgleich extern erreichbar. Bis zu 100mA sind dort entnehmbar.

Der Test mit den drei Master Bricks ist über Nacht durchgelaufen. Ich hatte nur einen angezeigten Timeout im Brick Viewer. Kein Neustart o.ä. Habe den Test jetzt umgebaut (von unten nach oben): Step Down Power Supply Master Brick 2.0 WIFI 1.0 an Port D über 15cm Kabel angeschlossenes LED Strip Bricklet Chip Typ WS2801, 10ms Frame Duration, 150 LEDs und dann "Show Moving Color Gradient". Das Läuft aktuell auch bereits wieder über eine Stunde ohne Probleme. Teste ich noch falsch? Kann es sein, dass bei euch der WLAN Empfang sehr schlecht ist o.ä.? (Access-Point ist bei mir 10m Luftlinie entfernt mit einer Holzdecke dazwischen)

Ich teste aktuell mit einem Stapel aus drei Master Bricks 2.0 (hatte ich gerade zur Hand)

overflow gibt dir an ob es seit dem Start jemals ein "overflow" gab, "low_watermark" die größte Ausnutzung des Puffers, und "used" wieviel Bytes vom Puffer aktuell benutzt werden. Dafür gibt es keine vorhergesehende Logik. Das ist erst einmal nur eine Statusinformation. btw. Ich habe jetzt hier seit über einer Stunde einen Aufbau mit WIFI 1.0 Extension und LED Strip Bricklet am laufen und lasse einen "Moving Color Gradient" mit 100ms Frame duration und 150 LEDs laufen. Bisher kein Neustart oder irgendwelche anderen Problem. Teste weiter...

Hallo zusammen, hier hat sich ja wieder einiges angesammelt. Ich versuche das ganze mal zusammenzufassen: 1) Mit WIFI 2.0 sind uns nach der Firmwareänderung keine weiteren Probleme mehr bekannt. Damit sollte alles wie gewünscht laufen. 2) Mit WIFI 1.0 kann es Probleme geben. Wir sind da zur Zeit bei. Zur Frage von Reinhard: Die Methode gibt wie beschrieben Informationen zum Zustand des Buffers (Überläufe etc.). Zu der Wifi 1.0 Geschichte melde ich mich noch.

Hallo Reinweb, was erhoffst du dir davon? Wir haben absichtlich alle Programme (Brick Viewer, Logger etc.) auf Getter umgestellt, damit es keine Seiteneffekte zu anderen Nutzerprogrammen gibt (keine Umkonfigurierung der Callbacks, kein Deaktivieren der Callbacks)

Ok, ich halte dann erstmal die Füße still. Melde du dich bitte wenn du mehr weißt.

Hallo Chris, wenn du das mit dem Multimeter testen könntest, wäre gut. Falls nicht könntest du uns den Aufbau zuschicken, dann machen wir ausfinden was das Problem ist.

Hallo Chris, du hast bereits sehr sinnvolle Tests gemacht. Sehr gut! Falls du ein Multimeter o.ä. zur Hand hast, könntest du mal versuchen in der grünen Buchse der Step Down Power Supply die Spannung zu messen. Ich wüsste ehrlich gesagt nicht, dass bei einem Nutzer mal die Step Down Power Supply kaputt gegangen ist. Aber ausschließen kann man es natürlich nicht. Versorgst du sie denn noch? Arbeitet das Netzteil noch? (Nicht das du einfach nichts mehr einspeist) Wenn die Bricks im Stapel noch funktionieren, wenn du per USB versorgst kann mit denen eigentlich wirklich nichts sein. VG, Bastian

Dieser Bug bezieht sich nur auf den Code der WIFI V2. WIFI V1 arbeitet intern komplett anders. Das Problem sollte bei der V1 nicht vorkommen.

Sorry Reinhard, die WIFI Extensions Version 2 und Version 1 nutzen komplett unterschiedliche Software. Der gefundene Bug bezieht sich nur auf Version 2.

Hallo Reinhard, das mit dem response expected gilt für alle unsere Produkte unabhängig von Extensions. Du kannst das auch mit einer WIFI V1 nutzen.

Hi mrpmorris, I guess you mean some kind of sensor fusion. For that our IMU Brick (accelerometer, magnetometer and gyroscope) is often used by our customers. Best regards, Bastian

Ebenfalls eine Neuigkeit von uns dazu. Wir haben eben die WIFI 2.0 Firmware in Version 2.0.3 veröffentlicht. In der Tat gab es noch einen "Bug", der auftreten konnte, wenn mehr Nachrichten aufgetauscht werden sollten, als die WIFI Extension schaffte. Hier der Changelog zur Firmware: Ein-/Ausgangs-Buffergrößen vergrößert Halte TCP Transfers bevor die Buffer überlaufen (Nachrichten werden beim Sender gebuffert) Testet bitte ab jetzt mit der neuen Firmware. Es sieht momentan danach aus, als ober das Masder Programm genau diesen Fehler auslösen konnte. In dem Programm wurden sehr viele Nachrichten zum Stellen von RGB LEDs (LED Strip Bricklet) generiert. Das Reinweb Problem könnte ähnlich sein. Bei WIFI kann die Empfangs/Sendequalität stark schwanken, so dass mal mehr und mal weniger Nachrichten durchgehen. Da der Bug nun hoffentlich gefixt ist sollte es so sein, dass auf Anwendercode-Seite die noch nicht verschickten Nachrichten (Funktiosaufrufe) gespeichert werden und nach und nach verschickt werden. Dadurch stauen sich Nachrichten auf. Das Problem der aufstauenden Nachrichten kann eigentlich nur durch "Set'ter" erzeugt werden, da diese keine Antwort erwarten. Es können also prinzipiell beliebig viele Set'ter pro Sekunde aufgerufen werden, was das System überfordert. Die Nachrichten sammeln sich dann im TCP Buffer. Das Problem lösen kann man durch den "set response expected" Mechanismus, bei dem jeder Setter auch eine Antwort vom System erwartet. Dann bekommt man auch mit (über Timeout), wenn eine Nachricht nicht beim System angekommen ist. Es werden dann aber auch doppelt so viele Nachrichten ausgetauscht (Set-Nachricht hin, Antwort zurück).

Ja, wäre es. Allerdings haben wir Designs bei dem nicht so viel Platz ist (z.B. RED Brick). Wir versuchen Standardbauteile einzusetzen, die wir dann in größerer Stückzahl abnehmen.

Die Drossel ist für den Bestücker nicht ganz einfach anzulöten. Wir vermuten, dass die nicht richtig angelötet war, so dass sie bei unserem Flashen und Testen noch draufsaß, danach aber irgendwann abgeflogen ist. So einen Fall hatten wir schonmal, daher sind wir recht schnell darauf gekommen. Haben die restlichen Master Bricks kontrolliert und konnten zum Glück aber keine weiteren Bricks mit Problemen feststellen. Bei einer Produktion von über 1000 Master Bricks, zwei Fälle mit diesem Problem ist fürchte ich "im Rahmen". Wir werden dennoch zukünftig mehr darauf achten. EXPO meinte dann auch, dass da ggf. die Drossel fehlte. Er hat uns den Brick zugeschickt und ich konnte das hier bestätigen. Damit ggf. (ich hoffe nicht das es auftritt) andere ebenfalls auf dieses Problem hingewiesen werden, haben wir hier die Ursache dokumentiert.

Wir konnten das Problem ausfindig machen. In der USB Datenleitung sitzt unter anderem eine kleine Drossel (auf der Unterseite der Leiterkarte). Wenn diese fehlt, wird der Brick noch per USB mit Strom versorgt (LEDs leuchten etc.) aber er kann mir dem Rechner nicht kommunizieren.

Wichtig ist, dass die Treiber aktuell sind. Direkte Anforderungen an das USB Kabel gibt es nicht. Ein Master Brick alleine sollte eigentlich mit jedem Mini-USB Kabel funktionieren. Bei minderwertigen Kabeln treten Probleme mit höheren Lasten (=Strömen) auf. Wurde schon versucht das Brick neu zu flashen?

Hallo, solange der Brick eine Firmware besitzt und mit Strom versorgt wird sollte die blaue LED neben der USB Buchse leuchten. Die vier LEDs an der Seite machen beim Starten des Master Bricks einmal ein "Lauflicht" und gehen dann aus. Das ist soweit in Ordnung, solange die blaue LED neben der USB Buchse leuchtet. Ggf. ist es ein Treiber Problem bei einer USB 3.0 Schnittstelle? Siehe: http://www.tinkerforge.com/de/doc/FAQ.html#eines-meiner-bricks-wird-im-brick-viewer-nicht-angezeigt