Forum: Mikrocontroller und Digitale Elektronik Daten Kompression auf STM32f4 mit 128k RAM


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Mat. K. (matthias_kornfield)


Lesenswert?

Hi
ich muss irgendwelche ADS Werte auf einem kleinen Prozessor 
komprimieren(lossless).
Meine Datenpackete sind gerade mal 1000 bytes. Es geht um eine 
Echtzeitübertragung, was bedeutet dass es bei 1000 Bytes bleibt.
Eine Idee ob es da was gibt?

von Wastl (hartundweichware)


Lesenswert?

Mat. K. schrieb:
> ich muss irgendwelche ADS Werte auf einem kleinen Prozessor
> komprimieren(lossless)

Nein, musst du nicht. Während du noch mit dem Herumfummeln im
Datensatz zum Komprimieren beschäftig bist sind die paar
Bytes schon längst unkomprimiert übertragen.

Mat. K. schrieb:
> Meine Datenpackete sind gerade mal 1000 bytes.

Nein.
Deine Datenpakete sind gerade mal 1000 Bytes gross.

: Bearbeitet durch User
von Norbert (der_norbert)


Lesenswert?

Mat. K. schrieb:
> Hi
> ich muss irgendwelche ADS Werte auf einem kleinen Prozessor
> komprimieren(lossless).
> Meine Datenpackete sind gerade mal 1000 bytes. Es geht um eine
> Echtzeitübertragung, was bedeutet dass es bei 1000 Bytes bleibt.
> Eine Idee ob es da was gibt?

Ja klar gibt's da was.

Wie stark komprimieren?
Wie sehen die Daten aus?
Wie viel Rechenleistung steht zur Verfügung?
Wie komplex darf die Komprimierung sein?

>Echtzeitübertragung
Worüber? LASER-Strecke, USB, UART, Blink-Relais?

von Martin S. (strubi)


Lesenswert?

Mat. K. schrieb:
> Eine Idee ob es da was gibt?

Es gibt z.B. DPCM (Differential pulse code modulation). Wenn deine Daten 
nicht wild rauschen und einem gewissen Muster folgen was in weiten 
Teilen gut vorhersagbar ist, reichen weniger Bits aus. Die musst du dann 
clever verarzten, da wuerde ich mir noch zu den Stichworten 
Golomb-Rice-Coding oder Huffman etwas auf den Teller ziehen. Ein paar k 
fuer die Tabellen muessten dann noch uebrig sein, sonst wird das nix.

Das bessere Forum fuer solche Anfragen ist sonst encode.su.

von Wastl (hartundweichware)


Lesenswert?

Wastl schrieb:
> ... sind die paar
> Bytes schon längst unkomprimiert übertragen.

Zumal man mit DMA Transfer die Prozessorlast noch verringern
kann und damit der Controller während des Block-Transfers schon
einen neuen Datensatz vorbereiten kann. Der englisch-sprachige
Programmierer nennt diese Art der Abarbeitung "interleaved".

von Wastl (hartundweichware)


Lesenswert?

Norbert schrieb:
> Ja klar gibt's da was.

Martin S. schrieb:
> Es gibt z.B. DPCM (Differential pulse code modulation).

Bevor ich mir Gedanken um eine aufwendige Komprimierung mache
überlege ich mir genau ob ich das brauche oder verlange von
Demjenigen der das machen möchte eine klare Begründung dass
das so sein muss bzw. dass es anders nicht funktioiert.

von Norbert (der_norbert)


Lesenswert?

Wastl schrieb:
> Bevor ich mir Gedanken um eine aufwendige Komprimierung mache
> überlege ich mir genau ob ich das brauche oder verlange von
> Demjenigen der das machen möchte eine klare Begründung dass
> das so sein muss bzw. dass es anders nicht funktioiert.

Das ist sicherlich korrekt.

Nur, wenn man keine Komprimierung bräuchte, dann würde vermutlich keine 
Anfrage notwendig gestellt werden.

Aber … um die Frage auch nur halbwegs vernünftig beantworten zu können, 
dann sollten schon etwas mehr Informationen gegeben werden.

