Étude du protocole du système de surveillance de la pression des pneus des véhicules (TPMS)

Le système de surveillance à distance de la pression de l'air dans les pneus de voiture (abréviation TPMS - Tire Pressure Monitoring System) est conçu pour informer rapidement l'utilisateur de la diminution de la pression des pneus et de la température critique des pneus.



Les capteurs sont disponibles en interne ou en externe. Les intérieurs sont installés à l'intérieur du pneu de roue tubeless, les extérieurs sont vissés sur la ferrure de roue. Une roue avec un capteur interne ressemble exactement à une roue sans capteur. Une telle roue est facile à gonfler. Le capteur externe est perceptible, il peut être volé et doit d'abord être dévissé lors du gonflage de la roue. Il est également influencé par les phénomènes atmosphériques.



Pour étudier le protocole du système TPMS, j'ai été poussé par l'idée d'installer un tel système sur une poussette pour surveiller rapidement la pression des pneus.



image

Fig. 1. Apparence du système TPMS



image

Fig. 2. Carte contrôleur système TPMS



Il n'a pas été possible d'installer une unité de réception standard comme cela, car la valeur de pression minimale autorisée est de 1,1 bar, et dans une poussette pour bébé, elle est inférieure. Par conséquent, le module émet constamment un bip, informant de la faible pression des pneus. Vous pouvez lire sur le développement d'un contrôleur pour la poussette "Smart" "Maksimka" , dans laquelle les résultats de la recherche sont appliqués, dans mon article [1].



La collecte d'informations sur le fonctionnement du TPMS a commencé par la recherche d'articles sur Internet. Mais, malheureusement, il y a peu d'informations. Et cela s'applique également aux systèmes de voiture habituellement standard, qui sont un peu plus compliqués et beaucoup plus chers. Et j'avais besoin d'informations sur un simple système chinois bon marché. J'avais une compréhension minimale, maintenant je devais commencer à expérimenter.



Alors, nous nous armons du sifflet USB du tuner DVB, lançons RTL-SDR et regardons l'émission. Les capteurs fonctionnent à 433,92 MHz en modulation FSK. Au départ, j'ai enregistré la diffusion puis analysé manuellement le protocole. Ici, les difficultés ont commencé. Auparavant, ne rencontrait que la modulation OOK. Tout y est simple. C'est un peu plus compliqué ici. Les informations sont codées avec deux fréquences. Par conséquent, j'ai étudié des exemples, la théorie des modulations. Puis j'ai vu comment le programme URH-Universal Radio Hacker était utilisé [2, 3]. J'ai essayé de l'installer, mais cela ne fonctionne pas sur mon WinXP 32 bits. J'ai dû chercher un ordinateur avec win8 64bit, puis le programme a été installé. Vous pouvez en savoir plus sur son travail sur le site Web du développeur. URH a rendu le processus un peu plus facile pour moi, car il capte le signal de l'air, l'affiche avec un oscillogramme et le décode immédiatement sous une forme numérique brute sous forme binaire et hexadécimale.



image

Fig. 3. Capture d'écran du programme avec une image capturée de l'envoi TPMS



Le capteur envoie plusieurs messages l'un après l'autre dans une session. La période entre les sessions peut aller jusqu'à une minute ou plus. Si une situation d'alarme se produit, le capteur commence immédiatement à envoyer des paquets de données. Le fichier son du message du capteur [8]. Un exemple d'un message du capteur extrait du programme URH:



010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101011001100110100110101001011001011010011010100110101001100101010101011010010101010101010110101001011001101010010101100101101001010101011001011001100110101001


Sous forme hexadécimale, cette prémisse prendra la forme:



5555555555555555555555555555555555555555555555555555555555555555555556669a965a6a6a6555a5555a966a565a556599a9


Il était évident que les 4 colis d'une session avaient les mêmes données, ce qui signifie que le paquet a été accepté correctement et que vous pouvez commencer à l'analyser.



