borg

Die API wird für den Nutzer gleich bleiben. Da wir die API jetzt einmal für alle Bricklets anfassen, haben wir natürlich die Möglichkeit Verbesserungen durchzuführen und Fehler auszumerzen. Das neue GPS Bricklet bietet z.B. API um an die Position aller Satelliten zu kommen die das GPS Modul gesehen hat und einen Callback für den 1Hz Takt der bei GPS generiert wird. Des weiteren kann es GPS sowie Galileo und du kommst auch an die Satelliten- und Positionsdaten für die Galileo Satelliten. Kann ich mir nicht vorstellen, wenn das die Sorge der Anwender wird, brauchen sie erst gar nicht mit der Programmierung anfangen. U.U. wird es zu Versehen bei der Bestellung kommen, wenn das aber idiotensicher im Shop auswählbar ist, dann kein Problem. Sehe ich Mittlerweile auch so, hat bei uns intern aber zu soviel Diskussion geführt das wir uns dazu entschieden haben einfach die Kunden zu fragen . Bisher ist die Umfrage ja auch ziemlich eindeutig.

Um eine große Auswahl an Sensoren etc nutzen zu können benötigen wir 3.3V, 5V und GND. Dazu haben wir im neuen Standard 4 Leitungen für die Kommunikation. Diese 4 Leitungen sind notwendig um weiterhin 1000 Nachrichten pro Sekunde bei einer maximalen Nachrichtengröße von 64 byte mit vier angeschlossenen Bricklets zu unterstützen. Rein technisch haben wir uns da bereits sehr viele Gedanken gemacht. Ein I2C Bus hätte auch den riesigen Nachteil das wir wieder einen 8m langen Bus bekommen wenn jemand 4x2m Bricklet Kabel verwendet. Angenommen wir wollten über I2C auch den oben angesprochenen Durchsatz erreichen, wären wir weit weg von 400kHz standard I2C. Des weiteren wäre das ein großes Problem bezüglich EMV. CE-Kompatibilität ist bei uns notwendig.

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.