yvo

Hallo MatzeTF

Super, vielen Dank für Deine umfassende Rückmeldung. Alles klar, das passt so perfekt.

Mit den besten Grüssen,

Yvo

Hallo TinkerUnity

Ich setzte Real-Time Clock Bricklet 2.0 um den Zeitstempel von Messungen zu garantieren. Die Bricklets hängen jeweils an einem HAT-Brick und dieses an einem RPi4.

Die Bricklets gingen etwa im vergangenen August 2023 in Betrieb. Seit der vergangenen Woche Januar 2024 scheint ein Bricklet die Zeit regelmässig zu vergessen, respektive setzt sich auf 01-01.2000 zurück.

Das heisst, die Bricklets sind nun etwa 6 Monate im Betrieb. Ich kann aber nicht sagen, zu wie viel Zeit der RPi vom Strom getrennt ist.

Als Stützbatterie nutze ich die von Tinkerforge mitgelieferten Batterien.

Fragen:

• Gibt es eine Möglichkeit, aus der Ferne die Spannung der Batterien zu prüfen?
• Gibt es Erfahrungswerte über die Lebenserwartung der Stützbatterien?
• Gibt es Alternativen zu den Stützbatterien? Zum Beispiel über eine sehr schwache externe Stromversorgung.

Freue mich auf jede Idee oder Hinweis.

Mit den besten Grüssen,

Yvo

Am 24.11.2023 um 13:17 schrieb Superp:

Good find. Let us know how it goes.

I have used this cable so far, but it takes up too much space in my machines.

I will do. The cable is not on stock right now. But should be delivered by mid-December. Let's see.

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

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