Je tente d'intégrer à un projet Arduino la visualisation de la pression de mes pneus via des capteurs TPMS Bluetooth à visser à la place des bouchons de valve et qu'on trouve sur les sites chinois.
J'arrive à sniffer les trames de données qu'ils envoient de manière autonome mais j'ai beaucoup de mal à les interpréter.
Voici un exemple de trame:
-avec cette trame, l'appli m'affiche 10deg et 90.1kpa:
-une autre qui donne 9 deg 120.3kpa:
0x80 0xea 0xca 0x10 0x02 0x6b 0x36 0xd6 0x01 0x00 0xde 0x03 0x00 0x00 0x25 0x00
Quand je retire le capteur du pneu, les valeurs que j'ai identifiées comme étant la pression passent à 0x00.
En convertissant l'hexa en décimal je ne retrouve rien ne s'approchant de près ou de loin aux valeurs lues par l'appli, même en faisant la conversion kpa/psi celsius/farenheight.
Je j'ai pas de formation informatique donc je ne sais pas si je dois additionner en décimal les valeurs qui me semblent significatives.
Des idées ?
Essaye de les mettre à des endroits de températures différentes, dans le frigo, sous la couette, avec un thermomètre pour connaître la valeur mesurée, et regarde ce qu'il fournit.
Plus il y aura de données, plus tu auras de chance de comprendre...
Quand un nombre tient sur plusieurs octets il y a deux façons d'enchaîner les octets , içi c'est 'poids fort en dernier'. (Les octets sont sans doute rangés dans cet ordre dans la mémoire de la puce BT et émis tout simplement par adresses croissantes)
pour la température :
0x042C = 1068 pour 10,68°C , partie entière 10
0x03DE = 990 pour 9,9°CC , partie entière 9
pour la pression :
0x00016020 = 90144 , donc 90,144
0x0001D636 = 120374 , donc 120,374
al1fch:
c'est du verlan (cf little endian ou big endian, petit boutiste ou gros boutiste...)
Quand un nombre tient sur plusieurs octets il y a deux façons d'enchaîner les octets , içi c'est 'poids fort en dernier'. (Les octets sont sans doute rangés dans cet ordre dans la mémoire de la puce BT et émis tout simplement par adresses croissantes)
pour la température :
0x042C = 1068 pour 10,68°C , partie entière 10
0x03DE = 990 pour 9,9°CC , partie entière 9
pour la pression :
0x00016020 = 90144 , donc 90,144
0x0001D636 = 120374 , donc 120,374
on n'a pas le choix de l'assemblage, on s'adapte au choix fait par le concepteur de l'unité centrale, du processeur, microprocesseur, microcontrolleur
Içi on est en présence d'une puce qui 'prend les nombres par le petit bout'.
par pure curiosité : avec quoi as tu 'sniffé' les paquets ? outils Linux ? appli Nordic Semiconductor sur smartphone ?....
Donc Linux , bien équipé en outils effiaces en ligne de commande pour analyser les 2 Bluetooth
Içi la trame donnée aumessage #1 est émise en advertising , ou obtenue après connection, en notification ou lecture ?
Non pas d'apairage préalable, le capteur envoie juste son identifiant quand on met sa pile. C'est seulement quand on l'installe sur la valve qu'il émet une trame "en clair" à chaque variation de pression/température.
J'ai bien vu que c'est du BLE !!! donc pas d'appairage contrairement au Bluetooth classique
mais il reste quand même deux options en BLE : avec ou sans connection (connection sans appairage)
On aurait donc affaire içi à des données émises dans la trame de signalement (advertising)
J'ai des capteurs de température+humidité Xiaomi qui font pareil , il suffit de les écouter pour récupérer les infos en hexa ( en se connectant, bonus, on a les données en ASCII !!)
@al1fch
Je viens tomber sur un post auquel tu as participé et je me retrouve confronté au problème du module HM-10 qui balance une moitié en ASCII et un petit bout "en clair". Vu que tu sembles connaitre le souci, aurais-tu sous la main une fonction qui transcrit ces caractères en HEX ?
Si ça peut m'éviter de jeter mon HM-10 pour un esp32...
Non je n'ai pas de fonction a proposer,je me suis limité pour l'instant a explorer le jeu de commandes AT des HM-10.
Si tu fais réferenceà la réponse à la commande AT+DISA, le traitement ne parait pas insurmontable , les trames en hexa sont bien encadrées par les AT+DISA: de la réponse, (les éléments du protocole AT sont en ASCII, les données sont telles quelles en hexadécimal, ce qui est finalement logique.
Je n'ai pas de HM-10 associé avec une carte Arduino
J'utilise un peu les HM-10 'en solo' (balise iBeacon, commande a distance des GPIO du HM-10)
Oui c'est la commande DISA mais en fait je ne sais pas vraiment quelle commande permet d'afficher ce que j'arrive à visualiser facilement sur le moniteur Bluetooth Raspberry.
En pièce jointe ce que les commandes AT+DISA? , AT+DISI? , AT+DISC affichent respectivement. Je ne vois rien ressemblant à la trame de data du premier post. Un convertisseur ASCII HEX ne donne que l'adresse du module BLE (quoi que un copier coller n'affiche pas l'intégralité des caractères affichés).
Galère galère...
Quelle(s) commande(s) donnent la bonne trame sur Raspberry PI ? (gattool, hcitool lescan, bluetoothctl....)
la trame y est-elle obtenue par un scan passif ou actif?
Avec le HM10 , AT+DISA? a-t-il été précédé de ROLE1, IMME1 et RESET ?
AT+DISC? ne donne que les adresses des appareils du voisinage (avec eventuellement leur nom et leur RSSI, si demandé au préalalble par AT+SHOW)
AT+DISI? est prévu pour scanner les seules balises iBeacon à proximité
Seule AT+DISA? retourne les trames d'Avertising
Utiliser un terminal affichant optionnellement en hexa (sous Linux en ce moment j'utilise CuteCom)..
(certains bidules BLE ne donnent pas toutes les infos dans une trame d'advertising unique, ils envoient plusieurs trames successives complémentaires en raison de la taille maxi d'une telle trame, il faut donc identifier la tarme 'util' avant d ela décortiquer)
Oui j'ai bien utilisé les commandes AT requises avant.
Effectivement un vrai teminal série permet d'y voir un peu plus clair:
Pour ceci côté moniteur Bluetooth j'ai :
0x80 0xea 0xca 0x10 0x02 0x6b 0x15 0x27 0x00 0x00 0xc1 0x08 0x00 0x00 0x38 0x00
Il me reste à trouver un pattern de délimiteurs (et surtout de les traiter côté Arduino).
perso sous windows j'utilise terminalbpp , bien pratique pour faire de la visu enASCII ou HEX , du log de fichier , jouer avec des tauds de bauds exotiques, etc
pas (encore ) trouvé l'equivalent sous linux
Voilà (Read The Doc !!!) la structure de la réponse à AT+DISA?
Dans ta copie d'écran on voit bien les 6 octets de l'adresse 'MAC' après les deux points de DISA: (0x3A)
(adresse mac à l'envers, poids faible d'abord)
Sous Windows, Artouste , dès qu'il s'agit de tester , archiver....des enchaînements de commandes AT avec prise en compte des réponses attendues, time out.... je 'préfère aussi' TeraTerm Pro et son langage de scripts simple.
La doc en pdf , elle, n'est pas encore dans la liste de téléchargement mais on peut le récupérer sur la page d'acceuil en cliquant sur la photo d'un des HM-10 !!
Je parviens enfin à isoler la trame de data en traitant tout comme des byte.
Mais pour reprendre mon exemple de base 0x042C qui est donc la valeur que je veux obtenir et facilement convertir en décimal.
Si j'ai un truc du genre byte temp[2]={0x04, 0x2C};
Comment je les imprique pour obtenir ma valeur à convertir en décimal ?
(cf l
