borg

Laut Fehlermeldung ist das "ipdb"-Paket auf deinem Rechner nicht installiert.

I don't know the image acquisition toolbox, but what format does it expect? The order of operation probably needs to be: * Capture image in Tinkerforge format (16-bit array) * Convert Tinkerforge format to Toolbox format (XXX array? Some kind of object?) * Use Toolbox with converted data

Oh, in der Tat. Da gab es einen Copy+Paste-Fehler in der Firmware. Ist jetzt in 2.0.1 gefixt: https://github.com/Tinkerforge/sound-pressure-level-bricklet/commit/1bef9471aa17ab0ae3b5a6e2543eb49250ab27e4

Die offizielle Herstellerangabe für den Sensor ist -40°C bis +80°C. Das hängt aber natürlich immer davon ab wo und wie der Sensor verbaut ist etc. In einem Gehäuse kann es z.B. wärmer sein als die Umgebungstemperatur. Wir gehen aber davon aus das unser System bei normalen europäischen Außentemperaturen immer laufen sollte .

Es gibt dazu interessanterweise keine Angabe in der offiziellen Spezifikation, hab es beim Hersteller angefragt. Melde mich wenn ich eine Antwort bekomme.

@insidERR: Wenn du diese Probleme auch hast melde dich bei info@tinkerforge.com mit der Bestellnummer der Temperature IR Bricklets (1.0), wir tauschen die dann aus durch neue 2.0er

Hab das gerade ausprobiert und ich kann keine Probleme feststellen. Schreib bitte eine Email an info@tinkerforge.com mit den Bestelldaten der Ethernet Extension, wir würden die alte V1.0 Ethernet Extension gegen eine neue V1.1 austauschen. Die alte V1.0 hatte bei ein paar Kunden Stabilitätsprobleme, das war der Grund warum wir bei der V1.1 den IC nochmal gewechselt haben. Es klingt so als hättest du jetzt diese Probleme. Warum die erst mit dem neuen Image auftreten kann ich mir nicht erklären.

Die Lebensdauer der Diode ist vom Hersteller mit 8000 Stunden angegeben. Das ist bei durchgängigem Betrieb ca. 1 Jahr. Man muss also nicht absolut penibel drauf achten, es ist nicht so das nach einer Woche sofort die Diode defekt ist o.ä.. Ich füge die 8000 Stunden Lebensdauer noch in die Spezifikation ein (wir sind gerade noch dabei letzte Feinheiten fertig zu machen, wir Veröffentlichen die neuen Bricklets aber denke ich heute noch offiziell). In der API kann man die Diode per "SetEnable" ein/ausstellen.

Grundsätzlich sollte es denke ich möglich sein brickd für Android mit dem NDK zu portieren (in der bestehenden Codebasis, ohne ein neues Projekt anzufangen). Die einzige wichtige Abhängigkeit die wir haben ist libusb und die scheint man mit dem NDK auch zum laufen zu bekommen: https://github.com/libusb/libusb/tree/master/android Wir sind natürlich für Patches/Pull Requests offen, auch Erfahrungswerte welche Schwierigkeiten etc es bei einem Portierungsversuch gab wären bereits hilfreich. Die Idee brickd für Android zu portieren hatten wir natürlich auch bereits, steht bei uns allerdings nicht hoch auf der Prioritätenliste. Edit: Als Bachelorarbeit o.ä. könnte ich mir das auch gut vorstellen. Edit2: Unser Protokoll ist hier definiert: https://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html

Danke, ist alles gefixt .

Danke für den Hinweis, ist gefixt .

Unfortunately we never had a compatible flat flex cable made since the demand for it was too low.

Gibt es da noch mehr Fehlermeldungen? Irgendwas woraus hervorgeht warum die Zertifikatsverifizierung fehlschlägt?

So you want to go in the direction of a position and get a callback if you have reached the position but not stop at the position, right? With the current API you could drive forward/backward and either poll "get_current_position" or use the "all_data"-callback. I don't see any easier way.

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 .