Linux ne décolle pas...

Le 06-10-2009, ? propos de
Re: Linux ne décolle pas...,
remy ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Il ne faut pas exagérer non plus. Maintenant, j'ai parlé de
techniques de transmission, pas de restitution.

tiens justement je suis en pleine apnée dans le codage
alors parlons en de la technique de transmission
donc petit cours de ratrappage ,il n'y a pas de raison que je sois le
seul à lire les techniques de codage non mais



donc pour transmettre un signal l'on a 3 éléments physiques sur
lequel l'on peut agir la fréquence, l'amplitude et la phase



en combinant ses trois éléments l'on va obtenir un codage
par exemple un cercle trigonométrique sur lequel l'on
va représenter un déphasage de pi, donne (y=0 x=1) (y=0 x=-1)
si j'ai quatre états, un déphasage de pi/2, une croix ( en gros)
bon bref on a de mémoire actuellement 64 états
pour l'adsl et un peu moins pour le wifi

maintenant on imagine que autour de ses points ou états, je vais avoir
un décalage lié à l'environnement se qui implique que au lieu d'avoir
un seul point à la lecture ou détection de l'état, je vais avoir un
nuage de points

Ce n'est pas le problème. On fait alors un récepteur optimal avec
une détection sur les zones de Voronoï. Le souci ne vient pas du
bruit, mais du canal qui n'est plus ni gaussien ni même de Rice, et
là, ça commence à merdoyer sévèrement parce qu'en plus, il n'a
aucune raison d'être de Rayleigh et _stationnaire_.

et plus il y aura d'état différents plus il y aura de chance que les
nuages se recouvrent mais avant il faut savoir les détecter donc

C'est un faux problème.

pour cela on va utiliser une séquence prédéfinie qui va permettre
d'apprendre l'environnement et de synchroniser les systèmes de
détection en gros j'engrange une séquence que je décale pour avoir
la bonne lecture par rapport à la séquence prédéfinie
donc maintenant je suis synchro

Certainement pas. On utilise pour se synchroniser des FFT (la
synchronisation est faite en temps et en décalage de fréquence entre
les oscillateurs locaux de l'émetteur et du récepteur). Et on ne
fait pas ça directement avec une séquence dédiée mais avec le signal
lui-même. Tant qu'on peut éviter d'utiliser un canal de
synchronisation, on évite.

ensuite je vais demander une info faite avec le max d'éléments de
codage différents si je ne peux pas la détecter
je vais dégrader volontairement le débit en demandant une info
avec un peu moins d'éléments de codage

Quelle idée tordue... On calcule surtout la qualité du canal en
réception indépendamment des informations circulant sur ce canal.
Cette qualité peut être donnée par les coefficient du canal estimé
voire par le rapport Eb/N0 calculé en réception ou tout simplement
par le taux d'erreur binaire. Il n'y pas de mécanisme de test avec
échec. Ça se fait dans la continuité de la transmission.

tiens coucou voilà les différentes barres du téléphone portable ou du
wifi
ensuite pour faciliter la correction des erreurs, je vais n'avoir
qu'un élément qui change entre deux états proches dans le codage de
l'information 0000001 000000 déphasage 0*pi/4 ,1*pi/4

Sauf que si le 0000000 est toujours présent dans un codage (enfin,
sauf à faire des trucs pathologiques) parce que _linéraire_, le
0000001 n'y sera pas (sauf à vouloir avoir une distance de Shannon
unitaire, ce qui est parfaitement idiot). Ensuite, on utilise
subtilement les affectations de symboles sur la constellation ce qui
permet de réduire le nombre d'erreurs par mot.

ensuite par dessus l'on va avoir le codage a proprement parlé de
l'information, ben là on n'a pas le choix, il faut rajouter de l'info
pour faire de la correction d'erreurs

Mouais... Généralement, on fait codage de source puis codage de
canal et modulation, voire codage de source puis modulation codée
directement. Et on ne rajoute pas d'information, seulement de la
redondance. Si à ce niveau tu rajoutes de l'information, c'est du
bruit !

c'est de la cuisine mathématique les meilleurs se sont les français
qui ont été les premiers à atteindre la limite entropique de shannon
avec le turbo code