von Wastl (hartundweichware)


Lesenswert?

Norbert schrieb:
> Nur, wenn man keine Komprimierung bräuchte, dann würde vermutlich keine
> Anfrage notwendig gestellt werden.

Man kann sich die Notwendigkeit einer Komprimierung auch einfach
mal als Schnapsidee einbilden und dies als Gedankengut hier im
Forum posten. Eine Begründung "ich brauche das" reicht bei
Weitem nicht.

von Norbert (der_norbert)


Lesenswert?

Wastl schrieb:
> Man kann sich die Notwendigkeit einer Komprimierung auch einfach
> mal als Schnapsidee einbilden und dies als Gedankengut hier im
> Forum posten.

He he, stimmt. Wäre nicht das erste Mal.

von Frank K. (fchk)


Lesenswert?

Mat. K. schrieb:
> Hi
> ich muss irgendwelche ADS Werte auf einem kleinen Prozessor
> komprimieren(lossless).
> Meine Datenpackete sind gerade mal 1000 bytes. Es geht um eine
> Echtzeitübertragung, was bedeutet dass es bei 1000 Bytes bleibt.
> Eine Idee ob es da was gibt?

Du musst die Charakteristiken Deiner Daten kennen!

Merke: Wenn Deine Daten aus Zufallszahlen bestehen, dann ist keinerlei 
verlustfreie Kompression möglich!

Wenn Du aber weißt, dass sich Deine Messwerte nur begrenzt über die Zeit 
ändern, dann kannst Du anstelle des Messwertes die Differenz übertragen.

Wenn es Text ist, dann haben die einzelnen Buchstaben verschiedene 
Häufigkeiten, was Du bei der Codierung ausnutzen kannst.

Wenn Du weißt, dass in Deinem Signal bestimmte Frequenzanteile da sind 
oder nicht da sind, kannst Du per FFT in den Frequenzbereich gehen, um 
dort eine effizientere Codierung zu finden.

Wie gesagt: Du musst die statistischen Eigenschaften Deines Signals 
wissen. Ansonsten wird das nix.

fchk

von Wastl (hartundweichware)


Lesenswert?

Norbert schrieb:
> He he, stimmt. Wäre nicht das erste Mal.

Dann warten wir mal auf eine saubere wasserdichte Begründung.
Wenn die nicht kommt dann kann man das Ganze ja schon mal
als vorgezogenen Freitags-Thread betrachten. Oder als
niedergeschriebene Schnapsidee.

von Martin S. (strubi)


Lesenswert?

Wastl schrieb:
> Bevor ich mir Gedanken um eine aufwendige Komprimierung mache
> überlege ich mir genau ob ich das brauche oder verlange von
> Demjenigen der das machen möchte eine klare Begründung dass
> das so sein muss bzw. dass es anders nicht funktioiert.

Es ist davon auszugehen, dass sich der TO einen Ueberblick ueber die 
gaengigen Methoden verschaffen will. Ist auch nicht sonderlich 
aufwendig.

Aber gleich mal besserwissen und lostrollen, ne? So kennt man dieses 
Forum.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Mat. K. schrieb:

> ich muss irgendwelche ADS Werte auf einem kleinen Prozessor
> komprimieren(lossless).
> Meine Datenpackete sind gerade mal 1000 bytes. Es geht um eine
> Echtzeitübertragung, was bedeutet dass es bei 1000 Bytes bleibt.
> Eine Idee ob es da was gibt?

Ja. Die sog. "1:1-Komprimierung". Wenn sich an dem 1000Byte-Datenpaket 
nichts ändern darf, ist das wirklich die einzige Lösung.

Geil ist: Diese spezielle Komprimierung ist lossless UND obendrein 
enorm einfach umzusetzen. Kostet auch keinerlei Rechenzeit.

Ein echtes Träumchen von einer Komprimierung.

Oder anders ausgedrückt: Verpiss' dich, Troll!

von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

