J-Log.eu - Forum

Hier total OT, "S32 Thread" missbraucht:

Bloß mal so, Anlass war das: https://www.rc-heli.de/board/showpost.php?p=3263644&postcount=674

Der Regelkreis ist hier nicht geschlossen, weil die Regelstrecke nicht existiert, solange das Ding nicht in der Luft ist.

---------------------------------------



Etwas detaillierter:


Der "Regler" ist nicht der Regelkreis. Regler+Regelstrecke ergeben den Regelkreis.
Das Verhalten des Regelkreises ist unser Ziel, - die Regelstrecke beeinflusst es.
Die Parameter eines Reglers müssen somit zwangsläufig an die Regelstrecke angepasst werden, - z.T. kann das ein Regler adaptiv durch "Statistik" anhand globalem Soll-Verhalten.
Wenn es gleich wie A auf Eimer passt, ist es Glück oder ein vorgefertigtes Set von Regler Parametern, die zur jeweiligen Regelstrecke passen (müssten).
Sprich, "Standardisierung". Jede Proprietät gegenüber angenommenem Standard erfordert Anpassen von als überwiegend passend angenommenen Set-Parametern eines "Standards".
Um es bildlich zu machen: Wenn jemand aus dem Nichtpassen eines Standard-Sets zu seinem Nichtstandard-Standard auf die Qualität eines Reglers schließt, dann wäre es dasselbe wie "Bei 6 aus 49 habe ich 2x 30 EUs gewonnen, bei Spiel 77 noch nie etwas. Ergo ist Spiel 77 Schei**e, 6 aus 49 die Gelddruckmaschine."

---
Wir reden hier (FBL) von 3 Reglern (+DZ-Regelung), von denen zwei miteinander gekoppelt sind, - und alle 3 Regelstrecken koppeln ineinander ein. Es gibt jeweils nicht eine Störgröße, sondern viele, die einander beeinflussen. Am Ende, zu den Reglern hin, sind es nur noch 3 Drehraten. Da geregelt wird, spielt die jeweilige Zeit (t) natürlich eine Rolle, im Falle eines sehr dynamisch geflogenen Objekts (oder sehr leichten) ganz besonders. Integratoren nehmen die Zeit in's Spiel. Beim Self Levelling (selbst ein Hyper-Regelkreis) kommt eine weitere Führungsgröße (bzw. Messgröße) hinzu, der Gravitationsvektor (statische Beschleunigung), - aber ohne die obigen reicht das nicht, denn waagerecht!=levelled, und Trends (Drift) müssen eliminiert werden, ohne den Fixpunkt (Umgebung) zu sehen. Den Freiheitsgrad "Höhe über Grasnarbe" könnte man ausregeln per Drucksensor im ungeliebt grünen Kästchen.

_________________
Tom

Das ist hier nicht mehr OT, weil es auch für den S32 zutrifft.

Anlass: https://www.rc-heli.de/board/showpost.php?p=3263661&postcount=676

Theoretisch kann FAT32 bis zu 8TB Kapazität. Praktisch ist es oft auf max. 32G limitiert, selbst in OS wie Windows: https://de.wikipedia.org/wiki/File_Allocation_Table#FAT32
FAT32 Implementierungen in "Embedded Systems", mit oder ohne OS (wie 3Digi, S32 u.v.a.m.), gehen meist von max. 32G Kapazität eines FAT32 formatierten Datenträgers aus. Das ist nicht nur Sinnfälligkeit in der jeweiligen Applikation geschuldet, sondern der Code selbst limitiert es.
Grund ist, dass ein größeres FAT32 natürlich per entsprechend mehr sog. "Cluster" (je bis zu 32kB) verwaltet wird. Auch die max. Anzahl Files steigt.
Das benötigt entsprechend mehr RAM in der Implementierung, "sinnloserweise" sozusagen, denn auch ein "besserer" ARM Microcontroller ist kein RAM-Schlaraffenland.

Elektronik entwickelt sich rasant, so auch Leistung/Preis bei MMC. (MMC== NAND Speicher + Controller, - als Card, USB Stick, eMMC (fest aufgelötet), ..)
Im Augenblick haben wir daher gewissermaßen einen weißen Fleck zwischen FAT32 Implementierung im Embedded System (oder sogar "Dick-Host") und bezahlbar Käuflichem. Wir (Leute wie Dirk und ich) können daher nur mit dem Hinweis agieren, die Kirche im Dorf zu lassen, - hinreichende Kapazitäten zu nehmen, 4/8G.
Irgendwann, in ein paar Jahren, wird das wahrscheinlich so enden wie mit JLog2.x: FAT16, max. 2G Cards, aber solche gibt es kaum noch zu kaufen.
Dann muss unsereiner reagieren, hier seinen FAT32 Code aufbohren, - und wenn der RAM dafür nicht reichen sollte (nicht eruiert), dann muss ein Prozzi mit mehr RAM her (siehe JLog 2.x -> 3).

---
Ich bin ein alter Knacker, kann die Entwicklung daher vor'm geistigen Auge der Historie besser bildlich nachvollziehen: Wir haben Unix7 auf den 256kB zweier 8" Disketten gefahren, waren stolz wie Oskar. An 15MB Winchester Drive verbog man sich das Kreuz (60kg), und der Kapazitätswahnsinn triumphierte, wenn man einen 100MB Wechselplattenstapel in die Top Loader Waschmaschine (Drive) hob.
Hätte ich damals eine Micro SD aus der Tasche ziehen können, sagen, "hier, 128 GIGABYTES", - dann wäre ich wohl in die Klapsmühle eingeliefert worden.

_________________
Tom

Ich lese weiter
https://www.rc-heli.de/board/showpost.php?p=3263815&postcount=683

Das "bestimmte Ereignis" gibt es mMn nicht in globaler Form, - also egal, in welchem Setup. Vor Erfüllen von User-Wünschen muss man sich stets zwei Dinge fragen:
- Welchen Multiplikator hat die Lösung? (Deckung mit dem Bedarf anderer User)
- Jede zusätzliche oder setup-bedingte Funktion kann den Effekt des Verkomplizierens aus der Sicht anderer User haben. Ist es gerechtfertigt, das für den Change in Kauf zu nehmen?
(Ich hinterfrage den Zweck des Wunsches hier generell.)

Dafür hat jeder Log-File eine laufende Nummer.

Dein Wunsch ist einer für eine kommende Hardware-Version. Der Prozzi des 3Digi verwendet momentan nicht seine RTC (Echtzeituhr). Das braucht neben einem extra Schwingquarz auch eine selbsttätig nachgeladene Bakterie. Batterie == Handlötjob, denn eine Batt explodiert im Reflow Oven. Kannst gerne mal den R2 Kollegen konsultieren, der diesen Job am S32 ausführt. Der springt auch in RCH rum, ich verrate nur nicht, unter welchem Nickname. Kannst Dir denken, wie "begeistert" er reagieren wird.
([user-]einsetzbare Batt: zu groß, [zu "gefährlich" für manche Wurschtfinger ])

_________________
Tom