yvo

Salut MatzeTF Jetzt hoffe ich, dass ich Deine Frage richtig verstanden und umgesetzt habe. Skizze angehängt. Bricklet nur via 7Pin-Kabel am Master angeschlossen. Messung Spannung wenn nur via MasterBrick angeschlossen: 0V zwischen rot markiertem Pin und GND beim Anschluss Brick. Spannung von 24V am PowerSupply angelegt. 0V zwischen rot markiertem Pin und GND beim Anschluss Brick. 24V zwischen rot markiertem Pin und GND des PowerSupplys Bei beiden Schaltzuständen von Channel 0. Entspricht der Eingangsspannung am PowerSupply. War dies wie von Dir gewünscht gemessen? Mit den besten Grüssen, Yvo

Salut MatzeTF Ich habe die verschiedenen Messungen gemacht: blau-gelb: In allen Zuständen eine Spannung von 3,3 V blau-grün: Bei Channel 0 auf GND -> 3.3V Bei Channel 0 auf VCC -> 2.2V Das sieht soweit sehr gut aus. Bei den Messungen der Widerstände muss ich Dir das angehängte Bild zukommen lassen. Da fehlt mir die Kenntnis dies zu interpretieren. Die Verbindung orange-rot gibt aber definitiv 0 Ohm. Hilft Dir das weiter? Mit den besten Grüssen, Yvo

Salut MatzeTF Vielen Dank für die schnelle Rückmeldung. Als Elektronik-Neuling habe ich versucht den Schaltplan und Deine Beschreibung zu interpretieren und am eingezeichneten Pin gemessen. An diesem Pin (wie auch an allen anderen) habe ich unabhängig von der VCC oder GND-Einstellung jeweils die Spannung vom PowerSupply gemessen. Komische Sache. Was meinst Du? Mit den besten Grüssen, Yvo

Hallo Liste Auf zwei Industrial Digital Out 2 (Version 2.0) Bricklets befinden sich die 4 Ausgänge immer im Zustand High. Auch wenn im brickv alle Ausgänge auf GND gesetzt sind. Wenn ich im Zustand GND im brickv die Spannung an einem Ausgang messe (zum Beispiel Channel 0 gemessen auf GND), messe ich die gleiche Spannung wie am PowerSupply (zum Beispiel 10V). Dies konsequent an allen 4 Ausgängen. Das Umschalten von VCC auf GND über Set Low und Set High macht keinen Unterschied. Nach meinem Verständnis, müsste ich bei GND eine Spannung von 0Volt messen und bei VCC eine Spannung welche identisch mit dem PowerSupply ist, oder? Frage: Habe ich in irgendeiner Art die beiden Industrial Digital Out 2 zerschossen? Oder mache, respektive überlege ich was falsch? Freue mich auf jeden Hinweis. Mit den besten Grüssen, Yvo

