Linky: La TIC historique modifiée?

[mjfcolas]

Bonjour à tous,

Un linky a été installé dans mon appartement. J'avais branché sur mon ancien compteur un jack qui me permettait d'enregistrer via une entrée casque le signal de la TIC, et de traiter le fichier "audio" obtenu pour pouvoir lire les informations qui y sont diffusées. Ça fonctionnait bien, j'étais content!

Le linky possède deux mode de TICs: La TIC historique, qui est d'après la doc enedis, la même que l'ancienne, configurée par défaut sur les linky, pour des questions de rétro compatibilité j'imagine, et la tic standard qui permet d'obtenir plus de données.

J'ai donc rebranché mon jack sur le linky, et la ... plus rien ne fonctionnait! J'ai du adapter mon programme pour le rendre compatible avec le linky.
En analysant les signaux fournis par le linky, j'ai découvert deux différences avec l'ancienne TIC qui rendaient mon programme obsolète.

1) Un caractère semble maintenant être transmis sur 11 bits à la place de 10
2) Il y a une pause dans la transmission après chaque retour à la ligne. Précédemment, la pause dans la transmission n'arrivait qu'à la fin de la trame.

Plus de détails à la fin du post

Est ce que quelqu'un sait expliquer ces changements ? On pouvait trouver sur internet des "lecteurs" à brancher sur les anciens compteurs. Est ce que ces derniers sont encore compatibles avec le linky ?

De mon côté, tout refonctionne, du coup, je n'ai pas spécialement de problème avec ça, mais je trouve ça bizarre!


Détails sur les changements que j'ai pu observer:

Une trame est diffusée sur plusieurs lignes sous la forme:
STX: Start text
LF: Line feed
Clé: par ex ADCO (pour la clé correspondant à l'adresse du compteur)
SP: Space
Valeur: par exemple adresse du compteur
SP
Checksum
CR: Carriage return
LF
Clé
...
ETX: End text

Un caractère est normalement codé sur 10 bits (d'après la doc enedis) : START, 7 bits qui représentent le caractère ASCII, parité, STOP

Voila une image ou je représente les bits de l'ancien compteur et du nouveau compteur. Les espaces sont simplement la pour mieux visualiser, pas de trous dans la réalité.



Comme on peut le voir, avec le linky, le bit de stop a l'air doublé, et après les CR, il y a une série de 1 non présente sur l'ancien compteur. Ces changements ne sont absolument pas mentionnés dans la doc.
-----

[invitee05a3fcc]

Bon , je pense que tu as inversé Linky et ancien

- On ne parle pas de "0" ou de "1" mais de Mark et Space
- La norme asynchrone autorise un ou deux bit stop (Mark)

Donc les deux formats que tu donnes sont rigoureusement compatibles avec la norme

Si tu as des problèmes de réception avec le Linky, c'est que tu as un UART (probablement soft ) qui est mal fait

[mjfcolas]

Merci pour ton lien!

Effectivement, Linky et Ancien sont inversés sur la capture.

L'UART peut être effectivement mal fait. Vu qu'il est maison, et plus basé sur mon interprétation du signal que sur la norme.

Est ce qu'il est possible de "détecter" le nombre de bits de stops ? Ou c'est une donnée qui doit être précisée?
Je me suis basé la dessus: http://www.enedis.fr/sites/default/f...OI-CPT_54E.pdf
Page 12, il est précisé qu'il y a 1 bit de stop.

Pour les Spaces après un CR, j'imagine qu'une UART bien faite attends le prochain bit de start, et doit pouvoir s'adapter à ce genre de signal.

[invitee05a3fcc]

L'UART peut être effectivement mal fait. Vu qu'il est maison, et plus basé sur mon interprétation du signal que sur la norme.

C'est un UART soft ou un UART intégré à un µC ?

Est ce qu'il est possible de "détecter" le nombre de bits de stops ? Ou c'est une donnée qui doit être précisée?

Le stop (niveau Mark) doit durer au moins la durée d'un bit. Et il peut durer plus longtemps (c'est le niveau de repos si il n'y a plus de caractère à transmettre .

Pour les Spaces après un CR, j'imagine qu'une UART bien faite attends le prochain bit de start, et doit pouvoir s'adapter à ce genre de signal.

Pour les Mark après un CR ! Oui (voir la norme de transmission en asynchrone)

[A voir en vidéo sur Futura]

[mjfcolas]

C'est du soft. Le signal analogique est enregistré sur l'entrée casque d'un ordinateur, et le fichier .wav est traité après l'enregistrement par un soft.

Merci pour ces réponses.

[invitee05a3fcc]

C'est du soft. Le signal analogique est enregistré sur l'entrée casque d'un ordinateur, et le fichier .wav est traité après l'enregistrement par un soft.

Donc ton traitement n'est pas conforme à la norme asynchrome

Linky: La TIC historique modifiée?

Pas modifié, il est conforme à la norme

[invitee05a3fcc]

l'algorithme sommaire de réception d'un mot (7 bits + parité) est le suivant :
La ligne est en Mark (pas de transmission)

1. On attend la transition Mark/Space
2. On attend la durée d'un demi-bit
3. On contrôle qu'on est toujours en Space (Sinon erreur)
4. On charge un compteur avec 8
5. On attend la durée d'un bit
6. Si on trouve un Space sur la ligne on présente un "0" en entrée d'un registre à décalage 8 bits à partir de la gauche. Si on trouve un Mark sur la ligne on présente un "1" en entrée d'un registre à décalage 8 bits à partir de la gauche
7. On décale le registre d'un bit vers la droite . On décrémente le compteur
8. Si le compteur n'est pas à zéro, GOTO 5.
9. On contrôle la parité de l'octet stocké dans le registre à décalage 8 bits (sinon erreur)
10. On attend la durée d'un bit
11. Si on trouve un Mark sur la ligne on a bien le premier bit stop (sinon erreur)
12. On fait un AND sur le registre à décalage avec le masque 01111111 (élimination du bit de parité)
13. Le caractère reçu se trouve dans le registre à décalage. on le stocke dans un buffer
14. GOTO 1.

PS : Je te laisse cogiter la gestion des cas d'erreur