Hi ich muss Daten mit 250 samples per second mit 24 bit für 32 Kanäle über Bluetooth verschicken. Wie kann ich meine Daten am einfachsten komprimieren. Es soll von rechenzeit her einfach sein. Eine idee? Was für Effekte wurde ich sehen wenn ich differential PCM benutzen wurde. Also den ersten Array von 32 samples der 32 Kanäle unkomprimiert übertragen und dann für n samples nur noch die differenz in zum Beispiel 16 bit Auflösung statt 24 bit. Da hätte ich etwas weniger als 33% Bandbreite gespart. In was für Probleme konte ich rein laufen? Danke
Die 24000 Bytes/sec bekommt man noch über Bluetooth Classic rüber - die Module hier liefen mit knapp 40 KByte/sec wenn die Verbindungqualität gut war. Blueooth Low Energy kann das IMHO auch, mann muss dann aber den Kanal ausquetschen (4.2 oder 5.0). Musst Du unbedingt Strom sparen? Ich frage das weil WLAN hier erheblich schneller und einfacher wäre...
Servus, es fehlen ein paar wichtige Infos. Auf welcher HW läuft das ganze? Müssen die Daten in Echtzeit übertragen werden, oder reicht es Daten zu sammeln und dann ein einem Rutsch zu übertragen? Gibt es für die HW eine (g)zip-libary? Wenn ja, möglicherweise einfach die Daten damit komprimieren lassen. Ansonsten: Überlegen ob man an Genauigkeit oder Übertragungsfrequenz sparen kann. 24 Bit ist schon eine sehr hohe Auflösung. Für was braucht man so was? Wenn man nur Differenzdaten überträgt, muß man sich halt überlegen, was passiert, wenn mal ein Paket "verloren" geht.
Hängt stark davon ab was für Daten es sind. Ist es eher wie ein Rauschen, dann macht Standard-komprimieren kaum sinn. Sind es eher Saubere Signale wie Sinus oder Audio kann man mit dem Signal angepassten Algorithmen extrem viel heraushohlen. Auch interessant, muss es Verlustfrei komprimiert werden damit eine 100% exakte Wiederherstellung möglich ist? Um was für Daten(Formen) handelt es sich denn? 73 55
:
Bearbeitet durch User
Ein Stichwort wäre lossless audio compression. Formate wie wav oder aiff stammen noch aus Zeiten, als ein PC weniger Leistung hatte als ein heutiger Mikrocontroller.
Hi Es geht um echtzeit übertragung von 24 bit x 32 kanal x 250 samples per sec= 192 kbs. Controller ist stm32f4 mit 120 Mhz. Allerdings kommt es wie gesagt auf Rechenzeit an.
Mat. K. schrieb: > In was für Probleme konte ich rein laufen? Z.B. in das Problem, zu wenig Information bekannt zu geben. Ich nehme an (!) dass es sich um Audio handelt? Auf welche Datenrate möchtest Du runter? Mit flac kannst Du 50% sparen, mit Datenreduktion (ogg, mp3, etc.) mehr. Ob Datenreduktion akzeptiert ist, wissen wir aber auch nicht. Mit einfacheren Verfahren wird das Potenzial noch geringer. Ohne Rechenleistung wirst Du also nicht nennenswert Einsparungen erzielen. gzip ist für Audio nur bedingt sinnvoll. Gruß Jobst
Ja was für Daten, schnelle Spannung/Leistung Daten oder langsam ändernde wie Temperatursensoren? Grad für Audio-Daten (Nehme aber von der Kanalanzahl an, dass es sich dabei nicht um solche handelt), habe ich selber Algorithmen entwickelt die sehr wenig Rechenleistung erfordern (Theoretisch sogar mit Hardware in einem GA machbar) sind. Aber eben: der_eine schrieb: > es fehlen ein paar wichtige Infos. ist halt ein Problem.....
:
Bearbeitet durch User
Nachtrag: Irrtum, bei 250 Samples/s kann es natürlich kein Audio sein ... Um so interessanter, was das für Daten sind. Gruß Jobst
Es sind vibrations Daten, die sich mit höchstens 120 Hz ändern. Ich will ca. 30% runter kommen mit der DatenMenge.
Moin, Mat. K. schrieb: > Es sind vibrations Daten, die sich mit höchstens 120 Hz ändern. Diese Informationen sind fuer den Kompressionsansatz voellig unerheblich. Viel wichtiger waeren so Dinge wie: Spektrum und Autokorrelation deines Signals; wieviel Fehler darf durch die Kompression verursacht werden, ... Das sind die entscheidenden Parameter. Wenn du die nicht weisst, aber du schon Sampledaten hast, dann mach' ein paar Tests mit den ueblichen verdaechtigen Algorithmen. Ob deren Kompression bei deinen Daten passt und ob du mit deren Rechenzeitbeduerfnissen zurechtkommst. Gruss WK
Dan würde ich eine Bitbreiten Reduktion empfehlen. Soll heißen du packst die 24 Bit in 3 8 Bit Pakete und gibst Idendifyer welches der 3 Pakete sich verändert damit kriegst du eine sehr hohe Kompression hin und kannst die Daten zu 100% Verlustfrei wieder herstellen. Die Rechenleistung dazu ist nur minimal, brauchst einfach ein genügend großer Stack. So kannst du die Sinuskurven (Was ja Vibrationsdaten in der Regel sind) Gut komprimieren und wieder Herstellen. Du sendest dann nur die Pakete die sich wirklich ändern und stellst dann per ID die unveränderten Pakete wieder her. Idendifyer Besteht aus Positionsinfo und Timedomain.
:
Bearbeitet durch User
Mat. K. schrieb: > Es sind vibrations Daten, die sich mit höchstens 120 Hz ändern. Daten, die sich mit max. 120Hz ändern? Dann reicht es doch, auch nur mit 120 Samples/s zu übertragen - schon mal mehr als 50% gespart. Oder Vibrationen/Schwingungen von max. 120Hz mit 250 Samples/s abgetastet? Sind da wirklich 24bit notwendig?
Patrick L. schrieb: > Dan würde ich eine Bitbreiten Reduktion empfehlen. > Soll heißen du packst die 24 Bit in 3 8 Bit Pakete und gibst Idendifyer > welches der 3 Pakete sich verändert damit kriegst du eine sehr hohe > Kompression hin und kannst die Daten zu 100% Verlustfrei wieder > herstellen. Wenn sich das höchst wertige Byte ändert, sind die beiden andern Bytes natürlich auch betroffen. In dem Fall ist die Kompression ist NULL. Die Maximal-Kompression gibt es nur bei sehr kleiner Aussteuerung, qualitativ bei ~96dB unter Full-Scale (24bit-Daten). Da der TO schon ziemlich nahe an der Nyquistfrequenz operiert, kann sich das Signal sich von Sample zu Sample um fast 100% ändern. Von einer garantierten Kompressionsrate kann man mit deinem Verfahren dann sicher nicht mehr reden. Und ... 120Hz Signalfrequenz @ 250 Samples/s klingt schon sehr sportlich - muss doch das Antialiasfilter genau genommen von 0dB (@120Hz) auf -144dB (@125Hz) dämpfen. Tut es das nicht, sind die 24bit eh für‘n Popo. just my 2ct
Jester schrieb: > Da der TO schon ziemlich nahe an der Nyquistfrequenz operiert, kann sich > das Signal sich von Sample zu Sample um fast 100% ändern. Von einer > garantierten Kompressionsrate kann man mit deinem Verfahren dann sicher > nicht mehr reden. Ähm wie fiel "G" hält der Sensor aus? Vibration ist sehr Träge, Den es gilt Masse x Geschwindigkeit was Physikalische grenzen setzt wenn er nicht gerade Molekühle einzeln in Bewegung setzen will... Ergo gehe ich von nicht all zu großen Sinus der Quelle aus. Aber da fehlen halt noch Puzzleteile ;-) Und das mit den Höchswertigen Byte kann man mit einem Algorithmus gut berechnen und berücksichtigen den das hat immer bei Sinuskurven einen festen Zusammenhang ;-) Deshalb braucht ja auch der Stack eine Gewisse Größe ;-)
:
Bearbeitet durch User
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.