Non. Les turbocodes ne reposent sur aucune théorie mathématique,
c'est un bricolage (qu'on parle de turbocode parallèle ou série
d'ailleurs) et je suis bien placé pour le savoir vu que j'ai
modestement participé à l'élaboration du bricolage. Le turbocode
est un truc bidouillé avec les mains à l'ENST Paris qui
approche les performances des codes à faible densité (LDPC) qui eux
sont très proches de la limite de Shannon et qui eux se démontrent.

en gros bruit blanc + Shannon et quelque intégrale pour la limite
entropique pour le turbo code pas tout compris

Exprime-toi en français, je te l'ai déjà dit !

bon bref, le problème de la tnt en ville c'est qu'il n'y a pas d'auto
adaptation ou d'apprentissage de l'environnement,contrairement au
téléphone portable ou wifi voila pourquoi il y en a qui reçoive mieux
à la campagne qu'en ville.

Gnî ?

voilà voilà

Une fois de plus, tu n'as pas tout compris. Il y a _forcément_
adaptation au canal en réception (pas forcément égalisation au sens
strict du terme, parce que le démodulateur peut démoduler et
égaliser en _même_ temps). L'acquisition du canal peut aussi se
faire sans séquence d'apprentissage du tout, en utilisant les
statistiques des signaux et en partant du principe que ses signaux
sont des signaux _cohérents_ (contenant une information inconnue)
et non du bruit.

Bref, tu as encore du boulot...

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB a écrit :

Le 06-10-2009, ? propos de
Re: Linux ne décolle pas...,
remy ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Il ne faut pas exagérer non plus. Maintenant, j'ai parlé de
techniques de transmission, pas de restitution.

tiens justement je suis en pleine apnée dans le codage
alors parlons en de la technique de transmission
donc petit cours de ratrappage ,il n'y a pas de raison que je sois le
seul à lire les techniques de codage non mais



donc pour transmettre un signal l'on a 3 éléments physiques sur
lequel l'on peut agir la fréquence, l'amplitude et la phase



en combinant ses trois éléments l'on va obtenir un codage
par exemple un cercle trigonométrique sur lequel l'on
va représenter un déphasage de pi, donne (y=0 x=1) (y=0 x=-1)
si j'ai quatre états, un déphasage de pi/2, une croix ( en gros)
bon bref on a de mémoire actuellement 64 états
pour l'adsl et un peu moins pour le wifi

maintenant on imagine que autour de ses points ou états, je vais avoir
un décalage lié à l'environnement se qui implique que au lieu d'avoir
un seul point à la lecture ou détection de l'état, je vais avoir un
nuage de points

Ce n'est pas le problème. On fait alors un récepteur optimal avec
une détection sur les zones de Voronoï. Le souci ne vient pas du
bruit, mais du canal qui n'est plus ni gaussien ni même de Rice, et
là, ça commence à merdoyer sévèrement parce qu'en plus, il n'a
aucune raison d'être de Rayleigh et _stationnaire_.

et plus il y aura d'état différents plus il y aura de chance que les
nuages se recouvrent mais avant il faut savoir les détecter donc

C'est un faux problème.

c'est le principal problème ou dit différemment une représentation du
principal problème

pour cela on va utiliser une séquence prédéfinie qui va permettre
d'apprendre l'environnement et de synchroniser les systèmes de
détection en gros j'engrange une séquence que je décale pour avoir
la bonne lecture par rapport à la séquence prédéfinie
donc maintenant je suis synchro

Certainement pas. On utilise pour se synchroniser des FFT (la
synchronisation est faite en temps et en décalage de fréquence entre
les oscillateurs locaux de l'émetteur et du récepteur). Et on ne
fait pas ça directement avec une séquence dédiée mais avec le signal
lui-même. Tant qu'on peut éviter d'utiliser un canal de
synchronisation, on évite.

les fft ne permettent pas une détection de phase

ensuite je vais demander une info faite avec le max d'éléments de
codage différents si je ne peux pas la détecter
je vais dégrader volontairement le débit en demandant une info
avec un peu moins d'éléments de codage

Quelle idée tordue... On calcule surtout la qualité du canal en
réception indépendamment des informations circulant sur ce canal.
Cette qualité peut être donnée par les coefficient du canal estimé
voire par le rapport Eb/N0 calculé en réception ou tout simplement
par le taux d'erreur binaire. Il n'y pas de mécanisme de test avec
échec. Ça se fait dans la continuité de la transmission.

et ton taux d'erreur binaire il est basé sur quoi ?
donc on est d'accord et disons que Eb/N0=-1.6 db est la limite de
Shannon mais l'on parle là de calcul ,dans la vraie vie il y a une
"sorte de canal de service "

tiens coucou voilà les différentes barres du téléphone portable ou du
wifi
ensuite pour faciliter la correction des erreurs, je vais n'avoir
qu'un élément qui change entre deux états proches dans le codage de
l'information 0000001 000000 déphasage 0*pi/4 ,1*pi/4

Sauf que si le 0000000 est toujours présent dans un codage (enfin,
sauf à faire des trucs pathologiques) parce que _linéraire_, le
0000001 n'y sera pas (sauf à vouloir avoir une distance de Shannon
unitaire, ce qui est parfaitement idiot). Ensuite, on utilise
subtilement les affectations de symboles sur la constellation ce qui
permet de réduire le nombre d'erreurs par mot.

