Introduction
Je ne publie pas autant d’articles qu’escompté, vie de famille oblige !
Néanmoins, la fin de la 2G approche à grands pas chez tous les opérateurs français… J’ai donc pris quelques heures çà et là pendant les vacances d’été pour procéder à une première rétro-ingénierie de mon module Diagral DIAG55AAX, et voir ce qu’il serait possible de faire pour le rendre compatible 4G ou bien le remplacer par une solution alternative.
Avant d’aller plus loin… un peu de juridique !
Avant de sortir le fer à souder et l’analyseur logique, une petite parenthèse juridique s’impose. L’objectif de cette analyse n’est pas de copier le DIAG55AAX, mais de comprendre son fonctionnement afin de développer éventuellement une solution indépendante capable de remplacer sa connectivité 2G par de la 4G/VoLTE.
Cette démarche est menée à titre strictement personnel et expérimental, sans aucune velléité commerciale ni intention de nuire à Diagral ou à ses produits. Je vais rester dans une approche « boîte noire » : observation des signaux et des échanges entre les composants, essais empiriques et analyse du comportement du matériel. Pas d’extraction ou de décompilation de firmware, pas de rétro-ingénierie du protocole radio Diagral et, bien entendu, aucun accès aux infrastructures du constructeur.
Le Code de la propriété intellectuelle prévoit par ailleurs, sous certaines conditions, la possibilité pour l’utilisateur légitime d’observer et d’étudier le fonctionnement d’un logiciel, ainsi que certaines exceptions liées à l’interopérabilité
Bref, l’idée est simplement de comprendre ce que fait le DIAG55AAX depuis l’extérieur, puis de tenter de reproduire son comportement avec notre propre matériel et notre propre code.
Ouverture et première analyse visuelle
En préambule, petit rappel sur la composition de ce module. En face avant il est doté d’un port coaxial pour raccorder une antenne externe et d’un connecteur 2 broches pour relier la batterie lithium.
En face arrière, il est doté d’un connecteur mâle de 20 broches réparties sur 2 rangées, et à écartement standard de 2,54mm. Il dispose aussi d’un port pour glisser la carte SIM.
L’ouverture du boitier plastique se fait facilement en écartant légèrement les 4 pattes de fixation.
En face avant du circuit, on constate la présence de :
- Un chipset radio de marque TELIT, modèle GM865 v3.1. (Sur un autre modèle à ma disposition, plus ancien et datant de 2018, le chipset est en v3)
- Un circuit intégré MCP6424 de chez Microchip : il s’agit d’un quadruple Amplificateur opérationnel (AOP)
- Un circuit intégré 26F032B de chez Microchip : il s’agit d’une mémoire flash de 32Mbit (4 Mo) communiquant via un bus SPI.
En face arrière du circuit (coté broches), on constate la présence de :
- Un circuit intégré 25Q03213E40 de chez Micron : il s’agit à nouveau d’une mémoire flash de 32Mbit (4 Mo) communiquant via un bus SPI.
- Un circuit intégré sous cage : il s’agit très probablement d’un microcontrôleur
- Un circuit intégré YF08E de chez Texas Instruments : il s’agit d’un adaptateur de niveau logique à 8 canaux
Mes premiers constats et hypothèses :
- Le quadruple AOP semble affecté au traitement audio venant ou restitué à la centrale (à confirmer)
- L’adaptateur de niveau logique est en coupure entre le microcontrôleur et le chipset Telit. Il doit certainement adapter les niveaux logiques du microcontrôleur (probablement 3,3V) avec ceux attendus par le Telit (probablement 1,8V)
- Il existe 2 mémoires flash : une doit contenir le firmware et une autre les données (probablement des enregistrements audio)
- Cela signifie aussi qu’il est fort probable que la centrale DIAG91AGFK ne gère pas directement les communications audio et SMS. Elle reçoit des ordres de la DIAG91AGFK pour la configuration ou en cas d’alerte, mais le traitement des communications sous-jacentes reste délégué au module DIAG55AAX.
Bien évidemment, pas question de dessouder les 2 mémoires flash pour faire un dump du contenu. On va plutôt se concentrer dans un premier sur les signaux entre la DIAG91AGFK et le DIAG55AAX, ainsi que les signaux échangés avec le module Telit.
Analyse au multimètre du YF08E
Le Microcontrôleur semble sous cage, et semble être soudé en BGA, donc impossible de déterminer où il est connecté sans détruire le module.
Néanmoins, on peut faire l’analyse coté Telit.
| Broche YF08E | Broche Telit GM865 | Commentaire |
|---|---|---|
| 1 | RTS | UART RS232 |
| 3 | RXD | UART RS232 |
| 4 | TXD | UART RS232 |
| 5 | DTR | UART RS232 |
| 6 | DVI_WA0 | Word Alignment audio numérique |
| 7 | DVI_RX | RX audio numérique (son à émettre vers la communication vocale) |
| 8 | DVI_TX | TX audio numérique (retour audio communication vocale) |
| 9 | DVI_CLK | Signal d’horloge audio numérique |
| 10 | PWRMON | Indique si le module Telit est opérationnel |
On constate qu’en plus de l’UART, le module utilise une interface dénommée DVI. Mais a quoi sert cette interface ? Il s’agit d’une interface numérique permettant de transmettre le signal audio, à la norme I²S.
D’ailleurs, en regardant de plus près, les broches audio analogique du module Telit ne semblent pas câblées sur le PCB. Donc :
- Soit le signal est généré par le module et il y a une restitution analogique vers la centrale
- Soit le signal est reçu en analogique puis converti en numérique par le microcontrôleur. Il est probable que ce soit cette option sinon on ne pourrait pas faire d’écoute avec le micro de l’alarme.
Analyse des échanges entre la centrale sirène et le module
La centrale sirène est couplé avec le module via 20 broches.
On note la présence des chiffres 1 et 2 au niveau des broches les plus au bord, c’est donc cet ordre que j’utiliserai à l’avenir
Pour se mettre en écoute sur ces 20 broches, j’ai réalisé un module « sandwich » sur une plaque perforée et dotée de broches de repiquages coudées à 90°. Les broches du haut (paires) sont déportées à droite.
Une première analyse m’a permis d’identifier au multimètre les broches de masse, au nombre de 5, ainsi que les 3 broches positives d’alimentation (5V sur secteur, 4,5V sur piles) et les 2 broches positives de la batterie de secours au lithium.
Reste donc 10 broches à analyser. Pour cela je me suis doté d’un analyseur logique LHT00SU1, via AliExpress. Il est doté de 2 entrées analogiques (-10V à +10V) et 8 entrées numériques (0V à 5V). Compte tenu des niveaux d’alimentation de la Diagral, cela fera amplement l’affaire !
Le logiciel opensource PulseView sera utilisé pour la partie capture et analyse. L’installation du driver USB du LHT00SU1 se fait via le logiciel Zadig. Il est ensuite reconnu par PulseView en tant que « CWAV USBee AX-Pro« , via le driver fx2lafw. Le 2ème canal analogique n’est pas disponible.
Le logiciel sigrok-cli (complémentaire à PulseView) sera utilisé également pour l’extraction de données.
Pour stimuler le module, j’ai utilisé 2 commandes sur la centrale :
- #660## : test du niveau de signal. La centrale annonce à intervalles réguliers le niveau de signal reçu
- #581## : appel vocal du premier correspondant puis écoute téléphonique possible une fois validation reçue par la touche 0.
Les premières analyses en analogique ont mis en évidence que 4 broches sont dévolues à la réception et émission audio en analogique. L’analyse des 6 broches restantes s’est faite uniquement en numérique.
In fine, voici la fonction de chacune des 20 broches :
| Broche connecteur | Destination | Fonction |
|---|---|---|
| 1 | Micro centrale | Signal analogique |
| 2 | Haut-parleur centrale | Signal analogique |
| 3 | Micro centrale | Signal analogique |
| 4 | Haut-parleur centrale | Signal analogique |
| 5 | GND | |
| 6 | GND | |
| 7 | ?? | Passe à 1 au démarrage de la centrale et semble rester ainsi |
| 8 | RX centrale | Echange de données RS232 entre la centrale et le module |
| 9 | ?? | Passe à 1 au démarrage de la centrale et semble rester ainsi |
| 10 | TX centrale | Echange de données RS232 entre la centrale et le module |
| 11 | Emission/Reception | La broche passe à 1 quand un échange de données a lieu entre la centrale et le module |
| 12 | ?? | |
| 13 | GND | |
| 14 | GND | |
| 15 | GND | |
| 16 | 5V USB ou 4,5V piles | Alimentation du module |
| 17 | VBAT (batterie lithium) | Envoi tension batterie lithium vers l’alarme (secours absence de tension secteur) |
| 18 | 5V USB ou 4,5V piles | – |
| 19 | VBAT (batterie lithium) | – |
| 20 | VBAT (batterie lithium) | – |
Remarques :
- Les échanges UART se font avec un débit de 115200 bauds, et ne contiennent aucune donnée de type « commande AT » a destination du module Telit. Cela renforce l’hypothèse où le module est autonome dans la gestion des communications voix/SMS.
- Pour la partie audio, il est toujours difficile de savoir si c’est la centrale ou bien le module qui génère les sons
Analyse simultanée UART centrale <> module et module <> Telit
J’ai relié les broches D0 à D5 de l’analyseur logique comme suit sur mon module de repiquage.
Puis j’ai rajouté 2 fils soudés directement sur les broches RX et TX du Telit, et connectés aux 2 broches numériques restantes de l’analyseur logique (D6 et D7)
On constate un dialogue vers le Telit en UART à 115200 baud avec un certain nombre de commandes AT.
Un ordre émanant de la Diagral peut être traduit en plusieurs commandes AT indépendantes. Cela confirme bien que le module DIAG55AAX est autonome dans la gestion de ses communications en fonction des consignes de la centrale sirène.
Pour simplifier l’analyse, j’ai réalisé un extrait des commandes AT RX puis la réponse sur TX via le logiciel sigrok-cli
sigrok-cli -i "capture pulseview.sr" -P uart:rx=D6:tx=D7:baudrate=115200:format=ascii -B uart=rx > "output_rx.txt"
sigrok-cli -i "capture pulseview.sr" -P uart:rx=D6:tx=D7:baudrate=115200:format=ascii -B uart=tx > "output_tx.txt"Les commandes UART utilisées sont généralement standards, mais un certain nombre sont spécifiques à Telit.
Voici une synthèse des commandes utilisées à la mise sous tension, lors d’un appel et lors d’un test de qualité de signal (merci l’IA) :
| Commande | Catégorie | Type | Fonction |
|---|---|---|---|
AT | Générique / Hayes | Test | Vérifie que le modem répond. |
ATE0V0Q0 | Générique / Hayes | Configuration | Désactive l’écho (E0), sélectionne les réponses numériques (V0) et active les codes de résultat (Q0). |
AT+CMEE=1 | Générique / 3GPP | Configuration | Active les messages d’erreur étendus +CME ERROR. |
AT+GMR | Générique / 3GPP | Lecture | Demande la version du firmware. |
AT+GMM | Générique / 3GPP | Lecture | Demande l’identification/modèle du modem. |
AT#JDR=0 | Telit | Configuration | Désactive la fonction de détection/notification de brouillage radio (Jammed Detect & Report). |
AT+COPS=0,2 | Générique / 3GPP | Configuration | Sélection automatique de l’opérateur, avec format numérique du PLMN. |
AT+CCID | Générique / 3GPP/Telit | Lecture | Demande l’ICCID de la carte SIM. |
ATV1 | Générique / Hayes | Configuration | Sélectionne les réponses sous forme textuelle (OK, ERROR, etc.). |
AT+CPIN? | Générique / 3GPP | Lecture | Interroge l’état du verrouillage SIM/PIN. |
ATV0 | Générique / Hayes | Configuration | Sélectionne les réponses sous forme numérique. |
AT+CPIN=1234 | Générique / 3GPP | Exécution | Fournit le PIN SIM 1234. |
AT+CMGF=1 | Générique / 3GPP | Configuration | Sélectionne le mode SMS texte. |
AT#DIALMODE=1 | Telit | Configuration | Configure le comportement de ATD lors d’un appel vocal. |
AT+CLVL=12 | Générique / 3GPP | Configuration | Définit le niveau de volume audio du haut-parleur. |
AT\R2 | Telit / Hayes | Configuration | Configure le comportement de la sortie RI (Ring Indicator). |
AT+CNMI=1,1 | Générique / 3GPP | Configuration | Configure la notification des SMS entrants, notamment via +CMTI. |
AT#JDR=1 | Telit | Configuration | Active la fonction de détection/notification de brouillage radio. |
AT+CREG? | Générique / 3GPP | Lecture | Interroge l’état d’enregistrement du modem sur le réseau GSM. |
AT#RFSTS | Telit | Lecture | Retourne les informations détaillées sur l’état radio et la cellule courante. |
AT#CODEC=01 | Telit | Configuration | Configure le codec audio utilisé ; 01 correspond au codec GSM Full Rate (FR). |
AT#DVI=1,1,0 | Telit | Configuration | Configure et active l’interface audio numérique DVI avec les paramètres indiqués. |
ATD06xxxxxxxx; | Générique / Hayes-3GPP | Exécution | Compose le numéro 06xxxxxxxx en appel vocal. Le ; indique un appel vocal. |
AT#DTMF=0 | Telit | Configuration | Configure le traitement/décodage DTMF ; 0 désactive le décodage DTMF. |
ATH | Générique / Hayes | Exécution | Termine l’appel en cours / raccroche. |
AT#DVI=0,1,0 | Telit | Configuration | Désactive l’interface DVI avec les paramètres indiqués. |
AT#CAP=0 | Telit | Configuration | Configure le mode de contrôle du chemin audio. |
AT#SGACT? | Telit | Lecture | Interroge l’état d’activation des contextes PDP. |
AT+CFUN=7 | Générique / 3GPP avec comportement Telit | Configuration | Place le modem dans le mode de fonctionnement correspondant à CFUN=7. |
AT+CFUN=1 | Générique / 3GPP | Configuration | Place le modem en fonctionnement complet. |
AT+CSQ | Générique / 3GPP | Lecture | Mesure la qualité du signal radio (RSSI et BER). |
Structure du protocole UART entre la centrale et le module
Capture d’un échange
Voici le tout premier échange qui se produit lorsqu’on déclenche le code #660## (donc émise par la centrale)
- Requête : 0x 08 29 07 B0 27 02 94 00 27
- Réponse : 0x 04 29 40 01 6C
Et voici les 2 trames suivantes (émise par le module)
- Requête : 0x 0A 32 07 B0 0F 01 00 00 00 02 83
- Réponse : 0x 04 32 40 01 77
- Requête : 0x 06 33 07 B0 28 01 AB
- Réponse : 0x 04 33 40 01 76
Le module TELIT reçoit une première instruction AT+CFUN=1 avec pour réponse 0
Puis reçoit régulièrement des instructions AT+CSQ avec pour réponse +CSQ: 12, 0, 0x0D 0x0A 0 0x0D
Le chiffre 12 correspond au niveau de signal.
Le module émet à la centrale le résultat de la requête AT+CSQ : le niveau de signal « 12 » est annoncé à la centrale.
- Requête : 0x 0A 34 07 B0 0F 04 00 00 00 0C 8E
- Réponse : 0x 04 34 40 01 71
La transmission se termine par l’envoi d’une trame par le module vers la centrale. En parallèle, le module Telit recoit la commande AT+CREG?.
- Requête : 0x 0A 52 07 B0 0F 01 00 00 00 02 E3
- Réponse : 0x 04 52 40 01 17
Enfin le module Telit reçoit 3 requêtes AT
| AT+CREG? | +CREG: 0,1 |
| AT#RFSTS | #RFSTS: « 208 10″,87,-83,B8D2,33,5,,,2,BFED, »20810xxxxxxxx46″, »F SFR »,3,2 |
| AT#SGACT? | #SGACT: 1,0 |
| AT+CFUN=7 | 0 |
Structure d’une requête et réponse
Si l’on regarde de plus près l’ensemble de la transmission
| Emetteur | Requête | Réponse | Commentaire |
|---|---|---|---|
| Centrale | 08 29 07 B0 27 02 94 00 27 | 04 29 40 01 6C | Déclenchement de #660## |
| Module | 0A 32 07 B0 0F 01 00 00 00 02 83 | 04 32 40 01 77 | |
| Module | 06 33 07 B0 28 01 AB | 04 33 40 01 76 | |
| Module | 0A 34 07 B0 0F 04 00 00 00 0C 8E | 04 34 40 01 71 | Envoi du niveau de signal |
| Module | … | … | Envoi du niveau de signal X fois |
| Module | 0A 52 07 B0 0F 01 00 00 00 02 E3 | 04 29 40 01 6C | Fin de transmission |
On peut repérer 3 blocs de données
Taille de transmission attendue
Il s’agit du premier octet, il détermine le nombre d’octets qui vont suivre. Si la valeur est de 0x08 la transmission contiendra 8 octets supplémentaires (soit un total de 9 octets)
Numéro de transmission
Il s’agit du second octet, il est incrémenté entre chaque transmission. Le module de transmission et la centrale ont chacun leur propre numéro de trame. La réponse reprend le numéro de trame de la requête.
Somme de contrôle
Le dernier octet est une somme de contrôle et basée sur un XOR des octets précédents. Par exemple sur la trame 06 33 07 B0 28 01 AB :
- 06 XOR 33 = 35
- 35 XOR 07 = 32
- 32 XOR B0 = 82
- 82 XOR 28 = AA
- AA XOR 01 = AB –> la transmission est OK
Présence supposée de « magic bytes »
Les octets 3 et 4 de chaque requête sont toujours les mêmes : 0x 07 B0
Par corollaire, sur chaque réponse, les octets 3 et 4 sont toujours : 0x 40 01
On peut supposer que ce sont des « magic bytes » donc toujours présents dans chaque requête et réponse.
Informations transmises (payload)
Si l’on regarde la charge utile de la première requête : 0x 27 02 94 00
02 94 correspond en hexadécimal à 660… exactement le code saisi sur la centrale !
Sur une autre capture avec le code #581## (appel du 1er contact), on constate la même chose : présence du code 581 (0x 02 45 en hexa)
Sur l’envoi du niveau de signal : 0x 0F 04 00 00 00 0C
0F 04 est probablement la valeur qui caractérise une transmission de type « niveau de signal »
00 00 00 0C correspond au niveau de signal de 12 (vérifié sur d’autres transmissions avec un niveau de signal différent). Je prends comme hypothèse que la valeur est codée sur 32 bits.
Que faire pour convertir ce module à la 4G ?
Cas 1 : faire un « drop in » du module Telit actuel par le ML865G1
Dans ce premier cas il faudrait garder le PCB d’origine mais venir souder un autre module à la place du Telit GM865. Il existe un chipset « drop in » comme signalé dans un commentaire de mon précédent article : le ML865G1
Malheureusement ce module ne gère pas la VoLTE, il y aura donc un fallback 2G pour les appels. Il est probable également qu’une adaptation du logiciel embarqué du DIAG55AAX soit nécessaire mais on ne dispose ni du code source ni du binaire compilé (et encore une fois le but n’est pas ici de faire une rétro-ingénierie du logiciel embarqué)
Cas 2 : remplacer le module Telit par un module alternatif
Il existe un module alternatif qui pourrait convenir : le SIMCOM A7672G. Il est compatible VoLTE et dispose d’entrées/sorties analogiques. On trouve des kits de développement sur Aliexpress disposant de toutes ces entrées/sorties.
Néanmoins un nombre non négligeable de commandes AT est associé à Telit, donc non compréhensibles par le module. Il faudra donc ajouter un « middleware » capable de traduire les commandes Telit en commandes SIMCOM puis de transcrire la réponse SIMCOM en réponse Telit.
On peut imaginer utiliser un Raspberry Pi RP2040 Zero, que l’on collerait à l’emplacement du Telit et qui le simulerait. Il est doté de 2 entrées/sorties UART mais peut également utiliser des entrées/sorties GPIO en mode DMA.
La partie du PCB utilisée par l’antenne du GM865 pourrait être coupée pour libérer de la place ou bien servir de support et ainsi héberger le kit de développement SIMCOM A7672G, qui serait connecté au RP2040.
Cela demande un travail de rétro-ingénierie des commandes AT mais qui n’est pas insurmontable car la documentation Telit et la documentation SIMCOM permettraient d’y arriver et notamment avec l’aide de l’IA.
Cela pourrait donner quelque chose qui ressemblerait potentiellement à cela (sans les fils de pontage entre les modules)
Reste néanmoins l’audio… a voir s’il est possible de repiquer l’audio en sortie des AOP plutôt que de récupérer le signal numérique DVI… pas sûr car le microcontrôleur semble générer ses propres samples audio numérique…
Cas 3 : reproduire le fonctionnement du module DIAG55AAX
C’est certainement le cas le plus difficile et qui demanderait une rétro-ingénierie plus complète pour comprendre tous les codes Diagral. Néanmoins cela ouvrirait la porte à la « domotisation » de la centrale en émulant le DIAG55AAX.
Par exemple en ajoutant de la connectivité Ethernet et/ou WiFi (ESP32, Pico W, …) pour superviser ou piloter les ordres marche / arrêt / alerte / … vers le système de son choix, appels/SMS via équipement externe ou intégré à l’alarme, etc… et cela sans dépendre de la Box alerte et pilotage et des serveurs de e-one.
Cas 4 : se passer du DIAG55AAX
De nouveaux modules sont disponibles sur le site de Diagral : DIAG63BRX et DIAG64BRX. Ils permettent de disposer d’un contact sec programmable et notamment en cas d’intrusion. C’est très « binaire » mais si l’unique besoin est d’être appelé en cas d’alerte il est certainement possible de coupler ce module avec un autre appareil d’alerte.
Il est aussi possible de réutiliser un ancien transmetteur RTC comme le DIAG52AAX. C’est « old school » mais toujours opérationnel via un module FXS SIP ou tout simplement via le port « TEL » de votre box opérateur ! Pour ma part, j’ai opté pour ce choix en attendant…
