Los sensores están disponibles interna o externamente. Los interiores se instalan dentro del neumático de la rueda sin cámara, los exteriores se atornillan al racor de la rueda. Una rueda con sensor interno se ve exactamente igual que una rueda sin sensor. Una rueda así es fácil de inflar. El sensor externo se nota, puede ser robado y primero debe desenroscarse al inflar la rueda. También está influenciado por fenómenos atmosféricos.
Para investigar el protocolo del sistema TPMS, me impulsó la idea de instalar dicho sistema en un cochecito para controlar rápidamente la presión de los neumáticos.
Figura 1. Apariencia del sistema TPMS
Figura 2. Tarjeta controladora del sistema TPMS
No fue posible instalar la unidad receptora estándar así, ya que el valor de presión mínimo permitido es 1.1 Bar, y en un cochecito de bebé es menor. Por lo tanto, el módulo emite un pitido constante, informando sobre la baja presión de los neumáticos. Puedes leer sobre el desarrollo de un controlador para el cochecito de bebé "Smart" "Maksimka" , en el que se aplican los resultados de la investigación, en mi artículo [1].
La recopilación de información sobre el funcionamiento de TPMS comenzó con la búsqueda de artículos en Internet. Pero, lamentablemente, hay poca información. Y también se aplica a los sistemas de coche habitualmente estándar, que son un poco más complicados y mucho más caros. Y necesitaba información sobre un sencillo sistema económico chino. Tenía una comprensión mínima, ahora tenía que empezar a experimentar.
Entonces, nos armamos con el silbato USB del sintonizador DVB, lanzamos el RTL-SDR y miramos la transmisión. Los sensores operan a 433,92 MHz en modulación FSK. Inicialmente, grabé la transmisión y luego analicé manualmente el protocolo. Aquí comenzaron las dificultades. Anteriormente, solo encontraba modulación OOK. Allí todo es sencillo. Aquí es un poco más complicado. La información está codificada con dos frecuencias. Por lo tanto, estudié ejemplos, la teoría de modulaciones. Luego vi cómo se usaba el programa URH-Universal Radio Hacker [2, 3]. Intenté instalarlo, pero no funciona en mi WinXP de 32 bits. Tuve que buscar una computadora con win8 64bit y luego se instaló el programa. Puede leer más sobre su trabajo en el sitio web del desarrollador. URH me facilitó un poco el proceso, porque captura una señal del aire, la muestra con un oscilograma y la decodifica inmediatamente en una forma digital en bruto, tanto en forma binaria como hexadecimal.
Fig. 3. Captura de pantalla del programa con un fotograma capturado de envío de TPMS
El sensor envía varios mensajes uno tras otro en una sesión. El período entre sesiones puede ser de hasta un minuto o más. Si ocurre una situación de alarma, el sensor comienza a enviar paquetes de datos inmediatamente. El archivo de sonido del mensaje del sensor [8]. Un ejemplo de un mensaje del sensor tomado del programa URH:
010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101011001100110100110101001011001011010011010100110101001100101010101011010010101010101010110101001011001101010010101100101101001010101011001011001100110101001En forma hexadecimal, esta premisa tomará la forma:
5555555555555555555555555555555555555555555555555555555555555555555556669a965a6a6a6555a5555a966a565a556599a9Era evidente que los 4 paquetes en una sesión tenían los mismos datos, lo que significa que el paquete se aceptó correctamente y puede comenzar a analizarlo.
En el ejemplo anterior, puede ver el preámbulo (secuencia 01010101 ...), luego vienen los datos. Después de leer Internet, entendemos que tenemos un paquete codificado con la codificación Manchester (GE Thomas). Cada bit está codificado con dos bits 01 o 10. Originalmente codifiqué a mano, reforzando así la teoría de codificación / decodificación. Pero luego decidí recurrir al decodificador en línea [4, 5, 6], que aceleró enormemente el proceso.
Entonces, decodificando el mensaje original del sensor con el código Manchester, obtenemos
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010101101110010011011101110100000011000000001110010111000100110000010010101110Los primeros 136 ceros son un preámbulo y pueden descartarse. Solo nos interesan los datos.
Al traducirlos en forma hexadecimal, obtenemos: 0x15B937740C03971304AE
Esto ya tiene hermosos datos iniciales, en los que el identificador, la presión de los neumáticos y la temperatura están ocultos en alguna parte.
Para futuras investigaciones es necesario recopilar datos estadísticos. Para hacer esto, enrollé un sensor en la rueda y capturé el aire, mientras grababa lo que muestra la placa del sistema original. Liberó la presión, la bombeó, puso la rueda en el congelador a temperatura negativa y la calentó. Luego buscó las mismas condiciones para que otro sensor averiguara los bytes de temperatura y presión.
El paquete completo ocupa 10 bytes. Si alinea los datos decodificados recibidos en una columna, puede ver datos constantes y datos cambiantes.
15B937740C03971304AE
15B937740C03A1FC00A4
15B937740C03A700087BHay pegatinas en los sensores del cuerpo. Cada sensor es diferente: 0A, 1B, 2C, 3D.
El pensamiento estereotipado aquí no funcionó bien. Pensé que este es el sensor de ID.
Dudé de por qué la ID toma solo 1 byte, pero luego me olvidé de ella y traté de buscar estos identificadores en la secuencia. Luego, en el menú del receptor original del sistema, vi que otros sensores podrían estar vinculados a este receptor, y el receptor mismo muestra el ID del sensor en cada rueda. Y, he aquí, descubrí que el sensor de la cuarta rueda tiene ID = 3774.
15B937740C03971304AEEntonces, el tercer y cuarto bytes del paquete son el ID de la rueda. En comparación con otros sensores y también los identificadores coincidieron con los mostrados por el panel estándar.
Conté el primer byte como el prefijo del inicio de los datos y el segundo como el identificador del subsistema TPMS.
A continuación se muestra la comparación de paquetes de diferentes sensores.
15B9F3FA2300BE1B007BSensor 0A ID = 0xF3FA
15B91AA43201B71B002ASensor 1B ID = 0x1AA4
15B9ABFF32027B1B029BSensor 2C ID = 0xABFF
15B937740C03971304AESensor 3D ID = 0x3774
Y me di cuenta de que las inscripciones en los sensores (0A, 1B, 2C, 3D) son solo números de rueda en forma digital y alfabética, no hexadecimal id de la rueda. Sin embargo, el sexto byte del paquete es muy similar al número de serie del sensor. Por mi parte, llegué a la conclusión de que esta es la ID de la rueda. Entonces, se decodifica un byte más.
Lo más probable es que el último byte sea una suma de comprobación, que todavía no sé cómo leer. Esto siguió siendo un misterio para mí hasta el final.
El siguiente byte decodificado es la temperatura de la rueda. Suerte aquí. La temperatura ocupa 1 byte y se presenta en grados enteros. Temperatura negativa en complemento a dos. Esto significa que la temperatura de -127 ... 128 grados Celsius cabrá en un byte.
En nuestro paquete, la temperatura es el octavo byte
15B9F3FA2300BE1B007B0x1B corresponde a +27 grados
15B937740C03A1FC00A40xFC corresponde a -4 grados
Hay tres bytes no reconocidos 5º, 7º, 9º. A juzgar por la dinámica del cambio, la presión de los neumáticos está oculta en 7 bytes, y en el noveno byte, muy probablemente, los bits de estado del sensor. Según varias fuentes de información en Internet, así como la funcionalidad de mi sistema TPMS, debería haber un poco de batería descargada, un poco de pérdida de presión rápida y un par de bits más que no están claros para qué.
Entonces, analizaremos el séptimo byte, ya que queremos decir que la presión se esconde en él.
Habiendo escrito estadísticas sobre diferentes sensores con diferentes presiones, no pude definir claramente la fórmula que recalcula la presión. Y no está claro en qué unidad predeterminada el sensor transmite presión (Bar, PSI). Como resultado, la tabla construida en Excel no dio una coincidencia exacta con el marcador estándar de TPMS. Se podría descuidar esta diferencia de 0.1 Bar, pero quería el concepto de protocolo hasta el último bit. Prevaleció la emoción.
Si no puede entender cómo se forma el byte de presión, entonces necesita crear un emulador de sensor de presión y, cambiando el valor de presión, ver lo que muestra el panel estándar.
Quedaba por averiguar el propósito de los bytes 5 y 9 del paquete, pero rara vez cambian, por lo que puede aceptar sus valores como en el paquete original, cambiando solo el byte de presión. Ahora la cuestión es solo calcular la suma de comprobación. Sin él, el panel estándar ignorará mi paquete y no mostrará nada.
Para emular el sensor, tenía que enviar un paquete. Para esto, tenía un transceptor SI4432 conectado a un PIC16F88, que una vez se usó para otros fines.
Figura 4. Foto del tablero de prueba
Utilizando antiguas prácticas de transferencia de datos, esbocé un programa para el PIC que transmite uno de los paquetes que recibí con el programa URH. Algún tiempo después de encender el transmisor, el panel mostró los datos que le fueron transferidos. Pero este es un paquete listo para usar con un CRC listo para usar, y para poder cambiar el byte de presión, también debo volver a calcular el CRC.
Comencé a leer, buscando información sobre qué CRC se utilizan, probé diferentes Xor, etc., pero nada funcionó. Ya pensaba que nada saldría bien y tendría que contentarme con la presión que recibí según mi tabla, pero ligeramente diferente al marcador original. Pero en Internet vi un artículo sobre la selección de CRC. Había un programa al que le da varios paquetes e intenta encontrar una suma de verificación y, si tiene éxito, genera el valor del polinomio y el valor de inicialización CRC. [7] Le
damos al programa varios paquetes:
reveng -w 8 -s 15B9ABFF3202AA1B0017 15B9ABFF3202AA1B0249 15B9F3FA2300D01A00D8 15B937740C037B130089 15B937740C03BD18025E 15B9ABFF32028F150834El programa emite:
width=8 poly=0x2f init=0x43 refin=false refout=false xorout=0x00 check=0x0c residue=0x00 name=(none)Escribí un programa para calcular CRC teniendo en cuenta estos datos y lo ejecuté a través de los paquetes, que recibí antes, ¡todo salió bien!
// 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
}Manos ansiosas por transmitir datos de presión. Después de completar el programa de prueba con un cálculo CRC, transmití el primer paquete. El panel OEM recibió la señal y mostró la presión y la temperatura. Un pequeño problema era que el panel estándar tenía un decimal y, mientras transmitía el valor al aire, la pantalla siempre mostraba la misma presión, porque el resto de las descargas no fueron visibles. Valor de byte pasado 0..255. Pero nuevamente, de alguna manera no está claro. Resultó que la presión de 0,00 bar comienza cuando el séptimo byte contiene el valor 97. No está claro por qué es así. Pero entonces todo está claro con una resolución de 0.01 Bar.
Byte P Presión, 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
A juzgar por la tabla, la presión máxima que cabe en un byte es solo 1.58 Bar, pero el sistema le permite medir la presión hasta 4 Atm. Significa que 1 bit del bit más significativo está oculto en otro lugar. No había ningún deseo de revisar todos los bytes y cambiar los bits en ellos. Se encontró una rueda de un automóvil, se le puso un sensor y se capturó una señal. La curiosidad prevaleció y en mi mente apostaba por dónde aparecería el ritmo. Y que será exactamente un bit, y no algún otro esquema de codificación.
Después de decodificar el paquete, vi este bit. Es el séptimo bit del sexto byte. Esto significa que el sexto byte contiene no solo el número de rueda, sino también la parte más significativa de la presión de los neumáticos.
15B937740C833C18025C
El bit más significativo de 0x83 y 0x3C da 0x13C = 219 que corresponde a una presión de 2,19 Bar
La fórmula para convertir la presión a Bar: P = (ADC-97) / 100,
Donde ADC = (B7 >> 7) * 0x100 + B6, donde B6 y B7 son los valores del byte 6 y del byte 7.
Con un valor de 511 tenemos una presión máxima de 4 , 14 bares. Tampoco estaba claro por qué la barra era de 4,14 bares, pero supongo que esto es igual a 4 atm, la presión máxima permitida para el sensor.
Queda por entender de qué son responsables los bits de estado. Los bits se obtuvieron purgando la presión, conectando el sensor a una fuente de alimentación regulada y reduciendo el voltaje. Quedaron 2 bits poco claros. Quizás haya más, pero nunca han aceptado el valor de uno durante todo el experimento.
Para simplificar el análisis, se escribió un programa [8]
Fig.5. La apariencia de la interfaz del programa para examinar los paquetes TPMS.
Puede configurar el paquete sin procesar del programa URH en el programa en forma hexadecimal y el programa decodifica el paquete, lee la suma de control y muestra los datos en unidades normales de temperatura y presión.
De alguna manera volví al menú del panel estándar y vi que el identificador del sensor no es de dos bytes, sino de cuatro. El panel tiene indicadores grandes y pequeños y no noté de inmediato que el segundo y el quinto bytes también están incluidos en el ID del sensor.
15B937740C833C18025C
Por lo tanto, solo el primer byte permanece sin reconocer, pero siempre es 0x15 (0b010101), y esto parece cierto preámbulo de un paquete o su identificador inicial.
Además, los bits de estado no se reconocen exactamente, pero sí los que faltan.
La curiosidad por averiguar qué había dentro del sensor se apoderó de mí y desmonté uno de ellos (Fig.6)
Fig.6. Sensor TPMS
Se basa en el microcircuito Infineon SP372 con un pequeño fleje. Una búsqueda de la documentación de este microcircuito en particular no arrojó nada. Los que encontré son encuestas o publicidad. Entonces no fue posible conocer el protocolo. Pero los artículos mencionan que este es un controlador programable, por lo que el programa puede ser cualquier cosa. Por tanto, no me atreví a comprar el microcircuito por separado.
Protocolo
Ahora sobre la recepción de datos del sensor al transceptor SI4432. Originalmente se planeó recibir datos sin procesar de SI4432 para que el controlador decodifique Manchester y recopile bytes. Pero este transceptor tiene una función de procesamiento de paquetes. Es decir, para la transmisión, puede configurar el transmisor a la frecuencia deseada, modulación, desviación, establecer la longitud del preámbulo, codificación, palabra de sincronización, velocidad de bits, longitud de datos. Luego, escriba el paquete de datos original en el búfer del transmisor (por ejemplo, nuestro 15B937740C833C18025C) e inicie la transmisión. El propio transceptor formará un paquete y lo emitirá, observando todos los parámetros especificados, mientras que el controlador está libre en este momento para procesar otra información.
Idealmente, me gustaría recibir procesamiento de datos por lotes desde el SI4432 al recibir. Para que el receptor reciba el paquete y genere una interrupción de que el paquete ha sido recibido. Luego, el controlador simplemente lee el búfer de recepción, que ya almacena los datos en su forma pura, liberando así tiempo del procesador para otras funciones.
Comencé a estudiar la configuración de los registros para el funcionamiento del transceptor para la recepción. Esto resultó ser mucho más difícil que transferir el paquete. Aquí necesitas conocer bien la teoría de la recepción de radio, que yo no tengo. Existen tablas para calcular los registros en Excel para este transceptor, pero o no funcionan por el hecho de que Excel es ruso, o están truncadas. También hay una aplicación del desarrollador, pero allí tampoco todo es muy transparente. Después de revisar muchos ejemplos y mirar las tablas de cálculo, leí manualmente los valores de registro de acuerdo con la documentación.
Conecté un registrador a la salida del receptor y capturé el aire, dependiendo de lo que emite el receptor. Como resultado, logré configurar los filtros del receptor para que dejaran pasar mi paquete. Manipuló el caudal, golpeó la pandereta. La teoría, lamentablemente, todavía no me queda clara.
Para que el receptor pueda recibir un paquete de datos, debe especificar la longitud del preámbulo, la palabra de sincronización que debe estar presente y la longitud de los datos. También es posible que el receptor lea la propia suma de comprobación, pero en SI4432 el algoritmo de cálculo no corresponde al algoritmo CRC de los sensores de presión.
La presencia obligatoria de una palabra de sincronización de dos bytes podría eclipsar la idea de recibir un paquete, pero aquí fue una suerte que el mensaje del sensor comience en 0x15B9 (15B937740C833C18025C) y sea el mismo para todos los sensores. Esto significa que se especificó 0x15B9 para la palabra de sincronización. La longitud del paquete de datos es de 8 bytes, el análisis de suma de comprobación está deshabilitado. Configuramos la generación de una interrupción al recibir un paquete e iniciamos el procedimiento de recepción.
Cuando el receptor recibe el preámbulo, la palabra de sincronización 0x15B9 y 8 bytes de datos, emitirá una interrupción al controlador principal, que simplemente lee 8 bytes de datos del búfer del receptor. A continuación, el controlador principal calculará la suma de comprobación, la comparará y decodificará los datos recibidos. Afortunadamente, ¡todo salió como estaba planeado!
Figura 7. Foto del indicador TPMS estándar y la pantalla del cochecito "inteligente"
El siguiente es un ejemplo de cómo inicializar el transceptor SI4432 para recibir:
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 recepción de datos en sí se verá así:
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 función SI4432_ReadFIFO () simplemente lee 8 bytes del búfer del receptor, que contiene los datos del sensor.
La función TPMS_Parsing () analiza la suma de comprobación y decodifica la información en unidades finales de presión y temperatura, así como información de estado.
Problemas
- Al leer la información sobre los sensores, se mencionó la sincronización de los sensores entre sí. Por alguna razón, es necesario emparejar los sensores, había algo sobre una velocidad de más de 20 km / h durante 30 minutos. No está claro por qué esto es necesario. Quizás esto se deba al momento de la transferencia de información, pero esta es mi suposición.
- No me enteré hasta el final de la función de los bits de estado del sensor de presión.
- No está claro sobre la configuración del transceptor SI4432 para la recepción, sobre la velocidad en baudios utilizando la codificación Manchester. Funciona para mí, pero aún no se comprende el principio.
Resultados del trabajo
La investigación cubierta en este artículo tomó aproximadamente un mes de tiempo libre.
Como resultado del estudio del protocolo del sistema de monitoreo de presión de los neumáticos, se plantearon los problemas de transmisión y recepción de datos por aire, se consideró brevemente la codificación de la señal y se probó el transceptor SI4432 para transmisión y recepción. Esta tarea permitió integrar TPMS en el proyecto principal de un cochecito de bebé inteligente. Conociendo el protocolo de intercambio, puedes conectar más sensores e integrarlos en tu desarrollo. Además, la presión controlada puede estar dentro de amplios límites, y no como en el sistema estándar 1.1-3.2 Bar, porque La presión fuera de este rango va acompañada de un alarmante chirrido del sistema de unidad central estándar. Además, el TPMS ahora se puede usar para controlar la presión de los neumáticos de una motocicleta, bicicleta o, por ejemplo, un colchón de aire. Todo lo que queda es instalar físicamente el sensor y escribir un programa de nivel superior.
Enlaces
- Cochecito de bebé "inteligente" "Maksimka"
- github.com/jopohl/urh
- habr.com/ru/company/neuronspace/blog/434634
- www.rapidtables.com/convert/number/hex-to-binary.html
- www.rapidtables.com/convert/number/binary-to-hex.html
- eleif.net/manchester.html
- hackaday.com/2019/06/27/reverse-engineering-cyclic-redundancy-codes
- Mis utilidades, paquete de muestra, selección de CRC. Archivar contraseña "tPmSutiLity" dropmefiles.com/MtS9W "
- i56578-swl.blogspot.com/2017/08/eavesdropping-wheels-close-look-at-tpms.html
- www.rtl-sdr.com/tag/tpms