l'on est toujours d'accord ,sinon bien sûr ,que le zéro est toujours
présent et je pense que même le 1 aussi doit être présent
aïe pas la tête

ensuite par dessus l'on va avoir le codage a proprement parlé de
l'information, ben là on n'a pas le choix, il faut rajouter de l'info
pour faire de la correction d'erreurs

Mouais... Généralement, on fait codage de source puis codage de
canal et modulation, voire codage de source puis modulation codée
directement. Et on ne rajoute pas d'information, seulement de la
redondance. Si à ce niveau tu rajoutes de l'information, c'est du
bruit !

la redondance est liée au code auto correcteur

c'est de la cuisine mathématique les meilleurs se sont les français
qui ont été les premiers à atteindre la limite entropique de shannon
avec le turbo code

Non. Les turbocodes ne reposent sur aucune théorie mathématique,
c'est un bricolage (qu'on parle de turbocode parallèle ou série
d'ailleurs) et je suis bien placé pour le savoir vu que j'ai
modestement participé à l'élaboration du bricolage. Le turbocode
est un truc bidouillé avec les mains à l'ENST Paris qui
approche les performances des codes à faible densité (LDPC) qui eux
sont très proches de la limite de Shannon et qui eux se démontrent.

j'ai assisté il y a moins d'un mois à un exposé payé
avec la formation professionnelle sur le sujet histoire de se tenir
au courant mais je savais que tu n'allais pas être d'accord :-)

http://www.captronic.fr/actualites/seminaires/detail.asp?acidP19&fl_004_2=-1&fl_004_17/09/09&fl_004_18=&fl_0_f=%20&fl_004_21=1&ps00&ap00=1


l'intervenant est un enseignant chercheur sur Bordeaux donc son
maître de thèses était justement l'inventeur du turbo code, donc je
suppose qu'il avait quelques compétences

bon et comme je suis à la bourre, je vais dire que j'étais bouché



remy

JKB

--
http://remyaumeunier.chez-alice.fr/

Le 06-10-2009, ? propos de
Re: Linux ne décolle pas...,
remy ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Ce n'est pas le problème. On fait alors un récepteur optimal avec
une détection sur les zones de Voronoï. Le souci ne vient pas du
bruit, mais du canal qui n'est plus ni gaussien ni même de Rice, et
là, ça commence à merdoyer sévèrement parce qu'en plus, il n'a
aucune raison d'être de Rayleigh et _stationnaire_.

et plus il y aura d'état différents plus il y aura de chance que les
nuages se recouvrent mais avant il faut savoir les détecter donc

C'est un faux problème.

c'est le principal problème ou dit différemment une représentation du
principal problème

Non, c'est un faux problème parce qu'on s'arrange pour que ça
n'arrive pas en affectant les bits correctement sur les points de la
constellation.

pour cela on va utiliser une séquence prédéfinie qui va permettre
d'apprendre l'environnement et de synchroniser les systèmes de
détection en gros j'engrange une séquence que je décale pour avoir
la bonne lecture par rapport à la séquence prédéfinie
donc maintenant je suis synchro