Frank K. schrieb:
> Du musst die Charakteristiken Deiner Daten kennen!
>
> Merke: Wenn Deine Daten aus Zufallszahlen bestehen, dann ist keinerlei
> verlustfreie Kompression möglich!

Einfach mal so einen Datensatz in eine Text-Datei auf einem PC stopfen 
und mit z.B. (7-)Zip packen. Da sieht man schonmal ob da überhaupt 
"Luft" drin ist, die man rauslassen kann. Ggf. dabei auch mal 
verschieden Komprimieralgos ausprobieren.

Allgemein dürften folgende die "einfacheren" Vertreter der Sorte 
"verlustfrei " sein, wo man auch genug Implementierungen im i-net 
findet.
- https://de.wikipedia.org/wiki/Laufl%C3%A4ngenkodierung
- https://de.wikipedia.org/wiki/Deflate
- https://de.wikipedia.org/wiki/Huffman-Kodierung

von Mat. K. (matthias_kornfield)


Lesenswert?

Hi
ich sehe gar nicht so leicht.
Es geht um Kompression von physiologischen Daten von Tieren über BLE. 
Das 1000 byte Packet wird dann in BLE Packeten unterteilt.
Ok ich sehe das ist gar nicht trivial. Die Signaleigenschaften sind mir 
gar nicht bekannt.

von Rainer W. (rawi)


Lesenswert?

Mat. K. schrieb:
> Es geht um Kompression von physiologischen Daten von Tieren über BLE.

Ob das physiologische Daten von Tieren sind, ist völlig egal. Für die 
Komprimierbarkeit kommt es auf die statistischen Eigenschaften an, z.B. 
wie stark sich die Daten gegenüber dem vorherigen Block geändert haben.

> Die Signaleigenschaften sind mir gar nicht bekannt.

Dann ist eine Hausaufgabe doch schon einmal klar.

Vielleicht lohnt es auch, über die Art der Daten nachzudenken 
(Zeit-/Bitauflösung), also unnötiges Zeugs gar nicht erst senden zu 
wollen.

: Bearbeitet durch User
von Harald K. (kirnbichler)


Lesenswert?

Mat. K. schrieb:
> Es geht um Kompression von physiologischen Daten von Tieren über BLE.
> Das 1000 byte Packet wird dann in BLE Packeten unterteilt.

Warum muss überhaupt was komprimiert werden? Daß Du Pakete (ohne c!) mit 
1000 Byte Größe hast, ist für sich keinerlei Voraussetzung oder 
Bedingung dafür, daß was komprimiert werden muss.

Auch wenn Deine "1000-Byte"-Pakete auch noch in kleinere Pakete 
unterteilt werden, um via BLE übertragen zu werden, ist das ebenfalls 
nichts, was für sich eine Kompression erfordert.

Sieh mal: Eine UART überträg keine Pakete, sondern nur einzelne Bytes. 
Und auch das ist nirgendwo die Begründung für irgendeine Kompression.

Kompression benötigt man, wenn mehr Daten anfallen, als dafür 
Speicherplatz vorhanden ist, oder wenn mehr Daten anfallen, als sich in 
der gleichen Zeit über den vorgesehenen Kommunikationsweg übertragen 
lassen.

Darüber hast Du aber exakt gar nichts erzählt.

Mit welcher Rate fallen die Daten an, wie groß ist ein Datensatz, welche 
Meta-Informationen (Zeitstempel?) gehören dazu?

Mit welcher Rate können Deine "1000-Byte"-Pakete (immer noch ohne c!) 
übertragen werden?

Wieviele dieser Pakete meinst Du, in Deinem µC gleichzeitig vorhalten zu 
können? Du schreibst ja, daß der µC 128 kB RAM hätte, da sollte Dein 
Programm ja wohl Platz für mehr als eines dieser Pakete übriglassen 
können.

von Peter (pittyj)


Lesenswert?

Ich vermisse die Definition, was hier bei Echtzeit ist.

Wie viele dieser "Packete" sollen in welcher Zeit transferiert werden?

von Wastl (hartundweichware)


Lesenswert?

Mat. K. schrieb:
> Ok ich sehe das ist gar nicht trivial.

