borg

Oh, that is not good. That could mean that we had a problem during a whole batch. I will pick some Ethernet Extension from our stock at random and read the MAC address. If i find one with MAC address 40:D8:55:02:A0:00 we will probably have to re-configure all of them . Thank you for the hint and sorry for the problems!

Wir haben ein paar Sprachen die wir gerne noch unterstützten würden auf einer Liste, Julia steht da leider relativ weit unten. In der Zwischenzeit könntest du aber die C Bindings nehmen. In Julia kann man direkt C Funktionen aufrufen per ccall: https://docs.julialang.org/en/stable/stdlib/c/#Base.ccall

Oh? Das muss ich definitiv versuchen nachzustellen. Hab mir gerade die Codeänderungen durchgeguckt die es zwischen den Firmware Versionen gab und kann nichts relevantes finden .

You shouldn't need to set the MAC addresses. They should come pre-configured with the MAC address that is on the sticker. We even pay for the addresses to get them properly from IEEE. Do all Ethernet Extensions that you own have the same address or only two that you had? I can only imagine that there was some kind error during our initial testing/flashing setup and we accidentally wrote the same address to two extensions.

Die ersten Silent Stepper Bricks sind soeben bei uns angekommen, wir müssen die jetzt noch fotografieren, testen, Kühlkörper draufkleben und eintüten. Sollte also diese Woche noch was werden .

Thank you for the test code, i will try it out next Tuesday (don't have the time today and there is a holiday tomorrow and next Monday in Germany). From looking at the code, it should definitely work without any delays!

Der Punkt ändert sich je nach Port des Master Bricks? Dann kann es ja kein Wackelkontakt in den Pixeln sein! Was hast du im Brick Viewer genau eingestellt?

Das ist leider nicht möglich. Ein Servo hat 3 Anschschlüsse, davon liegt einer auf Masse, einer auf ~5V und der dritte macht PWM. Den Strom zieht das Servo immer über den 5V-Anschluss. Wenn du die "Geschwindigkeit" des Vibrationsmotor einstellen können möchtest müsstest du den DC Brick nehmen. Wenn der Vibrationsmotor nur an und aus geschaltet werden soll würde auch ein Industrial Quad Relay funktionieren!

Oh, das klingt so als wäre ein Pixel in einem der Bündel defekt. Kannst du zum Testen versuchen an dem letzten Pixel der nicht funktioniert und an dem erste der funktioniert zu wackeln? Hinten an den Kabeln zupfen und zur Seite ziehen und so. Funktioniert es dann zwischendurch? Zum testen könntet ihr das Bricklet auch an das Zweite Bündel anschließen, funktionieren dann die restlichen 200 LEDs wie erwartet?

Did you also install Brick Daemon?

Keine Angst, ich verstehe dich vollkommen. Nur leider du mich nicht :-). Du hast mich noch nicht davon überzeugt das ich ein WLAN-Passwort anders absichern muss als ein Zugriff auf ein Relay. Nochmal zur FritzBox: Ich kann von meinem Handy aus die Webseite der FritzBox aufrufen, dort das Authentifizierungspasswort eingeben und dann das WLAN-Passwort auslesen. Jetzt sagst du: Eine Smartphone App kann Port 4223 öffnen und das WLAN-Passwort einer WIFI Extension auslesen. Dazu sage ich: Dafür gibt es die Authentifizierung. Damit haben wir die gleiche Situation wie bei der FritzBox. Denn wenn ich das Authentifizierungspasswort kenne kann ich eine App schreiben die Port 80 öffnet um die Webseite der FritzBox zu öffnen, sich dort authentifiziert und danach das WLAN-Passwort ausliest. Wenn ich das Authentifizierungspasswort der Extension/FritzBox nicht kenne, kann ich in beiden Fällen das WLAN-Passwort nicht auslesen. Was bleibt ist der Use Case wo ich jemanden Zugriff auf Bricks/Bricklets in einem WLAN-Netz mit einer WIFI Extension geben möchte, aber nicht das WLAN-Passwort.

Authentifizierung aktivieren. Dafür ist die da. Im Zweifeilsfall wäre ein Zugriff auf das Relay welches das Aquarium steuert auch viel schlimmer als der Zugriff auf das WLAN-Passwort. Wenn ich das Authentifizierungspasswort der FritzBox kenne kann eine App auf dem Smartphone auch das WLAN-Passwort der FritzBox auslesen.

Der Grund ist damit ich das Passwort wieder auslesen kann wenn ich es brauche. Aus dem gleichen Grund aus dem ich es auch aus der FritzBox wieder rausbekomme. Wie häufig haben wir folgende Situation¹: Es ist jemand in deinem WLAN (vielleicht über Ethernet), er soll vollen Zugriff auf die Bricks/Bricklets bekommen, er soll aber nicht das Passwort auslesen können. Das ist ein bisschen als hättest du jemanden in deinem Netz der deine FritzBox konfigurieren können soll, aber nicht das Passwort auslesen. ¹: Dein Szenario 1 ist so nicht möglich da die WIFI Extension 2.0 kein EAP unterstützt.