Certainement pas. On utilise pour se synchroniser des FFT (la
synchronisation est faite en temps et en décalage de fréquence entre
les oscillateurs locaux de l'émetteur et du récepteur). Et on ne
fait pas ça directement avec une séquence dédiée mais avec le signal
lui-même. Tant qu'on peut éviter d'utiliser un canal de
synchronisation, on évite.

les fft ne permettent pas une détection de phase

Apprends-moi mon métier. J'ai écrit des papiers sur les problèmes de
synchronisation temps/fréquence. Tu remplaces la corrélation
habituelle par une FFT et tu retrouves un calage parfait en
fréquence, en temps _et_ en phase. J'ai même écrit un papier sur les
problèmes de synchronisation fréquence/phase de l'UMTS en démontrant
qu'avec les specs de la norme (quartz à 2E-6), il était impossible
d'effectuer une synchronisation sans un canal dédié. Ce papier est
dans IEEExplore, démerde-toi pour le trouver. C'est en anglais. Je
dois avoir quelque part des archives de travaux préliminaires en
français, mais j'ai la flemme de les chercher.

ensuite je vais demander une info faite avec le max d'éléments de
codage différents si je ne peux pas la détecter
je vais dégrader volontairement le débit en demandant une info
avec un peu moins d'éléments de codage

Quelle idée tordue... On calcule surtout la qualité du canal en
réception indépendamment des informations circulant sur ce canal.
Cette qualité peut être donnée par les coefficient du canal estimé
voire par le rapport Eb/N0 calculé en réception ou tout simplement
par le taux d'erreur binaire. Il n'y pas de mécanisme de test avec
échec. Ça se fait dans la continuité de la transmission.

et ton taux d'erreur binaire il est basé sur quoi ?

Sur un calcul du décodeur (taux d'erreur réel ou estimateur).

donc on est d'accord et disons que Eb/N0=-1.6 db est la limite de
Shannon mais l'on parle là de calcul ,dans la vraie vie il y a une
"sorte de canal de service "

Un canal de service... Comme l'escalier ? Le taux d'erreur binaire
_théorique_ dépend du Eb/N0 _et_ du canal.

tiens coucou voilà les différentes barres du téléphone portable ou du
wifi
ensuite pour faciliter la correction des erreurs, je vais n'avoir
qu'un élément qui change entre deux états proches dans le codage de
l'information 0000001 000000 déphasage 0*pi/4 ,1*pi/4

Sauf que si le 0000000 est toujours présent dans un codage (enfin,
sauf à faire des trucs pathologiques) parce que _linéraire_, le
0000001 n'y sera pas (sauf à vouloir avoir une distance de Shannon
unitaire, ce qui est parfaitement idiot). Ensuite, on utilise
subtilement les affectations de symboles sur la constellation ce qui
permet de réduire le nombre d'erreurs par mot.

l'on est toujours d'accord ,sinon bien sûr ,que le zéro est toujours
présent et je pense que même le 1 aussi doit être présent
aïe pas la tête

Si le 1 est présent, mathématiquement, cela revient à ne pas ajouter
de redondance, donc de capacité de détection d'erreur ou de
correction (ce sont _deux_ notions _différentes_) mais c'est toi qui voit.

ensuite par dessus l'on va avoir le codage a proprement parlé de
l'information, ben là on n'a pas le choix, il faut rajouter de l'info
pour faire de la correction d'erreurs

Mouais... Généralement, on fait codage de source puis codage de
canal et modulation, voire codage de source puis modulation codée
directement. Et on ne rajoute pas d'information, seulement de la
redondance. Si à ce niveau tu rajoutes de l'information, c'est du
bruit !

la redondance est liée au code auto correcteur

'auto-correcteur' ? Qu'est-ce qu'il ne faut pas lire. Commence par
relire et _comprendre_ les bases de la théorie de l'information.
L'information est l'information, c'est la même qu'elle soit portée
par $n$ symbole ou par le double. La différence entre les deux est
la redondance.

c'est de la cuisine mathématique les meilleurs se sont les français
qui ont été les premiers à atteindre la limite entropique de shannon
avec le turbo code

Non. Les turbocodes ne reposent sur aucune théorie mathématique,
c'est un bricolage (qu'on parle de turbocode parallèle ou série
d'ailleurs) et je suis bien placé pour le savoir vu que j'ai
modestement participé à l'élaboration du bricolage. Le turbocode
est un truc bidouillé avec les mains à l'ENST Paris qui
approche les performances des codes à faible densité (LDPC) qui eux
sont très proches de la limite de Shannon et qui eux se démontrent.

j'ai assisté il y a moins d'un mois à un exposé payé
avec la formation professionnelle sur le sujet histoire de se tenir
au courant mais je savais que tu n'allais pas être d'accord :-)

http://www.captronic.fr/actualites/seminaires/detail.asp?acidP19&fl_004_2=-1&fl_004_17/09/09&fl_004_18=&fl_0_f=%20&fl_004_21=1&ps00&ap00=1