Dans l'exemple ci-dessus, vous pouvez voir le préambule (séquence 01010101….), Suivi des données. Après avoir lu Internet, nous comprenons que nous avons un package encodé avec l'encodage Manchester (GE Thomas). Chaque bit est encodé avec deux bits 01 ou 10. J'ai initialement encodé à la main, renforçant ainsi la théorie de l'encodage / décodage. Mais j'ai ensuite décidé de me tourner vers le décodeur en ligne [4,5,6], qui a grandement accéléré le processus.



Ainsi, en décodant le message d'origine du capteur avec le code Manchester, nous obtenons



000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010101101110010011011101110100000011000000001110010111000100110000010010101110


Les 136 premiers zéros sont un préambule et peuvent être supprimés. Nous ne nous intéressons qu'aux données.



En les traduisant sous forme hexadécimale, nous obtenons: 0x15B937740C03971304AE



Cela a déjà de belles données initiales, dans lesquelles l'identifiant, la pression des pneus et la température sont cachés quelque part.



Pour de plus amples recherches, il est nécessaire de collecter des données statistiques. Pour ce faire, j'ai enroulé un capteur sur la roue et capturé l'air, tout en enregistrant ce que montre la carte système d'origine. Il a relâché la pression, l'a gonflée, a mis la roue dans le congélateur pour une température négative, l'a réchauffée. Puis il a cherché les mêmes conditions pour qu'un autre capteur découvre les octets de température et de pression.



L'ensemble du paquet prend 10 octets. Si vous alignez les données décodées reçues dans une colonne, vous pouvez voir les données constantes et les données changeantes.



15B937740C03971304AE
15B937740C03A1FC00A4
15B937740C03A700087B


Il y a des autocollants sur les capteurs sur le corps. Chaque capteur est différent: 0A, 1B, 2C, 3D.



La pensée stéréotypée ici n'a pas bien fonctionné. Je pensais que c'était le capteur d'identification.

Je doutais de la raison pour laquelle l'ID ne prend qu'un octet, mais je l'ai oublié et j'ai essayé de rechercher ces identifiants dans le flux. Ensuite, dans le menu du récepteur d'origine du système, j'ai vu que d'autres capteurs pouvaient être liés à ce récepteur, et le récepteur lui-même affiche l'identifiant du capteur sur chaque roue. Et, voilà, j'ai découvert que le quatrième capteur de roue a un ID = 3774.



15B937740C03971304AE


Ainsi, les 3e et 4e octets du paquet sont l'ID de roue. Par rapport à d'autres capteurs, les identifiants coïncidaient également avec ceux affichés par le panneau standard.



J'ai compté le 1er octet comme préfixe du début des données et le 2e octet comme identifiant du sous-système TPMS.

Ci-dessous, la comparaison des colis de différents capteurs.



15B9F3FA2300BE1B007BID du capteur 0A = 0xF3FA ID du

15B91AA43201B71B002Acapteur 1B = 0x1AA4 ID du

15B9ABFF32027B1B029Bcapteur 2C = 0xABFF ID du

15B937740C03971304AEcapteur 3D = 0x3774



Et j'ai réalisé que les inscriptions sur les capteurs (0A, 1B, 2C, 3D) ne sont que des numéros de roue sous forme numérique et alphabétique, pas hexadécimale id de roue. Mais, néanmoins, le 6e octet du paquet est très similaire au numéro de série du capteur. Pour ma part, j'ai conclu que c'était l'identifiant de la roue. Ainsi, un octet de plus est décodé.



Le dernier octet est probablement une somme de contrôle, que je ne sais pas encore lire. Cela est resté un mystère pour moi jusqu'à la toute fin.



Le prochain octet décodé est la température de la roue. Chanceux ici. La température prend 1 octet et est présentée en degrés entiers. Température négative dans le complément à deux. Cela signifie que la température -127 ... 128 degrés Celsius tiendra dans un octet.



Dans notre package, la température est le 8ème octet



15B9F3FA2300BE1B007B0x1B correspond à +27 degrés

15B937740C03A1FC00A40xFC correspond à -4 degrés



