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?
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
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?
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.
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".
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.
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.
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.
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.
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
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.
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.
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!
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
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.
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
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.
Ich vermisse die Definition, was hier bei Echtzeit ist. Wie viele dieser "Packete" sollen in welcher Zeit transferiert werden?
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.
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.
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...
Ε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
Ε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.
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.
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.
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.
Mat. K. schrieb: > Also die 1000 Bytes werden ca 100-120 mal die Sekunde über BLE Ah, eine Salamischeibe steigt am Himmel auf ...
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
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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?
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?
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.