borg

Das HAT bekommt den gleichen Prozessor der auch auf den neuen Bricklets ist. Dieser Prozessor hat RTC-Funktionlität, was wir da zusätzlich brauchen ist nur ein Uhrenquarz. Die Synchronisation der Zeit mit dem RPi übernimmt der Brick Daemon, so ist zumindest im Moment der Plan. Die LiPos werden über den Standard 3-Pin Stecker angeschlossen (für LiPos mit Temperatursensor). Damit kann der Ladestrom entsprechend der Temperatur geregelt werden, alles andere wäre uns zu riskant. Das HAT taucht ganz normal als Bricklet auf und hat Funktionen um die angeschlossenen Bricklets abzuschalten sowie das RPi schlafen zu schicken. D.h. ein Programm auf dem RPi kann dem HAT sagen: "Schalte mich in 2 Minuten für eine Stunde ab". In der Zeit ist dann alles aus und es wird nur minimal Strom gezogen. Die Ladeschaltung/externe Einspeisung bietet USV-Funktionalität. D.h ich kann den Akku anschließen und eine externe Stromversorgung die den Akku lädt. Wenn ich die Stromversorgung entferne übernimmt der Akku die Versorgung (des Gesamtsystems). Wenn die Stromversorgung wieder anschließe wird der Akku wieder geladen. Die API des HATs wird detaillierte Informationen zum Ladezustand/Ladestrom/Lebenszeit des Akkus liefern können. So ist aktuell der Plan, bitte nicht vergessen das wir hier gerade vom ersten Prototypen reden, womöglich lässt sich davon etwas nicht umsetzen oder es ist zu teuer o.ä.

The error message above comes from the IMU Brick 1.0 bindings. You can see it from the names and also because of the "f f f f", since the 1.0 IMU returned floats while the new one returns ints. Please download the example again from here https://www.tinkerforge.com/en/doc/Software/Bricks/IMUV2_Brick_Python.html#simple and try it again.

But it says "BrickIMU.FUNCTION_GET_QUATERNION" in your pasted error message. It should be "BrickIMUV2". Are you sure you are not using the IMU 1.0 example?

Das HAT wird im Brick Viewer auftauchen. Das wird auch einige Funktionen haben. Das RPi bleibt allerdings wie ein PC, der taucht entsprechend nicht im Brick Viewer auf.

@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.