Discussion :

[DjÔsh Nash]

Bonjour tout le monde

Je viens vers vous car dans le cadre de mon stage, on me demande de créer une I.H.M afin d'afficher des données. Ces données proviennent d'un MODEM relié au PC via une RS-232. Jusqu'ici tout va bien.
Le problème, c'est que pour afficher ces données en temps réel, je dois faire transiter 4331 bits/13.33 ms (en effet toutes les 13.33ms je reçois les nouvelles données) via la RS-232 qui a un débit max de 1535 bits/13.33 ms . Vous voyez ou se situe le problème ? Mon tuteur de stage m'a dit qu'il serait possible d’implémenter directement un bout de code en C ou Java dans le MODEM afin de compresser les données, et ainsi respecter ce débit binaire de 1535 bits/13.33 ms. Il me resterai donc plus qu'à décompresser les données pour ainsi les afficher. Je fais donc appel à vous afin de savoir si vous connaissiez un alogorithme facilement codable en C ou Java, possible de compresser/décompresser un flux binaire.


Merci à vous , bonne journée

[souviron34]

ben ces données c'est quoi ??

Des entiers, des shorts, des bytes ?

[DjÔsh Nash]

Ces données sont stockées sur 32 bits au niveau du MODEM, mais vont véhiculer au format RS-232 à travers la liaison RS-232. Soit 8 bits de data + 1 bit de start + 1 bit d'arrêt + 1 bit de parité = 11 bits.

[souviron34]

et tes 8 bits de data représentent quoi ?

Tu as d'abord les algos de compressions usuels (LZW etc), et puis après il peut y avoir une compression dépendante des données et de leur type - distribution (par exemple du style GIF pour des images)

[DjÔsh Nash]

Ces données représentent des amplitudes de puissances.
Le problème c'est qu'il me faudrait un algo simple à coder, et qui ne prenne pas beaucoup de temps, afin que les infos affichées correspondent bien aux données "actuelles".

[souviron34]

Comme je dis, ça dépend des propriétés des données...

Si tu as plusieurs (voire beaucoup de) fois les mêmes valeurs, tu peux compresser en faisant des listes indexées.. (comme GIF)

Tu peux aussi, si tes valeurs sont dans un certain "range", stocker le "range" une fois et ensuite ne stocker que les différences, qui nécessitent moins de bits. (très efficace quand beaicoup de valeurs réelles (le format GRIB (principalement utilisé en météo) est comme ceci)). : taux de compression record.


Si tu n'as pas d'a-priori particulier, une comprssion style LZW ou autre (algos et programmes dispos librement, comme zip, tar, etc..)

[DjÔsh Nash]

Merci de la réponse.

J'ai vu effectivement qu'il y avait des algos basés sur la récurrence des valeurs. Le problème avec cette méthode, c'est qu'il faut certainement stocké, et donc perte du "temps réel". Oui car j'ai aussi une contrainte sur le temps.

Schématiquement voila ce que je souhaiterais obtenir:

Donnée sur 32 bits -> compression -> donnée sur 16 bits -> transfert via RS-232 -> décompression -> donnée initiale sur 32 bits -> affichage.

Mais comme il faut que la donnée affichée corresponde bien à la donnée du tout début, dans le temps imparti (13.33 ms), il ne faut pas que je stocke des données afin de les comparer lors de la phase de compression.

Je sais pas si j'ai été clair

[souviron34]

je ré-itère :

on peut avoir un exemple de tes données ? Varient-elles peu autour d'une valeur médiane, ou entre 2 bornes ? Quelle est leur précision ?

[pseudocode]

Schématiquement voila ce que je souhaiterais obtenir:

Donnée sur 32 bits -> compression -> donnée sur 16 bits -> transfert via RS-232 -> décompression -> donnée initiale sur 32 bits -> affichage.

Mais comme il faut que la donnée affichée corresponde bien à la donnée du tout début, dans le temps imparti (13.33 ms), il ne faut pas que je stocke des données afin de les comparer lors de la phase de compression.

Un taux de compression de 35% avec une latence de 0, je ne pense pas que ce soit possible avec un codage dynamique. Peut-être avec un codage statique (huffman ?) sur un ensemble de données caractéristiques.

Vue les contraintes, les meilleures options sont de diminuer le volume de données ou d'augmenter la bande passante.

[souviron34]

Un taux de compression de 35% avec une latence de 0, je ne pense pas que ce soit possible avec un codage dynamique. Peut-être avec un codage statique (huffman ?) sur un ensemble de données caractéristiques.

Vue les contraintes, les meilleures options sont de diminuer le volume de données ou d'augmenter la bande passante.

Comme je dis, ça dépend des données...

Si il a des valeurs réeles osicllant entre 2 bornes, il peut qssez facilement ne paser en réel que les 2 bornes et un facteur, et passer les valeurs comme delta au facteur près... Ce qui fait un taux de compression assez sensationnel..


Mais il faudrait voir ses données..

[DjÔsh Nash]

Bonjour,