Begründe endlich klar und eindeutig warum komprimiert werden
muss und schwafle nicht herum.

Mat. K. schrieb:
> ich muss irgendwelche ADS Werte auf einem kleinen Prozessor
> komprimieren

Mat. K. schrieb:
> Es geht um Kompression von physiologischen Daten

So wie du dich ausdrückst hast du von der Materie (der Daten-
übertragung und Kompression) noch gar keine Ahnung.

von Wastl (hartundweichware)


Lesenswert?

Was schreib ich hier eigentlich noch, Andere sollten sich das
auch fragen. Schliesslich ist es doch das was ich schon vermutet
habe:

Wastl schrieb:
> kann man das Ganze ja schon mal
> als vorgezogenen Freitags-Thread betrachten.

von Εrnst B. (ernst)


Lesenswert?

Rainer W. schrieb:
> Ob das physiologische Daten von Tieren sind, ist völlig egal.

Nicht wirklich.

z.B. könnte man die Körpertemperatur einfach als 64-Bit Double in den 
Datensatz packen. Geht einfach, reicht vom Messbereich und Auflösung 
sicher.
Man könnte aber auch Nebenwissen anwenden, z.B. dass ein Tier bei 1000° 
eher ein Haufen Asche ist, und nur 16 Bit dafür verwenden...

von Rainer W. (rawi)


Lesenswert?

Εrnst B. schrieb:
> Man könnte aber auch Nebenwissen anwenden, z.B. dass ein Tier bei 1000°
> eher ein Haufen Asche ist, und nur 16 Bit dafür verwenden...

Das meinte ich mit:
Rainer W. schrieb:
> Vielleicht lohnt es auch, über die Art der Daten nachzudenken ...

: Bearbeitet durch User
von Peter D. (peda)


Lesenswert?

Εrnst B. schrieb:
> Man könnte aber auch Nebenwissen anwenden

Nun, Daten von Tieren werden sich ja nicht im MHz-Takt ändern. Von der 
Datenrate her dürfte eine Kompression also maximal unsinnig sein.

von Michi S. (mista_s)


Lesenswert?

Mat. K. schrieb:
> Es geht um Kompression von physiologischen
> Daten von Tieren über BLE.

Steig um auf Bonsai-Tiere, da schrumpft auch gleich die Datengröße mit.


Mat. K. schrieb:
> ADS

Das ist doch so etwas ähnliches wie ADHS, oder?


Mat. K. schrieb:
> Meine Datenpackete sind gerade mal 1000 bytes.

Das ist doch nicht so wahnsinnig viel, bist Du sicher, daß Du überhaupt 
etwas komprimieren mußt?

> Es geht um eine Echtzeitübertragung, was bedeutet

Na dann mal Klartext: Wie hoch ist die maximale Reaktionszeit, die das 
System jedenfalls einhalten muß? Ohne eine solche Angabe ist die 
Forderung nach Echtzeit sinnlos, denn in Nullzeit schaffts nichtmal Dein 
Meßwert vom Sensor zum AD-Wandler, geschweige denn weiter zum µC. Und 
gleich vorweg: so schnell wie möglich übersteigt Dein Budget um einige 
Größenordnungen.

> dass es bei 1000 Bytes bleibt.

Also willst Du ohnehin nichts komprimieren.


Mat. K. schrieb:
> Die Signaleigenschaften sind mir gar nicht bekannt.

Das ist schlecht, sehr sehr schlecht.

Denn gerade physiologische Daten haben die Eigenschaft, daß sowohl ihr 
Wertebereich und ihre sinnvolle Auflösung recht eingeschränkt sind (z.B. 
Körpertemperatur vmtl. 30-50°C bei einer sinnvollen Auflösung von 0,1K, 
macht gerade mal 200 Werte, also 1 Byte statt 4 Byte fürn float).
Auch ihre Änderungsraten sind i.A. recht begrenzt, was die Anzahl der 
Werte in einem Zeitraum nochmals massiv reduziert (z.B. ein Messwert pro 
Minute, statt alle Zehntelsekunden).
Damit hättest Du Deine 1000 Byte Körpertemperatur-Daten schon auf unter 
ein halbes Byte komprimiert ohne wesentliche Informationen zu verlieren; 
das schafft kein noch so gutes generisches Komprimierverfahren.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

