borg

Der Hauptvorteil ist die bessere Usability der Stecker. Das ist in dem Sinne gar nicht festgelegt. Ein neuer Master Brick welcher passende Hardwareeinheiten passende angeschlossen hat könnte durchaus mehrere Bricklets gleichzeitig abfragen. Ein alter Master Brick wird weiterhin round-robin die Bricklets abfragen, allerdings kann das Bricklet in der Zwischenzeit in aller Ruhe Berechnungen machen und z.B. Flanken im MHz-Bereich zählen. Dies ist im alten System einfach nicht möglich. Das ist aber unabhängig vom verwendeten Kabel. Wir hätten gerne eine kleinstmögliche standardisierte Schnittstelle. Das spricht gegen 3 Leitungen die in den meisten Fällen nicht genutzt werden. Rein technisch macht das auch keinen Sinn, da die 3 Leitungen die wegfallen als Bus über alle 4 Brickletanschlüsse gemeinsam genutzt werden (I2C). Das I2C wird aktuell zum auslesen der EEPROMs genutzt, dies brauchen wir mit Co-Prozessor natürlich nicht mehr. Dadurch versprechen wir uns auch eine Steigerung an Stabilität, da ein Brick mit vier angeschlossenen 2m Kabel keinen 8m langen Bus mehr aufbaut! Das ändert technisch gar nichts. Wenn wir bei dem alten Stecker bleiben werden 3 Leitungen einfach für immer ungenutzt bleiben.

Detaillierte Erklärung zur Umfrage: Siehe Blogeintrag Zusammenfassung: Auf Grund einer Änderung in der Funktionsweise von Bricklets haben wir die Möglichkeit auf neue, benutzerfreundlichere Bricklet-Stecker umzusteigen. Dabei sehen wir diese zwei Szenarios: Szenario 1 * Die Stecker bleiben so wie sie sind für alle Module. * Es gibt die normalen 10-Pol zu 10-Pol Bricklet-Kabel für die alte sowie neue Bricklet Generation. Szenario 2 * Die Stecker auf den neuen Co-Prozessor Bricklets sind 7-Pol JST GH. * Es gibt zwei Bricklet-Kabel-Varianten: 10-Pol zu 10-Pol für alte Bricklets und 10-Pol zu 7-Pol für die neue Bricklet Generation. * Nachdem alle Bricklets umgestellt sind (vielleicht in 3 Jahren) können die Stecker auf den Bricks auch auf 7-Pol umgestellt werden. * Danach gibt es dann nur noch 7-Pol zu 7-Pol Bricklet-Kabel. In beiden Szenarien sind die alten Bricklets und die Bricklets der neuen Generation komplett kompatibel zueinander und zu den alten Bricks. Was würdet ihr vorziehen?

A detailed description of the poll can be read in the blog. Summary: Because of changes in the functionality of Bricklets we will be able to change the current connector to a new one that is more user friendly. We see two possible scenarios: Scenario 1 * The connectors remain the same for all of the building blocks. * The normal 10-pole to 10-pole Bricklet cable is compatible to the new and old generation of Bricklets. Scenario 2 * The connector on the new co-processor Bricklets is a 7-pole JST GH. * There are two Bricklet cable variants: 10-pole to 10-pole for the old Bricklets and 10-pole to 7-pole for the new generation of Bricklets. * After all Bricklets are converted (perhaps in 3 years) we will be able to change the connectors of the Bricks to the new 7-pol variant. * After that we only need 7-pole to 7-pole cables for the whole system. In both scenarios the old Bricklets and the Bricklets of the new generation are completely compatible to each other and the old Bricks. What do you prefer?

I already added the API in the Motion Detector source code, will be available with the next Bindings release. https://github.com/Tinkerforge/motion-detector-bricklet/commit/f327f00f01dafd6a01bc4bc704b49e686aea94bb

Rückblick auf 2016 Blogeintrag

Looking back at 2016 Blog Entry

Plugin: RS232 Bricklet 2.0.3 Fix Bug with baudrates below 4800 baud Change RESET beahvior to be compatible with new hardware version Plugin: Motion Detector Bricklet 2.0.1 Add API to turn status LED permantenly on/off Download: RS232 Bricklet, Motion Detector Bricklet

