borg

@RSchiessl: Für eine Funkabnahme CE/FCC? Wir machen ja ständig normale Störaus-/Einstrahlungsprüfungen (61000-6-X). Die kosten natürlich keine 25k€. Bei einer Funkabnahme haben wir bisher allerdings immer Angebote in dieser Größenordnung gesehen.

Ich würde sagen das Accelerometer Bricklet ist besser geeignet. Es hat eine höhere Auflösung und eine höhere Datenrate für die Beschleunigungsmessung. Magnetometer und Gyroskop sind auch eher uninteressant zum Messen von Vibrationen.

Beispiel: #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "XYZ" # Change XYZ to the UID of your Industrial Digital In 4 Bricklet from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_industrial_digital_in_4_v2 import BrickletIndustrialDigitalIn4V2 # Callback function for interrupt callback def cb_all_value(changed, value): print("Changed: " + str(changed)) print("Value: " + str(value)) print("") if __name__ == "__main__": ipcon = IPConnection() # Create IP connection idi4 = BrickletIndustrialDigitalIn4V2(UID, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected # Callback every 100ms, value does not have to change idi4.set_all_value_callback_configuration(100, False) # Register interrupt callback to function cb_interrupt idi4.register_callback(idi4.CALLBACK_ALL_VALUE, cb_all_value) raw_input("Press key to exit\n") # Use input() in Python 3 ipcon.disconnect()

Wir hinken leider mit den Beispielen etwas hinterer. Welche Sprache?

So richtig können wir uns das nicht erklären, wir haben viele Jahre gar nichts von Problemen gehört und als die ersten Probleme bei Kunden da waren konnten wir es hier nicht reproduzieren. Kurz danach sind wir dann bereits auf die V2-Version umgestiegen. Eventuell waren in einer Bestückung ein paar der Sensoren nicht in Ordnung o.ä. Schwer zu sagen. Da wir die V1 Version nicht mehr nachproduzieren und nicht mehr auf Lager haben macht es aber aus unserer Sicht keinen Sinn da jetzt noch genauer nachzuforschen. Wir haben in Summe vielleicht 15-20 Stück ausgetauscht, was prozentual von den ganzen verkauften über die Jahre auch keine riesige Menge ist.

Ich befürchte das wird nicht funktionieren. Das Bricklet benötigt eine Eingangsspannung von mindestens 10V, der IR-Empfänger kann aber nur bis 5.5V.

Ich bin mir nicht 100%ig sicher ob ich verstehe was du machen möchtest. Das Industrial Counter Bricklet kann PWM als Eingang bearbeiten, also Periode, Pulsweite, Frequenz eines PWMs bestimmen. Es kann kein PWM erzeugen.

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?