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 sont stockées dans la RAM d'un MODEM que l'on va relier à un 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" (cad que les données affichées correspondent bien aux données "actuelles" ), je dois faire transiter 4331 bits/13.33 ms (en effet toutes les 13.33ms on reçoit les nouvelles données qui sont stockées dans la RAM du MODEM) via la RS-232 qui a un débit max de 1535 bits/13.33 ms . C'est là que 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, dans l'espoir de respecter ce débit binaire de 1535 bits/13.33 ms. En effet, les données stockées dans ce MODEM, sont codées sur 32 bits. Si j'arrive à compresser ces données (les coder sur moins de bit, genre 16) sans perte, je vais pouvoir atteindre le débit max de la RS-232.  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  

tu peux au moins tenter à coup de zlib dans ce cas, mais ca ne te donnera pas un débit constant à chaque "trame" de 4kb

En Java, à mon avis, t'oublies si t'as de tels pbs de ram et de perfs
 
Algo de compression sans perte, du classique : Huffman, LZW sont les plus efficaces pour des suites de bits je pense. Y'a bien RLE qui est très simple mais pas très efficace...
http://fr.wikipedia.org/wiki/Compr [...] nn%C3%A9es
 
Edit : je suis un peu étonné du si faible débit du modem

 
pour ton edit : c'est probablement juste un port "service" sur le modem, pour le configurer, et pas l'interface par laquelle les données réelles circulent.

Plutôt que / en plus de compresser tes données et si t'as de quoi faire tourner un peu de code sur le modem, tu peux pas diffuser uniquement un différentiel du dernier état ?
Ça dépend de la nature de tes données évidemment.

1535 bits/13.33 ms, ça fait 115 kbit/s. C'est une vitesse assez standard pour du RS-232.

1535 bits/13.33 ms -> j'avais lu 13.33 secondes, ce qui faisait 115 bits/s   Du coup, oui, 115kb/s, c'est un débit normal...

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

Tu veux compresser tes données à un taux d'au moins 65%, et plutôt 70% ou plus pour avoir une marge. Ca n'est possible qu'avec des données très redondantes, sinon tu n'atteindras jamais ce taux là avec les algos sans perte classiques. Par ailleurs, il faut savoir si tu acceptes de perdre des trames ou des données ou non, sachant que la plupart des algos de compression n'acceptent pas la perte de trames (une erreur à un endroit et le reste est impossible à décoder) et donc ne sont pas adaptés à ce type d'utilisation.
Si tu ne peux pas admettre des pertes en ligne, tu peux:
- renvoyer les données quand l'émetteur détecte un dépassement du temps imparti,
- faire passer un différentiel du dernier état comme le suggère LeRiton si ça réduit la quantité de données,
Si aucun n'est acceptable, alors je ne vois techniquement pas de solution, il faut passer par autre chose que le RS-232 qui a une bande passante trop limitée pour votre utilisation.

Y'a peut-être moyen d'ajouter un algo de détection/correction d'erreur quand l'erreur porte juste sur peu de bits...

Non mais surtout il faudrait savoir quel type de données est envoyé.
Si c'est totalement aléatoire, il y a peu d'espoir de pouvoir 'a coup sur' compresser dans les limites indiquées, par contre, s'il y a une certaine régularité dans ses données, ça peut être exploité pour que la compression tombe systématiquement dans les paramètres voulus.
A+,

Je ne sais absolument pas si ces données vont avoir une certaine redondance, étant donné que ces données représentent l'amplitude des puissance des tons composants un signal composite. Donc pour les algos de compression je crois que les carottes sont cuites.  
 
La technique du delta entre la valeur précédente et la valeur actuelle, me parait une solution intéressante, tout du moins à creuser. ce qui me chagrine, c'est que lors de la "1ere émission", je vais avoir un retard (car je vais devoir émettre la donnée sur les 32 bits), et je ne sais pas si je vais pourvoir "rattraper" ce retard. De plus, rien ne me garanti que les deltas à transmettre peuvent se coder sur 16 bits. Ça va dépendre de la 1ere valeur transmise ect...

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.

Si tu peut perdre de la précision, alors oui, une transmission, du MSB fera l'affaire.
Note que dans ta proposition, la bande passante nécessaire est toujours trop élevée.
 
Sinon il y a une raison de te limiter à 115200 bauds? J'ai déjà vu des liaison RS à 1.5Mbit/s, ça marche du tonnerre!