borg

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

Do you have the IMU Brick V2 directly connected to a PC via USB or is it in a stack? Do you have any additional Bricklets connected? If the fusion algorithm is enabled you should be able to reach a 100Hz update rate. Here is screenshot from the BNO055 datasheet: If you turn the fusion algorithm off (see set_sensor_fusion_mode) the frequency goes up, you can then configure it with the set_sensor_configuration function.

Firmware: Thermal Imaging 2.0.1 Bricklet now uses "low gain" in "high range" mode. Otherwise the full 400°C range can't be reached. Download: Thermal Imaging

Firmware: Thermal Imaging 2.0.1 Bricklet nutzt jetzt automatisch "low gain" im "high range"-Modus. Ansonsten kann der volle 400°C Bereich nicht erreicht werden. Download: Thermal Imaging

Wenn du das Programm auf dem PC ausführst kannst du es mit Spyder debuggen. Es läuft dann auf dem PC wie jedes andere Programm auch.