Hallo zuisammen,
kennt jemand einen einfachen MP3 Decoder (Sourcecode) der möglichst
wenig Ressourcen braucht?
Ich muss einfach nur Wert für Wert in eine Schleife auslesen. Es reicht
wenn der Decoder nur eine Sampling Rate bzw. Bitrate beherrscht. Die
kann ich vorgeben.
Ich stelle mir das ungefähr so vor:
Andreas V. schrieb:> möglichst wenig Ressourcen
Worauf soll er denn laufen?
Du hast das in "PC-Programmierung" gepostet; welcher PC ist denn heute
noch so langsam, daß es auf "wenig Ressourcen" ankommt?
Es sollte nach Möglichkeit auf dem PC und auch auf einem Mikrocontroller
laufen. Ich will (Musik-)Daten übertragen und der Empfänger kann ein PC
oder auch ein Mikrocontroller sein.
Aha. Was für ein Microcontroller soll das sein? Es macht schon einen
Unterschied, ob man mp3 auf einem 32-Bit-Controller mit Speicher oder
einem 8-Bit-Controller mit (fast) keinem Speicher decodieren will.
Rufus Τ. F. schrieb:> Aha. Was für ein Microcontroller soll das sein? Es macht schon einen> Unterschied, ob man mp3 auf einem 32-Bit-Controller mit Speicher oder> einem 8-Bit-Controller mit (fast) keinem Speicher decodieren will.
Da habe ich mich noch nicht entschiedem. ;-)
Ein 8080 oder ein Highspeed Z80 vielleicht?
Beim Mikrocontroller dachte ich auch schon an einen Hardware-Decoder.
Für den Anfang habe ich schon mal eine Funktion gefunden.
Ein 80486 hat schon Problem das in Echtzeit zu machen.
(die c't hatte mal ein Hardwareprojekt dazu gemacht)
Kann auch sein, dass meine Erinnerung da völlig irre ist.
Dirk B. schrieb:> Ein 80486 hat schon Problem das in Echtzeit zu machen.> (die c't hatte mal ein Hardwareprojekt dazu gemacht)>> Kann auch sein, dass meine Erinnerung da völlig irre ist.
Vielleicht brauche ich das gar nicht in Echtzeit und will nur die Daten
lesen können.
Andreas V. schrieb:> Ein 8080 oder ein Highspeed Z80 vielleicht?
Das kannste knicken. Könnte bestenfalls bei "Speech"-Bit- und
Sampleraten funktionieren. Aber nichtmal das, wenn in C geschrieben.
Große Teile müssten in hochoptimiertem Assembler umgesetzt werden.
> Beim Mikrocontroller dachte ich auch schon an einen Hardware-Decoder.
Das war mal eine gute Idee. Heute nimmt man einfach einen hinreichend
leistungsfähigen µC.
> Für den Anfang habe ich schon mal eine Funktion gefunden.>
>> Die werde ich mal auf dem PC ausprobieren...
OMG
Du hast ja nicht den Hauch einer Andeutung einer Ahnung, was diese
Funktion alles tut...
Naja, auf jedem heute üblichen PC läuft's natürlich völlig problemlos...
:-)))
Ich wollte es ja auch erst einmal nur auf dem PC ausprobieren!
Mir ist schon klar dass da einiges an Mathematik dahintersteckt...
Huffmann-Codes/Tabellen, (Reverse-)FFT, Filter, CRC's, Codierungen ...
Zu den µP: Das war schon klar. Ich wollte halt nicht gleich mit
TI-Prozessoren anfangen. Allerdings komme ich wegen des Stromverbrauchs
immer wieder dort hin, weil meine Geräte nicht die Batterien leerziehen
sollen.
Inzwischen bin ich mir nicht mehr so sicher ob das mit mp3 so eine gute
Idee war. Ich habe den Aspekt mit den Lizenzen nicht beachtet...
Andreas V. schrieb:> Inzwischen bin ich mir nicht mehr so sicher ob das mit mp3 so eine gute> Idee war. Ich habe den Aspekt mit den Lizenzen nicht beachtet...
Dicke SDHC Karte kostet wenig und kann unkomprimierten Sound stundenlang
speichern.
Dürfte energieeffizienter sein als MP3 Dekodierung, wenn man keine
spezialisierte Hardware einsetzen will.
rbx schrieb:> und ich nehme an,> Beitrag "Software MP3 decoder for ATmega/ATxmega"> hast du dir schon angesehen?
Danke! Den Artikel hatte ich nicht gefunden. Das beantwortet die meisten
Fragen!
mind. 8K RAM, 45kb flash, ein Kanal...
Ich denke MP3 kann ich dann als Übertragungsformat vergessen, aber die
Huffmann-Tabellen könnten funktionieren...
Dirk B. schrieb:> Ein 80486 hat schon Problem das in Echtzeit zu machen.
Daran erinnere ich mich noch sehr sehr gut. MP3 war hip und in und ich
wollte mir damals einen MP3 Player für die Stereoanlage bauen.
Hatte ich auch gemacht gehabt und das Minimumsystem das MP3 gerade noch
so konnte war ein 486DX2/66. Das ging unter DOS noch gerade so.
DOS-Programm hatte sogar eine "Schnittstelle" zu einem Textdisplay das
über den Druckerport angeschlossen werden konnte und über den Tasten
eingelesen wurden um den Player zu steuern. Im Bios mußte eingestellt
sein, dass der Rechner trotz nicht angeschlossener Tastatur bootet.
Das Ding war dennoch häßlich: ich hatte in das Gehäuse ein
Floppylaufwerk eingebaut (fest) von dem DOS 6.22 gebootet wurde, ein
altes (Single-Speed) CD-ROM war nach aussen gelegt.
Wie gesagt, der Kasten war groß, häßlich und das Teil mußte von Diskette
gebootet werden (was dauerte).
Später gabs dann eine reine Hardwarelösung mit MP3 Dekoder.
Um MP3 in Software zu dekodieren mutmaße ich dass es min. eines Cortex
M4 bedarf (und dann wohl nicht der kleinste).
Eventuell geht ja das China Blackboard mit STM32F407 ?!?
Mit Z80 oder 8080/8085 garantiert nicht !
Jim M. schrieb:> Dicke SDHC Karte kostet wenig und kann unkomprimierten Sound stundenlang> speichern.>> Dürfte energieeffizienter sein als MP3 Dekodierung, wenn man keine> spezialisierte Hardware einsetzen will.
Das war auch mein Gedanke eine 64GB SD oder ähnliches zu verwenden.
Allerdings gibt's da enorme Unterschiede beim Stromverbrauch.
Ich glaube da muss ich mal die Kreditkarte einbacken, zum roten Markt
fahren und shoppen gehen...
Ich habe das mal gemacht, mit einem PIC32MX470, mit 80MHz. Die brauchte
er auch, weil er nicht nur decodieren muss, sondern auch die Samples
rausschreiben, mit FATFS die SD-Karte lesen, ein User interface
bedienen, ein GLCD betreiben, USB bespassen, einen I2S permanent füttern
und so weiter.
Trotzdem, das decodieren ist die Hauptarbeit.
Ich habe jenen Codec verwendet:
https://www.microchip.com/SWLibraryWeb/product.aspx?product=Helix%20MP3%20Decoder%20Library
Da ist nicht nur Code dabei, sondern auch eine gute Beschreibung dazu.
Das ist ein richtiger Codec, kein kastrierter. Der spielt alle mp3s.
Die Widergabe ist dafür etwas komplexer als man sich das zunächst
vorstellt. Der Codec frisst nämlich nicht einfach nur die Daten.
Du darfst zunächst mal die gültigen Frameheader suchen, die zahlreichen
Fehler behandeln und so weiter.
Der Helix werkelt nicht nur am µC sondern auch im PC.
Streaming ist mit mp3 sehr gut machbar, auch mit dem Codec. Du musst ihn
ja nur mit frames füttern, und wo die herkommen ist egal.
Andreas V. schrieb:> Was meinst Du damit?
Das ist ein STM32 Fanboy. Die olle "der STM32 ist das Beste auf der
Welt, und alle müssen das nutzen sonst blöke ich 100 mal" Leier. Es
nervt.
Wobei man das Probelm selbstverständlich auch mit einem STM32 lösen
kann. Schließlich gibt es natürlich auch für ARMs MP3-Decoder.
Beispiel:
https://static.docs.arm.com/dui0121/b/DUI0121B_mp3_v1_pg.pdf
Ich vermute mal, mp3 decoieren geht mit jedem halbwegs flotten 32-Bit µC
recht gut.
Man kann vermutlich auch 16 oder 8-Bitter verwenden, was mit nicht
unerheblichen Klimmzügen verbunden sein dürfte.
Ralph S. schrieb:> Um MP3 in Software zu dekodieren mutmaße ich dass es min. eines Cortex> M4 bedarf (und dann wohl nicht der kleinste).
Wir setzen einen (Assembler-)optimierten MP3-Decoder ein. Der braucht
(je nach Bitrate) auf einem 168MHz-M3 keine 20% Rechenleistung, auf
einem M4 kommt der auf 10%.
> Eventuell geht ja das China Blackboard mit STM32F407 ?!?
Mit Sicherheit. Wie geschrieben, ist da noch ohne Ende Rechenleistung
für andere Dinge übrig, wenn man den M4 richtig ausnutzt und die
Software intelligent schreibt (Loop Unrolling, SIMD).
soso... schrieb:> Das ist ein STM32 Fanboy. Die olle "der STM32 ist das Beste auf der> Welt, und alle müssen das nutzen sonst blöke ich 100 mal" Leier. Es> nervt.
... bin ich nicht, ich nutze auch AVR, STM8, ESP8266 und manchmal sogar
noch MCS51.
soso... schrieb:> Ich vermute mal, mp3 decoieren geht mit jedem halbwegs flotten 32-Bit µC> recht gut.
Stimmt, allerdings ist glaube ich, ist das Blackboard wohl das Board mit
dem besten Verhältnis von Preis zu Rechenleistung.
soso... schrieb:> Die olle "der STM32 ist das Beste auf der > Welt, und alle müssen das nutzen
Falsch, die Wahl des Controllers richtet sich nach der Aufgabenstellung.
Ein MP3 Player kann auch mit einem ESP8266 sehr gut realisiert werden.
Von daher gilt für mich: den besten Mikrocontroller (der Welt) gibt es
nicht.
Ralph S. schrieb:> Stimmt, allerdings ist glaube ich, ist das Blackboard wohl das Board mit> dem besten Verhältnis von Preis zu Rechenleistung.
Das man mit einem fertigen Board auskommt, glaube ich nicht, weil der
Teufel im Detail steckt.
Erst mal brauchts einen I2S-DAC. Aus dem DAC des STM32 kommt aus
Telefonqualität, höchstens. Das hat nichts mit dem DAC an sich zu tun,
aber 12Bit sind für Audio zu wenig.
Dann brauchts für I2S einen speziellen Takt. Entweder man lässt das
System auf einem I2S-kompatiblen Takt laufen (dann: Tschüss, USB), oder
man nimmt einen sehr speziellen DAC mit PLL (UDA1334ATS zum Beispiel).
Dann braucht man auch mit einem fertigen Digitalboard gar nicht
anzufangen, sonst hört man im Hintergrund den STM32-Task im Kopfhörer.
Da brauchts ein sauberes Stromversorgungssystem und Layout.
All das wird man auf einem fertigen Board in der Form nicht finden.
Rufus Τ. F. schrieb:> Mal eine Frage an den Threadstarter:>> Welches eigentliche Problem willst Du mit der mp3-Decodierung lösen?
Danke der Nachfrage!
Ich will die Datenrate über einen grottigen Kanal (der auch ausfallen
kann) um das 10-fache erhöhen. Der Empfänger wäre in der Regel ein PC.
Außerdem könnte man auf dem Sender Speicherplatz sparen. Aber so wie ich
das momentan sehe geht das einfach zu sehr auf die Batterie des Senders.
Die Genauigkeit sollte ausreichen.
Andreas V. schrieb:> Ich will die Datenrate über einen grottigen Kanal (der auch ausfallen> kann) um das 10-fache erhöhen.
Die Datenrate von Audiodaten?
Oder willst Du irgendwelche beliebigen Analogdaten damit "komprimieren"?
Andreas V. schrieb:> Ich will die Datenrate über einen grottigen Kanal (der auch ausfallen> kann) um das 10-fache erhöhen. Der Empfänger wäre in der Regel ein PC.> Außerdem könnte man auf dem Sender Speicherplatz sparen. Aber so wie ich> das momentan sehe geht das einfach zu sehr auf die Batterie des Senders.> Die Genauigkeit sollte ausreichen.
Das heißt, du willst auf dem "kleinen Device" ENCODIEREN, der PC muss
decodieren korrekt?
Encodieren ist schon ein etwas anderes Kapitel, als decodieren, denn es
ist viel rechenaufwändiger.
Man liest, dass dazu ein 32-Bitter mit min. 300-500MHz nötig sein
soll.Das ist keine Aufgabe für einen µC mehr, sondern da muss was
dickeres ran, oder Hardware.
Wie das:
http://www.vlsi.fi/en/products/vs1063.html
Willst du nur (im Speicher liegende) wave-Samples encodieren, sieht die
Sache möglicherweise anders aus, dann kannst du den µC ja rödeln lassen.
Ich weiß aber nicht, ob du eine Referenzimplementierung für encodieren
finden musst.
Ich hatte vor Urzeiten einen MP3-Player auf einen 486 mit 100 MHz
laufen.
Die Rechenelsitung reichte.
Aber für Z80 etc sehe ich schwarz, denn die Encoder brauchen einiges an
Ram.
1 Sekunde Musik, die zwischengespeichert wird, braucht 176 KBytes
Buffer. Das geht nicht mit den kleinen 8-Bittern.
Unter 1MByte würde ich nicht anfangen. Da sind mehrere Threads
(Lesen/Decoden/Ausgeben) Und alle brauchen ihre Buffer, meist als
Doppelbuffer.
Rufus Τ. F. schrieb:> Die Datenrate von Audiodaten?>> Oder willst Du irgendwelche beliebigen Analogdaten damit "komprimieren"?
Daten sind Daten. Im konkreten Fall wären das sich langsam ändernde
Messwerte. Der Kanal hat zwischen 100kBit bis 400kBit. Wenn man die
Daten vorkomprimiert dann sollte man bei erfolgter Verbindung mind. 1-2
MBit Daten übertragen können. Ich dachte da gibt es inzwischen
billigere(/bessere) (Hardware-)mp3-Decoder.
Aber da gibt es ja noch andere Kompressionsverfahren...
Andreas V. schrieb:> Daten sind Daten
Du irrst.
Mp3 ist extra dafür definiert für Menschen gedachte Audiosignale so zu
komprimieren, dass der Informationsverlust dem menschlichen Gehör nicht
auffällt. (--> Psychoakustik)
Du kannst da also nicht beliebige Daten in einen Mp3-encoder reinstopfen
und erwarten, dass am Ende was kleineres rauskommt und nach der
Dekompression wieder so aussieht wie vorher.
Überlege dir, welchen Wertebereich deine Messwerte haben und in welcher
Auflösung du sie brauchst (eventuell auch abhängig vom Bereich) und
rechne die Samples entsprechend um. Wenn in deinem Signal dann wirklich
nur noch die Daten drin stecken, die du auf der Gegenseite brauchst,
kannst du noch eine Entropie-Kodierung machen, oder Differenzwerte
übertragen, wenn sich nur wenig ändert.
Vlad T. schrieb:> Du irrst.> Mp3 ist extra dafür definiert für Menschen gedachte Audiosignale so zu> komprimieren, dass der Informationsverlust dem menschlichen Gehör nicht> auffällt.>> Du kannst da also nicht beliebige Daten reinstopfen und hoffen, dass am> Ende was kleineres rauskommt und nach der Dekompression wieder so> aussieht wie vorher.
Es geht mir ja auch um die Kurve. Wenn ich eine Sinuskurve von 300 Hz
eingebe, dann kommt annähernd eine Sinuskurve von 300Hz heraus. Der
(gewünschte) Nebeneffekt ist dass abweichende Peaks herausgefiltert
werden. Wenn ich jetzt die Periodenlänge um das Tausendfache
zusammenstauche bei entsprechender Abtastrate ist das genau das was ich
will. Und nach der Übertragung mache ich den Prozess rückgängig...
Andreas V. schrieb:> Wenn ich eine Sinuskurve von 300 Hz eingebe, dann kommt annähernd eine> Sinuskurve von 300Hz heraus.
Ja, wenn das eine Sinuskurve ist, dann mag das noch funktionieren. Aber
Du wirst sicherlich nichts so langweiliges wie eine Sinuskurve messen
wollen.
> Der (gewünschte) Nebeneffekt ist dass abweichende Peaks herausgefiltert> werden.
Das aber passiert nicht; die "abweichenden Peaks" können je nachdem, wie
sie im psychoakustischen Modell bewertet werden, eine komplett andere
und für Deine Messwerte stark störende Auswirkung haben.
Andreas V. schrieb:> Aber da gibt es ja noch andere Kompressionsverfahren...
Das erinnert mich ein wenig an ein alternatives Sampler OS für den TX16W
von Yamaha (Motorola 68000, 12 Bit Sampling).
http://nuedge.net/typhoon2000/WhatIsTyphoon.htm
Das bot "Audio file compression" mit an, ein recht praktisches Feature.
Rufus Τ. F. schrieb:> Das aber passiert nicht; die "abweichenden Peaks" können je nachdem, wie> sie im psychoakustischen Modell bewertet werden, eine komplett andere> und für Deine Messwerte stark störende Auswirkung haben.
Peaks sind nicht harmonisch. Sie sollten immer herausgefiltert werden,
wenn das Modell halbwegs angepasst ist. mp3 macht aus einer exp-Kurve
keine Dreieckfunktion. Wenn ich eine Einschwingkurve habe sollte es auch
passen. Wie das im Einzelnen hineinschlägt muss man natürlich prüfen!!!
In der Praxis wird so etwas öfter gemacht. GPS und medizinische Geräte
fallen mir da ein.
Wenn man etwas nicht ausprobiert weiß man nicht ob es funktioniert
hätte!
Andreas V. schrieb:> Wenn ich jetzt die Periodenlänge um das Tausendfache> zusammenstauche bei entsprechender Abtastrate ist das genau das was ich> will. Und nach der Übertragung mache ich den Prozess rückgängig...
Abgesehen von deiner Salami-Taktik hast du offenbar nicht gelesen oder
verstanden, was in den ganzen Posts weiter oben steht.
Wie Vlad T. schon schrieb, basiert MP3 u. a. darauf, für das menschliche
Ohr unhörbare Teile eines Audio-Spektrums herauszufiltern. Wenn du jetzt
ein 300Hz-Sinus um den Faktor 1000 zusammenstauchst, hast du rechnerisch
einen Sinus mit 300kHz. Was glaubst du, was dein MP3-Encoder macht? Der
schmeißt deinen 300kHz-Sinus eiskalt raus. Damit wird dein ach so tolles
Signal zur Nulllinie...
Andreas V. schrieb:> Wenn man etwas nicht ausprobiert weiß man nicht ob es funktioniert> hätte!
Um das auszuprobieren, kannst du aber einfach irgendwelche quelloffenen
Encoder/Decoder (LAME) auf einem PC laufen lassen. Da kannst du auch
gleich noch Ogg Vorbis mit testen.
Jörg W. schrieb:> Um das auszuprobieren, kannst du aber einfach irgendwelche quelloffenen> Encoder/Decoder (LAME) auf einem PC laufen lassen. Da kannst du auch> gleich noch Ogg Vorbis mit testen.
Das was ich bislang per Programm als WAV codiert hatte sah als analoge
mp3-Ausgabe auch so aus. Ausnahme sind Rechtecksignale. Da gab es wie
erwartet Peaks. Rechtecksignale bestehen aus sehr vielen Sinuswellen und
sind nicht harmonisch. Rechteckkurven erwarte ich nicht bei langsam
ändernden Werten.
Hallo
Andreas V. schrieb:> Das was ich bislang per Programm als WAV codiert hatte sah als analoge> mp3-Ausgabe auch so aus. Ausnahme sind Rechtecksignale. Da gab es wie
Mp3 ist ein Verfahren, bei dessen Anwendung die Kodierung deutlich mehr
kostet als die Dekodierung. Also eigentlich genau das, was Du nicht
willst, wenn die Hardware des Senders leistungsschwach ist im Vergleich
zum Empfänger.
> erwartet Peaks. Rechtecksignale bestehen aus sehr vielen Sinuswellen und> sind nicht harmonisch. Rechteckkurven erwarte ich nicht bei langsam> ändernden Werten.
Was immer auch langsam ist. Wenn man eh schon ein bestimmtes Verhalten
der Meßwerte erwarte, dann sollte dieses Wissen halt eben auch in den
Algorithmus mit einfließen.
MfG
Vlad T. schrieb:> Du irrst.> Mp3 ist extra dafür definiert für Menschen gedachte Audiosignale so zu> komprimieren, dass der Informationsverlust dem menschlichen Gehör nicht> auffällt. (--> Psychoakustik)
Exakt. Mp3 hat genau einen einzigen Zweck - Audio zu komprimieren.
Das, und dazu der Umstand, dass das Encodieren ein Mörderaufwand ist,
machen mp3 für die Anwendung einen absoluten Fehlgriff.
Und darum wäre es nett gewesen, hätte er die Anwendung gleich genannt!
Ich würde mich bei "lossles" Formaten umsehen. gzip zum Beispiel. lässt
sich auch auf dem µC gut umsetzen. Wenn im Signal viele gleiche Werte
vorkommen, bricht das schnell auf wenige Bytes zusammen.
Wahrscheinlich ist es noch viel einfacher. Einfach die Bandbreite
runterschrauben und seltener Werte senden.
Also Leuts es funzt schon. Es gibt bei der Sache nur ein Problem. Und
das ist die Kompressionsrate. Da hätte ich mir mehr erwartet.
Kompressionsfaktor: 4
Schade! Jetzt versuch ich es mit bzip2 und einem nachgeschaltetem
Filter.
Danke an Alle! Ich habe trotzdem viel gelernt.
wenn du ein Sinussignal übertragen willst, kannst du das ganz gut
komprimieren: es reichen 3 Parameter - Frequenz, Phase und Amplitude
Mach auf deinem Controller eine FFT mit für deine
Auflösungsanforderungen geeigneter Breite und bestimme die Parameter auf
dem Controller und übertrage nur die.
Vielleicht schilderst du aber auch erstmal dein genaues Problem, um auf
das Grundproblem dieses Threads - die Salamitaktik - zurückzukommen.
Dann kann man vielleicht ein paar hilfreichere Stichpunkte geben.
Vlad T. schrieb:> Vielleicht schilderst du aber auch erstmal dein genaues Problem, um auf> das Grundproblem dieses Threads - die Salamitaktik - zurückzukommen.
Ich weiß nicht ob dass nur mein Problem ist. Was mich nervt ist das
permanente "Best Case" Denken. Vielleicht passe ich auch nicht in diese
Zeit oder ich lebe in der falschen Dimension...
Jeder redet von Nachhaltigkeit. Was ich sehe sind Rauchmelder,
Körperwagen, Uhren, Wetterstationen, Küchenwaagen usw. die regelmäßig
leere Batterien haben. Am besten schließt man ein Atomkraftwerk direkt
an. Das ist nicht nur nervig, sondern auch genau das Gegenteil von dem
was man redet. Aber was interessiert mich mein Geschwätz von gestern,
wenn ich die Produkte verkauft habe...
Was mich auch stört ist die schlechte Bedienbarkeit der meisten Geräte.
Ich denke da speziell an TV's. Da sieht man oft dass keine Zeit da war
etwas zu Ende zu bringen. Am besten man kauft sich nach zwei Jahren ein
neues nerviges Gerät.
Was ich auch schon oft gefunden habe waren Software und Treiber die
niemand hinterfragt und sie benutzt weil sie funktionieren und die ganze
Hardware auf Trapp halten. Also nimmt man "mehr Hardware"!
Ich bin der Meinung dass eine Batterie (besser Akku) unter Realbedingung
5-10 Jahre halten sollte bis das Gerät nicht mehr arbeitet. Andere
Geräte dürften erst gar nicht zugelassen werden.
Die meisten Geräte arbeiten mit der Leistung eines PC's vor 25 Jahren
und leisten fast gar nichts. Aber sie könnten ja was leisten und ziehen
die Batterie leer. Richtige Auslegung der Komponenten wäre sinnvoller.
Die meisten Geräte sind spezialisiert auf eine Anwendung und nur
kompatibel zu sich selbst.
Was mich ärgert sind Messerfassungssysteme die zu teuer und schlecht zu
bedienen sind.
Meine Konsequenz daraus:
Ich bin gerade dabei ein Modul zur Messerfassung zu bauen dass über
grottenschlechte Verbindungen (z.B. 100 kBit) Daten über mehrere
Kilometer versenden kann und trotzdem performant ist. Die Daten sollen
sicher über eine kompatible Schnittstelle übertragen werden und
automatisiert auf dem PC abgespeichert werden. Dabei dürfen keine Daten
durch Ausfall der Funkstrecke verloren gehen. Der Akku soll 10 Jahre
halten. Das Teil muss so richtig billig sein! Mein Ziel: Einkaufspreis
unter 10€.
Anwendungsfall:
unendlich viele...
Bevor jetzt jemand anfängt zu lästern: Ja, das ist möglich!
Der wesentliche Teil, den Du noch nicht erwähnt hast, ist die
Datenmenge, die Dein System speichern und übertragen soll.
Vielleicht machst Du Dir in all Deiner Mühe, "nachhaltig" zu arbeiten,
unnötig Sorgen an Stellen, die gar nicht das eigentliche Problem sind
...
Andersrum gefragt:
Wie hoch sind die Anzahl der Kanäle, die Auflösung pro Kanal und die
Abtastrate, und wie lange soll die Vorhaltezeit der Daten ohne
Verbindung zu einem PC sein?
Rufus Τ. F. schrieb:> Wie hoch sind die Anzahl der Kanäle, die Auflösung pro Kanal und die> Abtastrate, und wie lange soll die Vorhaltezeit der Daten ohne> Verbindung zu einem PC sein?
16 Bit, 2-4 Kanäle, erst einmal je 1 Sample/s
Vorhaltezeit je nach Anzahl der Kanäle (Art der
Medianbildung/Durchschnittswertbildung) 9h bis einige Tage/Monate
FYI: Die meisten SD-Karten ziehen zu viel Strom!
Das müsste für viele Anwendungsfälle reichen.
"Ich weiß nicht ob dass nur mein Problem ist. Was mich nervt ist das
permanente "Best Case" Denken. Vielleicht passe ich auch nicht in diese
Zeit oder ich lebe in der falschen Dimension..."
Jup...wie immmer hier..eine simple Frage endet in einer unendlichen
Diskussion.
Was an seiner absolut simplen Frage so schwer zu verstehen ist, verstehe
ich nicht....
Was soll IMMER und IMMER wieder die Frage nach dem Controller?!
Diese Frage ist absolut NICHT relevant..
die Frage lautet
"kennt jemand einen einfachen MP3 Decoder (Sourcecode) der möglichst
wenig Ressourcen braucht?"
Dabei spielt der Controller und die Bidratene tc absolut KEINE Rolle!!
Es geht darum einen MP3 Decoder zu finden der möglichst weniger ...es
ist nicht mal möglich das noch prägnanter zusammenzufassen!!
Also noch detailierter und auf den Punkt KANN man diese Frag gar nicht
stellen dennoch kommen etliche Diskussionen, die man schon gar nicht
mehr liest...weil völlig am Thema vorbei.
"Thema verfehlt" hieß es in der Schule
Thomas M. schrieb:> Was soll IMMER und IMMER wieder die Frage nach dem Controller?!> Diese Frage ist absolut NICHT relevant..
Offensichtlich ist die Frage überaus relevant, weil sich dadurch erst
herausgestellt hat, wie morsch der Holzweg ist, auf dem der
Threadstarter sich da verrannt hat.
Andreas V. schrieb:> 16 Bit, 2-4 Kanäle, erst einmal je 1 Sample/s
D.h. knapp 700 kByte pro Tag in unkomprimierter Rohfassung.
Hast Du Dir als Kompressionsverfahren schon mal ADPCM angesehen?
und Du kapierst nicht wie Du dich in einem Forum als Mod verhalten
sollst um nicht ständig den Streit anzuheizen!
Anstatt das einfach so stehen zu lassen und mit gutem Beispiel als Mod
voranzugehen kommt wieder ein Kommentar der Stimmung macht!
Lass es doch jetzt einfach so stehen, das und lass die anderen user über
+- entscheiden bzw mich mit - abzustrafen!..
Thomas M. schrieb:> und Du kapierst nicht wie Du dich in einem Forum als Mod verhalten> sollst um nicht ständig den Streit anzuheizen!
Den suchst hier nur Du.
Leute, ich hätte den Thread auch schon geschlossen, weil ich inzwischen
gewohnt bin nach Tickets zu arbeiten.
Was da auf der Strecke bleibt ist die Innovation.
Neue Ideen ergeben sich indem man unproduktiv in eine Sackgasse läuft
und dann in die nächste bis man den richtigen Weg findet. So besteigt
man einen Berg. Oder man fragt einen Bergführer oder findet den Weg
zusammen heraus. Und so wurden die heute alltäglichsten Geräte wie
Fernseher, Radio, Computer, Dieselmotor, usw... umgesetzt (ohne mich mit
den Erfindern vergleichen zu wollen).
Wie soll man Herangehensweisen verbessern wenn man nicht ständig
hinterfragt was nicht so gut läuft. Oft kennt man sich mit einem Thema
nicht aus. Dann fragt man oder vergräbt sich für Monate in seinem
Stübchen. Entgegen der meisten Meinungen hatte ich ja eine Lösung, aber
die Kompression war halt nicht so gut.
Ja es ist manchmal nicht so strukturiert hier im Forum, aber vielleicht
ist das ja auch eine Stärke! Entgegen dem allgemeinen Trend interessiert
man sich hier für die Hintergründe. Das kostet viel Mühe und die sollte
man nicht schelten!!!
Ist dir klar, dass das mp3-Format nie dazu gedacht war MESSWERTE zu
encodieren?
Es ist verlustbehaftet Verfahren.
Jede verlustbehaftete Kompression verzichtet auf einen Anteil im Signal
zugunsten der Datenmenge. Und worauf wurde mp3 optimiert? Auf die
Psychologie des Menschen, nicht auf Genauigkeit. Die ist total wurscht
für Musik.
Es ist daher - und wegen des asymmetrischen Aufwandes der Kompression -
KEIN geeigntes Verfahren um Messwerte zu komprimieren.
Da gibt es andere. Ich würde mir halt erst mal die klassichen wie zip
ansehen, und prüfen, wie gut das auf die Anwendung passt. Es gibt sie in
vielerlei Spielart.
Es gibt sicher auch verlustbehaftete Verfahren, die sich besser eignen.
Eines wäre einfach eine Reduktion der Bandbreite.
Andreas V. schrieb:> Was da auf der Strecke bleibt ist die Innovation.
Innovation ist keine Ausrede, sich in undurchdachte Schnellschüsse zu
verrennen. Außerdem - mp3 ist weder innovativ, noch ist es die
Datenkompression von Messergebnissen.
Hallo
Andreas V. schrieb:> Jeder redet von Nachhaltigkeit. Was ich sehe sind Rauchmelder,> Körperwagen, Uhren, Wetterstationen, Küchenwaagen usw. die regelmäßig> leere Batterien haben. Am besten schließt man ein Atomkraftwerk direkt
Man braucht nur die Batterie dick genug machen :-) Ist auch nicht so,
daß alle Entwickler doof wären. Es gibt oft gute Gründe, bestimmte
Batterien zu nehmen. Z.B. Küchenwaage: Klar, könnte man statt einer
CR2032, die nach ein paar Jahren leer ist, zwei AAA-Zellen nehmen. Dann
halten die im Zweifel aber solange, bis die Batterien auslaufen. Sehe
ich bei der Verwandschaft leider viel zu häufig.
Und da Du von Nachhaltigkeit schreibst: Meßdaten mit einem Rechenzeit
und damit Energie fressenden MP3-Algorithmus aufzuarbeiten ist bestimmt
nicht nachhaltig.
Andreas V. schrieb:> Ich bin gerade dabei ein Modul zur Messerfassung zu bauen dass über> grottenschlechte Verbindungen (z.B. 100 kBit) Daten über mehrere> Kilometer versenden kann und trotzdem performant ist. Die Daten sollen> sicher über eine kompatible Schnittstelle übertragen werden und> automatisiert auf dem PC abgespeichert werden. Dabei dürfen keine Daten> durch Ausfall der Funkstrecke verloren gehen. Der Akku soll 10 Jahre> halten. Das Teil muss so richtig billig sein! Mein Ziel: Einkaufspreis> unter 10€.>> Anwendungsfall:> unendlich viele...>> Bevor jetzt jemand anfängt zu lästern: Ja, das ist möglich!
Möglich mag das sein. Dann aber bitte mit an das jeweilige Meßproblem
angepaßten Algorithmus. Es wird je nach anfallenden Daten nicht den
Kompressionsalgorithmus geben. Kompression kostet genauso Energie wie
Funkübertrageung. Je nach Daten(anfall) kann es günstiger sein,
unkomprimiert oder stark komprimiert zu Übertragen.
Thomas M. schrieb:> Jup...wie immmer hier..eine simple Frage endet in einer unendlichen> Diskussion.> Was an seiner absolut simplen Frage so schwer zu verstehen ist, verstehe> ich nicht....
Immerhin scheint die Frage so einfach zu sein, daß Du zwar viel
schreibst aber keine Antwort lieferst.
Andreas V. schrieb:> Leute, ich hätte den Thread auch schon geschlossen, weil ich inzwischen> gewohnt bin nach Tickets zu arbeiten.
Ähm, findest Du das nicht seltsam, kostenlosen Support einzufordern und
wenn's Dir nicht paßt, abzubrechen zu wollen?
> Was da auf der Strecke bleibt ist die Innovation.>> Neue Ideen ergeben sich indem man unproduktiv in eine Sackgasse läuft> und dann in die nächste bis man den richtigen Weg findet. So besteigt> man einen Berg. Oder man fragt einen Bergführer oder findet den Weg> zusammen heraus. Und so wurden die heute alltäglichsten Geräte wie> Fernseher, Radio, Computer, Dieselmotor, usw... umgesetzt (ohne mich mit> den Erfindern vergleichen zu wollen).
Jeder, der einen Berg besteigen will, muß sich die Grundlagen, z.B.
Kondition, Verhalten usw, draufschaffen. Jeder der Erfinder o.g. Geräte
hat das auch getan.
War es nicht Edison, der meint das Genie zu 1% aus Inspiration und 99%
Transpiration (also Arbeit) besteht?
MfG
Andreas V. schrieb:> Rufus Τ. F. schrieb:>> Wie hoch sind die Anzahl der Kanäle, die Auflösung pro Kanal und die>> Abtastrate, und wie lange soll die Vorhaltezeit der Daten ohne>> Verbindung zu einem PC sein?>> 16 Bit, 2-4 Kanäle, erst einmal je 1 Sample/s>> Vorhaltezeit je nach Anzahl der Kanäle (Art der> Medianbildung/Durchschnittswertbildung) 9h bis einige Tage/Monate> FYI: Die meisten SD-Karten ziehen zu viel Strom!>> Das müsste für viele Anwendungsfälle reichen.
Und was willst Du da mit MP3-Kompression?
Es gilt wie immer: Beschreibe nicht Deinen Lösungsansatz, sondern
beschreibe das eigentliche Problem.
Rufus Τ. F. schrieb:> Und, hast Du Dir jetzt mal ADPCM angesehen?
Sorry, es hat ein bissl gedauert: Ja, ich habe es mir angesehen!
Das ist ein skalierbares, verlustbehaftetes Verfahren zur
Datenkompression mit Vorhersagefunktion. Es beinhaltet also auch einen
Filter.
Nach kurzer Einschwingphase geht die Fehlerquote von 100% auf unter ein
Prozent zurück.
Bei 2000 Werten kommt der Algorithmus zu sehr genauen Werten.
=> siehe Bild
Ich legte die Orignialkurve noch einmal mit Offset 500 an, weil man die
erste Kurve durch die dekomprimierten Werte überschrieben wurde.
Andreas V. schrieb:> kennt jemand einen einfachen MP3 Decoder (Sourcecode) der möglichst> wenig Ressourcen braucht?
"DF-Player mini". Kostet ca. 5-10 EUR und kann MP3 - auch verschiedene
Abtastraten. Lautsprecher-Verstärker ist auch schon dabei,
SD-Karteneinschub ebenso.
Das Ding kann man per (Soft-)UART auch mit jedem kleinen ATTiny steuern.
Rufus Τ. F. schrieb:> Das ist Sourcecode?
Nö ;-)
> Für mich riecht das sehr streng nach Hardware ...
Er schrieb ja später:
Andreas V. schrieb:> Beim Mikrocontroller dachte ich auch schon an einen Hardware-Decoder.
Daher wollte ich ihm nur eine weitere (bequemere) Option aufzeigen.
Ich dachte wir waren uns einig, dass MP3-Kompression hier nicht der
richtige Ansatz ist. Es geht eben nicht darum, Musik so zu
komprimieren dass sie für das menschliche Gehör immer noch gut klingt.
Und genau dafür ist MP3 bekanntlich entwickelt worden.
Leider ist dies ein Problem, das hier im Forum immer wieder auftaucht:
Der Themenersteller präsentiert nicht die eigentliche Aufgabe und sucht
nach einer Lösung, sondern er präsentiert einen bereits von ihm
gewählten Ansatz, der nur dummerweise nicht richtig zur Aufgabenstellung
passt.
Wenn ich einen Euro hätte für jedes Mal, wo das hier vorkommt... ich
müsste nie wieder arbeiten ;-)
> Ich dachte wir waren uns einig, dass MP3-Kompression hier nicht der> richtige Ansatz ist.
na offenbar nicht - dem TO ist ja aufgefallen, daß Fremdnutzung möglich
ist (siehe ADPCM.gif).
Seine Annahme der Zweckentfremdung ist also nicht ganz unberechtigt.
> Es geht eben nicht darum, Musik so zu> komprimieren dass sie für das menschliche Gehör immer noch gut klingt.> Und genau dafür ist MP3 bekanntlich entwickelt worden.
Das Einzige, was man ihm ankreiden kann, ist, daß er seine Abweichung
etwas spät erklärt. (Datum: 31.01.2019 19:45)
Das hätte ruhig etwas früher kommen können.
> Wenn ich einen Euro hätte für jedes Mal, wo das hier vorkommt... ich> müsste nie wieder arbeiten ;-)
Sei kreativ und schreib Dir ein Lottoprogramm :-)
Hallo zusammen,
ich bin jetzt ein Stück weiter gekommen.
Also ich habe jetzt einige Komprimierungs-Algorithmen durch.
- MP3 (braucht zu viele Ressourcen, benutzt aber Filter)
- ADPCM (ist machbar, funktioniert aber nur bei harmonischen
Schwingungen gut)
- BZIP2 (braucht zu viel Ressourcen, brachte mich aber auf Huffman
Codierung)
- Huffman Codierung (machbar, funktioniert nur bei sehr gleichen Daten
gut)
- LZW (Ich erinnerte mich an mein altes US-Robotics Modem, GIF und
v.42bis...)
=> Nachteil: 0 ist nicht zugelassen, weil Trennzeichen...
LZW:
Ich habe LZW nach C (nicht C++ !!!) portiert und der Prototyp
funktioniert sehr performant! Es ist allerdings noch sehr
Stack-lastig...
Ich generierte typische Werte die vom Sensor kommen könnten und
komprimierte diese:
16 Elemente = 0,48 Komprinierung
32 Elemente = 0,48 Komprinierung
64 Elemente = 0,48 Komprinierung
128 Elemente = 0,45 Komprinierung
800 Elemente = 0,36 Komprinierung
2000 Elemente = 0,33 Komprinierung
Es macht also erst so richtig Sinn ab 800 Werten die Komprimierung
anzustoßen! Das liegt daran dass LZW ein Wörterbuch aufbauen muss!
FAZIT:
Ich denke daran LZW und Huffman zu kombinieren und einen Filter drüber
laufen zu lassen. Ich teste noch wie das am besten harmoniert. Evtl.
brauche ich noch eine Base255 (nicht Base256) Codierung.
Das ist ein Kanal mit Vorkomma und Nachkomma.
Man hätte auch wie folgt schreiben können
18,6
20,8
20,4
.
.
.
Floatzahlen eignen sich nicht unbedingt gut zum Komprimieren.
Da sieht es dann gern so aus:
66 66 a6 41 (1. Zahl)
cd cc 9c 41 (2. Zahl)
33 33 9b 41 (3. Zahl)
33 33 9b 41
66 66 92 41
0 0 94 41
0 0 94 41
66 66 92 41
66 66 92 41
33 33 8b 41
33 33 8b 41
0 0 a0 41
0 0 a0 41
0 0 98 41
0 0 98 41
9a 99 99 41
9a 99 99 41
33 33 93 41
cd cc 88 41
cd cc 88 41
9a 99 a5 41
9a 99 a5 41
cd cc a4 41 (letzte Zahl)
(17 bis 20 in 0,1 er Schritten)
Nicht nachrechnen! Das ist nur ein Beispiel!
Andreas V. schrieb:> Floatzahlen eignen sich nicht unbedingt gut zum Komprimieren.> Da sieht es dann gern so aus:
vor allem ist das unter Umständen nicht platformunabhängig.
sieht auf den ersten Blick aber auch nicht so aus, als brauchtest du
floats.
deswegen schrieb ich vor einer ganzen Weile schon:
Vlad T. schrieb:> Überlege dir, welchen Wertebereich deine Messwerte haben und in welcher> Auflösung du sie brauchst (eventuell auch abhängig vom Bereich) und> rechne die Samples entsprechend um. Wenn in deinem Signal dann wirklich> nur noch die Daten drin stecken, die du auf der Gegenseite brauchst,> kannst du noch eine Entropie-Kodierung machen, oder Differenzwerte> übertragen, wenn sich nur wenig ändert.
Rufus Τ. F. schrieb:> Aha. Was für ein Microcontroller soll das sein? Es macht schon> einen> Unterschied, ob man mp3 auf einem 32-Bit-Controller mit Speicher oder> einem 8-Bit-Controller mit (fast) keinem Speicher decodieren will.
Nur bei Echtzeit! Er kann einen 8Bitter auch nutzen um einfach MP3 zu
WAV oder umgekehrt zu wandeln. Macht zwar keinen Sinn, läuft aber auch
mit 1kHz wenn man genug Zeit hat...
Andreas V. schrieb:> Es geht mir ja auch um die Kurve. Wenn ich eine Sinuskurve von 300 Hz> eingebe, dann kommt annähernd eine Sinuskurve von 300Hz heraus. Der> (gewünschte) Nebeneffekt ist dass abweichende Peaks herausgefiltert> werden. Wenn ich jetzt die Periodenlänge um das Tausendfache> zusammenstauche bei entsprechender Abtastrate ist das genau das was ich> will. Und nach der Übertragung mache ich den Prozess rückgängig...
Der eigentliche Gedanke war dass es in der Natur harmonische Änderungen
gibt. MP3 nutzt Filter um die wichtigen Informationen zu extrahieren und
reduziert die Datenmenge erheblich. Nun war DSP bei mir in den letzten
Jahren nicht unbedingt im Fokus. Ich habe überhaupt kein Gefühl mehr für
den Ressourcenverbrauch. Ich bin der Meinung es geht Anderen ebenso. Es
macht halt keinen Unterschied ob ich einen I7 mit 8 virtuellen Kernen
für 1 Millisekunde mit 100% oder mit 0,00000001 % belastet wird.
Zur eigentlichen Idee:
======================
Wenn ich jetzt sekündlich Messwerte aufnehme erhalte ich 3600 Messwerte
pro Stunde. 44000/48000 Samples sind ca. 1 Tag. Wenn ich per Definition
sage 1 Tag = 1 Sekunde, dann komme ich den üblichen Sample Rates für
Audio relativ nahe.
Was ich dabei nicht bedacht hatte war dass z.B. Temperatur-Kurven nicht
die harmonischen Kurven wiedergeben wie man das im ersten Moment denkt.
Bei Schwingungsmessung ist das eine andere Geschichte. Da habe ich
100000 und mehr Samples / Sekunde und das Verfahren eignet sich schon.
Wenn ich dafür die zehnfache Menge übertragen kann und hauptsächlich die
Kurvenform wichtig ist dann kann das OK sein. Das FFT ein Problem macht
was Ressourcen betrifft hatte ich schon auf dem Schirm. Aus dem Grund
dachte ich auch an Hardwarelösungen.
A. v. S. schrieb:> Schon heatshrink oder lzo mit deinen Daten vermessen?
Hey, danke!
Das hat mich darauf gebracht:
Beitrag "Einfache Bildkomprimierung für Mikrocontroller">Heatshrink scheint dahingehend entwickelt worden zu sein große>Datenmengen (mehrere Megabytes) zu komprimieren. Man könnte es>vermutlich für - die hier gegebenen - kleinen Datenmengen anpassen, aber>bessere Ergebnisse als von den bereits erwähnten Verfahren würde ich>nicht erwarten.>Ich habe das Bild jetzt mal noch mit LZO, Heatshrink und Exomizer>getestet, und die Tabelle schaut nun so aus:>Originalbild, ungepackt : 77.568 Bytes>Heatshrink : 21.534 Bytes>Arithmetic Coder (Order 0, adaptiv) : 17.559 Bytes>RLE : 16.328 Bytes>LZW : (12 Bit Wörterbuch): 16.198 Bytes>LZO : 14.003 Bytes>RLE + AC : 13.926 Bytes>PNG : 13.295 Bytes>Pucrunch : 13.199 Bytes>Exomizer : 12.706 Bytes>GIF : 12.342 Bytes
Heatsink braucht ohne Header 600 Zeilen komplexen Code für den Decoder.
LZW kommt inkl. Header mit 120 Zeilen aus (Prototyp). Außerdem scheint
die Komprimierung von LZW besser zu sein.
Momentan sieht es nach LZW aus...
Andreas V. schrieb:> Das ist ein Kanal mit Vorkomma und Nachkomma.
Wenn das so sein sollte, dann stimmt irgendwas nicht. Mindestens ist
das Probe zu klein.
Kann es sein, dass da eigentlich ein ganz anderes Problem besteht?
Poste mal ein umfangreicheres Probe (bitte als Anhang!).
LZO braucht 5000 Byte Arbeitsspeicher um überhaupt zu funktionieren.
Anscheinend baut der Algorithmus erst ein Wörterbuch auf.
512 Bytes werden auf 290 Bytes komprimiert was einer Komprimierung von
0,57 entspricht.
c-hater schrieb:> Wenn das so sein sollte, dann stimmt irgendwas nicht. Mindestens ist> das Probe zu klein.>> Kann es sein, dass da eigentlich ein ganz anderes Problem besteht?>> Poste mal ein umfangreicheres Probe (bitte als Anhang!).
Verstehe ich nicht. Die Werte sind OK.
Andreas V. schrieb:> Verstehe ich nicht. Die Werte sind OK.
Wenn das Vorkomma und Nachkomma einer Meßreihe sein sollen, ist die
Nachkommastelle einfach nicht hinreichend zufällig, um echt zu sein.
Das kann in einer derart kleinen Stichprobe natürlich mal rein zufällig
tatsächlich so passieren. Deswegen die Bitte um eine Größere.
Nur so kann man die Signaleigenschaften (und damit auch das Potential
für eine Komprimierung) korrekt einschätzen. Oder alternativ auch
systematische Fehler in der Software diagnostizieren, die die Werte
liefert...
Angewandte Statistik. Sau-öder Stoff, nur furztrockene Mathematik, aber
trotzdem gelegentlich recht hilfreich. Wenn man gelernt hat, dieses
Wissen sinnvoll anzuwenden...
Moin,
Andreas V. schrieb:> Man hätte auch wie folgt schreiben können>> 18,6> 20,8> 20,4
Soso, haette man koennen. Man haette auch lateinische Zahlen nehmen
koennen. Und die dann als ASCII String verwursten. Oder einen h265 codec
und die Messwerte als y,u und v samples nehmen koennen - Die
Bitratenreduktion ist bei Videocodecs noch deutlich heftiger als beim
mp3. Ueberleg'mal: PAL-Aufloesung unkomprimiert: ca. 165MBit/sec laesst
sich prima auf h265 mit < 1MBit/sec eindampfen und sieht dabei noch
prima aus...
Kann man alles machen, aber das sind leider komplette Schnapsideen.
Alleine schon diese Messwerte: Das ist doch voellig unherheblich, wo da
das Komma sitzt. Entscheidend ist doch erstmal: mit wieviel Bit krieg'
ich jeden Wert angeliefert, brauch' ich die Alle? Und dann kann ich
anfangen mit Auftrittswahrscheinlichkeiten, Korrelationen von Werten,
etc. bla. Da gibts doch einen gut gefuellten Handwerkskasten, wie man
sich da was passendes zusammensetzen kann...Wie kommt man denn da bloss
grad' auf mp3?
Gruss
WK
Moin,
Na, das sieht ja gut aus. Ist dann wohl bald fertig.
Aber irgendwie hab' ich den Eindruck, als koenntest oder wolltest du
um's Verrecken nicht mit irgendwelchen Daten rausruecken, die irgendwie
belastbar und zielfuehrend waeren.
Ich hab' mir mal den Wunderfitz-Sensor angeguckt, nachdem du den ja
schon im droelfzehnten Post dieses Threads mal erwaehnt hast.
Da komm' ich zum Schluss, dass aus dem Ding pro Messung hoechstens 20
Bit Informationsgehalt rauskommen koennen.
Mit wievielen Bit rechnest du denn?
Wieso glaubst du, es gaebe ueberhaupt ein Kompressionsverfahren, dass
diese 20 Bit zuverlaessig auf <=2 bit pro Messung eindampft, ohne dass
du irgendwelche Randbedingungen erwaehnst?
Und wie sieht dein "unzuverlaessiger" Kanal aus, ueber den du die 2
bit/Messung transportieren willst? Wieviel Bit/sec gehen da drueber?
Bitfehlerwahrscheinlichkeit? Fehlerverteilung, Buendelfehler, etc.?
Wenn du das alles nicht weisst, wirds eng.
Nein: "Moeglichst gute Fehlerkorrektur" und "moeglichst wenig Daten"
sind keine zulaessige Angabe :-)
Gruss
WK
Moin,
Andreas V. schrieb:> Wobei da noch Strings herauszufiltern bzw. nicht auszugeben sind.
<loriot>Ach.</loriot>
> Die Temperaturdaten habe ich schon gepostet.
Ja, aber so, dass man da aus Informationstheoretischer Sicht nix bis
wenig damit anfangen kann.
Der Sensor an sich operiert ja nur von -20...+60 Grad. Also 80 Grad
Differenz. Und liefert eine dezimale Nachkommastelle. Also gibts
ungefaehr nur 800 verschiedene Temperaturen, die der messen kann. Also
log(800)/log(2)=9.64 bit pro Temperaturmessung. Fuer die Feuchte ist's
auch so aehnlich, d.h. gegenueber einer Uebertragung als z.b String
"39.5",der dann 32 bit gross ist (oder gar 40 mit \0) kannst du schon
mal locker den Faktor 3 rausholen. Die 9.xx bit sind der nackte
Informationsgehalt des Sensors. Wenn du jetzt weisst, dass sich der Wert
von Messung zu Messung nicht komplett aendern kann, dann ist der
Informationsgehalt noch geringer.
Nur unter diesen Informationsgehalt kannst du mit keiner verlustlosen
Kompression drunter kommen.
Wenn du jetzt natuerlich zig verschiedene Sensoren hast, wird das alles
schwieriger. Dann musst du dir halt ein Datenformat ueberlegen, mit dem
du noch die Zusatzinfo: welcher Sensor, etc. auch noch uebertragen
kannst. Da wirds wahrscheinlich ausreichen, das nicht bei jeder Messung
mitzuliefern, sondern deutlich seltener.
Und dabei kann man natuerlich auch anfangen zu ueberlegen, ob denn
wirklich jedesmal die Temperatur voellig anders sein kann, und wenn
nicht, dann eben mit irgendeiner Forward-Estimation arbeiten, wodurch
die Datenrate weiter schrumfen kann. Du allerdings auch in die Hoelle
kommst, wenn die Temperatur dann doch mal bei jeder Messung voellig
anders ist...
Irgendwann hast du mal dein Datenformat. Das kannst du dann durch alle
moeglichen Pruefsummen,Hamming/ReedSolomon/BCH,wasweissich soweit
erweitern, dass es Fehler auf der Uebertragungsseite besser abkann.
Dadurch wirds natuerlich wieder groesser. Ist halt so. Wenn du das nicht
magst, nimm einen besseren Uebertragungskanal.
Gruss
WK
Dergute W. schrieb:> Der Sensor an sich operiert ja nur von -20...+60 Grad. Also 80 Grad> Differenz. Und liefert eine dezimale Nachkommastelle. Also gibts> ungefaehr nur 800 verschiedene Temperaturen, die der messen kann. Also> log(800)/log(2)=9.64 bit pro Temperaturmessung. Fuer die Feuchte ist's> auch so aehnlich, d.h. gegenueber einer Uebertragung als z.b String> "39.5",der dann 32 bit gross ist (oder gar 40 mit \0) kannst du schon> mal locker den Faktor 3 rausholen. Die 9.xx bit sind der nackte> Informationsgehalt des Sensors. Wenn du jetzt weisst, dass sich der Wert> von Messung zu Messung nicht komplett aendern kann, dann ist der> Informationsgehalt noch geringer.> Nur unter diesen Informationsgehalt kannst du mit keiner verlustlosen> Kompression drunter kommen.
Ah, das ist doch mal ein intelligenter Ansatz. Wenn man nur 10 Bits
bräuchte um eine Information zu kodieren, dafür aber regelmäßig 32 Bits
verwendet und überträgt, dann ist das Problem erstmal ein vernünftiges
Datenformat zu finden. Danach (wenn überhaupt noch notwendig) kann man
sich Gedanken über eine eventuelle Kompression machen.
Mark B. schrieb:> Ah, das ist doch mal ein intelligenter Ansatz. Wenn man nur 10 Bits> bräuchte um eine Information zu kodieren, dafür aber regelmäßig 32 Bits> verwendet und überträgt, dann ist das Problem erstmal ein vernünftiges> Datenformat zu finden. Danach (wenn überhaupt noch notwendig) kann man> sich Gedanken über eine eventuelle Kompression machen.
Wie gesagt:
Und das geht mit Huffman Coding...
Das ganze ist doch eh sinnfrei wenn der Übertragungsweg nicht robust
genug ist und er wieder Redundanz draufpacken muss, das kann dann je
nach zustand des Kanals selbst mit Kompression nicht ausreichen um die
Bitrate einzuhalten.
Ohne vorherige Tests und genaue Infos ist hier jeder Ratschlag fürn A*
Der Kanal ist doch erst mal egal. Ob Bluetooth, WLAN, ZIGBee, etc.
Störungen kann es überall geben. Wenn ich den LAN-Stecker ziehe oder den
Stecker vom Router ziehe funzt es auch nicht.
=> siehe OSI Referenz-Modell.
Moin,
Andreas V. schrieb:> Wie gesagt:>> Und das geht mit Huffman Coding...
Mumpitz. Wenn du weisst, mit welcher Wahrscheinlichkeit bestimmte
Ereignisse (in deinem Fall dann halt Temperaturen, etc.) auftreten und
da grosse Unterschiede in den Auftrittswahrscheinlichkeiten sind, dann
kannst du den Huffman rausholen und noch ein paar Bits mit Codierung
einsparen.
Personaler schrieb:> Das ganze ist doch eh sinnfrei wenn der Übertragungsweg nicht robust> genug ist und er wieder Redundanz draufpacken muss, das kann dann je> nach zustand des Kanals selbst mit Kompression nicht ausreichen um die> Bitrate einzuhalten.
Nein, sinnfrei ists nur, weil halt so garnix an konkreten Infos
rueberkommt. Sonst ist's ganz normale digitale Kommunikation. Guck' dir
z.b. DVB-S an: Erst wird diverses Audio und Video kleinkomprimiert, dann
in handliche Transportstrompakete verpackt, dann kommt ein Interleaver,
der spaeter auftretende Buendelfehler spreizen soll, dann ReedSolomon
Fehlerschutz drauf, dann auf das ganze noch eine Viterbi
Faltungscodierung, dann erst wird's QPSK moduliert und geht ueber den
Satellit. Im Empfaenger dann alles rueckwaerts...und? Geht prima, oder?
Uebliche Werte sind z.B. 38MBit/sec Transportstrom ohne
Fehlerkorrekturbits und 55 MBit/sec mit Fehlerkorrektur. Also fast 50%
"Aufblasen" fuer den Fehlerschutz.
Nur damit mal ne Hausnummer im Raum steht.
Andreas V. schrieb:> => siehe OSI Referenz-Modell.
Janeee, ist klaa.
Gruss
WK
Andreas V. schrieb:> Ich bin gerade dabei ein Modul zur Messerfassung zu bauen dass über> grottenschlechte Verbindungen (z.B. 100 kBit) Daten über mehrere> Kilometer versenden kann und trotzdem performant ist. Die Daten sollen> sicher über eine kompatible Schnittstelle übertragen werden und> automatisiert auf dem PC abgespeichert werden. Dabei dürfen keine Daten> durch Ausfall der Funkstrecke verloren gehen. Der Akku soll 10 Jahre> halten. Das Teil muss so richtig billig sein! Mein Ziel: Einkaufspreis> unter 10€.
Also 100 kBit über Funk. Die Störungen hängen von meinem Horoskop, von
den aktuellen Sonneneruptionen, von feldgebundenen Störungen, sowie von
den eingeschalteten Mikrowellen ab. Die Fehlerkorrektur sollte
normalerweise von der Übertragungsschicht übernommen werden.
Darauf verlässt man sich aber nicht unbedingt...
Thread beobachten
Seitenaufteilung abschalten