@Backdraft007 Ich habe mich ausführlich mit der von Dir angegebenen Webseite befasst. Und konnte zum Glück was herleiten, das für mich tauglich ist. Und ich habe noch das Glück, dass ich das Bricklet doch um 90 Grad drehen kann und die X-Achse nach "vorne" guckt. So kann ich mit dieser Achse anstelle der Y-Achse arbeiten. Die restliche Mathe um die Quaternionen musst ich leider aufgeben. Die Funktionen für die Berechnung der Rotation um die X-Achse im gewünschten Bereich von ]0, 2Pi[ sehen jetzt so aus: def normQ(q): ''' Calculates the normalized Quaternion a is the real part b, c, d are the complex elements ''' # Source: Buchholz, J. J. (2013). Vorlesungsmanuskript Regelungstechnik und Flugregler. # GRIN Verlag. Retrieved from http://www.grin.com/de/e-book/82818/regelungstechnik-und-flugregler # https://www.cbcity.de/tutorial-rotationsmatrix-und-quaternion-einfach-erklaert-in-din70000-zyx-konvention a, b, c, d = q # Absolute value used for the normalization. Z = np.sqrt(math.pow(a, 2) + math.pow(b, 2) + math.pow(c, 2) + math.pow(d, 2)) return np.array([a / Z, b / Z, c / Z, d / Z]) def Q2Eul(q): ''' Calculates the Euler Angles from Quaternion a is the real part b, c, d are the complex elements ''' # Source: Buchholz, J. J. (2013). Vorlesungsmanuskript Regelungstechnik und Flugregler. # GRIN Verlag. Retrieved from http://www.grin.com/de/e-book/82818/regelungstechnik-und-flugregler # https://www.cbcity.de/tutorial-rotationsmatrix-und-quaternion-einfach-erklaert-in-din70000-zyx-konvention ''' Getting the quaternion normalized. Remarks: * In case of Tinkerforge-IMU, the values given by the sensor have to be divided by 16383 (14 bit). * After the division, the values are already within the range ]-1, +1[. * Principally, no normalization requested. * To have a generic, function, the normalization of the quaternion is done in any case. ''' q = normQ(q) a, b, c, d = q z = np.arctan2(2.0 * (b * c + a * d), (math.pow(a, 2) + math.pow(b, 2) - math.pow(c, 2) - math.pow(d, 2))) y = np.arcsin(2.0 * (a * c - b * d)) x = np.arctan2(2.0 * (c * d + a * b), -1 * (math.pow(a, 2) - math.pow(b, 2) - math.pow(c, 2) + math.pow(d, 2))) * -1 x += math.pi return np.array([z, y, x]) def cb_all_data(acceleration, magnetic_field, angular_velocity, euler_angle, quaternion, linear_acceleration, gravity_vector, temperature, calibration_status): ''' Reduction of the values given by the sensor into the usual range of -1.0 to +1.0 for quaternions. Requested by the IMU-bricklet of Tinkerforge: * Division of the return values by 16383 (14 bit). ''' q = np.array( [quaternion[0] / 16383.0, quaternion[1] / 16383.0, quaternion[2] / 16383.0, quaternion[3] / 16383.0]) q2EulResult = Q2Eul(q) rotationX = q2EulResult[2] print("X-axis by quaternion (radians): " + str(round(rotationX, 2))) print("X-axis by quaternion (degrees): " + str(round(math.degrees(rotationX), 2))) So kriege ich aktuell die von mir benötigten Werte korrekt raus. Die Rotationen um die Y- und Z-Achse kann ich (zum Glück) ignorieren. Nochmals vielen Dank für den super Link. Mit den besten Grüssen, Yvo

@Backdraft007 noch eine Frage zur suppertollen Webseite, welche Du mir angegeben hast. Merci nochmals dafür: Dort wird eingangs beschrieben, dass es bei den Ausführungen darum geht, die Winkel für die DIN70000 auszugeben. Da verstehe ich, dass bei einem (Strassen-)Fahrzeug kein Interesse an einem Roll-Winkel zwischen ]0, 360[ Grad besteht. Frage: Könnte dies ein Grund sein, dass die Winkel / Formelapparate keinen Roll-Winkel zwischen ]0, 360[ Grad ausgeben? Das wäre allenfalls einen neuen Hinweis für die weitere Suche. Mit den besten Grüssen, Yvo

Salut Backdraft007 Vielen Dank für den Link. Ich muss mir das gleich im Detail reinziehen. Ich habe noch versucht, mit dem kurzen Video die Drehung zu zeigen. Grundsätzlich ist es eine "simple" Fragestellung: Die montierte IMU wird über die Rotation ausgelenkt. Dies in einem vollen Kreis, in welchem die Position in einem Bereich von ]0, 360[ Grad gemessen werden muss. Eventuell kommt Dir da noch etwas in den Sinn. Merci vielmals, Yvo ImuVersuchsaufbau.webm

Salut Backdraft007 Ich habe ein Foto des aufbaus gemacht. Allenfalls besser als eine Skizze. Ich hoffe, es ist so gut erkennbar: In der Mitte befindet sich die Drehachse. Um diese kann in beide Richtungen gedreht werden. Auf dem Schild sind die Sollwerte beschrieben: Unten 0 Grad Oben 180 Grad Links und Recht die 90 und 270 Grad Unten auf dem Stab ist die IMU montiert. Wie beschrieben, kann diese nur in so montiert werden: Die IMU wird auf der Y-Achse rotiert. Die weiteren Rotationen (X- und Z-Achse) interessieren in diesem Setup nicht. Erklärt diese Skizze die Situation? Freue mich auf alle Inputs, Yvo

Hallo TinkerUnity Ich verwende ein IMU 3.0 Bricklet für die Bestimmung einer Rotation um eine Achse. Dabei benötige ich einen Wert zwischen ]0, 360[ Grad. Aktuell versuchte ich die Rotation um die Y-Achse (Roll-Winkel) zu nutzen (aus konstruktiven Gründen). Da musste ich feststellen, dass der Wertebereich des ausgegebenen Euler-Winkels sich zwischen ]-90, +90[ bewegt. Das irritiert mich sehr. Vor allem kann ich so die Auslenkung nicht eindeutig bestimmen. Dann habe ich die beiden anderen Achsen noch angesehen und habe die folgenden Wertebereiche erhalten: * Z-Achse (Heading): ]0, 360[ * X-Achse (Pitch): ]-180, +180[ * Y-Achse (Roll): ]-90, +90[ Aus gewissen Aspekten kann ich diese Bereiche verstehen (Flugzeug, Copter). Leider passt dies aber nicht für meine Anwendung. Leider kann ich aus konstruktiven Gründen nur die beiden Achsen X und Y verwenden (Pitch und Roll). Frage: * Gibt es eine Möglichkeit, den Roll-Winkel im Bereich ]0, 360[ Grad trotzdem zu berechnen? Aus den Quaternionen? Leider übersteigt das meine Fähigkeiten bei weitem. Falls jemand eine konkrete Umsetzung hätte, wäre ich sehr dankbar. Mit den besten Grüssen, Yvo

Heja rtrbt Ganz grossen Dank für Deine ausführliche Rückmeldung. Super. Allenfalls probiere ich das mal bei einem nächsten Projekt aus. Gruss, Yvo

Hallo TinkerUnity Ich wurde von RS-Online auf eine mir noch unbekannte Reihe von Einplatinen-Rechnern aufmerksam gemacht: ROCK Single Board Computers Frage: Könnten diese auch mit einem Tinkerforge HAT betrieben werden? Kennt jemand diese Rechner und was sind die Erfahrungen in einem industriellen Umfeld? Mit dem Ubuntu als Betriebssystem wäre zumindest die Grundlage für Tinkerforge gegeben, oder? Zum Beispiel der Radxa ROCK 4C+? Der Link führt zur Spezifikation der Ein- und Ausgänge, auf welchen ein HAT aufgesetzt würde. Freue mich auf allfällige Rückmeldungen und Gruss, Yvo

Ah, das ist cool und ein gangbarer Weg. Vielen Dank für den Hinweis.

Heja photron Oups. das sind keine guten Neuigkeiten. Meinst Du, dass 24 bis 48 Stunden im Bereich sein könnten? Respektive, gäbe es eine Variante, den HAT mit sehr wenig Strom zu stützen, dass die Zeit über einen etwas grösseren Zeitbereich gehalten werden könnte? Oder etwas zusätzliches externes, welches länger halten würde? Dankbar für jede Info.

Guten Tag TinkerUnity Ich habe mehrere Messvorrichtungen, welche einen Pi zusammen mit dem TF-HAT verwenden. Die Messvorrichtungen werden gelegentlich verwendet und mit Strom versorgt, aber ohne Internet. Um dann die periodischen Messungen zeitlich (absolutes Datum und Zeit auf die Minute genau) zu verorten würde ich mich gerne auf die "Real-Time Clock" / "Echtzeituhr" verlassen. Frage dazu: Wie lange kann die "Real-Time Clock" / "Echtzeituhr" vom RaspberryPi-HAT mehr oder minder korrekt laufen, ohne dass der Pi und das HAT am Strom hängt, oder am Internet hängt? Und wie müsste ich die Uhr wieder updaten? Respektive, geht das automatisch sobald dieser Internet-Verbindung hat? Freue mich auf jeden Hinweis. Mit den besten Grüssen, Yv0

Dear photron Thank you very much for the fast replays and the suggestions. Currently I am using a baudrate of 9600 and the data I am sending are rather small: "123.444;-999.99;-999.99;2199.456;2076.765;-999.99;-999.99;-999.99\r\n" The values of -999.99 are for further use and eventually replaced later by smaller numerical values similar to the other ones. Each dataset can be sent once every 500msec. In a simplified C#-application, the approach works. Based on this experience, I implemented it into the main application using a loop sending data constantly instead of once and then the application stops. The strange thing is, that using a debug-stop allows the Arduino doing the work. But not a paused thread on the side of the C#-application. Almost 20 years ago, I had to trigger system-calls within C#-applications by a specific system call. As I remember, this call allowed the system to get the internal jobs done. No idea, if this is a similar problem ... and no idea anymore, how we triggered this call then.

Dear List I have a strange behavior by the communication between a RS-232 bricklet and an Arduino (TTL-based communication). The communication is only one-way (using only one wire between TX of the bricklet and the RX of the Arduino. The information sent is a simple ASCII-string terminated with an "\r\n". The application on the TF-side is written in C#. Using the setting BrickletRS232V2.FLOWCONTROL_OFF the communication only works, if the C#-application is stopped by a debugger-stop and launched again. As soon as the C#-application runs normally (without debugger-stop), the communication is not successfully on the Arduino-side. The code sending the message over the TTL-connection runs in a background-worker-thread. And an additional sleep of the calling thread is not solving the problem (the assumption was, to simulate the debugger-stop. Using the settings BrickletRS232V2.FLOWCONTROL_HARDWARE and rickletRS232V2.FLOWCONTROL_SOFTWARE lets running the data-exchange, but the data are not received correctly. Question: Does anyone has an idea, what could cause this kind of behavior? Do I have to implement a two-way-communication to get it running? Is FLOWCONTROL a good starting-point for any further research to solve the problem? Looking forward to any ideas and thoughts. Cheers, Yvo

Dear photron Thank you very much for the replay. The HAT has already the new firmware installed. Changing the RTC-driver to DS1338 seemed to solve the problem. After a reboot of the RaspberryPi, the command dsmeg got the probably correct answer back: [ 12.195400] rtc-ds1307 1-0068: registered as rtc0 [ 12.219366] rtc-ds1307 1-0068: setting system clock to 2023-04-18T10:49:16 UTC (1681814956) The date and time looks perfect now. Cheers, Yvo

Dear List I tried to get the Real-Time-Clock (RTC) of the HAT set to the current time. The setup is following: RaspberryPi 3B+ HAT Raspberry and HAT powered by the 5-28V input of the HAT providing about 21V The entire setup is headless Access of the Raspberry and HAT by the LAN-interface The Raspberry is connected by WiFi-interface to the internet Following the description, I tried to get the RTC configured. With the command dmesg I receive the following information: [ 13.116016] rtc-pcf8523 1-0068: hctosys: unable to read the hardware clock [ 455.792146] rtc-pcf8523 1-0068: low voltage detected, time is unreliable Using the following command: hwclock --systohc gives the output: hwclock: Cannot access the Hardware Clock via any known method. hwclock: Use the --verbose option to see the details of our search for an access method. Question: Does anyone can interpret the output? Why is the RTC not accessible? What to do, to get the RTC running? Looking for any suggestions and ideas. Cheers, Yvo

Hallo Backdraft007 Noch eine kurze Rückmeldung: Das hat mit dem Industrial Digital Out gut funktioniert. Vielen Dank für die Info. Die LED's die ich zu verbauen habe, ziehen aber bis 100mA und da ist das Digital Out überfordert. Ich habe des halb auf das Quad-Relaise gewechselt: https://www.tinkerforge.com/de/doc/Hardware/Bricklets/Industrial_Quad_Relay_V2.html Da kann ich bis 100mA pro Anschluss ziehen und funktioniert auch einwandfrei. Mit den besten Grüssen, Yvo

Oh, thank you very much for the quick replay and the hint about the ARM-based micro controller: Looks like the Arduino Entwicklerboard Nano RP2040 Connect mit Pinleisten should work. The family of the processor is defined as ARM. I will try and let the forum know as soon as I have a result.

Dear list I have to send messages from the Tinkerforge environment to an Arduino-board. In this specific case only one-way from TF to Arduino. Question: Is my assumption correct, that the RS232 Bricklet 2.0 is able to send by using the TTL communication to the Arduino-board? Based on the documentation of the Serial communication of Arduino, it seems possible to me. Looking forward to any suggestions, opinions or corrections. Best regards, Yvo

Hi Superp Thank you again for your extensive feedback. I am not surprised, that you are confused. Sorry for my imprecise description. I try to explain it in more detail (especially if someone else comes up with a similar question). Basically, the approach is used for a "rocker -switch"-only measure-device: As soon as a person switches the device on, the Pi starts and a Python-software runs the measurements. As soon as the person switches the device off, the measurements have to stop, all the resources have to be closed, the log has to be written and the Pi has to stop. The start works ok. I am using services to start the software after powering the Pi. The stop is what still worries me. The power-supply of the device is done by batteries (about 22V). When I understand your replay correctly, I have to take the following steps: Running the measurements. In parallel, I monitor the power-supply of the HAT (e.g. by using callbacks). As soon as the power-supply drops below a defined voltage (e.g. 10V), I assume that the person switched the device of. The software runs the final operations, such as logging and closing all resources. As soon as all operations are terminated, the software calls the OS and initiates a shutdown. Additionally, the software calls the HAT-API function set_sleep_mode with the parameters you suggested (the value for the power_off_duration taking 136 year is ok 😇 The software stops running. After the given delays, everything falls asleep and the device consumes only a minimum of power. As soon as a person switches the device back on, the Pi starts and using the services, the entire setup runs again. Isn't it? What do you think? Was I able to summarize more or less your proposal of the previous post? Looking forward to any hints and suggestions. Cheers, Yvo

Hi Superp Thank you very much for the quick replay and the proposed solution 2. Eliminate the StromPi. This sounds very promising! I checked the API of the HAT-brick again. But I am not sure yet, if I am able to implement my needs: HAT registers a drop of the DC-voltage below threshold: That should be OK. Script stops the execution of the application immediately: That should be OK. Script shutdowns the RaspberryPi and the attached HAT: Not sure how to do. Shall I call os.system("sudo shutdown now") Question: Will the mentioned command be enough to shutdown the Raspberry and all attached bricklets? As far as I understood the description of the API of the HAT, I will be able to send to sleep the HAT and cut the power-supply of the Pi and the bricklets. But I will not be able to run an entire shutdown (e.g. power_off_duration = 0). Question: Do you have a different great suggestion? Advantage of the StromPi is, that you are able to configure an entire shutdown of the system after a defined time-span. Looking forward to any suggestions. Cheers, Yvo

Guten Tag Form Für ein Projekt verwende ich das HAT Brick entsprechend zusammen mit einem RaspberryPi 3B+. Für die spannungsfreie Stromversorgung benutze ich den StromPi 3 in Kombination mit der Batterie-Einheit für StromPI 3. Zentral dabei ist die serielle Message vom StromPi 3, dass die Stromhauptversorgung unterbrochen ist und die Einheit auf der Batterie läuft. Diese Message wird von einem Python-Programm genutzt, die eigentliche Sensor-Applikation mit Tinkerforge-Bricklets kontrolliert zu beenden, bevor der RaspberryPi 3B+ via dem StromPi 3 runter gefahren wird. Im ersten Prototypen hat es soweit funktioniert: Der StromPi 3 reagiert wie konfiguriert: Message wird ausgesendet, wenn Hauptstrom weg ist. Die ganze Einheit läuft zuverlässig weiter. Die ganze Einheit wird nach den definierten 30 Sekunden runtergefahren. Das HAT Brick kann mit den Bricklets kommunizieren: Soweit keine Einschränkungen gefunden. Über die serielle Schnittstelle im Python-Programm kann die Powerfail-Message entgegengenommen werden. Soweit so gut. Was aber ein Problem macht, ist die Konfiguration des StromPi 3: Wenn das HAT Brick montiert ist, kann die Konfigurationssoftware vom StromPi 3 nicht gestartet werden. Hier kommt es zu einem Konflikt auf der seriellen Schnittstelle. Sobald das HAT Brick demontiert ist, können die Konfigurationen vom StromPi 3 problemlos gemacht werden. Diese sind dann nach dem Reboot und Montage des HAT Brick auch aktiv. Wenn der RaspberryPi 3B+ mit dem StromPi 3, ohne HAT Brick aber mit einem Master-Brick via USB verwendet wird, treten die oben beschriebenen Probleme nicht auf: Ich vermute, dass dann die Kommunikation ausschliesslich über den USB-Bus läuft, oder? Frage: Kennt sich jemand mit dem StromPi 3 in Kombination mit dem HAT Brick aus? Respektive, hat jemand schon ähnliche Erfahrungen gemacht? Freue mich auf jeden Hinweis. Mit den besten Grüssen, Yvo

Ah, das ist sehr clever. Ganz herzlichen Dank. Das ist genau die Idee, welche ich gesucht habe. In der Doku von TF auf der Webseite ist eine LED sogar als Last beim Beispiel aufgeführt. Topp. Merci und Gruss.