À mon avis, tu n'as pas du tout comprendre.

l'intervenant est un enseignant chercheur sur Bordeaux donc son
maître de thèses était justement l'inventeur du turbo code, donc je
suppose qu'il avait quelques compétences

Il n'y a pas eu _un_ inventeur du turbo-code. Et je te prie de
croire ce que je dis, j'y étais. Il y a eu _une_ équipe, avec des
_tas_ d'articles. Ce n'est que quelques années plus tard qu'on s'est
rendu compte que le turbo-code est un cas (dégénéré) de code LDPC.
Je ne vais pas rentrer dans le détail, je ne suis pas convaincu que
tu puisses me suivre vu ce que tu as écrit plus haut.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB a écrit :

dans IEEExplore, démerde-toi pour le trouver. C'est en anglais.

branli-branla va pas aimer...

A+
JF

Le 06-10-2009, ? propos de
Re: Linux ne décolle pas...,
Cumbalero ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

dans IEEExplore, démerde-toi pour le trouver. C'est en anglais.

branli-branla va pas aimer...

De toute façon, il ne sait pas ce qu'est une FFT et son rapport
signal sur bruit est largement négatif !

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

On 2009-10-06, Cumbalero <cumbalero@NOSPAM.yahoo.fr> wrote:

dans IEEExplore, démerde-toi pour le trouver. C'est en anglais.

branli-branla va pas aimer...

Mais il va quand même analyser le document. Dans son blog...


--

Encore que je ne sois pas sur que cela fonctionne tout le temps.

Il ne me reste plus que le fusil de chasse ou le SAM-7.

Le SAM 7 c'est le petit nom de vidéolan avec le plugin "mauvaise foi" ?

Sam, mauvaise foi ? vois pas le rapport.

Le Tue, 06 Oct 2009 09:52:08 +0000, JKB a écrit :

rapport signal sur bruit (...) négatif

est-ce Dieu possible ?

JKB a écrit :

Le 06-10-2009, ? propos de
Re: Linux ne décolle pas...,
remy ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Ce n'est pas le problème. On fait alors un récepteur optimal avec
une détection sur les zones de Voronoï. Le souci ne vient pas du
bruit, mais du canal qui n'est plus ni gaussien ni même de Rice, et
là, ça commence à merdoyer sévèrement parce qu'en plus, il n'a
aucune raison d'être de Rayleigh et _stationnaire_.

et plus il y aura d'état différents plus il y aura de chance que les
nuages se recouvrent mais avant il faut savoir les détecter donc

C'est un faux problème.

c'est le principal problème ou dit différemment une représentation du
principal problème

Non, c'est un faux problème parce qu'on s'arrange pour que ça
n'arrive pas en affectant les bits correctement sur les points de la
constellation.

pourquoi tu compliques tout c'est pas possible
une fréquence avec n déphasage de phases
tu prends un cercle de trigo
tu fais des croix rouges sur ce putain de cercle
qui représente les n déphasages

à la lecture en fonction et après détection des différents états et en
fonction de l'environnement ta lecture ne sera pas exactement sur les
croix précédemment definies

tu auras un nuage autour de ses croix rouges et plus il y aura de
croix rouges plus les nuages pourront se recouvrir et donc
augmenteront le taux d'erreur

ensuite tu prends un canal de service et tu negocies le bout de gras
pour avoir le moins d'erreurs possible tout en gardant le plus de
croix rouges possible et accessoirement tu peux utiliser le canal de
service pour faire de la synchro j'ai pas écrit que l'on ne pouvait
pas s'en passer

et cela d'un point de vue mathématique, c'est Shannon plus un bruit
gaussien

après l'on peut parler entropie ,code détection d'erreurs ,
code correcteur ,codage de l'information ou compression



mais la tnt ne négocie pas le bout de gras le wifi et le téléphone
portable le négocie

tu peux ne pas être d'accord mais cela ne changera rien à la norme






--
http://remyaumeunier.chez-alice.fr/

On 2009-10-06, Professeur Méphisto <professeur.mephisto@wanadooooo.fr> wrote:

rapport signal sur bruit (...) négatif

est-ce Dieu possible ?

Newsgroups: fr.comp.os.linux.debats

