Historiquement j'ai l'ADSL à 512k depuis quelques années. (6800 m du NRA)
Normalement, si j'en crois degrouptest, un nouveau NRA-ZO a été installé
le 14/12 et je me retouve donc avec les caractéristiques suivantes :
1800m soit 8 Mb.
Cette augmentation de débit va-t-elle se faire toute seule, ou mon FAI
doit modifier quelque chose (SFR : ex Télé2) ou il faut modifier des
paramètres dans mon adaptateur ADSL : Bewan ADSL Ethernet ST.
Le mode fastpath garde le mode de correction d'entrelacement et le mecanisme FEC puisque ca reste de l'interleaved, par contre, le mode DSLSafe est desactivé.
Ok, donc ça reste intéressant pour le lignes dont les erreurs sont corrigées par FEC, et qui ont au final peu de CRC / HEC...
Je voudrais juste dire que les CRC ne sont pas des FEC que ce mécanisme n'a pas réussi à corriger. Il y a bien deux codeurs, avec la matrice d'entrelacement entre les deux. Ce que code le codeur "FEC" n'a donc rien à voir avec le train binaire que voit le codeur "CRC". Donc, en réception, on a des FEC, erreurs corrigées sur ce qui ve entrer dans le désentrelaceur, puis passage dans le décodeur "CRC", qui déctectera d'éventuelles erreurs qu'ils ne corrigera pas. Didier.
Herm a écrit :
"Channels" a écrit :
Le mode fastpath garde le mode de correction d'entrelacement et le
mecanisme FEC puisque ca reste de l'interleaved, par contre, le mode
DSLSafe est desactivé.
Ok, donc ça reste intéressant pour le lignes dont les erreurs sont
corrigées par FEC, et qui ont au final peu de CRC / HEC...
Je voudrais juste dire que les CRC ne sont pas des FEC que ce mécanisme
n'a pas réussi à corriger.
Il y a bien deux codeurs, avec la matrice d'entrelacement entre les deux.
Ce que code le codeur "FEC" n'a donc rien à voir avec le train binaire
que voit le codeur "CRC".
Donc, en réception, on a des FEC, erreurs corrigées sur ce qui ve entrer
dans le désentrelaceur, puis passage dans le décodeur "CRC", qui
déctectera d'éventuelles erreurs qu'ils ne corrigera pas.
Didier.
Le mode fastpath garde le mode de correction d'entrelacement et le mecanisme FEC puisque ca reste de l'interleaved, par contre, le mode DSLSafe est desactivé.
Ok, donc ça reste intéressant pour le lignes dont les erreurs sont corrigées par FEC, et qui ont au final peu de CRC / HEC...
Je voudrais juste dire que les CRC ne sont pas des FEC que ce mécanisme n'a pas réussi à corriger. Il y a bien deux codeurs, avec la matrice d'entrelacement entre les deux. Ce que code le codeur "FEC" n'a donc rien à voir avec le train binaire que voit le codeur "CRC". Donc, en réception, on a des FEC, erreurs corrigées sur ce qui ve entrer dans le désentrelaceur, puis passage dans le décodeur "CRC", qui déctectera d'éventuelles erreurs qu'ils ne corrigera pas. Didier.
Herm
"Didier" a écrit :
Herm a écrit :
"Channels" a écrit :
Le mode fastpath garde le mode de correction d'entrelacement et le mecanisme FEC puisque ca reste de l'interleaved, par contre, le mode DSLSafe est desactivé.
Ok, donc ça reste intéressant pour le lignes dont les erreurs sont corrigées par FEC, et qui ont au final peu de CRC / HEC...
Je voudrais juste dire que les CRC ne sont pas des FEC que ce mécanisme n'a pas réussi à corriger. Il y a bien deux codeurs, avec la matrice d'entrelacement entre les deux. Ce que code le codeur "FEC" n'a donc rien à voir avec le train binaire que voit le codeur "CRC". Donc, en réception, on a des FEC, erreurs corrigées sur ce qui ve entrer dans le désentrelaceur, puis passage dans le décodeur "CRC", qui déctectera d'éventuelles erreurs qu'ils ne corrigera pas. Didier.
Bonjour,
C'est pourtant ce que j'ai compris en lisant certains articles, comme : http://fr.wikipedia.org/wiki/Asymmetric_Digital_Subscriber_Line
Pour ma part, il me semblerait curieux que FEC soit d'abord appliqué sur la séquence de bits d'une trame reçue brute, et qu'ensuite le désentrelaçement soit appliqué...
Le but de l'entrelaçement étant de changer l'ordre des bits pour qu'en cas de perturbation touchant plusieurs bits d'affilés, cela corresponde en fait à des bits éloignés, le tout pour faciliter la correction d'erreur FEC. Ça veut bien dire qu'au décodage, les bits sont d'abord remis dans l'ordre, et qu'ensuite FEC est appliqué sur les bits remis dans l'ordre. Il n'y a aucun interêt à faire de l'entrelaçement si ça n'aide pas quelque part !
Les algos CRC (niveau trame j'ai l'impression) puis HEC (niveau cellule) permettent ensuite de valider si les données obtenues, et éventuellement corrigées, sont réellement valides ... ou pas ...
-- Herm
"Didier" a écrit :
Herm a écrit :
"Channels" a écrit :
Le mode fastpath garde le mode de correction d'entrelacement et le
mecanisme FEC puisque ca reste de l'interleaved, par contre, le mode
DSLSafe est desactivé.
Ok, donc ça reste intéressant pour le lignes dont les erreurs sont
corrigées par FEC, et qui ont au final peu de CRC / HEC...
Je voudrais juste dire que les CRC ne sont pas des FEC que ce mécanisme
n'a pas réussi à corriger.
Il y a bien deux codeurs, avec la matrice d'entrelacement entre les deux.
Ce que code le codeur "FEC" n'a donc rien à voir avec le train binaire que
voit le codeur "CRC".
Donc, en réception, on a des FEC, erreurs corrigées sur ce qui ve entrer
dans le désentrelaceur, puis passage dans le décodeur "CRC", qui
déctectera d'éventuelles erreurs qu'ils ne corrigera pas.
Didier.
Bonjour,
C'est pourtant ce que j'ai compris en lisant certains articles, comme :
http://fr.wikipedia.org/wiki/Asymmetric_Digital_Subscriber_Line
Pour ma part, il me semblerait curieux que FEC soit d'abord appliqué sur
la séquence de bits d'une trame reçue brute, et qu'ensuite le
désentrelaçement soit appliqué...
Le but de l'entrelaçement étant de changer l'ordre des bits pour qu'en cas
de perturbation touchant plusieurs bits d'affilés, cela corresponde en fait
à des bits éloignés, le tout pour faciliter la correction d'erreur FEC. Ça
veut bien dire qu'au décodage, les bits sont d'abord remis dans l'ordre, et
qu'ensuite FEC est appliqué sur les bits remis dans l'ordre. Il n'y a aucun
interêt à faire de l'entrelaçement si ça n'aide pas quelque part !
Les algos CRC (niveau trame j'ai l'impression) puis HEC (niveau cellule)
permettent ensuite de valider si les données obtenues, et éventuellement
corrigées, sont réellement valides ... ou pas ...
Le mode fastpath garde le mode de correction d'entrelacement et le mecanisme FEC puisque ca reste de l'interleaved, par contre, le mode DSLSafe est desactivé.
Ok, donc ça reste intéressant pour le lignes dont les erreurs sont corrigées par FEC, et qui ont au final peu de CRC / HEC...
Je voudrais juste dire que les CRC ne sont pas des FEC que ce mécanisme n'a pas réussi à corriger. Il y a bien deux codeurs, avec la matrice d'entrelacement entre les deux. Ce que code le codeur "FEC" n'a donc rien à voir avec le train binaire que voit le codeur "CRC". Donc, en réception, on a des FEC, erreurs corrigées sur ce qui ve entrer dans le désentrelaceur, puis passage dans le décodeur "CRC", qui déctectera d'éventuelles erreurs qu'ils ne corrigera pas. Didier.
Bonjour,
C'est pourtant ce que j'ai compris en lisant certains articles, comme : http://fr.wikipedia.org/wiki/Asymmetric_Digital_Subscriber_Line
Pour ma part, il me semblerait curieux que FEC soit d'abord appliqué sur la séquence de bits d'une trame reçue brute, et qu'ensuite le désentrelaçement soit appliqué...
Le but de l'entrelaçement étant de changer l'ordre des bits pour qu'en cas de perturbation touchant plusieurs bits d'affilés, cela corresponde en fait à des bits éloignés, le tout pour faciliter la correction d'erreur FEC. Ça veut bien dire qu'au décodage, les bits sont d'abord remis dans l'ordre, et qu'ensuite FEC est appliqué sur les bits remis dans l'ordre. Il n'y a aucun interêt à faire de l'entrelaçement si ça n'aide pas quelque part !
Les algos CRC (niveau trame j'ai l'impression) puis HEC (niveau cellule) permettent ensuite de valider si les données obtenues, et éventuellement corrigées, sont réellement valides ... ou pas ...
-- Herm
Didier
Herm a écrit :
"Didier" a écrit :
Herm a écrit :
"Channels" a écrit :
Le mode fastpath garde le mode de correction d'entrelacement et le mecanisme FEC puisque ca reste de l'interleaved, par contre, le mode DSLSafe est desactivé.
Ok, donc ça reste intéressant pour le lignes dont les erreurs sont corrigées par FEC, et qui ont au final peu de CRC / HEC...
Je voudrais juste dire que les CRC ne sont pas des FEC que ce mécanisme n'a pas réussi à corriger. Il y a bien deux codeurs, avec la matrice d'entrelacement entre les deux. Ce que code le codeur "FEC" n'a donc rien à voir avec le train binaire que voit le codeur "CRC". Donc, en réception, on a des FEC, erreurs corrigées sur ce qui ve entrer dans le désentrelaceur, puis passage dans le décodeur "CRC", qui déctectera d'éventuelles erreurs qu'ils ne corrigera pas. Didier.
Bonjour,
C'est pourtant ce que j'ai compris en lisant certains articles, comme : http://fr.wikipedia.org/wiki/Asymmetric_Digital_Subscriber_Line
Pour ma part, il me semblerait curieux que FEC soit d'abord appliqué sur la séquence de bits d'une trame reçue brute, et qu'ensuite le désentrelaçement soit appliqué...
Le but de l'entrelaçement étant de changer l'ordre des bits pour qu'en cas de perturbation touchant plusieurs bits d'affilés, cela corresponde en fait à des bits éloignés, le tout pour faciliter la correction d'erreur FEC. Ça veut bien dire qu'au décodage, les bits sont d'abord remis dans l'ordre, et qu'ensuite FEC est appliqué sur les bits remis dans l'ordre. Il n'y a aucun interêt à faire de l'entrelaçement si ça n'aide pas quelque part !
Les algos CRC (niveau trame j'ai l'impression) puis HEC (niveau cellule) permettent ensuite de valider si les données obtenues, et éventuellement corrigées, sont réellement valides ... ou pas ...
Toit à fait, j'ai vraiment trop approximé, et surtout j'ai eu la flemme de lire la doc (992.1 de l'ITU). Le modèle en émission est bien : CRC -> FEC -> entrelaceur -> codeur de constellation -> FFT -> tampon de sortie -> émission Ta remarque est très logique : on entrelace pour séparer les erreurs qui vont survenir en ligne. Néanmoins le train binaire entrant dans le codeur Reed-Solomon (FEC) vient du codeur CRC; il comporte donc des données de redondance. Il n'a donc rien à voir avec les données entrées dans ce codeur. Je pense donc que les CRC ne sont pas des "FEC dont la correction a échoué", ou des "dépassements" de la puissance du décodeur Reed-Solomon. Petite remarque : curieusement, la 992.1 donne des schémas ATU-R et ATU-C pour l'émission, pas pour la réception. Mais je ne l'ai pas lue en entier (274 pages). Didier.
Herm a écrit :
"Didier" a écrit :
Herm a écrit :
"Channels" a écrit :
Le mode fastpath garde le mode de correction d'entrelacement et le
mecanisme FEC puisque ca reste de l'interleaved, par contre, le mode
DSLSafe est desactivé.
Ok, donc ça reste intéressant pour le lignes dont les erreurs sont
corrigées par FEC, et qui ont au final peu de CRC / HEC...
Je voudrais juste dire que les CRC ne sont pas des FEC que ce
mécanisme n'a pas réussi à corriger.
Il y a bien deux codeurs, avec la matrice d'entrelacement entre les deux.
Ce que code le codeur "FEC" n'a donc rien à voir avec le train binaire
que voit le codeur "CRC".
Donc, en réception, on a des FEC, erreurs corrigées sur ce qui ve
entrer dans le désentrelaceur, puis passage dans le décodeur "CRC",
qui déctectera d'éventuelles erreurs qu'ils ne corrigera pas.
Didier.
Bonjour,
C'est pourtant ce que j'ai compris en lisant certains articles, comme :
http://fr.wikipedia.org/wiki/Asymmetric_Digital_Subscriber_Line
Pour ma part, il me semblerait curieux que FEC soit d'abord appliqué
sur la séquence de bits d'une trame reçue brute, et qu'ensuite le
désentrelaçement soit appliqué...
Le but de l'entrelaçement étant de changer l'ordre des bits pour qu'en
cas de perturbation touchant plusieurs bits d'affilés, cela corresponde
en fait à des bits éloignés, le tout pour faciliter la correction
d'erreur FEC. Ça veut bien dire qu'au décodage, les bits sont d'abord
remis dans l'ordre, et qu'ensuite FEC est appliqué sur les bits remis
dans l'ordre. Il n'y a aucun interêt à faire de l'entrelaçement si ça
n'aide pas quelque part !
Les algos CRC (niveau trame j'ai l'impression) puis HEC (niveau
cellule) permettent ensuite de valider si les données obtenues, et
éventuellement corrigées, sont réellement valides ... ou pas ...
Toit à fait, j'ai vraiment trop approximé, et surtout j'ai eu la flemme
de lire la doc (992.1 de l'ITU).
Le modèle en émission est bien :
CRC -> FEC -> entrelaceur -> codeur de constellation -> FFT -> tampon de
sortie -> émission
Ta remarque est très logique : on entrelace pour séparer les erreurs qui
vont survenir en ligne.
Néanmoins le train binaire entrant dans le codeur Reed-Solomon (FEC)
vient du codeur CRC; il comporte donc des données de redondance. Il n'a
donc rien à voir avec les données entrées dans ce codeur.
Je pense donc que les CRC ne sont pas des "FEC dont la correction a
échoué", ou des "dépassements" de la puissance du décodeur Reed-Solomon.
Petite remarque : curieusement, la 992.1 donne des schémas ATU-R et
ATU-C pour l'émission, pas pour la réception.
Mais je ne l'ai pas lue en entier (274 pages).
Didier.
Le mode fastpath garde le mode de correction d'entrelacement et le mecanisme FEC puisque ca reste de l'interleaved, par contre, le mode DSLSafe est desactivé.
Ok, donc ça reste intéressant pour le lignes dont les erreurs sont corrigées par FEC, et qui ont au final peu de CRC / HEC...
Je voudrais juste dire que les CRC ne sont pas des FEC que ce mécanisme n'a pas réussi à corriger. Il y a bien deux codeurs, avec la matrice d'entrelacement entre les deux. Ce que code le codeur "FEC" n'a donc rien à voir avec le train binaire que voit le codeur "CRC". Donc, en réception, on a des FEC, erreurs corrigées sur ce qui ve entrer dans le désentrelaceur, puis passage dans le décodeur "CRC", qui déctectera d'éventuelles erreurs qu'ils ne corrigera pas. Didier.
Bonjour,
C'est pourtant ce que j'ai compris en lisant certains articles, comme : http://fr.wikipedia.org/wiki/Asymmetric_Digital_Subscriber_Line
Pour ma part, il me semblerait curieux que FEC soit d'abord appliqué sur la séquence de bits d'une trame reçue brute, et qu'ensuite le désentrelaçement soit appliqué...
Le but de l'entrelaçement étant de changer l'ordre des bits pour qu'en cas de perturbation touchant plusieurs bits d'affilés, cela corresponde en fait à des bits éloignés, le tout pour faciliter la correction d'erreur FEC. Ça veut bien dire qu'au décodage, les bits sont d'abord remis dans l'ordre, et qu'ensuite FEC est appliqué sur les bits remis dans l'ordre. Il n'y a aucun interêt à faire de l'entrelaçement si ça n'aide pas quelque part !
Les algos CRC (niveau trame j'ai l'impression) puis HEC (niveau cellule) permettent ensuite de valider si les données obtenues, et éventuellement corrigées, sont réellement valides ... ou pas ...
Toit à fait, j'ai vraiment trop approximé, et surtout j'ai eu la flemme de lire la doc (992.1 de l'ITU). Le modèle en émission est bien : CRC -> FEC -> entrelaceur -> codeur de constellation -> FFT -> tampon de sortie -> émission Ta remarque est très logique : on entrelace pour séparer les erreurs qui vont survenir en ligne. Néanmoins le train binaire entrant dans le codeur Reed-Solomon (FEC) vient du codeur CRC; il comporte donc des données de redondance. Il n'a donc rien à voir avec les données entrées dans ce codeur. Je pense donc que les CRC ne sont pas des "FEC dont la correction a échoué", ou des "dépassements" de la puissance du décodeur Reed-Solomon. Petite remarque : curieusement, la 992.1 donne des schémas ATU-R et ATU-C pour l'émission, pas pour la réception. Mais je ne l'ai pas lue en entier (274 pages). Didier.
Herm
"Didier" a écrit :
[...] Néanmoins le train binaire entrant dans le codeur Reed-Solomon (FEC) vient du codeur CRC; il comporte donc des données de redondance. Il n'a donc rien à voir avec les données entrées dans ce codeur. Je pense donc que les CRC ne sont pas des "FEC dont la correction a échoué", ou des "dépassements" de la puissance du décodeur Reed-Solomon. Petite remarque : curieusement, la 992.1 donne des schémas ATU-R et ATU-C pour l'émission, pas pour la réception. Mais je ne l'ai pas lue en entier (274 pages). Didier.
Bonsoir,
Bon, j'ai tenté (encore une fois) de me plonger dans cette doc. Félicitation à ceux qui ont réussi à en comprendre le contenu, moi, je bloque, et cette relecture n' a rien changé :-(
Normalement, CRC n'ajoute qu'une somme de contrôle, alors que c'est FEC qui ajoute des données de redondance. C'est ce dernier, FEC, qui a la lourde tâche de tenter de réparer les erreurs de transmission. Le procédé n'est pas infaillible, il peut y avoir trop d'erreurs à corriger, ou il peut arriver que des erreurs se produisent dans ces données de redondance. CRC est donc là pour faire un premier niveau de vérification. Mais même CRC peut être pris en défaut : deux erreurs dans un même bloc, si elles sont bien 'choisies' peuvent "s'annuler" et tromper l'algo de vérification CRC, une dernière vérification est faite au niveau des cellules via le champ HEC.
Enfin, c'est comme ça que je me le représente, actuellement ...
... faute de mieux ...
-- Herm
"Didier" a écrit :
[...]
Néanmoins le train binaire entrant dans le codeur Reed-Solomon (FEC) vient
du codeur CRC; il comporte donc des données de redondance. Il n'a donc
rien à voir avec les données entrées dans ce codeur.
Je pense donc que les CRC ne sont pas des "FEC dont la correction a
échoué", ou des "dépassements" de la puissance du décodeur Reed-Solomon.
Petite remarque : curieusement, la 992.1 donne des schémas ATU-R et ATU-C
pour l'émission, pas pour la réception.
Mais je ne l'ai pas lue en entier (274 pages).
Didier.
Bonsoir,
Bon, j'ai tenté (encore une fois) de me plonger dans cette doc. Félicitation
à ceux qui ont réussi à en comprendre le contenu, moi, je bloque, et cette
relecture n' a rien changé :-(
Normalement, CRC n'ajoute qu'une somme de contrôle, alors que c'est FEC qui
ajoute des données de redondance. C'est ce dernier, FEC, qui a la lourde
tâche de tenter de réparer les erreurs de transmission. Le procédé n'est pas
infaillible, il peut y avoir trop d'erreurs à corriger, ou il peut arriver
que des erreurs se produisent dans ces données de redondance. CRC est donc
là pour faire un premier niveau de vérification. Mais même CRC peut être
pris en défaut : deux erreurs dans un même bloc, si elles sont bien
'choisies' peuvent "s'annuler" et tromper l'algo de vérification CRC, une
dernière vérification est faite au niveau des cellules via le champ HEC.
Enfin, c'est comme ça que je me le représente, actuellement ...
[...] Néanmoins le train binaire entrant dans le codeur Reed-Solomon (FEC) vient du codeur CRC; il comporte donc des données de redondance. Il n'a donc rien à voir avec les données entrées dans ce codeur. Je pense donc que les CRC ne sont pas des "FEC dont la correction a échoué", ou des "dépassements" de la puissance du décodeur Reed-Solomon. Petite remarque : curieusement, la 992.1 donne des schémas ATU-R et ATU-C pour l'émission, pas pour la réception. Mais je ne l'ai pas lue en entier (274 pages). Didier.
Bonsoir,
Bon, j'ai tenté (encore une fois) de me plonger dans cette doc. Félicitation à ceux qui ont réussi à en comprendre le contenu, moi, je bloque, et cette relecture n' a rien changé :-(
Normalement, CRC n'ajoute qu'une somme de contrôle, alors que c'est FEC qui ajoute des données de redondance. C'est ce dernier, FEC, qui a la lourde tâche de tenter de réparer les erreurs de transmission. Le procédé n'est pas infaillible, il peut y avoir trop d'erreurs à corriger, ou il peut arriver que des erreurs se produisent dans ces données de redondance. CRC est donc là pour faire un premier niveau de vérification. Mais même CRC peut être pris en défaut : deux erreurs dans un même bloc, si elles sont bien 'choisies' peuvent "s'annuler" et tromper l'algo de vérification CRC, une dernière vérification est faite au niveau des cellules via le champ HEC.
Enfin, c'est comme ça que je me le représente, actuellement ...
... faute de mieux ...
-- Herm
Didier
Herm a écrit :
"Didier" a écrit :
[...] Néanmoins le train binaire entrant dans le codeur Reed-Solomon (FEC) vient du codeur CRC; il comporte donc des données de redondance. Il n'a donc rien à voir avec les données entrées dans ce codeur. Je pense donc que les CRC ne sont pas des "FEC dont la correction a échoué", ou des "dépassements" de la puissance du décodeur Reed-Solomon. Petite remarque : curieusement, la 992.1 donne des schémas ATU-R et ATU-C pour l'émission, pas pour la réception. Mais je ne l'ai pas lue en entier (274 pages). Didier.
Bonsoir,
Bon, j'ai tenté (encore une fois) de me plonger dans cette doc. Félicitation à ceux qui ont réussi à en comprendre le contenu, moi, je bloque, et cette relecture n' a rien changé :-(
Normalement, CRC n'ajoute qu'une somme de contrôle, alors que c'est FEC qui ajoute des données de redondance. C'est ce dernier, FEC, qui a la lourde tâche de tenter de réparer les erreurs de transmission. Le procédé n'est pas infaillible, il peut y avoir trop d'erreurs à corriger, ou il peut arriver que des erreurs se produisent dans ces données de redondance. CRC est donc là pour faire un premier niveau de vérification. Mais même CRC peut être pris en défaut : deux erreurs dans un même bloc, si elles sont bien 'choisies' peuvent "s'annuler" et tromper l'algo de vérification CRC, une dernière vérification est faite au niveau des cellules via le champ HEC.
Enfin, c'est comme ça que je me le représente, actuellement ...
... faute de mieux ...
Pour moi, dans CRC, R="Redundance"; les deux codes fonctionnent avec de la redondance. Ce que je voulais dire, c'est que l'algo FEC s'applique à un train binaire dont il ignore la nature, en particulier qu'il sort du codeur CRC. C'est aux erreurs sur ce train binaire qu'il pourra appliquer en réception des corrections. Ce seront des erreurs en moins pour le CRC en réception. En ce sens il donne "un coup de pouce" au CRC, mais les deux s'occupent chacun de "leur" binaire. Quand au HEC, pour moi il ne s'occupe que des erreurs dans l'entête ATM. Mais bon, comme tu le dis, la doc n'est pas vraiment faite pour les amateurs. Quest-ce que c'était bien le RNIS ! Didier.
Herm a écrit :
"Didier" a écrit :
[...]
Néanmoins le train binaire entrant dans le codeur Reed-Solomon (FEC)
vient du codeur CRC; il comporte donc des données de redondance. Il
n'a donc rien à voir avec les données entrées dans ce codeur.
Je pense donc que les CRC ne sont pas des "FEC dont la correction a
échoué", ou des "dépassements" de la puissance du décodeur Reed-Solomon.
Petite remarque : curieusement, la 992.1 donne des schémas ATU-R et
ATU-C pour l'émission, pas pour la réception.
Mais je ne l'ai pas lue en entier (274 pages).
Didier.
Bonsoir,
Bon, j'ai tenté (encore une fois) de me plonger dans cette doc.
Félicitation à ceux qui ont réussi à en comprendre le contenu, moi, je
bloque, et cette relecture n' a rien changé :-(
Normalement, CRC n'ajoute qu'une somme de contrôle, alors que c'est FEC
qui ajoute des données de redondance. C'est ce dernier, FEC, qui a la
lourde tâche de tenter de réparer les erreurs de transmission. Le
procédé n'est pas infaillible, il peut y avoir trop d'erreurs à
corriger, ou il peut arriver que des erreurs se produisent dans ces
données de redondance. CRC est donc là pour faire un premier niveau de
vérification. Mais même CRC peut être pris en défaut : deux erreurs dans
un même bloc, si elles sont bien 'choisies' peuvent "s'annuler" et
tromper l'algo de vérification CRC, une dernière vérification est faite
au niveau des cellules via le champ HEC.
Enfin, c'est comme ça que je me le représente, actuellement ...
... faute de mieux ...
Pour moi, dans CRC, R="Redundance"; les deux codes fonctionnent avec de
la redondance.
Ce que je voulais dire, c'est que l'algo FEC s'applique à un train
binaire dont il ignore la nature, en particulier qu'il sort du codeur
CRC. C'est aux erreurs sur ce train binaire qu'il pourra appliquer en
réception des corrections.
Ce seront des erreurs en moins pour le CRC en réception.
En ce sens il donne "un coup de pouce" au CRC, mais les deux s'occupent
chacun de "leur" binaire.
Quand au HEC, pour moi il ne s'occupe que des erreurs dans l'entête ATM.
Mais bon, comme tu le dis, la doc n'est pas vraiment faite pour les
amateurs.
Quest-ce que c'était bien le RNIS !
Didier.
[...] Néanmoins le train binaire entrant dans le codeur Reed-Solomon (FEC) vient du codeur CRC; il comporte donc des données de redondance. Il n'a donc rien à voir avec les données entrées dans ce codeur. Je pense donc que les CRC ne sont pas des "FEC dont la correction a échoué", ou des "dépassements" de la puissance du décodeur Reed-Solomon. Petite remarque : curieusement, la 992.1 donne des schémas ATU-R et ATU-C pour l'émission, pas pour la réception. Mais je ne l'ai pas lue en entier (274 pages). Didier.
Bonsoir,
Bon, j'ai tenté (encore une fois) de me plonger dans cette doc. Félicitation à ceux qui ont réussi à en comprendre le contenu, moi, je bloque, et cette relecture n' a rien changé :-(
Normalement, CRC n'ajoute qu'une somme de contrôle, alors que c'est FEC qui ajoute des données de redondance. C'est ce dernier, FEC, qui a la lourde tâche de tenter de réparer les erreurs de transmission. Le procédé n'est pas infaillible, il peut y avoir trop d'erreurs à corriger, ou il peut arriver que des erreurs se produisent dans ces données de redondance. CRC est donc là pour faire un premier niveau de vérification. Mais même CRC peut être pris en défaut : deux erreurs dans un même bloc, si elles sont bien 'choisies' peuvent "s'annuler" et tromper l'algo de vérification CRC, une dernière vérification est faite au niveau des cellules via le champ HEC.
Enfin, c'est comme ça que je me le représente, actuellement ...
... faute de mieux ...
Pour moi, dans CRC, R="Redundance"; les deux codes fonctionnent avec de la redondance. Ce que je voulais dire, c'est que l'algo FEC s'applique à un train binaire dont il ignore la nature, en particulier qu'il sort du codeur CRC. C'est aux erreurs sur ce train binaire qu'il pourra appliquer en réception des corrections. Ce seront des erreurs en moins pour le CRC en réception. En ce sens il donne "un coup de pouce" au CRC, mais les deux s'occupent chacun de "leur" binaire. Quand au HEC, pour moi il ne s'occupe que des erreurs dans l'entête ATM. Mais bon, comme tu le dis, la doc n'est pas vraiment faite pour les amateurs. Quest-ce que c'était bien le RNIS ! Didier.