Il y a trois octets non reconnus 5e, 7e, 9e. À en juger par la dynamique du changement, la pression des pneus est cachée dans 7 octets, et dans le 9e octet, très probablement, les bits d'état du capteur. Selon diverses sources d'informations sur Internet, ainsi que les fonctionnalités de mon système TPMS, il devrait y avoir un peu de batterie déchargée, un peu de perte de charge rapide et quelques bits supplémentaires qui ne sont pas clairs pour quoi.



Donc, nous allons analyser le 7e octet, puisque nous voulons dire que la pression s'y cache.

Ayant tapé des statistiques sur différents capteurs avec des pressions différentes, je n'ai pas pu définir clairement la formule qui recalcule la pression. Et il n'est pas clair dans quelles unités le capteur transmet la pression par défaut (Bar, PSI). En conséquence, le tableau construit dans Excel ne correspondait pas exactement au tableau de bord TPMS standard. On pourrait négliger cette différence de 0,1 Bar, mais je voulais le concept de protocole jusqu'au dernier bit. L'excitation a prévalu.



Si vous ne pouvez pas comprendre comment l'octet de pression est formé, vous devez créer un émulateur de capteur de pression et, en modifiant la valeur de pression, voir ce que le panneau standard affiche.



Il restait à découvrir le but des 5e et 9e octets du paquet, mais ils changent rarement, vous pouvez donc accepter leurs valeurs comme dans le paquet d'origine, en ne changeant que l'octet de pression. Maintenant, la question est uniquement de calculer la somme de contrôle. Sans cela, le panneau standard ignorera mon paquet et ne montrera rien.



Pour émuler le capteur, vous deviez envoyer un paquet. Pour cela, j'avais un émetteur-récepteur SI4432 connecté à un PIC16F88, qui était autrefois utilisé à d'autres fins.



image

Fig. 4. Photo de la planche de test



En utilisant d'anciennes pratiques de transfert de données, j'ai esquissé un programme pour le PIC qui transmet l'un des paquets que j'ai reçus avec le programme URH. Quelque temps après avoir allumé l'émetteur, le panneau affiche les données qui y ont été transférées! Mais ceci est un paquet prêt à l'emploi avec un CRC prêt à l'emploi, et pour que je puisse changer l'octet de pression, je dois également recalculer le CRC.



J'ai commencé à lire, à chercher des informations sur les CRC utilisés, j'ai essayé différents Xor, Et ainsi de suite, mais rien n'a fonctionné. Je pensais déjà que rien ne marcherait et qu'il faudrait se contenter de la pression que j'ai reçue selon mon tableau, mais légèrement différente du tableau de bord original. Mais sur Internet, j'ai vu un article sur la sélection des CRC. Il y avait un programme auquel vous donniez plusieurs paquets, et il essaie de trouver une somme de contrôle et, en cas de succès, affiche la valeur polynomiale et la valeur d'initialisation CRC. [7] Nous



donnons au programme plusieurs packages:



reveng -w 8 -s 15B9ABFF3202AA1B0017 15B9ABFF3202AA1B0249 15B9F3FA2300D01A00D8 15B937740C037B130089 15B937740C03BD18025E 15B9ABFF32028F150834


Les enjeux du programme:



width=8  poly=0x2f  init=0x43  refin=false  refout=false  xorout=0x00  check=0x0c  residue=0x00  name=(none)


J'ai écrit un programme pour calculer le CRC en tenant compte de ces données et je l'ai parcouru à travers les paquets, que j'ai reçus plus tôt - tout s'est réuni!



//  CRC  
 crc=0x43;    //     
 for(j=0;j<9;j++)
 {
  crc ^= tmp[j];
  for(i=0;i<8;i++)
   crc=crc&0x80 ? (crc<<1)^0x2F : crc<<1;  //  0x2F    CRC
 }