Irgend W. schrieb:

> Einfach mal so einen Datensatz in eine Text-Datei auf einem PC stopfen
> und mit z.B. (7-)Zip packen. Da sieht man schonmal ob da überhaupt
> "Luft" drin ist, die man rauslassen kann. Ggf. dabei auch mal
> verschieden Komprimieralgos ausprobieren.

Die Idee ist schon ganz gut. Ich würde aber nicht Text nehmen, der läßt 
sich bereits sehr gut komprimieren, sondern tatsächliche Messdaten. 
Einfach die Messdaten, so wie sie sind, in eine Binärdatei schreiben.

@Mat. K. Du solltest in Deinem Protokoll schon vorsehen, dass Lücken in 
der Übertragung auftreten können. Neben der erwähnten Tatsache, dass 
nicht alle Signale kompremierbar sind, hast Du mit BLE eben auch keine 
garantierte Bandbreite. Wenn diese Anforderung (verlustfrei) vom Kunden 
kommt, dann solltest Du mit ihm reden und ihm erklären, dass das nicht 
möglich ist.

von Mat. K. (matthias_kornfield)


Lesenswert?

Danke, für den Input.
Also die 1000 Bytes werden ca 100-120  mal die Sekunde über BLE 
(2mPhy)geschickt.

Soviel habe ich mitgenommen von eurem Input, dass jeder 
Kompressionsalgorithmus sich die Eigenschaften des Signale zu nutze 
macht.
Da kam ich schon auf die eine oder andere Idee.

von Harald K. (kirnbichler)


Lesenswert?

Mat. K. schrieb:
> Also die 1000 Bytes werden ca 100-120  mal die Sekunde über BLE

Ah, eine Salamischeibe steigt am Himmel auf ...

von Michael G. (michael_g968)


Lesenswert?

Moin,

wird eng.

100 transaktionen je sekunge bei 1000 byte macht dann 0.8MBit je 
Sekunde,

Wir haben einen 2Mbit phy, das ist aber die gesamte sende / 
empfangsleisung, teilt sich somit auf, ... die 2mbit stehen dem sender 
nicht exclusive zur verfuegung.

Sender und empfaenger kommen immer im wechsel zum zug. Mindestens ein 
ack muss gesendet werden. wenn beide ack senden, dann hat nimand mer was 
zu sagen. und dann legen sich beide schlafen bis zum naechten conntect 
(connection window)
150us je wechsel zwischen senden und empfangen, alle 41 bzw 265 byte.
ein ack hat 10byte (Kleinst moegliches paket)

Nutzlast bei BLE je paket sind 20Byte  + 21Byte overhead (41byte)
oder mit data length extension 244Byte + 21 byte Overhead. (265byte)
(auf gatt layer)
1000 / 244 = 4.1 pakete -> wir brauchen damit 4ganze und ein 
angebrochnenes!

4*((244+21)*8us/2 + 150us + 40us + 150) + (24+21)*8us/2 + 150 us
4 * (1060us + 150us + 40us) + 180 + 150us + 40 + 150
= 4.94ms je 1000 byte

Sieht jetzt estmal machbar aus. Aber, das ist reine theorie und nur 
streaming im best case ohne irgend welche stoerungen, retries, ...

und es gibt da noch jede menge andere schweinereien, die dir das timing 
kaput machen koennen.

Connection Window; wie wird auf gatt ebene die daten uebertragen, write 
with response oder write without response, ... welche gegenstellen 
werden verwendet? (das angebissene obst ist da besonders auffaellig)

ich sehe gerade, du schreibst stm32f4, ...
Wie wird das BLE am STM32F4 angebunden, was wird da verwendet?
Wie kommen die daten vom stm32F4 zum BLE?
Welches GATT profil wird verwendet, was eigenes oder ein Serieles vom 
hersteller?


