borg

Da haben wir leider keine Kontrolle drüber, das WIFI Modul welches wir auf der Extension nutzen unterstützt anscheinend nur MSCHAPv1 .

Seite 31 unten: https://github.com/Tinkerforge/silent-stepper-brick/raw/master/datasheets/TMC2100_datasheet.pdf Das sind die einstellbaren Modi.

Kurzer Hinweis: Wir haben gerade während der "Endkontrolle" noch Hardwarebugs auf dem Silent Stepper Brick Prototyp gefunden, kurz bevor er in Produktion gehen sollte. D.h. wir benötigen dort leider noch einen Prototypen wodurch sich das ganze noch ein bisschen nach hinten verschieben wird .

Firmware: IMU 2.0 Brick 2.0.3 Use DMA for I2C communication with BNO055. This allows for better SPI stack communication throughput, since we don't have to disable the interrupts for the whole communication. Download: IMU Brick

Firmware: IMU 2.0 Brick 2.0.3 Nutze DMA für I2C-Kommunikation mit BNO055 Dies erlaubt höheren Durchsatz für SPI-Stapel-Kommunikation, da Interrupts nicht für die komplette Kommunikation ausgeschaltet werden müssen. Download: IMU Brick

Der MCP3911 (welchen wir als AD-Wandler auf dem Bricklet nutzen) hat ein so starkes rauschen auf den Daten, da sind die ersten ~4-5 Bits schlicht nicht nutzbar. Um dieses rauschen zu eliminieren bräuchte das Bricklet ein richtiges Analog Frontend, die Bauteile dafür würden den Preisrahmen für ein Bricklet deutlich sprengen. Zum Vergleich: Die Performance des Dual Analog In Bricklet entspricht einem "35000 Count Multimeter". Das ist schon richtig high-end, z.B. hier mit vergleichbar: https://www.conrad.de/de/hand-multimeter-digital-keysight-technologies-u1273a-datenlogger-oled-display-cat-iii-1000-v-cat-iv-600-v-anzeige-counts-30000-128113.html Der große Unterschied ist natürlich, dass das Multimeter neben dem +-30V Bereich auch einen +-30mV Bereich hat, wo dann auf einmal eine Auflösung im µV Bereich möglich ist.

Zwei Ethernet Extension auf dem RED Brick gleichzeitig werden aktuell leider nicht unterstützt .

So it seems the MAX31865 for some reason doesn't change its state anymore after a while? I would say we ship you a new PTC Bricklet, but you have this exact problem with two PTC Bricklets, right?

Plugin: Thermocouple Bricklet 2.0.1 Signed 19 bit to signed 32 Bit conversion fixed (In 2.0.0 positive temperatures that have bit 15 set are shown negative) Download: Thermocouple Bricklet Please note: Because of a bug in Brick Viewer this firmware has to be updated by and, you can not use the "Auto-Update-Function". This will be fixed in the next version of Brick Viewer.

Plugin: Thermocouple Bricklet 2.0.1 Signed 19 Bit nach Signed 32 Bit Konvertierung gefixt (In 2.0.0 werden positive Temperaturen welche Bit 15 gesetzt haben als negativ angezeigt) Download: Thermocouple Bricklet Hinweis: Aufgrund eines Bugs in Brick Viewer muss diese Firmware händisch aktualisiert werden, eine Aktualisierung über die "Auto-Update-Funkion" ist leider nicht möglich. Dies wird in der nächsten Brick Viewer Version behoben.

In der Tat. tinkerforge.com bekommt in nächster Zeit ein Update um es besser von Smartphones/Tablets aus bedienbar zu machen. In dem Zuge stellen wir auch auf "https everywhere" um auf tf.com. Danach können wir dann mal gucken ob wir tinkerunity.org nicht auch mal aktualisieren sollten , vielleicht auch das Design entsprechend anpassen.

Tinkerforge auf Messen 2016 Blogeintrag

Tinkerforge at Trade Fairs in 2016 Blog Entry

Indeed, that looks different. Does the flat value recover after a while or do you definitely have to reset? I just looked through the code, if "is_sensor_connected()" returns true during the flat time, it means that the MAX31865 IC that we use on the PTC Bricklet does return the same resistance for the whole time. If you reset the Master Brick, the MAX31865 will be reinitialized. But during initialization we only configure the default values again. For testing, could you try to call "set_noise_rejection_filter" (it does not matter if you turn it on or off). Internally this will also set the whole configuration again. Does this also fix the problem? If it does fix the problem, we may have to set the configuration periodically in the firmware? Sounds strange, but i currently have no other idea .

Good to know that it works now. As long as the resistance from the PTC sensor is in a "possible range" it can't tell that it isn't connected correctly. I think that was probably the problem here .

Die 10 Kontakte an dem Bricklet Port müssen definitiv gelötet werden, nur mit kleben funktioniert das nicht . Am besten du schickst den Master Brick (inklusive abgerissener Buchse) ein, dann gucken wir uns das an ob da eventuell etwas nicht korrekt angelötet war und tauschen den Master Brick entsprechend aus.

Huch? Das ist komisch, ich kann mir gar nicht erklären wie das überhaupt passieren kann. Gucke ich mir an, wird auf jeden Fall gefixt . Edit: Der Fehler ist in der Tat im Brick Viewer, ein einfacher Copy/Paste-Fehler natürlich . Das wird in der nächsten Version gefixt.

Update of Ethernet Extensions, new Accessories Blog Entry

Update der Ethernet Extensions, neues Zubehör Blogeintrag

Uhm, das ist noch bei uns in der Forschungsabteilung, da haben wir noch keine genaueren Informationen zu .

Uh, that is indeed a little misleading. What we mean is that the API returns mV, but the resolution is 10mV. Which does not mean that it has a absolute precision of +-10mV. Nevertheless, by increasing the averaging you can increase the resolution and precision (although we do always round to full 10mV in the firmware).

Wird noch ca. einen Monat dauern, kommt aber .

Um dein Problem nochmal zusammenzufassen: Wenn du einen "Schreibtischtestaufbau" hast geht alles und sobald du es verbaust kommen die Fehler. Richtig? Wie genau verbaust du es? Ist die Kabellänge im verbauten Zustand anders? Das sollte irrelevant sein.

Das ist komisch, ich versuche das mal hier nachzustellen. Kannst du zum testen die Periode runterdrehen? Also z.B. auf 250Hz (alle 4ms)? Tritt das Problem dann nicht mehr auf?

Sweet!