yvo

Backdraft007 In the meantime, I found a hopefully suitable cable: https://www.audiophonics.fr/en/power-supply-accessories/male-90-angled-usb-c-to-bare-wires-power-cable-22awg-25cm-p-13575.html I will see, how it works. Cheers, Yvo

Hi Backdraft007 Thank you very much for the link. Looks promising and worth a trial. A downside will be, that I will introduce an open connection more. Currently, I prefer to cut cables to avoid an addition, for humidity and vibrations, delicate connection. Cheers, Yvo

Dear batti Thank you very much for the advice and pointing out the precise location. I had a look at the HAT itself, puhh, this is all pretty small. I guess, this will exceed my skills of soldering 😟 I re-checked the available space between the USB-socket and the case were the RPI and the HAT are located: There are 15mm available. Using an USB-cable with a 90-degrees rotated plug, it should fit. See attached images. Probably, buying such cables, cutting and just using the two power-wires will be easier than soldering an additional cable onto the board of the HAT. Hope you agree. Cheers, Yvo

Hi Backdraft007 Perfect. Thank you very much. In this case, I will go with the positions of the bricklets. That sounds the most promising. Cheers, Yvo

Dear List I am using the Rugged Approach approach for programming in C# and in Python. It just works perfectly! Thanks for the great tutorial. Till now, I worked with many bricklets, but each of a different type. For this case, the approach and code in the tutorial works like a charm. Question: But what would be the best-practice, if you have several bricklets of the same type? Of course, I could use the UID of the individual bricklets to make the differentiation of the individual bricklets. But I would like to avoid the usage of the UID in Rugged Approach for several reasons: Lost of the very generic procedure of the Rugged Approach introducing somehow hard-coded UIDs of bricklet. Incompatibility of several installations of hardware having different UIDs. In the specific application I am working on, the bricklets are connected with a HAT Brick. Question: Is there a possibility to avoid the UIDs? Could I use the information of the ports were each of the bricklet is connected to? In this case, I have to make sure, that each bricklet is connected with a well defined port. An approach which could be realistic. The information of the port connected to would be based on the return value of the get_identity() function of each bricklet. If I would use the UIDs, is it reasonable/possible to change the UIDs of the individual bricklets to have the same UIDs of the bricklets in each identical installation of the hardware. Looking forward to any ideas and suggestions. Cheers, Yvo

Dear List I have to use the 5V power-supply of the HAT Brick additionally to the 5-28V DC-input. But for constructive reasons (no available space), I cannot use an USB-connectors. Question: Is there a possibility / location to sold a cable directly onto the HAT Brick? With soldering directly a cable, I could use the additional power-supply (which I have to use for several reasons additionally to the 5-28V DC-input, see https://www.tinkerunity.org/topic/11345-hat-brick-und-strompi-3-mögliche-konflikte-bei-serieller-kommunikation-respektive-problem-bei-konfiguration-von-strompi-3/ ) even within the very small space available where the RPi and HAT are installed. Looking forward to any ideas and suggestions. Cheers, Yvo

Das ist in der Tat sehr merkwürdig. Ich habe alles nochmals geprüft und vor allem die Pole des PowerSupply (siehe Foto). Da sehe ich keinen Fehler meines Erachtens. Oder mache ich etwas falsch?

Kein Problem. Ich bin leider ein Elektronik-Analphabet. Folgendes ist gemessen: In der blauen Verbindung messe ich in allen Schaltzuständen 24V (also wie PowerSupply).

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