https://punchthrough.com/maximizing-ble-throughput-part-3-data-length-extension-dle-2/

https://interrupt.memfault.com/blog/ble-throughput-primer

von Wastl (hartundweichware)


Lesenswert?

Michael G. schrieb:
> ich sehe gerade, du schreibst stm32f4, ...
> Wie wird das BLE am STM32F4 angebunden, was wird da verwendet?

Das ist ein Freitags-Thread, falls du das aus dem Zusammenhang
noch nicht kapiert hast. So ein Thread ist dazu gedacht möglichst
viele Leute wie dich hinterm Ofen hervorzulocken und viel heisse
Luft zu produzieren.

Die zaghaften unreflektierten Nachträge bzw. Salamischeiben
dienen auch dazu den Forum-Traffic weiterzuführen bzw. wieder
anzuheizen. Weiterhin Fiel Fergnügen beim sinnlosen verrgeuden
von Geistesleistung.

Wastl schrieb:
> Wenn die nicht kommt dann kann man das Ganze ja schon mal
> als vorgezogenen Freitags-Thread betrachten. Oder als
> niedergeschriebene Schnapsidee.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

Wastl schrieb:

> Das ist ein Freitags-Thread, falls du das aus dem Zusammenhang
> noch nicht kapiert hast.

Was ist den so schwer am Thema des OPs zu verstehen? Er hat Daten, die 
sich mit der gegebenen Bandbreite nicht übertragen lassen. Nun braucht 
er mal etwas Input, wie er damit umgehen kann.

Wenn ich den thread nach Deinem Namen durchsuche, dann finde ich aber 
auch wirklich ausnahmslos Beiträge, die nicht hilfreich sind. Wenn hier 
jemand die grundsätzlichen Möglichkeiten von Datenkompressionen 
diskutieren möchte, dann muss er doch nicht vorher beweisen, dass dies 
in seinem Kontext sinnvoll ist.

In so einem Forum geht es doch um Wissensaustausch. Ist es denn so 
schwer, den Thread zu ignorieren, wenn einem der Inhalt nicht passt? Mir 
jeder Deiner nörgle-Nachrichten, bekommen alle Beteiligten eine Email in 
ihr Postfach.

P.S.: Falls eine Interesse daran besteht, weiter zum Thema 
"Mindestanforderungen an einen Post und wie häufig muss an die 
Nichteinhaltung erinnert werden" zu diskutieren, würde ich vorschlagen, 
dass wir das im "Offtopic-Bereich" fortsetzen.

von Mat. K. (matthias_kornfield)


Lesenswert?

Michael G. schrieb:
> wird eng.
Hi
wir benutzen zusätzlich ein NRF BLE. Der Beispiel code von denen schafft 
mit paar kleinen Handgriffen schon 100-120 packete a 1000byte, die dann 
auf Nordic in BLE Packete untergebrochen werden. Das läuft schon.

Die Sache bei BLE ist nun mal, Die Bandbreite sinkt mit der Distanz. Was 
bedeutet, dass wenn die Daten komprimiert werden, die Distanz bei der 
fehlerfrei & lückenlos übertragen werden kann, steigt.
Danke für die Links.
Schaue ich an.

von Norbert (der_norbert)


Lesenswert?

Mat. K. schrieb:
> Was
> bedeutet, dass wenn die Daten komprimiert werden, die Distanz bei der
> fehlerfrei & lückenlos übertragen werden kann, steigt.

Wenn das nun die neue Prämisse ist, dann kann es doch nur ein einziges 
sinnvolles Vorgehen geben. Daten genauestens analysieren und dazu 
passende Kompressionsverfahren aussuchen bzw. ersinnen.
Wenn diese Trauben dann maximal ausgequetscht sind, prüfen ob es für den 
Übertragungsweg reicht.
Falls nein, Konzept -> Tonne.

von Chris S. (schris)


Lesenswert?