Les mains démangeaient de transmettre les données de pression. Après avoir terminé le programme de test avec un calcul CRC, j'ai transmis le premier paquet. Le panneau OEM a reçu le signal et a affiché la pression et la température. Un petit problème était que le panneau standard avait une décimale et, tout en transmettant la valeur à l'air, l'écran affichait toujours la même pression, car le reste des décharges n'était pas visible. Valeur d'octet transmise 0..255. Mais encore une fois, ce n'est pas clair. Il s'est avéré que la pression 0,00 Bar démarre lorsque le 7e octet contient la valeur 97. On ne sait pas pourquoi il en est ainsi. Mais alors tout est clair avec une résolution de 0,01 Bar.



Octet P Pression, Bar

255 1,58

254 1,57

... ...

107 0,10

106 0,09

105 0,08

104 0,07

103 0,06

102 0,05

101 0,04

100 0,03

99 0,02

98 0,01

97 0,00



À en juger par le tableau, la pression maximale qui tient dans un octet n'est que de 1,58 bar, mais le système vous permet de mesurer une pression jusqu'à 4 Atm. Cela signifie qu'un bit du bit le plus significatif est caché ailleurs. Il n'y avait aucun désir de parcourir tous les octets et de changer les bits qu'ils contiennent. Une roue d'une voiture a été trouvée, un capteur a été enroulé dessus, un signal a été capturé. La curiosité a prévalu et, dans mon esprit, je pariais sur l'endroit où le rythme apparaîtrait. Et que ce sera exactement un bit, et non un autre schéma de codage.



Après avoir décodé le paquet, j'ai vu ce morceau. C'est le 7ème bit du 6ème octet. Cela signifie que le 6e octet contient non seulement le numéro de roue, mais également le bit le plus significatif de la pression des pneus.

15B937740C833C18025C



Le bit le plus significatif de 0x83 et 0x3C donne 0x13C = 219 ce qui correspond à une pression de 2,19 Bar

La formule pour convertir la pression en Bar: P = (ADC-97) / 100,

où ADC = (B7 >> 7) * 0x100 + B6, où B6 et B7 sont la valeur de l'octet 6 et l'octet 7.



Avec une valeur de 511, nous avons une pression maximale de 4 , 14 bar. La raison pour laquelle la barre était de 4,14 bar n'était pas non plus claire, mais je suppose que cela équivaut à 4 atm - la pression maximale autorisée pour le capteur.



Il reste à comprendre de quoi sont responsables les bits d'état. Les bits ont été obtenus en purgeant la pression, en connectant le capteur à une alimentation régulée et en réduisant la tension. Est resté incertain 2 bits. Il y en a peut-être plus, mais ils n'ont jamais accepté la valeur d'un pendant toute l'expérience.



Pour simplifier l'analyse, un programme a été écrit [8]



image

Fig.5. L'apparence de l'interface du programme pour l'examen des packages TPMS



Vous pouvez définir le paquet brut du programme URH dans le programme sous forme hexadécimale et le programme décode le paquet, lit la somme de contrôle et affiche les données en unités de température et de pression normales.



D'une manière ou d'une autre, je suis retourné dans le menu du panneau standard et j'ai vu que l'identifiant du capteur n'était pas de deux octets, mais de quatre. Le panneau a des indicateurs grands et petits et je n'ai pas immédiatement remarqué que les 2e et 5e octets sont également inclus dans l'ID du capteur.



15B937740C833C18025C



Ainsi, seul le 1er octet reste non reconnu, mais il est toujours 0x15 (0b010101), et cela ressemble à un certain préambule d'un paquet ou à son identifiant de début.



De plus, les bits d'état ne sont pas reconnus exactement, mais ceux qui manquent.



La curiosité de savoir ce qu'il y avait à l'intérieur du capteur a pris le relais et j'ai démonté l'un d'entre eux (Fig.6)



image

Fig.6. Capteur TPMS



Il est basé sur le microcircuit Infineon SP372 avec un petit cerclage. Une recherche de la documentation de ce microcircuit particulier n'a rien donné. Ceux que j'ai trouvés sont soit des sondages, soit de la publicité. Il n'a donc pas été possible de connaître le protocole. Mais les articles mentionnent qu'il s'agit d'un automate programmable, donc le programme peut être n'importe quoi. Par conséquent, je n'ai pas osé acheter le microcircuit séparément.