Le 06-10-2009, ? propos de
Re: Linux ne décolle pas...,
remy ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Le 06-10-2009, ? propos de
Re: Linux ne décolle pas...,
remy ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Ce n'est pas le problème. On fait alors un récepteur optimal avec
une détection sur les zones de Voronoï. Le souci ne vient pas du
bruit, mais du canal qui n'est plus ni gaussien ni même de Rice, et
là, ça commence à merdoyer sévèrement parce qu'en plus, il n'a
aucune raison d'être de Rayleigh et _stationnaire_.

et plus il y aura d'état différents plus il y aura de chance que les
nuages se recouvrent mais avant il faut savoir les détecter donc

C'est un faux problème.

c'est le principal problème ou dit différemment une représentation du
principal problème

Non, c'est un faux problème parce qu'on s'arrange pour que ça
n'arrive pas en affectant les bits correctement sur les points de la
constellation.

pourquoi tu compliques tout c'est pas possible
une fréquence avec n déphasage de phases
tu prends un cercle de trigo
tu fais des croix rouges sur ce putain de cercle
qui représente les n déphasages

C'est un cas particulier mais pourquoi pas.

à la lecture en fonction et après détection des différents états et en
fonction de l'environnement ta lecture ne sera pas exactement sur les
croix précédemment definies

Oui, et ?

tu auras un nuage autour de ses croix rouges et plus il y aura de
croix rouges plus les nuages pourront se recouvrir et donc
augmenteront le taux d'erreur

Ce que j'essaye d'enfoncer dans ton crâne, c'est que la numérotation
des points de la constellation est faite en sorte de minimiser le
taux d'erreur, même si tu passes de l'une de tes croix rouges à une
autre. Ce que j'essaye aussi de te faire comprendre, c'est que tu
n'as peut-être pas le droit d'utiliser tous les symboles en même
temps, ce qui fait que ton raisonnement ne tient pas. Regarde ce
qu'est un codage de Gray d'une constellation ou une modulation
codée. Ce n'est pas parce que tu as des points adjacents que ces
points sont utilisables donc valides à un instant $t$ et que la
distance minimale de fausse décision de ton récepteur optimal vaut
la distance entre ces points sur deux (dans ton cas). Ce n'est pas
non plus parce que ton symbole de réception est faux que les bits
transmis, après correction, le seront.

ensuite tu prends un canal de service

Un canal de service, c'est comme du beurre en broche, ça n'existe
pas. Un canal est gaussien, à évanouissement, binaire, whatever,
mais pas de service. C'est l'escalier qui est de service !

et tu negocies le bout de gras
pour avoir le moins d'erreurs possible tout en gardant le plus de
croix rouges possible et accessoirement tu peux utiliser le canal de
service pour faire de la synchro j'ai pas écrit que l'on ne pouvait
pas s'en passer

et cela d'un point de vue mathématique, c'est Shannon plus un bruit
gaussien

Non ! Mais après tout, si tu en es convaincu... Un canal, c'est
grossièrement et en première approximation un filtre échantillonné
(pour une transmission numérique), c'est bien plus qu'un bruit
gaussien.

après l'on peut parler entropie ,code détection d'erreurs ,
code correcteur ,codage de l'information ou compression



mais la tnt ne négocie pas le bout de gras le wifi et le téléphone
portable le négocie

Le téléphone portable ne négocie rien. Même l'UMTS ne négocie rien,
il mesure les interférences et choisit un facteur d'étalement (un
code d'Hadamard) en conséquence pour modifier le rapport Eb/N0 du
canal _après_ démodulation WB-CDMA qui elle ne change pas. La modulation
ne change absolument pas en fonction du canal, c'est le traitement du signal
en bande intermédiaire ou bande de base (je ne sais pas comment
c'est implanté dans les trucs du commerce, mais nous, on bossait en bande
de base) qui compense. Et ça fonctionne parce qu'on parle d'énergie
sur variance du bruit et non de puissance.

tu peux ne pas être d'accord mais cela ne changera rien à la norme

Je ne suis pas d'accord avec les conneries que tu avances et qui
prouvent que tu n'as strictement rien compris au problème. Et ce
n'est pas le fait d'avoir assisté à une conférence qui te permet de
dire que tu t'y connais. Tu commenceras à être crédible lorsque tu
auras _compris_ (je ne dis pas _lu_) le bouquin fondateur de Claude
Shannon, quelques articles de Gallager, de Glavieux et de quelques
autres, et au moins le Proakis. Pour l'instant, tu brasses du vent.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.