Plugin: RS232 Bricklet 2.0.3 Fix Bug mit Baudraten kleiner als 4800 Baud Ändere RESET-Verhalten um Kompatibilität mit neuer Hardware Version herzustellen Plugin: Motion Detector Bricklet 2.0.1 Füge API zum permanenten an/ausschalten der Status LED hinzu Download: RS232 Bricklet, Motion Detector Bricklet

Alles klar, gucke ich mir dann an wenn sie hier ankommen. Ich bin gespannt!

For the Master Brick there is a disable_wifi2_status_led() as well as a disable_status_led() function. For the Motion Detector Bricklet we currently don't have such an API. I will write in on my TODO list, adding this API is not a huge amount of work. edit: Translated to English, accidentally answered in German .

http://www.tinkerunity.org/forum/index.php/topic,673.msg22745.html#msg22745

Kannst du dir mal die Bricklet Stecker vom Master Brick und von den Bricklets angucken? Ist da vielleicht irgendwo einer der Pinne krumm o.ä und verursacht einen Kurzschluss? Mein Test den ich hier gestartet hatte (mit 4x Temp IR) läuft jetzt seit über einer Woche durch .

mh, passt die UID? Eine falsche UID würde am einfachsten erklären warum es nicht funktioniert. Da du nur einen Setter aufrufst würdest du auch keine Fehlermeldung bekommen.

Mh, wenn du sagst es hat vorher funktioniert und du hast nichts geändert und jetzt funktioniert es nicht mehr muss es ja ein Hardwaredefekt sein. Hast du schonmal geguckt ob es eine Beschädigung am HDMI Stecker o.ä. gibt? Am besten meldest du dich per Email bei info@tinkerforge.com damit wir den RED Brick austauschen können.

1) You can connect the IMU Brick 2.0 directly via USB, no Master Brick needed 2) Perhaps the Raspberry PI 3 does have enough power for your purposes? You could also use the RED Brick, in this case you don't have to use USB. You can just stack the IMU Brick 2.0 onto the RED Brick: http://www.tinkerforge.com/en/doc/Hardware/Bricks/RED_Brick.html If neither of them have enough power you will probably have to use some kind of "normal mini PC mainboard".

Das Analog In 2.0 hat keine interne Kalibrierung. Du kannst es aber natürlich extern kalibrieren (new_value = old_value*1483/1410.0). Falls das nicht gut genug ist: Das Industrial Dual Analog wird bei uns Werkskalibriert und lässt sich auch vom Nutzer nachkalibrieren .

Aktuell läuft mein Test noch. Mal schauen ob es bis Montag durchläuft.

Hab das jetzt heute morgen nachgebaut (mit 2m Kabel usw). Bisher funktioniert noch alles. Was mir gerade bei deinen Screenshots aufgefallen ist: Deine Master Brick Firmware Version ist nicht aktuell, die könntest du einmal aktualisieren. Wobei ich vermute dass das nichts an den Problemen die du hast ändern wird, aber ein Versuch ist es Wert!

Ich glaube das ist dieses Problem: http://www.tinkerunity.org/forum/index.php/topic,3174.msg19663.html Da gibt es eine Lösung in der Mitte des Threads .

Kann ich mir nicht erklären warum es da immernoch Probleme gibt . Ich versuche das nochmal hier zu reproduzieren. Dein Aufbau besteht nur aus 1x Master Brick und 4x Temp IR Bricklet, korrekt? Welche Länge haben die Kabel? Musst du irgendwie in einer bestimmten Frequenz Werte abfragen o.ä. damit das Problem auftritt? Wie lange dauert es bis es auftritt?

It can be powered over USB!

Dieses Wetterstation Beispiel nutzt 4 Bricklets: https://github.com/Tinkerforge/weather-station/blob/master/write_to_lcd/c/weather_station.c Hilft das weiter?

Die lange Geschichte der Entwicklung des Silent Stepper Bricks: http://www.tinkerforge.com/de/blog/2016/12/8/silent-stepper-brick Das gibt vielleicht mal einen Einblick was alles so schief laufen kann und warum es manchmal etwas länger dauert sowas zu entwickeln als man vermuten würde.

Die lange Geschichte des Silent Stepper Brick Blogeintrag

The long story of the Silent Stepper Brick Blog Entry