Dann nimm einfach lz4, wenn das Resultat kleiner ist, wird komprimiert 
übertragen, ansonsten RAW. Wenn mehr Kompression gebraucht wird muss man 
sich die Daten ansehen und Absolutwerte sowie Deltas speichern, sowie 
fixed point data mit Offset oder gefilterte ADC Data mit Offset und 
Delta, kann man in einem zweiten Moment immer noch machen.

von Axel S. (a-za-z0-9)


Lesenswert?

Chris S. schrieb:
> Dann nimm einfach lz4, wenn das Resultat kleiner ist, wird komprimiert
> übertragen, ansonsten RAW

Das kann gut gehen, muß aber nicht. Ohne Kenntnis seiner Daten ist 
jede Diskussion über ein geeignetes Kompressionsverfahren reine 
Spekulation.

Das grundlegende ist sowieso erstmal, die Daten in einer möglichst 
redundanzarmen Form zu erfassen. Stichwort: Quellencodierung. Je nach 
Art der Daten kann eine geeignete Quellencodierung mehr bewirken als das 
beste Kompressionsverfahren.

Beispiel: Körpertemperatur kann man naiv als float codieren. Oder als 
Offset zu z.B. 30°C in Schritten von 0.1K. Letzteres kommt mit 7 Bit aus 
(bis 42.7°C). Man wird sich schwer tun, ein allgemeines 
Kompressionverfahren zu finden, das 32 Bit auf 7 Bit reduziert.

Wenn man komprimieren muß, dann gibt es noch ein paar Punkte zu 
beachten:

Kompression funktioniert i.A. umso besser, je mehr Daten vorliegen. Das 
gilt besonders für adaptive Verfahren (die ein Wörterbuch oder einen 
Codebaum während der Kompression erst erzeugen). Die 1000 Bytes von 
denen der TE sprach, sind schon an der unteren Grenze. Bei BTLE ist mit 
Paketverlust zu rechnen, deswegen ist ein adaptives Verfahren immer auf 
ein Datenpaket limitiert.

Wenn Daten aus verschiedenen Quellen zusammengefaßt werden, kann es 
günstiger sein die Daten nicht zu verschachteln. Also nicht z.B. Puls 
#1, Temperatur #1, Puls #2, Temperatur #2 ... sondern Puls #1, Puls #2, 
... gefolgt von Temperatur #1, Temperatur #2, ... (soviel wie halt in 
ein Paket paßt). So werden Redundanzen in den Daten besser erkennbar.

Evtl. verschickt man die Daten sogar als separate Pakete und mit jeweils 
verschiedener Kompressionsmethode. Das kommt auch darauf an, mit wieviel 
Paketverlust man rechnet und welche Lücken jeweils akzeptabel sind.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

Axel S. schrieb:

> Beispiel: Körpertemperatur kann man naiv als float codieren. Oder als
> Offset zu z.B. 30°C in Schritten von 0.1K. Letzteres kommt mit 7 Bit aus
> (bis 42.7°C). Man wird sich schwer tun, ein allgemeines
> Kompressionverfahren zu finden, das 32 Bit auf 7 Bit reduziert.

man kann sich z.B. auch die Quelle angucken. Wenn die Temperatur mit 
einem 8-Bit AD-Wandler gemessen wurde, dann ist ziemlich klar, dass jede 
Kodierung mit mehr als 8-Bit Redundanz enthalten muss.

von Michael G. (michael_g968)


Lesenswert?

Axel S. schrieb:
> ...
> Bei BTLE ist mit
> Paketverlust zu rechnen, ...

Jein.
verbindung mit pairing und bonding, ist
ein Paketverlust ist immer auch ein connection lost.

Denn a wartet auf ein ack oder ein paket von B (ein ack ist ein packet 
ohne nutzdaten) wenn das nicht ankommt, dann weiss A das die verbindung 
zu B tot ist. -> connection lost

Selbst NRF sagt: Write with response ist nur in den aller seltensten 
faellen notwendig. da der response eigentlich unnoetig ist.
Versaut nur die bandbreite, Den bevor der naechste write auf eine 
chracteristik erfolgen kann, muss der response zurueck.

