borg

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

Oh . Das muss ich mir angucken, eine Erklärung hab ich da direkt erstmal nicht für. Das Changelog sagt: Da das Accelerometer Bricklet auch I2C nutzt könnte es da durchaus einen Zusammenhang geben!

Die Möglichkeit gibt es leider nicht. Die Rohwerte der drei Sensoren (Beschleunigungsensor, Magnetometer, Gyroskop) können aber ausgelesen werden, ihr könntet also versuchen die Daten selbst zu verarbeiten.

If you go to the FreeIMU library, click on the download link und open the file libraries/FreeIMU/FreeIMU.cpp, you can find the code in line 570ff.

Schwer zu sagen, wenn der IMU Brick außerhalb des Fahrzeugs gut funktioniert vermute ich das wechselnde Magnetfelder im Auto dem Algorithmus zu schaffen machen. Seit der neuesten Firmware Version gibt es die Möglichkeit per set_sensor_fusion_mode() eine Fusion-Modus ohne Mangnetometer zu benutzen, vielleicht ist das ein Versuch Wert? Dabei geht natürlich die Bestellung der absoluten Orientierung verloren.

Der RED Brick hat funktioniert und dann hast du ein neues Image auf die SD-Karte geschrieben und jetzt funktioniert er nicht mehr? Oder hat der RED Brick vorher auch nicht funktioniert?

I wrote the Python code, but as it says in the code, the actual filter algorithm comes from here: http://www.varesano.net/blog/fabio/complementary-filtering-high-res-barometer-and-accelerometer-reliable-altitude-estimation

Currently we unfortunately don't have any Brick/Bricklet that can read a 5kHz PWM. You could perhaps use the RS232 Bricklet to communicate with the STM32 (through uart)?

Strange! I can't immediately figure out why this happens. I will take a look at this on Monday.

Hard to say, since it failed at random times during the flashing it seems to be something indeterministic. Perhaps the voltage of the RPi USB port was not high enough because of too much power draw by other USB devices?

Schwer zu sagen, einen Softwarefehler können wir denke ich ausschließen. Das Fehlerbild klingt nach einem krummen Pin der einen Kurzschluss verursacht, das kannst du ja nochmal überprüfen. Ansonsten schicke den defekten Master Brick ein, wir gucken uns dann an was er für schmerzen hat und tauschen ihn aus.

Die Firmware Version sollte völlig egal sein, ich bin nur darauf gekommen weil du geschrieben hast das es nach dem Update nicht mehr funktionierte. Oder hatte der Brick vorher auch schon nicht funktioniert?

Kannst du nachgucken ob vielleicht im Bricklet-Stecker des Mater Brick 2.0 ein Pinn krumm ist und Kurzschlüsse verursacht wenn du ein Bricklet einsteckst? Bricklets sind übrigens nicht hotplug-fähig. Edit: Oh, ich sehe gerade du hast geschrieben die Pinne sind OK. Dann hab ich keine Idee dazu . Ich probiere morgen einen Master Brick 2.0 aus, kann mir aber nicht vorstellen warum es da generelle Probleme geben sollte. Edit 2: Funktioniert der Master Brick 2.0 denn wenn du eine ältere Mater Brick Firmware nutzt?

Hinweis: Master Brick Firmware 2.4.3 zusammen mit WIFI Extension Firmware 2.1.2 hat erheblich bessere Performance bei einer Verbindung mit Windows PCs (wir unterstützen jetzt delayed ACKs) und einige Bug fixes. Wir empfehlen ein Update! Firmware: Master Brick 2.4.3 Fix bug in double buffer rx peak Increase reaction time by decreasing ACK timeout Increase general WIFI send timeout (through bricklib) Add timeout count API (through bricklib) Download: Master Brick Firmware: WIFI Extension 2.0 2.1.2 Send new packets even if others are not yet acked to support Windows delayed ACK properly Fix bug in route match removal Increase routing table size from 10 to 16 to allow more packets at once Decrease ACK timeout significantly, Master Brick 2.4.2 handles messages with new rx peak functionality Don't resend data if rx buffer is full, in this case the ACK is likely already in the buffer Fix broken length check Download: WIFI Extension 2.0

Note: Master Brick Firmware 2.4.3 together with WIFI Extension Firmware 2.1.2 has significantly better performance in combination with Windows PCs (we support delayed ACKs properly now) and several bug fixes. We recommend that you update! Firmware: Master Brick 2.4.3 Fix bug in double buffer rx peak Increase reaction time by decreasing ACK timeout Increase general WIFI send timeout (through bricklib) Add timeout count API (through bricklib) Download: Master Brick Firmware: WIFI Extension 2.0 2.1.2 Send new packets even if others are not yet acked to support Windows delayed ACK properly Fix bug in route match removal Increase routing table size from 10 to 16 to allow more packets at once Decrease ACK timeout significantly, Master Brick 2.4.2 handles messages with new rx peak functionality Don't resend data if rx buffer is full, in this case the ACK is likely already in the buffer Fix broken length check Download: WIFI Extension 2.0