Protocole



Maintenant sur la réception des données du capteur vers l'émetteur-récepteur SI4432. Il était initialement prévu de recevoir des données brutes du SI4432 afin que le contrôleur décode Manchester et collecte des octets. Mais cet émetteur-récepteur a une fonction de traitement de paquets. Autrement dit, pour la transmission, vous pouvez configurer l'émetteur sur la fréquence, la modulation, la déviation souhaitées, définir la longueur du préambule, le codage, le mot de synchronisation, le débit binaire, la longueur des données. Ensuite, écrivez le paquet de données d'origine dans la mémoire tampon de l'émetteur (par exemple, notre 15B937740C833C18025C) et démarrez la transmission. L'émetteur-récepteur lui-même formera un paquet et le diffusera, en observant tous les paramètres spécifiés, tandis que le contrôleur est libre à ce moment-là de traiter d'autres informations.



Idéalement, je souhaite recevoir un traitement de données par lots du SI4432 lors de la réception. Pour que le récepteur reçoive le paquet et génère une interruption indiquant que le paquet a été reçu. Ensuite, le contrôleur lit simplement le tampon de réception, qui stocke déjà les données sous leur forme pure, libérant ainsi le temps du processeur pour d'autres fonctions.



J'ai commencé à étudier le réglage des registres pour le fonctionnement de l'émetteur-récepteur pour la réception. Cela s'est avéré beaucoup plus difficile que de transférer le colis. Ici, vous devez bien connaître la théorie de la réception radio, que je n'ai pas. Il existe des tableaux pour calculer les registres dans Excel pour cet émetteur-récepteur, mais ils ne fonctionnent pas en raison du fait qu'Excel est russe ou ils sont tronqués. Il y a aussi une application du développeur, mais tout n'est pas très transparent là non plus. Après avoir parcouru de nombreux exemples et consulté les tables de calcul, j'ai lu manuellement les valeurs des registres selon la documentation.



J'ai connecté un enregistreur à la sortie du récepteur et capturé l'air, en fonction de ce que le récepteur émet. En conséquence, j'ai réussi à configurer les filtres du récepteur pour qu'il laisse passer mon paquet. Il a manipulé le débit, a battu le tambourin. La théorie, malheureusement, n'est toujours pas claire pour moi.



Pour que le récepteur puisse recevoir un paquet de données, il doit spécifier la longueur du préambule, le mot de synchronisation qui doit être présent et la longueur des données. Il est également possible pour le récepteur de lire la somme de contrôle lui-même, mais dans SI4432 l'algorithme de calcul ne correspond pas à l'algorithme CRC des capteurs de pression.



La présence obligatoire d'un mot de synchronisation de deux octets pourrait éclipser l'idée de recevoir un paquet, mais ici, il était chanceux que l'envoi du capteur commence à 0x15B9 (15B937740C833C18025C) et soit le même pour tous les capteurs. Cela signifie que 0x15B9 a été spécifié pour le mot de synchronisation. La longueur du paquet de données est de 8 octets, l'analyse de la somme de contrôle est désactivée. Nous définissons la génération d'une interruption lors de la réception d'un paquet et commençons la procédure de réception.



Lorsque le récepteur reçoit le préambule, le mot de synchronisation 0x15B9 et 8 octets de données, il émettra une interruption vers le contrôleur principal, qui lit simplement 8 octets de données dans la mémoire tampon du récepteur. Ensuite, le contrôleur principal calculera la somme de contrôle, la comparera et décodera les données reçues. Heureusement, tout s'est déroulé comme prévu!



image

Fig. 7. Photo de l'indicateur TPMS standard et de l'affichage de la poussette "intelligente"



Voici un exemple d'initialisation de l'émetteur-récepteur SI4432 pour recevoir:



WriteSI4432(0x06, 0x05);	   // interrupt all disable
   WriteSI4432(0x07, 0x01);	   // to ready mode
   WriteSI4432(0x09, 0x7f);	   // cap = 12.5pf
   WriteSI4432(0x0A, 0x06);	   // uC CLK: 1 MHz

   WriteSI4432(0x73, 0x00);	   // no frequency offset
   WriteSI4432(0x74, 0x00);	   // no frequency offset 
   WriteSI4432(0x75, 0x53);	   // 430-440MHz range   
   WriteSI4432(0x76, 0x62);	   // 0x621A-433.924 
   WriteSI4432(0x77, 0x1A);	   //  
   WriteSI4432(0x79, 0x00);	   // no frequency hopping
   WriteSI4432(0x7a, 0x00);	   // no frequency hopping  
 
   //      9090/2
   WriteSI4432(0x1C, 0x81);    // 01 IF Filter Bandwidth 
   WriteSI4432(0x1D, 0x44);    // 44 AFC Loop Gearshift Override 
   WriteSI4432(0x1E, 0x0A);    // 0A AFC Timing Control
   WriteSI4432(0x1F, 0x05);    // 00 Clock Recovery Gearshift Override
   WriteSI4432(0x20, 0x28);    // 64 Clock Recovery Oversampling Ratio 
   WriteSI4432(0x21, 0xA0);    // 01 Clock Recovery Offset 2 
   WriteSI4432(0x22, 0x18);    // 47 Clock Recovery Offset 1 
   WriteSI4432(0x23, 0xD2);    // AE Clock Recovery Offset 0 
   WriteSI4432(0x24, 0x08);    // 12 Clock Recovery Timing Loop Gain 1 
   WriteSI4432(0x25, 0x19);    // 8F Clock Recovery Timing Loop Gain 0 
   WriteSI4432(0x2A, 0x00);    // 00 AFC Limiter 
   WriteSI4432(0x69, 0x60);    // 60 AGC Override 1
   
   WriteSI4432(0x70, 0x26);     //  Manchester,   
   WriteSI4432(0x71, 0x22);	    //  FSK, FIFO
   WriteSI4432(0x72, 31);       //  31*625=19375  (     )
   WriteSI4432(0x34,10);         // 10 -    4- 
   WriteSI4432(0x35,0x1A);      // preambula threshold
   
   WriteSI4432(0x36,0x15);      //  3  0x15
   WriteSI4432(0x37,0xB9);      //  2  0xB9
   
   WriteSI4432(0x27,0x2C);      // RSSI

   //  
   WriteSI4432(0x33, 0x0A);     // fixpklen=1, Synchronization Word 3 and 2
   WriteSI4432(0x32, 0x00);     //   
   WriteSI4432(0x30, 0x80);	    // Skip2ph, Enable Packet RX Handling=0 (   Skip2ph...)
   WriteSI4432(0x3E, 0x08);     //    8 

   WriteSI4432(0x0B, 0x12);     //  GPIO0     TX 
   WriteSI4432(0x0C, 0x15);     //  GPIO1     RX

   //  FIFO TX
   WriteSI4432(0x08, 0x01);// 0x01  Operating Function Control 2 
   WriteSI4432(0x08, 0x00);// 0x00  Operating Function Control 2      
   //  FIFO RX
   WriteSI4432(0x08, 0x02);// 0x02  Operating Function Control 2 
   WriteSI4432(0x08, 0x00);// 0x00  Operating Function Control 2      
 
   //   :  ,  ,  
   WriteSI4432(0x05, 0x02);     //    
   WriteSI4432(0x06, 0x00); 
   //   ,       NIRQ  . 1
   SI4432_stat[0] = ReadSI4432(0x03); 
   SI4432_stat[1] = ReadSI4432(0x04); 
   WriteSI4432(0x07, 0x05);     //   


La réception des données elle-même ressemblera à ceci:



if (si_int)		//      SI4432
   {
    //      
    SI4432_stat[0] = ReadSI4432(0x03); 
    SI4432_stat[1] = ReadSI4432(0x04); 
    SI4432_RSSI = ReadSI4432(0x26); 
    if (SI4432_stat[0]&0x02)
    {
     WriteSI4432(0x07, 0x01);      //  .     .  ,     
     SI4432_ReadFIFO();            //   FIFO 8  
     TPMS_Parsing();               //  CRC   
     //  FIFO
     WriteSI4432(0x08, 0x02);      //  0x02  Operating Function Control 2 
     WriteSI4432(0x08, 0x00);      //  0x00  Operating Function Control 2      
     //WriteSI4432(0x07, 0x05);      //   
    }
    else
    {
     //  FIFO TX
     WriteSI4432(0x08, 0x01);// 0x01  Operating Function Control 2 
     WriteSI4432(0x08, 0x00);// 0x00  Operating Function Control 2      
     //  FIFO RX
     WriteSI4432(0x08, 0x02);// 0x02  Operating Function Control 2 
     WriteSI4432(0x08, 0x00);// 0x00  Operating Function Control 2      
    }
    if (SI4432_stat[0]&0x80)
    {
     //  FIFO RX
     WriteSI4432(0x08, 0x02);// 0x02  Operating Function Control 2 
     WriteSI4432(0x08, 0x00);// 0x00  Operating Function Control 2      
    }
    WriteSI4432(0x07, 0x05);      //   
    si_int=0;
   }


La fonction SI4432_ReadFIFO () lit simplement 8 octets dans le tampon du récepteur, qui contient les données du capteur.



La fonction TPMS_Parsing () analyse la somme de contrôle et décode les informations en unités de pression et de température finales, ainsi qu'en informations d'état.



Problèmes



  1. Lors de la lecture des informations sur les capteurs, la synchronisation des capteurs entre eux a été mentionnée. Pour une raison quelconque, il est nécessaire de coupler les capteurs, il y avait quelque chose à propos d'une vitesse de plus de 20 km / h pendant 30 minutes. On ne sait pas pourquoi cela est nécessaire. Peut-être que cela est dû au moment du transfert d'informations, mais c'est mon avis.
  2. Je ne l'ai découvert qu'à la fin de la fonction des bits d'état du capteur de pression.
  3. Il n'est pas clair sur le réglage de l'émetteur-récepteur SI4432 pour la réception, sur la vitesse de transmission en utilisant le codage Manchester. Cela fonctionne pour moi, mais il n'y a pas encore de conscience du principe.


Résultats des travaux



La recherche couverte dans cet article a pris environ un mois de temps libre.



À la suite des travaux sur l'étude du protocole du système de surveillance de la pression des pneus, les problèmes de transmission et de réception de données par voie aérienne ont été soulevés, le codage du signal a été brièvement examiné, l'émetteur-récepteur SI4432 a été testé pour la transmission et la réception. Cette tâche a permis d'intégrer le TPMS dans le projet principal de la poussette intelligente. Connaissant le protocole d'échange, vous pouvez connecter plus de capteurs et les intégrer dans votre développement. De plus, la pression contrôlée peut être dans de larges limites, et non comme dans le système standard 1.1-3.2 Bar, car la pression en dehors de cette plage s'accompagne d'un grincement alarmant du système d'unité centrale standard. De plus, le TPMS peut maintenant être utilisé pour surveiller la pression des pneus d'une moto, d'un vélo ou, par exemple, d'un matelas pneumatique. Il ne reste plus qu'à installer physiquement le capteur et à écrire un programme de haut niveau.



Liens



  1. Landau "intelligent" "Maksimka"
  2. github.com/jopohl/urh
  3. habr.com/ru/company/neuronspace/blog/434634
  4. www.rapidtables.com/convert/number/hex-to-binary.html
  5. www.rapidtables.com/convert/number/binary-to-hex.html
  6. eleif.net/manchester.html
  7. hackaday.com/2019/06/27/reverse-engineering-cyclic-redundancy-codes
  8. Mes utilitaires, exemple de package, sélection CRC. Mot de passe d'archivage "tPmSutiLity" dropmefiles.com/MtS9W "
  9. i56578-swl.blogspot.com/2017/08/eavesdropping-wheels-close-look-at-tpms.html
  10. www.rtl-sdr.com/tag/tpms



All Articles