und anstelle von "kein response" bekommst du ein "connection lost".

Muss man natuerlich auch in der BLE FW behandeln, ... wenn nicht, dann 
fehlen die daten. Und die einfachen beispiele beruecksichtigen das meist 
nicht.

von Flip B. (frickelfreak)


Lesenswert?

Axel S. schrieb:
> Beispiel: Körpertemperatur kann man naiv als float codieren. Oder als
> Offset zu z.B. 30°C in Schritten von 0.1K. Letzteres kommt mit 7 Bit aus
> (bis 42.7°C). Man wird sich schwer tun, ein allgemeines
> Kompressionverfahren zu finden, das 32 Bit auf 7 Bit reduziert.

Ich wette, die Datencodierung des TO ist JSON oder ähnlich und der 
scheinbare bedarf zu komprimieren liegt nur an ineffizienter codierung 
und übertragung aller Keys im ungekürzten klartext. Schnelle abhilfe 
schafft die verwendung von Protobuffer als encoding, damit lassen sich 
strukturierte daten recht effizient übertragen, beide 
kommunikationspartner bekommen vorher eine Datei mit allen zum parsen 
nötigen informationen. Noch effizienter geht nur mit statischem encoding 
von binärwerten.
1
 
2
 “Tier”: [
3
4
      {
5
6
         “name”: “Eichhörnchen”,
7
8
         “puls”: “220bpm”,
9
10
         “körpertemperatur”: “40,4C”,
11
12
         “laufstrecke”: “1250,000m”
13
14
      }
15
16
]

-> vielleicht 6 Byte nutzdaten codiert in 155Byte, so ist das üblich 
beim heutigen softwareentwickler. Der 500mBit/s Internetanschluss will 
ja auch ausgelastet werden.

: Bearbeitet durch User
von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

Michael G. schrieb:

> Jein.
> verbindung mit pairing und bonding, ist
> ein Paketverlust ist immer auch ein connection lost.

Nein, bei BLE gibt es ein Supervision Timeout. Wenn das überschritten 
ist, ohne das die Gegenseite ein Ack bekommen hat, ist die Verbindung 
verloren. (Core Spec. Vol 6. Part B. 4.5.2)

> Selbst NRF sagt: Write with response ist nur in den aller seltensten
> faellen notwendig. da der response eigentlich unnoetig ist.
> Versaut nur die bandbreite, Den bevor der naechste write auf eine
> chracteristik erfolgen kann, muss der response zurueck.

Es gibt aber ein ganz praktisches Problem: Die meisten APIs auf desktop 
oder smartphone OSes geben Dir keinen Zugriff auf die Größe interner 
Queues. Wenn Du da 500 Write Without Response startest, kannst Du davon 
ausgehen, dass das OS davon einige sang- und klanglos verwerfen wird.

Wenn man möglichst hohe Bandbreiten über BLE erreichen will, sollte man 
auf L2CAP runter gehen.

von Monk (roehrmond)


Lesenswert?

Flip B. schrieb:
> Ich wette, die Datencodierung des TO ist JSON

Du hast keine Ahnung! Ich wette, sie ist XML.

Nein, tue ich nicht. Was soll dieses wilde herumraten?

von Rbx (rcx)


Lesenswert?

Mat. K. schrieb:
> Eine Idee ob es da was gibt?

Für "irgendwelche" Daten auf "irgendwelchen" Prozessoren für 
"irgendeine"
Echtzeitübertragung wird es schon irgendwas geben, glaube ich auch.

Oder anders ausgedrückt: mal angenommen wir haben nur nix, außer 
irgendwas, und wollen "was" (bzw. was konkretes) gewinnen.

So ginge z.B. Brainstorming für die eigene Ideengewinnung.
https://de.wikipedia.org/wiki/Brainstorming

Nur baut aber selbst diese Technik auf einem Minimum an Vorgabe auf:

Aufgabe: Wir wird aus irgendwas was (konkretes)? Eine Minute Zeit.
Na, kommen da schon tolle Einfälle?

Bitte 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
Noch kein Account? Hier anmelden.