borg

Tinkerforge and GDPR Blogeintrag

Tinkerforge und DSGVO Blogeintrag

The BNO055 uses an automatic continuous calibration. The chip tells us when it thinks it is currently calibrated well. Then all of the calibration parameters turn green (in Brick Viewer) and you can press the "save calibration" button. The current calibration is then saved and will be used on next startup as a starting point for the automatic continuous calibration. If you leave the IMU running for a while (if possible move it around a lot during the time), does the orientation then change or is it still 45° off? For the exact specifications and description of the calibration you can take a look at the datasheet: https://github.com/Tinkerforge/imu-v2-brick/raw/master/datasheets/BNO055.pdf See 3.10 for the automatic calibration description.

I think it should show ~0/360° if in your image the USB connector goes to the bottom (or maybe to the top? Not 100% sure). I would expect that there will still be a discrepancy of a few degrees between the phone and the Brick. The earth magnetic field is quite weak and there are lots of small magnetic fields generated in the phone as well as the Brick. Do you have a real compass for comparison?

Ich könnte mir gut vorstellen das wir ein RPi Hat direkt mit auf das letzte Umstellungs-Panel machen .

Das Bricklet soll auf Dauer das LCD20x4 ersetzen und es hat eine vergleichbare Größe. Es gibt auch eine äquivalente API die Text drauf schreibt wie beim LCD20x4, wenn man es wirklich als Ersatz nutzen möchte. Die Buttons unter dem Display werden in der Tat durch Touch-Funktionalität ersetzt (inklusive API zum erkennen von Standard-Wisch-Gesten). Das neue Bricklet kommt auf das nächste Panel welches wir in ca. 2-3 Wochen bestellen. So eine Produktion dauert dann Erfahrungsgemäßig ca. 3 Monate. Nach diesem Panel ist dann übrigen nur noch ein weiteres Panel offen und wir haben alle Bricklets auf Co-Prozessoren umgestellt .

Hab gerade kurz in den Code geschaut, da gibt es einen ganz offensichtlichen Bug, fixe ich im Laufe der Woche. Dort wird aber nur der Rückgabewert von der GetMovingAverage-Funktion verfälscht, intern ist alles korrekt und die Werte werden auch korrekt genutzt und Berechnet.

Wir haben das Problem gefunden. Die neuere uboot Version welche wir seit 1.10 nutzen hat ein kurzes Fenster wo auf Eingaben gewartet wird. Mit aufgesteckter RS485 Extension hat der uboot RX Pin (welcher gleichzeitig der RS485 RX Pin ist) eine Längere Antenne und es ist wahrscheinlicher das der Wert zufällig hin und her springt während des bootens. So gibt es aus Sicht von uboot Tastatureingaben und der Bootprozess bleibt hängen. Wir fixen das mit dem 1.12 Relase, welches in ca. 2 Wochen zusammen mit einem Schub neuer Bricklets kommen wird. Danke für den Hinweis und die Hilfe!

Ich konnte das Problem reproduzieren mit 1.11 (das Problem tritt soweit ich das sehen kann mit 1.9 noch nicht auf). Es sieht also so aus als würde es mit der neuen Kernel Version zusammenhängen. Zwischen 1.9 und 1.11 haben wir den Kernel von 3.10 auf 4.13 aktualisiert. Könnte noch ein bisschen dauern bis wir das gefixt bekommen. Der Kernel bleibt irgendwo recht früh während des Boot-Prozesses hängen, sowas ist natürlich immer anstrengend zu debuggen.

If your preferred language is C/C++ you can use it, no problem. You could for example use libcurl to send a POST request.

Ist geplant. Wir bekommen mittlerweile einen quad/octa-core in vergleichbarer Größe zum A10s (14x14mm). Allerdings hat die Stromversorgung von den neueren Chips leider einen riesigen Platzbedarf. Da sind wir noch tüfteln wie wir so ein Design auf 4x4cm bekommen können .

Firmware: Distance IR 2.0.3 Bug in Distanzberechnung gefixt (Interpolation zwischen Lookup-Table-Werten war fehlerhaft) Download: Distance IR Firmware: Dust Detector 2.0.1 Bug in Moving-Average-Setter gefixt Download: Dust Detector

Firmware: Distance IR 2.0.3 Fix bug in distance calculation (interpolation between lookup table values was broken) Download: Distance IR Firmware: Dust Detector 2.0.1 Fix bug in moving average setter Download: Dust Detector

Ich hab es mir auf die TODO-Liste geschrieben, gucke ich mir an. Komme ich aber frühestens Anfang nächster Woche zu.

Komisch. Mir ist nicht klar was ein Neustart von einem "Powercycle" unterscheidet . Das Problem tritt nur bei einem Neustart auf. Bei einem ersten Start funktioniert es, richtig?

Die Image Version 1.1 ist sehr alt, könntest du einmal auf die neuste 1.11 aktualisieren? http://download.tinkerforge.com/red_images/full/

In ca. 2 Wochen kommt ein Schub neuer Bricklets. Da gibt es dann wieder ein neues Bindings Release.

Firmwares: DC Brick 2.3.7, IMU Brick 2.3.7, IMU 2.0 Brick 2.0.12, Master Brick 2.4.8, Servo Brick 2.3.7, Silent Stepper Brick 2.0.6, Stepper Brick 2.3.8 Potentiellen Deadlock zwischen USB-Stack und Co-MCU-Enumerierung behoben (konnte passeren wenn ein Stapel an einem ausgeschalteten PC angeschlossen wurde und PC danach gestartet wurde). [nur IMU 2.0] Support für Kalibrierung mit SAM4 Prozessor hinzugefügt. [nur IMU 2.0] Computation tick return-bug behoben. Behebt falsche periode bei Callbacks. Download: DC Brick, IMU Brick, IMU 2.0 Brick, Master Brick, Servo Brick, Silent Stepper Brick, Stepper Brick

Firmwares: DC Brick 2.3.7, IMU Brick 2.3.7, IMU 2.0 Brick 2.0.12, Master Brick 2.4.8, Servo Brick 2.3.7, Silent Stepper Brick 2.0.6, Stepper Brick 2.3.8 Fix potential deadlock between USB stack and comcu enumeration (can happen if stack is connected to turned off PC and PC is turned on afterwards). [iMU 2.0 only] Add calibration support for SAM4 processors. [iMU 2.0 only] Fix computation tick return-bug. Fixes erroneous callback periods. Download: DC Brick, IMU Brick, IMU 2.0 Brick, Master Brick, Servo Brick, Silent Stepper Brick, Stepper Brick

Yes, i know. Have the calibration fixed in git already! I will make a new firmware release today. Edit: New firmware (2.0.12) is released now!

We now have an account at Instagram: https://www.instagram.com/tinkerforge/

Wir haben jetzt ein Nutzerkonto bei Instagram: https://www.instagram.com/tinkerforge/

One Stepper Brick can only control one stepper motor.

You have to build a stack out of Master Brick + Stepper Brick + Ethernet Extension to get a Stepper Brick that you can control via Ethernet.

I tested it and to my surprise i could reproduce your problems! While introducing proper I2C DMA handling we added a bug to the IMU Brick V2 that resulted in some crazy randomness in the period calculation for the callbacks (and also the I2C communication period with the BNO055 was a bit broken). Can you try the attached firmware? You should now get the callbacks in exact 10ms intervals. Thank you very much for your help with debugging this. imu-v2-2.0.12-beta1.bin