Effectivement, il serait possible de ne transmettre qu'un "delta" qui représenterai la différence entre la valeur "normale, ou une moyenne" et la valeur actuelle. Le problème c'est que je ne connais pas cette valeur "normale" (étant donné que ces données représentent la puissances des ton composants un signal composite, je ne sais pas si cette puissance est "constante" à l'émission). Mais c'est une bonne idée, qui mérite réflexion.

j'aimerais savoir ce que vous pensez de cette idée:

Il est possible de passer simplement de 32 bits à 16 bits en associant 65537 valeurs du mot codé sur 32 bits à 1 valeur du mot correspondant codé sur 16 bits. Pour cela, je divise le mot codé sur 32 bits par 35537, et je tronque le résultat (pour ne garder que la partie entière) ce qui donne la valeur correspondante du mot de 32 bits codé sur 16 bits.

Avec cette technique, il y aura une perte de précision. Ceci n’est pas important au vu de notre application. En effet, ce mot codé sur 32 bits contient les données concernant l’amplitude de la puissance d’un ton. 32 bits correspond à 4294967296 valeurs possibles, ce qui n’est pas nécessaire, car l’I.H.M ne pourra pas afficher tant de valeurs différentes (Cf. le nb de pixels verticaux sur un écran de PC), dans le cas d’un histogramme évolutif en temps réel.

[souviron34]

je ré-itère : pourrait-on avois un exepmple de tes données ?????

Raisonner dans l'absolu, on peut faire tout et n'importe quoi, et proposer n'importe quel algo..

En fontion de tes données, on peut peu-être trouver un truc efficace...

Quand je disiais un delta, c'est surtout si le facteur mutliplicatif peut donner un entier compris entre 2 bornes "petites", suffisamment pour être enregistré sur N bits, n << 32..

Donc, tant quon ne sait pas de quel style sont tes données, on peut rien dire de précis...

[DjÔsh Nash]

Je vais paraître débile, mais c'est à dire un exemple de mes données ?
Je vais essayer d'être plus claire: ces données codées sur 32 bits représentent l'amplitude de puissance d'un ton du signal composite. Ce signal composite est constitué de différent ton, et sera émis comme signal radio, réceptionné par le MODEM. Donc 1 mot de 32 bits = amplitude puissance d'un ton. Je peux pas savoir à l'avance ce que vont être ces données, ça va être aléatoire

[pseudocode]

Je vais paraître débile, mais c'est à dire un exemple de mes données ?
Je vais essayer d'être plus claire: ces données codées sur 32 bits représentent l'amplitude de puissance d'un ton du signal composite. Ce signal composite est constitué de différent ton, et sera émis comme signal radio, réceptionné par le MODEM. Donc 1 mot de 32 bits = amplitude puissance d'un ton. Je peux pas savoir à l'avance ce que vont être ces données, ça va être aléatoire

L'idée serait de savoir si les données ont une structure ou une caractéristique qui permettrait de trouver un mécanisme de compression : répétitions, plateaux, motifs, entropie, ...

[DjÔsh Nash]

J'imagine que cette puissance va être plus ou moins constante, mais encore une fois rien de certain !

[pseudocode]

J'imagine que cette puissance va être plus ou moins constante, mais encore une fois rien de certain !

Dans ce cas, comme le disait souviron34, un codage de type DPCM serait sans doute une bonne idée.

[DjÔsh Nash]

Oui, par contre avec cette méthode difficile de prédire d'un éventuel débordement. En effet, sinon l'échantillon xn-1 = 0 base 10 et que l'échantillon xn = 2000000, je suis dans les choux. Mais à tenter au vu de mon application.

[souviron34]

Oui, par contre avec cette méthode difficile de prédire d'un éventuel débordement. En effet, sinon l'échantillon xn-1 = 0 base 10 et que l'échantillon xn = 2000000, je suis dans les choux. Mais à tenter au vu de mon application.

ce sont les VALEURS dont j'aimerais avoir une idée...

que-ce-que c'est 'l'échantillon n-1"... ????

Et même avec ton exemple, QUELLE EST LA PRECISION ????

C'est pour ça que je demande une xepmle de données .PAs c "c'est du 32 bits".. je m'en tape.. Un exemple de la VARIETE DES VALEURS ....

Dans le cas que tiu donnes, si ce sont des enties, on peut très bien imaginer de passer en log, et donc de transferrer 9 comme facteur, et 0 puis 2 comme valeurs...

[souviron34]

Ce que je veux dire, c'est :

si tu peux définir le delta, d'une manière ou d'une autre, comme <= 255, tu peux sotcker tes valeurs sur 8 bits, si <= 10 sur 4 bits, etc etc ..

[DjÔsh Nash]

Voila mon problème, c'est que je n'ai aucune idée sur les valeurs que je vais recevoir. Et effectivement c'est un gros problème, c'est d'ailleurs pour ça que je n'ai pas pu rep.

Je crois que je vais rester sur l'idée de Division -> Transmission -> Multiplication.