Hallo zusammen, ich / wir haben folgendes Problem: ich / wir wollen den Verlauf einer Kurve auf einem Mikrocontroller hinterlegen um ihn später aus zu lesen und entsprechend des Verlaufes Hardware anzusteuern. Wir haben bis jetzt an die Möglichkeit gedacht x Wert in einem Array zu speichern und dazwischen linear zu interpolieren oder eine Funktion zu finden die den Verlauf beschreibt und dann die Werte zu berechnen. Was würdet ihr vorschlagen??? Ich habe mal 2 Bilder mit den Verläufen dazugepackt. Vielen Dank im Voraus
Angehängte Dateien:
DAC heißt das Zauberwort. oder auch digital-analog Converter.
Dominik Großkurth schrieb: > Was würdet ihr vorschlagen??? Wer misst misst Mist. => Muss die Kurve wirklich so aussehen, oder ist das eher ein Rechteck dass durch Messfehler usw einfach verschlissen ist? => Einfache PWM. Ansonsten passt linear interpolieren schon. Bei der Kurvenform: Stützpunkte nicht äquidistant wählen, dann reichen wenige.
Dominik Großkurth schrieb: > Was würdet ihr vorschlagen??? Mach das, was unter Berücksichtigung aller Randbedingungen einfacher ist.
Was hat ein DAC hier zu suchen? Das ist mir entgangen. Also wenn Du eine Kurve als Vergleichsreferenz brauchst, hast Du die Möglichkeit dies über Hardware oder Software zu tun. Wenn Du Dich scheinbar für eine Softwarelösung entschieden hast ist ist Art der optimalen Lösung von weiteren Angaben abhängig. Eine LookUp-Table, kurz LUT, ist schnell aber verbraucht bei hoher Auflösung mehr Speicherplatz. Eine Funktion verbraucht relativ wenig Speicher, kann aber viel Rechenleistung und eventuell viel Programmspeicher fressen. Es hängt stark von der Komplexität, der geforderten Genauigkeit und den Resourcen ab was die optimale Lösung wäre. Was Du vorschlägst ist ein Mittelweg, eine Hybridlösung, also eine vereinfachte Funktion zum interpolieren, gestützt von einer groben LUT. Solange die Hardware durch ihre Beschränkungen keine Richtung vorgibt (Speicher vs Rechenleistung), würde ich mich nicht totoptimieren und eine Lösung anstreben mit einer möglichst simplen Struktur. Das macht ein späteres Debuggen, Verifizieren, Optimieren und Portieren einfacher. Ohne ernsthaft beschränkenden Zwang sind die verschiedenen Wege also fast gleichwertig. Erst der Kontext macht den Unterschied. Ohne den ist das hier sinnlos zu diskutieren. Es gibt keine generell optimale Lösungen.
Kurzes Update: Ich möchte noch nichts Konvertieren weder A zu D noch D zu A Ja die Kurve muss so aussehen (oder so ähnlich) bis zu 5% Abweichung wären OK. Die Kurve entspricht einem menschlichen Atemprofil und ist nicht ein schlecht gemessenes Rechtecksignal. Um etwas konkreter zu werden, wir streben an den Atmega324P zu nutzen der parallel weiter Funktionen ausführen soll (Messwerte aufnehmen verarbeiten und Senden).
Wenn du den Kurvenverlauf abspeichern willst wirst du um eine AD Wandlung nicht rumkommen...
P.S. Ein Trapezsignal sollte sich da mit 5% Abweichung schon reinlegen lassen
Dominik Großkurth schrieb: > Die Kurve entspricht > einem menschlichen Atemprofil Dann wäre eine einfache LUT mit linearer Interpolation wahrscheinlich ausreichend. Zur Verbesserung des Verhältnisses von Speicherplatz vs Genauigkeit wäre der Vorschlag von Erns B nicht äquidistante Stützpunkte zu nehmen Überlegenswert, was aber den Algorithmus etwas komplexer macht. Die Frage ist also: Wie hoch sind die Ansprüche an die Genauigkeit und Auflösung. Wenn das Ganze nicht in Zeitraffa, sondern (annähernd) in Echtzeit laufen soll und ihr das Ganze mit einer übersichtlichen Formel modellieren könnt, würde es sich auch anbieten dies direkt in Echtzeit mit der Formel zu berechnen. Dann könnte man auf die LUT komplett verzichten. Solange man keine extrem feine Auflösung mit enorm vielen Stützstellen benötigt, dann würde übrigens die LUT auch nicht mehr in den Speicher passen, kann man davon ausgehen, daß kein Mensch so schnell atmen kann um den den Atmega rechentechnisch zu überfordern. Dafür reicht ein Bruchteil der Rechenleistung, sofern die Formel nicht hochkomplex ist. Es bleibt also noch genug Zeit für die anderen Aufgaben.
blablub schrieb: > Wenn du den Kurvenverlauf abspeichern willst wirst du um eine AD > Wandlung nicht rumkommen... Ich glaube Du mißverstehst seine Absichten. Er will eine Referenzkurve im Chip hinterlegen, von der ausgehend später etwas geregelt/gesteuert werden soll. Es soll keine Meßreihe aufgezeichnet werden.
Angehängte Dateien:
-
Profil.jpg
27 KB
OK vielen dank für die schnellen Antworten falls noch jemanden ein anderer Ansatz einfällt als Funktion ermittel oder LUT ablegen währe ich sehr dankbar Antworten in der Form wie sie "Carsten R. (kaffeetante)" gegeben hat währen nett ;) P.s. ein Atemprofil könnte auch so aussehen und dann kann man das Trapez leider vergessen.
Carsten R. schrieb: > blablub schrieb: >> Wenn du den Kurvenverlauf abspeichern willst wirst du um eine AD >> Wandlung nicht rumkommen... > > Ich glaube Du mißverstehst seine Absichten. Er will eine Referenzkurve > im Chip hinterlegen, von der ausgehend später etwas geregelt/gesteuert > werden soll. Es soll keine Meßreihe aufgezeichnet werden. Das trifft es auf den Punkt ;)
Dominik G. schrieb: > OK vielen dank für die schnellen Antworten falls noch jemanden ein > anderer Ansatz einfällt als Funktion ermittel oder LUT ablegen währe ich > sehr dankbar Die Frage ist, wofür ihr das braucht? Wie genau die Kurve reproduziert werden muss. Wenn das die Spannungskurve ist, mit der ein Magnetventil angesteuert wird, dann wirds wahrscheinlich ein simples Rechteck auch tun. Wenn das die Kurve ist, die einem EKG-Schreiber zur Simulation vorgeworfen wird, dann wirds ein Rechteck eben nicht tun. Müssen die Oberwellen exakt reproduziert werden oder nicht? ALles Fragen, die man ohne zu wissen wofür das ganze ist, nicht beantworten kann.
Karl Heinz Buchegger schrieb: > Dominik G. schrieb: >> OK vielen dank für die schnellen Antworten falls noch jemanden ein >> anderer Ansatz einfällt als Funktion ermittel oder LUT ablegen währe ich >> sehr dankbar > > Die Frage ist, wofür ihr das braucht? Wie genau die Kurve reproduziert > werden muss. > Wenn das die Spannungskurve ist, mit der ein Magnetventil angesteuert > wird, dann wirds wahrscheinlich ein simples Rechteck auch tun. Wenn das > die Kurve ist, die einem EKG-Schreiber zur Simulation vorgeworfen wird, > dann wirds ein Rechteck eben nicht tun. Müssen die Oberwellen exakt > reproduziert werden oder nicht? > > ALles Fragen, die man ohne zu wissen wofür das ganze ist, nicht > beantworten kann. Das Gerät darf am Ende nicht mehr als 5% von der Kurve abweichen was genau damit gesteuert wird steht noch nicht fest aber das ist auch ein anderes Problem. Ich möchte einfach wissen welche prinzipiellen Möglichkeiten es gibt eine Referenzkurve auf einem µC ab zu legen welche ich dann nutze und wie genau ich diese nutze ist dann mein Problem.
Carsten R. schrieb: > Wir haben bis jetzt an die Möglichkeit gedacht x Wert in einem Array zu > speichern und dazwischen linear zu interpolieren oder eine Funktion zu > finden die den Verlauf beschreibt und dann die Werte zu berechnen. > Ja die Kurve muss so aussehen (oder so ähnlich) bis zu 5% Abweichung > wären OK. > Es soll keine Meßreihe aufgezeichnet werden. Vielleicht solltest Du Deine Gedanken noch ein wenig sortieren um herauszufinden, was Du eigentlich möchtest. Mir persönlich scheint Deine Kurve von Zufallsparametern beinflußt zu sein, so dass Du mit der rein mathematischen Lösung nur einen sehr komplexen Lösungsansatz finden wirst. Einfacher wird es dann wohl sein, vielleicht alle 50ms einen Wert zu ermitteln und ihn mit 8 Bit Genauigkeit zu speichern. Sollte je nach Meßlänge im µC zu wenig Speicher vorhanden sein, dann läßt sich je nach Anforderung noch ein SRAM oder EEPROM an den µC anschließen.
Egal ob die Kurve nur eine Referenzkurve ist, oder ob sie Digital aufgezeichnet ist. Um sie Rekonstruieren zu können brauchst Du ein Abtastintervall (Anzahl werte), das der doppelten Frequenz der maximal im Signal enthaltenen entspricht. Auch hier gilt letztendlich das Shannonsche Abtasttheorem.
Dominik G. schrieb: > Ich möchte einfach wissen welche prinzipiellen > Möglichkeiten es gibt eine Referenzkurve auf einem µC ab zu legen welche > ich dann nutze und wie genau ich diese nutze ist dann mein Problem. Es gibt genau eine. Du speicherst Sie als Zahlenwert.
Es gibt prinzipiell nur die bisher genannten drei Möglichkeiten: - aus Formel berechnen - ein Bild/Array Speichern - aus 1 und 2 kombinierte Varianten mit unterschiedich gelagerten Schwerpunkten. Das war es! Funktionen sind mathematisch betrachtet Mengen von Tupeln, hier Paare, bestehend aus Urbild (Zeitindex) und Bild (zugehörigem Wert). Diese Menge kann man, wenn sie abzählbar sind, aufzählen (Array) oder zusammenhängend als Formel beschreiben. Funktionen können aus anderen Funktionen zusammengesetzt werden. Damit sind dann alle Möglichkeiten abschließend beschrieben. Da, zumindest nach aktuellem Stand der Technik, digitale Computer (keine Analogrechner), nur abzählbare Zahlenformate kennen, ist die Abzählbarkeit keine Einschränkung. Wir können ohnehin nur solche Sachverhalte modelieren.
nobi schrieb: > Egal ob die Kurve nur eine Referenzkurve ist, oder ob sie Digital > aufgezeichnet ist. > Um sie Rekonstruieren zu können brauchst Du ein Abtastintervall (Anzahl > werte), das der doppelten Frequenz der maximal im Signal enthaltenen > entspricht. > Auch hier gilt letztendlich das Shannonsche Abtasttheorem. Noch einer, der das Abtasttheorem nicht verstanden hat.
Dominik G. schrieb: > P.s. ein Atemprofil könnte auch so aussehen und dann kann man das Trapez > leider vergessen. Dann mußt Du irgendwann ein oder mehrere wählbare Profile festlegen. Wenn es ein "adaptives" Profil ist, wird es ohnehin nichts mit einer LUT. Dann bleibt nur noch ein Algorithmus. Adaptiv impliziert in diesem Falle aber INPUT. Das widerspräche aber dem bisherigen Konzept.
Dominik G. schrieb: > Ich möchte noch nichts Konvertieren weder A zu D noch D zu A wirst du aber müssen, sonst kann dein Mega nur Low oder High ausgeben. Willst du eine analoge Kurve erzeugen, musst du zwangsweise einen irgendwie gearteten DAC verwenden. deine Kurven enthalten doch offensichtlich Messrauschen. Ist es denn wichtig, dass dieses 1:1 wiedergegeben wird? Ich würde die Kurven glätten, mittels Regression versuchen, ein Modell zu finden und zur Reproduktion dieses mit Pseudozufallszahlen (-> Reproduzierbarkeit) überlagern. Dominik G. schrieb: > Das Gerät darf am Ende nicht mehr als 5% von der Kurve abweichen Was heißt 5%? 5% pro Messwert? welche Auflösung (samples/sec und bits/sample) und Länge (sec) soll das aufgezeichnete Referenzsignal denn haben? In meinen Augen sieht das Signal komisch aus. es müsste doch auch einen negativen Teil geben. und selbst wenn das der Absolutbetrag ist, kommt mir die Null-Linie dazwischen merkwürdig vor.
Vlad Tepesch schrieb: > sonst kann dein Mega nur Low oder High ausgeben. Und wo ist da das Problem? Bisher stand in den Anforderungen nirgends, daß er Analogwerte ausgeben möchte, im Gegenteil. Dies wurde sogar ausgeschlossen. Die hinterlegte Kurve soll bisher nur Eingabeparameter für die Nachfolgende Verarbeitungsstufe liefern. Mit dieser Strategie können auch beispielsweise PWM-Signale für einen "Sinuswechselrichter" moduliert werden. Die Pulsbreiten werden moduliert, das Signal ist und bleibt aber binär auf 0 und 1 beschränkt. Ein DAC wird erst dann notwendig wenn Analogwerte ausgegeben werden sollen, wie Du es selbst schon bemerkt hast. Dies ist bislang nicht gefordert.
Dominik G. schrieb: >> Er will eine Referenzkurve >> im Chip hinterlegen, von der ausgehend später etwas geregelt/gesteuert >> werden soll. Es soll keine Meßreihe aufgezeichnet werden. > > Das trifft es auf den Punkt ;) Vlad Tepesch schrieb: > Was heißt 5%? 5% pro Messwert? > welche Auflösung (samples/sec und bits/sample) und Länge (sec) soll das > aufgezeichnete Referenzsignal denn haben? Es soll nicht gemessen werden. Es soll eine gegebene Vorlage vom µController digital modelliert werden mit einer Abweichung von weniger als 5% zur Vorlage. Die zeitliche Auflösung wurde leider noch nicht spezifiziert. Letzteres hat aber auch nur indirekt was mit den 5 % zu tun, wenn zwischen den Punkten ein "Sprung" liegt. Die komische 0-Linie ergibt sich daraus, daß man nicht mehr Luft ausatmen kann als man eingeatmet hat. ;-) Ich kenne niemanden mit negativem Lungenvolumen.
Carsten R. schrieb: > Dies ist bislang nicht gefordert. Dominik G. schrieb: > ich / wir wollen den Verlauf einer Kurve auf einem Mikrocontroller > hinterlegen um ihn später aus zu lesen und entsprechend des Verlaufes > Hardware anzusteuern. das habe ich daraus abgeleitet, mag ein Trugschluss gewesen sein. Carsten R. schrieb: > Vlad Tepesch schrieb: >> Was heißt 5%? 5% pro Messwert? >> welche Auflösung (samples/sec und bits/sample) und Länge (sec) soll das >> aufgezeichnete Referenzsignal denn haben? > > Es soll nicht gemessen werden. Das habe ich verstanden, dennoch müssen die Daten initial gemessen und gespeichert werden. Entweder über eine funktionale Bildungsvorschrift, oder per Tabelle. Für beide Fälle wäre der Wertebereich/Auflösung interessant. reichen 256 Werte zwischen 0 und Skalenmaximum? falls nicht, reichen 1024 oder 2048 oder 4096? bei 8bit kann man immerhin unkomprimiert 25ksamples speichern, wenn man noch ein wenig Programmcode für Programm reserviert. Je nach Länge der Kurve und Abtastrate, sollte das als Basis für eine lineare Interpolation genug sein, wenn nicht jedes Bit Rauschen 1:1 reproduziert werden muss. Die Daten ansich haben relativ wenig Informationsgehalt, so dass sie sich außerdem super komprimieren lassen dürften. zB indem man Differenzen der Werte berechnet und diese Huffman kodiert. der OP könnte ja mal die Rohmessdaten der zu reproduzierenden Messreihen als csv posten. Carsten R. schrieb: > Die komische 0-Linie ergibt sich daraus, daß man nicht mehr Luft > ausatmen kann als man eingeatmet hat. ;-) Ich kenne niemanden mit > negativem Lungenvolumen. das heißt, das ist die Einatmenphase? Da ist also eine Diode in der Messstrecke ;)
Dominik G. schrieb: > P.s. ein Atemprofil könnte auch so aussehen und dann kann man das Trapez > leider vergessen. was heißt das? ist die abzulegende Kurve variabel? das heißt sie kann nur mit Aufwand in den Programmspeicher gepackt werden. (per Bootloader veränderbar). Der Ram wäre wahrscheinlich zu klein. Besser wäre es in so einem Fall vielleicht, ein externes Speichermedium zu benutzen, zB SD-Karte, von der der µC liest. Dann ist aber die Frage, ob die Geschwindigkeit für den SPI-Modus ausreicht. Das hängt natürlich wieder von den Daten Auflösung, Speichertiefe, Länge ab.
Vlad Tepesch schrieb: > Carsten R. schrieb: >> Die komische 0-Linie ergibt sich daraus, daß man nicht mehr Luft >> ausatmen kann als man eingeatmet hat. ;-) Ich kenne niemanden mit >> negativem Lungenvolumen. > das heißt, das ist die Einatmenphase? Da ist also eine Diode in der > Messstrecke ;) Nicht ganz. Gemäß den Größen an dem Diagramm betrachten wir die geladene "Kapazität". Vergleich: Wir betrachten die Ladung eines Kondensators und nicht den Strom der ein und aus geht. Hier reichen also rein positive Werte. Beim Rest stimme ich Dir zu. Es bleibt abzuwarten ob eine nicht äquidistante Speicherung oder gar eine Kompression erfoderlich ist oder ob der Speicherplatz ohne weitere Maßnahmen eine ausreichende Genauigkeit ermöglicht, was den Algorithmus einfacher und leichter prüfbar macht. Bei 5% Genauigkeit werden wir mit deutlich weniger als 1000 Stützpunkten auskommen. Es sieht mir nach einem Beatmungsgerät aus. Die Frage wäre dann, ob es nur ein rein aktives Gerät wäre (Steuerung) oder ein Reaktives (Regelung). Im Moment wäre das Modell ein rein Aktives.
Dominik G. schrieb: > P.s. ein Atemprofil könnte auch so aussehen und dann kann man das Trapez > leider vergessen. Ja. Oder es könnte aussehen wie der Nikolaus. Entscheide dich was du willst. Was ich da sehe ist, dass du eine irgendwie geartete, nicht näher spezifizierte, rein positive Kurvenform mit einer Genauigkeit von 5% (wohl im vergleich zum tatsächlichen Kurvenwert) ablegen willst. Da kommst du dann natürlich mit einer mathematischen Funktionsbeschreibung nicht weiter, da diese ja bekannt sein müsste, sie es aber offensichtlich nicht ist. Bleiben also noch Stützstellen. Das einzige, was alle deine Kurven gemeinsam haben ist der lange 0-Wert. Hier würde sich irgendeine Kompression anbieten, und wenn es nur das Dazuspeichern eines y-Wertes (eventuell auf einer art logarithmischen Skala). Dazwischen sollte dann interpoliert werden, da die Kurvenform völlig unbekannt ist wird dir nicht viel mehr als lineare Näherung übrig bleiben. Eventuell kannst du noch die Steigung dazu abspeichern und dann eine art Bezierkurve stückeln. Sprich, du kennst Wert und Steigung im Anfangs und Endpunkt, dann kannst du eine Parabel dazwischenlegen. Das wäre eine Überlegung wert.
Ok da scheinbar mehr Interesse am gesamt gerät besteht hier etwas mehr Kontext: Es soll ein Gerät gebaut werden das die Menschliche Luge beim einatmen simuliert um so ein Mundstück einer Pressluftatemflasche zu bedienen. Momentan ist noch nicht klar wie das Gerät aussehen soll sondern es sind nur Teilprobleme identifiziert worden und eines dieser Teilprobleme ist es Referenzkurven auf dem µC zu hinterlegen. Kurven als Mehrzahl da verschiedene Belastungen simuliert werden sollen (für die dann die Kurven anders aussehen) diese werden wir fest vorgeben. Die Diagramme sehen zugegebenermaßen etwas komisch aus da unser Sensor nur in eine Richtung messen konnte (1V bis 5V) in der anderen Richtung (0V bis 1V) sind die Ergebnisse nicht verwendbar. Die 5% beziehen sich auf die Abweichung des Volumenstroms in SLPM zu einer Zeit x von der Vorgegebenen Kurve. Aber ich wiederhole nochmal ich möchte keine fertige Lösung für das Ganze gerät und auch keine spezielle Lösung auf das Gerät angepasst sondern fragte nur nach prinzipiellen Lösungsansätzen für das Problem des Ablegens einer Referenzkurve. ;)
@Dominik G. (grosdode) >sondern fragte nur nach prinzipiellen Lösungsansätzen für das Problem >des Ablegens einer Referenzkurve. ;) Wo ist das Problem? Nimm einen Mikrocontroller mit ausreichend Flash-Speicher und pack deine Kurven ganz normal, einfach ohne Tricks dort als Array rein. Wenn man mal SEHR großzügig von 1ms Zeitauflösung und 10s pr Kurve ausgeht, macht das lausige 10kB. Und? Kostet heute keinen Euro. Controller mit 128kB, 256kB und mehr sind für wenig Geld verfügbar. Wenn man noch mehr braucht, kann man über seriellen Flash nachdenken, Kosten 8 MB knapp 3 Euro, sind leicht verfügbar und anzusteuern.
Dominik G. schrieb: > Kurven als Mehrzahl da verschiedene Belastungen simuliert werden sollen > (für die dann die Kurven anders aussehen) diese werden wir fest > vorgeben. Das ist eine entsheidende Information! Es sollen also verschiedene Funktionen simuliert werden! Entweder man baut eine Art Interpreter der verschiedene Funktionen dekodieren und dann berechnen kann, was wohl zu aufwendigt wäre, oder man nimmt eine LUT mit einer hinreichend genauen Auflösung und interpoliert. Dies wurde schon ausführlich beschrieben. Das Verfahren wäre ausreichend universell und man kann beliebige Kurven nachladen. Thema erledigt würde ich sagen.
Carsten R. schrieb: > Nicht ganz. Gemäß den Größen an dem Diagramm betrachten wir die geladene > "Kapazität". Vergleich: Wir betrachten die Ladung eines Kondensators und > nicht den Strom der ein und aus geht. Hier reichen also rein positive > Werte. Hier habe ich Mist erzählt. Bei Liter pro Minute geht es um den Strom und nicht um die Kapazität. Aber man könnte das Problem leicht passend umformatieren.
Dominik G. schrieb: > fragte nur nach prinzipiellen Lösungsansätzen für das Problem > des Ablegens einer Referenzkurve. ;) Im Prinzip handelt es sich hierbei um ein ganz normales Komprimierungsproblem. D.h.: du hast grundsätzlich erstmal die Wahl zwischen verlustloser und verlustbehafteter Kompression der Eingangsdaten der Kurve. So, wie die gezeigten Kurven aussehen, könnte wohl schon allein mit einem simplen Huffman-Kompressor (verlustlos!) das Datenvolumen auf weit weniger als ein Zehntel der ursprünglichen Datenmenge eingedampft werden. D.h.: Zur Laufzeit steht exakt die urprüngliche Kurvenform zu Verfügung und dass bei sehr moderaten Forderungen bezüglich der benötigten Rechenzeit zum Dekomprimieren der Kurvendaten.
@ c-hater (Gast) Ich bin mir nicht sicher ob ich das Huffman Prinzip richtig verstanden habe aber müsste ich dann nicht immer die gesamten Daten dekomprimieren wenn ich die Kurve "abfahren" möchte? Ich habe den Huffman bis jetzt nur zur Komprimierung von Text gesehen und dann wurde immer das gesamte Dokument komprimiert oder dekomprimiert um wieder damit zu arbeiten.
nein, die dekodierung erfolgt codewort für codewort seriell. die Codierung erfordert die statistische Analyse det gesamten daten. Allerdings ist es auch möglich den Baum dynamisch zu erzeugen. Bei dieser Variante muss er auch nicht abgespeichert werden.
@ Dominik G. (grosdode) >Ich bin mir nicht sicher ob ich das Huffman Prinzip richtig verstanden Du hast vor allem Netiquette nicht verstanden. Wegen deiner unzureichenden Informationen kam irgendeiner mit Datenkoimpression an. Das ist aber gar nicht das Problem. KEINER der Schreiber weiß, WIEVIEL Daten gespeichert werden müssen, also kann auch keiner was zu Notwendigkeit von Kompression sagen. Vergiss sie! Sag lieber was zu den Daten. Wieviele Kurven? Wieviele Punkte pro Kurve? Datenbreite?
blablub schrieb: > Wenn du den Kurvenverlauf abspeichern willst wirst du um eine AD > Wandlung nicht rumkommen... So wie es scheint, würde für die angestrebte Genauigkeit wohl ein RC-Tiefpass hinter einem (digitalen) PWM-Ausgang gut ausreichen. Ob dahinter noch ein Puffer erforderlich ist, hängt davon ab, wie niederohmig das Signal zur Verfügung stehen muss.
> Ich bin mir nicht sicher ob ich das Huffman Prinzip richtig verstanden > habe aber müsste ich dann nicht immer die gesamten Daten dekomprimieren > wenn ich die Kurve "abfahren" möchte? Nein. Nur beim Komprimieren muß die gesamte Datenmenge verfügbar sein und das auch nur dann, wenn man den optimalen Baum und die optimale Codewortbreite für diese Daten finden will. Dekomprimieren geht hingegen immer codewortweise. Wenn du die Bitbreite der Codeworte beim Encodieren entsprechend der ursprünglichen Samplegröße wählst, bekommst du also die dekomprimierten Daten auch direkt sampleweise aus dem Dekompressor. Das ist wirklich einfach, wenn auch nicht unbedingt optimal bezüglich der erzielbaren Kompressionsrate.
Und hast du auch ein Implementierung, die so klein ist das sie auf kleinen Microcontrollern sinnvoll ist? DAS scheint mir nämlich das größte Problem bei all den Komprimierungsalgorithmen. Jedenfalls war das der Eindruck nach einer Stunde im Web suchen. zip wäre ja schön, muß aber in ROM und RAM passen.
die huffman-decompression braucht neben dem Baum überhaupt kein Ram, wenn man das Dekodierte Datum direkt verwendet und nicht aufheben will. Der Baum braucht halt nur zwei Zeiger oder indices auf die Kindelemente und das kodierte Zeichen in den Blättern, welches man auch in einem Feld für die Kindknoten ablegen kann, da ein Knoten entweder kein, oder zwei Kinder hat. Ansonsten liest der Dekompressor einfach Bitweise aus dem Eingabestrom, und bewegt sich im Baum entsprechend des Bits. Ist er im Blatt angekommen, schreibt er das Codewort aus und setzs sich wieder auf die Baumwurzel. Und das so lange bis der Datenstrom zu ende ist. Dazu kommt der Code der den Baum rekonstruiert und fertig ist der Huffman-Decoder.
Ergänzung: Ist halt relativ simple, dh man darf keine Wunder erwarten, was Kompressionsrate angeht. Von Vorteil ist es vermutlich auch, wenn die Codewortlänge mit der Sample-Bittiefe übereinstimmt. ist die Codewortlänge relativ lang, ist natürlich mehr Information für den Baum nötig. ich würdefür einen AVR bei 8bit bleiben. Reichen 8bit nicht für die Samples. könnte man auch 2 Bäume benutzen. zB einen mit 4bit und einen mit 8bit Codewortlänge, die sich immer Abwecheln, wenn man bei einem Blatt angekommen ist. Der eine Baum wäre für die oberen Bits ders Ergebnisses zuständig, der andere für die unteren. Die Kompression wird zwar schlechter sein, als wenn man direkt 12bit benutzt, aber so hat man nur einen Baum mit 16 und einen mit 256 Elementen, anstatt einen mit mit 4096 Man könnte auch Differenzen zwischen 2 Samples kodieren, müsste sich aber einen Trick ausdenken, wie man Absolutwerte im Strom markiert, falls die Differenz zu groß ist. zB indem man die Differenz -128 nicht codiert, sondern diesen Wert als Signal benutzt, dass die nächsten 2 Codewörter ein Absolutwert bilden. Es könnte auch günstiger sein, die vollen 8bit für die Differenz zu nehmen (mit Ausnahme des Absolutmarkers (in dem Fall 255)) und das Vorzeichen separat in den Bitstrom zu schieben (sollte ja in etwa gleichverteilt sein) und auszulesen.
Der eine Mensch atmet flach der andere langsamer oder schneller, größeres Lungenvolumen kleines Lungenvolumen mit Zwergfell oder ohne, altersabhängig, aufgeregt nicht aufgeregt usw. Da kann es keine Referenz geben mit der Verglichen wird ! Ist ja als wenn du ne Formel für nen Känguru haben willst !
Alles was hier so aufgeführt wird ist meiner Meinung nach mit einem simplen MP3 Player auf Geräteebene wesentlich besser abzubilden wie mit einem µC etc auf Chipebene. Die Frage nach der Wandlung der Atemcharakteristika stellt sich ja unabhängig vom Recorder, ebenso die Rückwandlung. Beim selber proggen mache ich mir über den Chip keine Gedanken sondern nehme z.B. eins von diesen Geräten hier: http://www.mikroe.com/mikromedia/ MP3/SD/Flash/EEProm an Bord und mit dem TFT Touch Display werden auch gleich Kurven angezeigt und gewählt. Hope that help's
@Vlad: Kann deinen Vorschlägen folgen, ich dachte aber eher an ein fertiges Codestück, denn deinen Weg komplett zu implementieren und zu testen, erscheint mir nur was für echte Programmierer. Vielleicht reicht ja eine stark vereinfachte Variante, z.B.: Bei 8-Bit die typische Häufigkeitsverteilung ermitteln für das spezifische Projekt. Oder eine Differentialbildung wie bei ADPCM. Vielleicht sind beide Ansätze letztlich auch das Gleiche. Sieht mir danach aus.
Abdul K. schrieb: > @Vlad: > Kann deinen Vorschlägen folgen, ich dachte aber eher an ein fertiges > Codestück, denn deinen Weg komplett zu implementieren und zu testen, > erscheint mir nur was für echte Programmierer. ??? was sind wir denn hier sonst? Gute Frage.de? Klar sollte man für die Umsetzung der (De)Compression halbwegs programmieren können, aber das ist doch kein Hexenwerk und an einem Nachmittag erledigt. Und zu testen ist es einfach. ein paar Dateien komprimieren und dekomprimieren und hinterher auf Binäridentität testen. Das ganze kann man dann über Nacht rödeln lassen (Testdaten sollten sich auf jeder Festplatte genug finden (nein bitte nicht die Urlaubsfotos oder die MP3-oder Film-Sammlung benutzen)).
Binärfelder in C realisieren. Nein danke, da laß ich lieber andere ran. Ich glaub, wenn ich das machen müßte, würde ich gleich Assembler nehmen. Da weiß man wenigstens was passiert und wird nicht von Compiler-Gemeckere zugedröhnt. Ich bin Hardware-Entwickler und muß halt etwas Software dazustricken.
Hast du angst vor einem array, auf das du Bitweise zugreifen willst? Und das nochnichtmal wahlfrei sondern einfach nur schön geordnet? Das ist doch nix weiter als ein Eintrag (AVR=Byte) zu lesen, 8 * (das unterste Bit zu checken und hinterher dieses rausschieben).
Jep, vermeide ich wo ich kann. Nach Lesen solcher Dinge wie man das in C machen muß (und ich komme von Assembler) dachte ich, ok Junge, genau das laß sein. Denn wenn ich das Projekt ein Jahr nicht mehr angefasst habe, verstehe ich davon dann gar nix mehr. In der Zwischenzeit ist die Birne nämlich mit Preislisten und SPICE-Code überflutet worden. Daher wäre ein fertiges Modul für mich und andere super.
Vlad Tepesch schrieb: > die huffman-decompression braucht neben dem Baum überhaupt kein Ram, > wenn man das Dekodierte Datum direkt verwendet und nicht aufheben will. Fast richtig. Im konkreten Fall bräuchte man nichtmal für den Baum RAM, denn den kann man, da nach der Kompression der Waveform bereits bekannt, natürlich ebenfalls in den Flash packen und zwar sinnvollerweise gleich in direkt benutzbarer Form.
naja, ein fixer Baum ist sicherlich auch eine Option, aber nach Lektüre des Threads bin ich innerlich zu dem Schluss gekommen, dass die Kurven austauschbar sein müssen. Ansonsten hast du natürlich recht, wenn die Daten im Flash sind, kann man den passenden Baum auch in passender Form im Flash ablegen.
Puh, jetzt bin ich durch durch den Thread. Sooo viel Theorie. Manches hab ich sogar verstanden. ;-) Trotzdem scheint mir die Aufgabenstellung eher einfach zu sein: Ein analoges Signal, das sich ca. alle 5s wiederholt, wird per PWM über einen Tiefpass ausgegeben. Eckdaten: - Genauigkeit der Auslenkung z.B. 200 Stufen (viel besser als 5%) - Signaländerung stufenweise, z.B. alle 5ms Bei einem Signal, das sich alle 5 Sekunden wiederholt, braucht man somit 1000 Bytes Flash-Speicher. Als Mikrocontroller tuts ein Billigteil wie z.B. der ATtiny85. Es gibt in dieser Gewichtsklasse aber eine ganze Reihe anderer, auch Nicht-AVR. Bei 20 MHz Takt kommt man auf eine PWM-Frequenz von 100 kHz. Das reicht locker, um die Glättung gut hinzubekommen. Wenn ich das Datenblatt richtig verstehe, lässt sich die Frequenz des PWM-Signals sogar bis 320 kHz erhöhen (interner asynchroner 64-kHz-Takt). Inklusive Programm kriegt man in einem ATtiny85 etwa 6 bis 7 Kurven unter. Das reicht vermutlich für den Anwendungsfall. Oder hab ich etwas übersehen?
@ Markus Weber (Firma: guloshop.de) (m-w) >Puh, jetzt bin ich durch durch den Thread. Sooo viel Theorie. Manches >hab ich sogar verstanden. ;-) >Trotzdem scheint mir die Aufgabenstellung eher einfach zu sein: Bist du der OP? >Ein analoges Signal, das sich ca. alle 5s wiederholt, wird per PWM über >einen Tiefpass ausgegeben. Eckdaten: >- Genauigkeit der Auslenkung z.B. 200 Stufen (viel besser als 5%) >- Signaländerung stufenweise, z.B. alle 5ms >Bei einem Signal, das sich alle 5 Sekunden wiederholt, braucht man somit >1000 Bytes Flash-Speicher. Nett, dass diese Information sooo zeitig kommen. >Inklusive Programm kriegt man in einem ATtiny85 etwa 6 bis 7 Kurven >unter. Das reicht vermutlich für den Anwendungsfall. Scheint so.
Falk Brunner schrieb: > Bist du der OP? Nein, ich hab nur versucht, zwischen den Zeilen des Eröffnungsposts zu lesen. Ich weiß, das ist ein Wagnis. :-) > Nett, dass diese Information sooo zeitig kommen. War ironisch gemeint, oder? Sorry, wahrscheinlich hab ich im Thread dann doch einiges überlesen. Meine "Informationen" sollten auch nur einen Lösungsvorschlag darstellen. Einen, von dem ich meine, dass er irgendwie zum Problem passt.
Dann mal noch eine Idee... (zumindest für die regelmäßigen Signale) Die drei/vier Teile des Signals: - Low/Grundlinie - Anstieg/Abfall - High Alle sind mit Rauschen behaftet. D.h. es gäbe drei/vier Funktionen von denen zwei/drei u.U. hinreichend durch einfache Funktionen angenähert werden könnten und nur noch der High-Teil bspw. in einer LUT stehen müsste.
Arc Net schrieb: > Dann mal noch eine Idee... (zumindest für die regelmäßigen Signale) > Die drei/vier Teile des Signals: > - Low/Grundlinie > - Anstieg/Abfall > - High > > Alle sind mit Rauschen behaftet. > D.h. es gäbe drei/vier Funktionen von denen zwei/drei u.U. hinreichend > durch einfache Funktionen angenähert werden könnten und nur noch der > High-Teil bspw. in einer LUT stehen müsste. Endlich mal wieder wer der die Problematik verstanden hat :) Dein Vorschlag wäre also in einer LUT Werte zu speichern zwischen denen die Kurve durch verschiedene vordefinierte Funktionen realisiert wird? Das Problem ist nicht das ausgeben der Kurve! Es sollen lediglich 4 verschiedene Kurven abgelegt werden zwischen denen ich später wählen möchte. Keine Veränderung der Kurven zur Laufzeit. Für die immer wieder auf die Atmung los gehen ich lege 4 Atemprofile fest die ich durch Messreihen mehrer Probanden unter verschiedenen Belastungen ermittel aber das ist ein völlig anderes Thema.
Arc Net schrieb: > Die drei/vier Teile des Signals: > - Low/Grundlinie > - Anstieg/Abfall > - High Kann man so zerteilen, ja. Ist dann hilfreich, wenn der Flash-Speicher knapp wird. Ich vermute aber eher nicht, dass das passieren wird. > Alle sind mit Rauschen behaftet. Richtig. Aber das Rauschen beträgt weniger als 5 %, das heißt, man kann es ignorieren, denn vorgegeben war, dass 5 % Genauigkeit ausreichen. Kann aber sein, dass ich in dem langen Thread etwas überlesen oder falsch verstanden habe...
Uwe2 schrieb: > Der eine Mensch atmet flach der andere langsamer oder schneller, > größeres Lungenvolumen kleines Lungenvolumen mit Zwergfell oder ohne, > altersabhängig, aufgeregt nicht aufgeregt usw. > Da kann es keine Referenz geben mit der Verglichen wird ! > Ist ja als wenn du ne Formel für nen Känguru haben willst ! Absolut richtig. Der eine hat Asthma, der andere Hunger usw. Aber es geht hier um die eigentliche Aufgabe, wofür die ganze Threaddiskussion völlig unwichtig ist. Die eigentliche Frage wurde ja mehr als ausreichend beantwortet und ist vollständig gelöst. Sie stellt nur einen banalen Schnipsel des Gesamtprojektes dar. Dominik G. schrieb: > Es soll ein Gerät gebaut werden das die Menschliche Luge beim einatmen > simuliert um so ein Mundstück einer Pressluftatemflasche zu bedienen. > Momentan ist noch nicht klar wie das Gerät aussehen soll sondern es sind > nur Teilprobleme identifiziert worden und eines dieser Teilprobleme ist > es Referenzkurven auf dem µC zu hinterlegen. Wenn dort etwas mit der Kurve getestet wird, muß halt eine konstante Testumgebung stehen. Macht wohl sonst keinen Sinn, wenn sich so viele Parameter ändern. Und die Qualität dieser Kurve reicht dafür halt vollkommen aus, wenn sie der Realität halbwegs nahe kommt.
Dominik G. schrieb: > Endlich mal wieder wer der die Problematik verstanden hat :) Die Problematik haben wahrsheinlich alle hier verstanden. Das eigenliche Problem ist, dass du nur scheibchenweise mit unvollständigen Informationen rausrückst. Arcs Analyse der Kurven zB passt nur zu den eingangs von dir geposteten Bildern. das hier: Dominik G. schrieb: > P.s. ein Atemprofil könnte auch so aussehen gepostete passt schon wieder überhaupt nicht rein. Das es nur 4 Kurven sind kam auch erst im letzten Beitrag. Über Sampleauflösung und Samplerate, sowie Länge hast du dich auch trotz mehrfacher aufforderung nicht ausgelassen. Oder ob es reicht eine Periode zu speichern, oder ob so ein Profil zwingend aus mehreren bestehen muss. Wie wärs wenn du einfach mal ein paar Kurven als csv postest und dazu sagst, was davon Rauschen ist (oder das RAuschen am besten schon rausfilterst, so gut es geht) und was tatsächliche. Ich hab gestern spaßeshalber mal ein octavescript erzeugt, was irgendwas generiert, was ähnlich zu deinem ist, hatte dannach aber keine Lust mehr einen En/De-Coder zu bauen: (nur für den Fall, dass noch jemand spaß hat sich an der Kompression zu probieren)
1 | pkg load image % wird gebraucht für die Faltung |
2 | |
3 | phases = 50; % Anzahl zyklen potentiell unterschiedlicher Amplituden |
4 | samplesPerPhase = 200; % Anzahl Messwerte pro Zyklus |
5 | maxVal = 1000; % maximaler Messwert |
6 | preSmoothNoise = 100; % Veränderung der Kurve vor Glättung (soll schwankenden echten Wert simulieren) |
7 | postSmootNoise = 10; % Rauschen nach Glättung (soll Messrauschen simulieren) |
8 | smoothKernalLength = 51; % breite des Gauß-Glättungskernels |
9 | |
10 | % phasen bestimmen und Werte für Phasen generieren |
11 | T = round(rand(phases,1)).*(rand(phases,1)*.5 +.5); |
12 | D=0; |
13 | for i=1:phases |
14 | for j=1:samplesPerPhase |
15 | D( (i-1)*samplesPerPhase+j,1) = T(i) * maxVal + (rand()-.5)*preSmoothNoise*2; |
16 | end
|
17 | end
|
18 | |
19 | % Kurve glätten |
20 | K = fspecial("gaussian", [smoothKernalLength,1],smoothKernalLength/6); |
21 | D = conv(D, K, "same"); |
22 | |
23 | % Messrauschen hinzufügen |
24 | D = D + ((rand(phases*samplesPerPhase,1) -.5)* 2*postSmootNoise); |
25 | |
26 | D = D + abs(min(D)); % D in den kompletten positiven Bereich schieben |
27 | D = round(D); |
28 | plot(D); |
Vlad Tepesch schrieb: > Dominik G. schrieb: >> Endlich mal wieder wer der die Problematik verstanden hat :) > > Die Problematik haben wahrsheinlich alle hier verstanden. > Das eigenliche Problem ist, dass du nur scheibchenweise mit > unvollständigen Informationen rausrückst. Zumal sie ja anscheinend selber noch nicht wissen, was genau wie weiter gehen soll. Und wenn doch, sind sie die Einzigen, die es wissen (und auch wissen sollten). Die ganzen anderen Informationen und Randbedingungen kennt halt nur, wer involviert ist. Ich bin es nicht aber kann euch nur raten, sich auf die wesentlichen Dinge zu konzentrieren. Wer mit einer solchen Banalität so viel Zeit verschwendet, wird nie in Richtung eines Gesamtergebnisses kommen!
Also, aus meiner Sicht ist dieser Thread wieder ein typisches Beispiel für eine ungenaue Anfrage und viele Interpretationen und Spekulation über das was gemacht werden soll, was als Lösung gefordert sein könnte und wie die Eingangsvoraussetzungen sind. Gespickt wird das Ganze mit Erfahrungen und Lösungsvorlieben der am Thread beteiligten. Ich finde das teilweise sehr aufschlußreich, da man das Eine oder Andere aufschnappen kann was man noch nicht kennt ... ;-) Aus meiner Sicht gibt es einen entscheidenden Hinweis. Es geht wohl um einen Simulator für das Ausatmen zum bedienen eines Mundstückes einer Pressluftatemflasche. Dafür sind Stellglieder notwendig die einen Luftfluss steuern. Es gibt eine mechanische Strecke, die hier nicht berücksichtigt werden soll, die aber Erheblichen Einfluß auf die Funktion hat. Die gespeicherte Kurve hat unter Umständen nicht viel mit dem "Luftstrom-Profil" am Mundstück zu tun. Wenn meine Annahme bis hier hin stimmt dann würde ich das Sprungverhalten der "Steuerstrecke" bestimmen und damit das Verhalten der Strecke berechnen. Daraus ergibt sich das "Filterverhalten" der Strecke und damit auch die Signalart die der uC erzeugen muss um den Luftstrom zu erzeugen. Das Ergbnis dieses Signals kann sehr weit von dem geposteten Meßsignal abweichen! Vielleicht genügt ein Rechteckimpuls. Vielleicht eine Rampe, das Ergebnis am Mundstück hängt halt von der Strecke ab. Aber auch ich habe jetzt viel Spekuliert ... ob es weiter hilft, wer weis ... auf jeden Fall wird der Thread länger ... ;-)
>aus meiner Sicht ist dieser Thread wieder ein typisches Beispiel
Solche Threads nenne ich "Sherlock Holmes Threads".
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.