Die Frage ist: Wann darf ich das Passwort setzen? Wenn ich das Passwort nicht auslesen darf, aber es neu setzen kann hab ich ja nichts gewonnen. Wenn ich das Passwort weder per IP noch per USB setzen kann, dann müssen wir die Extension mit einem festen und unveränderlichem PW ausliefern? Oder wie stellst du dir das vor? Als einzige alternative könnte ich mir noch vorstellen das man zum ändern des PWs das alte PW mit übertragen muss. Damit hätte man dann aber die WIFI Extension gebrickt wenn man das PW vergisst... Man könnte als Kompromiss das auslesen/setzen von PWs über WLAN verbieten und nur über USB erlauben.

Im Gegensatz zum fehlendem https im Forum haben wir darüber schon häufiger intern diskutiert. Grundsätzlich kommst du nicht an das Passwort der WIFI Extension wenn du keinen physikalischen Zugriff hast (dazu zählen wir Zugriff per USB) und nicht im gleichen Netz bist. Für den Fall dass eine WIFI Extension in einem ansonsten öffentlichen Netz betrieben werden soll, gibt es Authentifizierung: https://www.tinkerforge.com/de/doc/Hardware/Master_Extensions/WIFI_V2_Extension.html#authentifizierung Das ist IMO soweit OK. Wenn ich im Netz einer FritzBox bin und das Passwort des Webinterfaces kenne (Authentifizierung), kann ich auch das WLAN-Passwort auslesen. Der vergleich passt sogar noch besser zur Webseite der WIFI Extension. Eine berechtigte Frage dazu ist: Sollte die Authentifizierung für die WIFI Extension per Default aktiviert sein?

Da muss ich dir recht geben, es gibt keinen Grund auf tinkerunity kein https zu verwenden. Da hat einfach keiner so richtig drüber nachgedacht das man ja auch ein Passwort hier im Forum setzt . Ich habs mir auf die TODO-Liste geschrieben.

Die günstigste Möglichkeit die ich dafür sehe wäre ein Raspberry Pi an dem die benötigten Bricklets über einen Master Brick angeschlossen sind. RS485 zur Kommunikation mit anderen Sensoren gibt es bald als Bricklet. Das RPi kommt mit WLAN, könnte Problemlos die ganze Logik ausführen (REST-API, etc) und auch eine vernünftige verschlüsselte Verbindung für die OTA updates aufmachen. Für einen Prototyp und kleinere Stückzahlen ist das so definitiv geeignet und es lässt sich auch schon die ganze Logik usw ausprogrammieren. Wenn es dann später in größeren Stückzahlen verkauft werden soll würde sich in diesem Fall sicherlich ein "Custom-RPi-Hat" anbieten welcher exakt die Sensoren hat die ihr benötigt. Edit: Falls ein RPi zu groß ist könnte man auch einen RED Brick mit USB-WLAN-Stick nehmen.

There is probably a slightly changed magnetic field in the plane during flight (because of the motors and such). See here: https://www.tinkerforge.com/de/doc/Software/Brickv.html#brick-firmware-flashing It is currently in production!

Dann bin ich ratlos. Bitte einmal bei info@tinkerforge.com mit der Bestellnummerund einer Adresse melden, wir schicken einen neue Master Brick und eine neues IMU Brick 2.0 raus. Ich würde dann einfach das Paar rausschicken mit dem ich hier die ganze Zeit teste, welches definitiv funktioniert . Entschuldigung für die Probleme!

Du brauchst immer RS485+ & RS485-. Wenn beide Seiten ein unterschiedliches Massepotential haben kann es sein dass du auch Ground benötigst.

Also der Aufbau ist: Master Brick unten, IMU Brick 2.0 oben und der Master Brick ist per USB angeschlossen? Sind an dem Master oder der IMU noch irgendwelche Bricklets angeschlossen? Ich kann diese Probleme nicht reproduzieren. Welche Firmware Versionen haben der Master Brick/IMU Brick 2.0?

Such mal nach SHR-04V-S-B

Es gibt eine neue Firmware fürs IMU Brick 2.0 sowie fürs Accelerometer. Bitte einmal ausprobieren (beides aktualisieren)! Die Probleme von tomha sollten damit gefixt sein, die konnte ich reproduzieren. @RonHa: Welche IMU Brick Firmware Version verwendet ihr? Das Problem kann ich nämlich nicht reproduzieren (weder mit 2.0.7 noch mit 2.0.6)

Firmware: IMU Brick 2.0 2.0.7 Move I2C mutex handling outside of interrupt.This fixes a race condition with the Accelerometer Bricklet (and potentially other Bricklets that use I2C). Download: IMU Brick 2.0 Plugin: Accelerometer Bricklet 2.0.3 Use I2C mutex to properly share Accelerometer Polling-I2C with IMU V2 DMA-I2C. Download: Accelerometer Bricklet

Firmware: IMU Brick 2.0 2.0.7 I2C Mutex wird jetzt außerhalb des Interrupts gehandhabt, andernfalls kann es eine Race-Condition im Zusammenhang mit anderen Bricklets die I2C nutzen geben. Download: IMU Brick 2.0 Plugin: Accelerometer Bricklet 2.0.3 Nutze Mutex für I2C damit das Polling-I2C des Bricklets mit dem DMA-I2C im IMU Brick korrekt zusammenarbeitet. Download: Accelerometer Bricklet