Estudo de protocolo do sistema de monitoramento da pressão dos pneus do veículo (TPMS)

O sistema de monitoramento remoto da pressão do ar em pneus de automóveis (abreviatura TPMS - Tire Pressure Monitoring System) foi desenvolvido para informar prontamente o usuário sobre a diminuição da pressão dos pneus e da temperatura crítica dos pneus.



Os sensores estão disponíveis interna ou externamente. Os internos são instalados dentro do pneu da roda sem câmara, os externos são aparafusados ​​no encaixe da roda. Uma roda com sensor interno é exatamente igual a uma roda sem sensor. Essa roda é fácil de bombear. O sensor externo é perceptível, pode ser roubado e deve primeiro ser desparafusado ao inflar a roda. Também é influenciado por fenômenos atmosféricos.



Para investigar o protocolo do sistema TPMS, tive a ideia de instalar um sistema desse tipo em um carrinho para monitorar rapidamente a pressão dos pneus.



imagem

Figura 1. Aparência do sistema TPMS



imagem

Figura 2. Placa controladora do sistema TPMS



Não foi possível instalar a unidade receptora padrão assim, pois o valor mínimo de pressão permitido é 1,1 Bar, e em um carrinho de bebê é menor. Portanto, o módulo emite bipes constantes, informando sobre pressão baixa dos pneus. Você pode ler sobre o desenvolvimento de um controlador para o carrinho de bebê "Smart" "Maksimka" , no qual os resultados da pesquisa são aplicados, em meu artigo [1].



A coleta de informações sobre o funcionamento do TPMS começou com a busca de artigos na Internet. Mas, infelizmente, há poucas informações. E também se aplica aos sistemas automotivos normalmente padrão, que são um pouco mais complicados e muito mais caros. E eu precisava de informações sobre um sistema barato chinês simples. Eu tinha um entendimento mínimo, agora precisava começar os experimentos.



Então, nós nos armamos com o apito USB do sintonizador DVB, lançamos o RTL-SDR e assistimos à transmissão. Os sensores operam a 433,92 MHz em modulação FSK. Inicialmente, gravei a transmissão e depois analisei manualmente o protocolo. Aqui as dificuldades começaram. Anteriormente, encontrava apenas modulação OOK. Tudo é simples aí. É um pouco mais complicado aqui. A informação é codificada com duas frequências. Portanto, estudei exemplos, a teoria das modulações. Então eu vi como o programa URH-Universal Radio Hacker foi usado [2, 3]. Tentei instalá-lo, mas não funciona no meu WinXP de 32 bits. Tive que procurar um computador com win8 64bit e então o programa foi instalado. Você pode ler mais sobre o trabalho dela no site do desenvolvedor. URH tornou o processo um pouco mais fácil para mim, porque ele captura o sinal do ar, exibe-o com um oscilograma e imediatamente o decodifica em uma forma digital bruta tanto na forma binária quanto hexadecimal.



imagem

Fig. 3. Captura de tela do programa com o frame capturado do envio do TPMS



O sensor envia vários pacotes um após o outro em uma sessão. O período entre as sessões pode ser de até um minuto ou mais. Se ocorrer uma situação de alarme, o sensor imediatamente começa a enviar pacotes de dados. O arquivo de som da mensagem do sensor [8]. Um exemplo de uma mensagem do sensor tirada do programa URH:



010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101011001100110100110101001011001011010011010100110101001100101010101011010010101010101010110101001011001101010010101100101101001010101011001011001100110101001


Na forma hexadecimal, essa premissa assumirá a forma:



5555555555555555555555555555555555555555555555555555555555555555555556669a965a6a6a6555a5555a966a565a556599a9


Ficou evidente que todos os 4 pacotes em uma sessão tinham os mesmos dados, o que significa que o pacote foi aceito corretamente e você pode começar a analisá-lo.



No exemplo acima, você pode ver o preâmbulo (sequência 01010101….), Seguido pelos dados. Depois de ler na Internet, entendemos que temos um pacote codificado com Manchester (GE Thomas). Cada bit é codificado com dois bits 01 ou 10. Eu codifiquei originalmente à mão, reforçando assim a teoria de codificação / decodificação. Mas então decidi recorrer ao decodificador online [4,5,6], que acelerou bastante o processo.



Então, decodificando a mensagem original do sensor com o código Manchester, obtemos



000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010101101110010011011101110100000011000000001110010111000100110000010010101110


Os primeiros 136 zeros são um preâmbulo e podem ser descartados. Estamos interessados ​​apenas em dados.



Traduzindo-os para a forma hexadecimal, obtemos: 0x15B937740C03971304AE



Isso já contém belos dados iniciais, nos quais o identificador, a pressão do pneu e a temperatura estão ocultos em algum lugar.



Para pesquisas futuras, é necessário coletar dados estatísticos. Para fazer isso, enrolei um sensor na roda e capturei o ar, enquanto gravava o que a placa do sistema original mostra. Ele liberou a pressão, bombeou, colocou a roda no freezer para uma temperatura negativa, aqueceu. Em seguida, ele procurou as mesmas condições para outro sensor para descobrir os bytes de temperatura e pressão.



O pacote completo ocupa 10 bytes. Se você alinhar os dados decodificados recebidos em uma coluna, poderá ver dados constantes e dados variáveis.



15B937740C03971304AE
15B937740C03A1FC00A4
15B937740C03A700087B


Existem adesivos nos sensores do corpo. Cada sensor é diferente: 0A, 1B, 2C, 3D.



O pensamento estereotipado aqui não funcionou bem. Achei que fosse o sensor ID.

Eu duvidava do motivo pelo qual o ID ocupava apenas 1 byte, mas então esqueci e tentei pesquisar esses identificadores no stream. Então, no menu do receptor original do sistema, vi que outros sensores poderiam ser ligados a este receptor, e o próprio receptor mostra o ID do sensor em cada roda. E, vejam só, descobri que o sensor da quarta roda tem ID = 3774.



15B937740C03971304AE


Portanto, o terceiro e o quarto bytes do pacote são o ID da roda. Comparado com outros sensores e também os identificadores coincidiram com aqueles exibidos pelo painel padrão.



Contei o primeiro byte como o prefixo do início dos dados e o segundo byte como o identificador do subsistema TPMS.

Abaixo está a comparação de pacotes de diferentes sensores.



15B9F3FA2300BE1B007BSensor 0A ID = 0xF3FA

15B91AA43201B71B002ASensor 1B ID = 0x1AA4

15B9ABFF32027B1B029BSensor 2C ID = 0xABFF

15B937740C03971304AESensor 3D ID = 0x3774



E percebi que as inscrições nos sensores (0A, 1B, 2C, 3D) são apenas números de rodas em formato digital e em ordem alfabética, não hexadecimal id da roda. Mas, mesmo assim, o 6º byte do pacote é muito semelhante ao número de série do sensor. Para mim, concluí que este é o identificador da roda. Então, mais um byte é decodificado.



O último byte é provavelmente uma soma de verificação, que ainda não sei ler. Isso permaneceu um mistério para mim até o fim.



O próximo byte decodificado é a temperatura da roda. Sorte aqui. A temperatura ocupa 1 byte e é apresentada em graus inteiros. Temperatura negativa em complemento de dois. Isso significa que a temperatura de -127 ... 128 graus Celsius caberá em um byte.



Em nosso pacote, a temperatura é o 8º byte



15B9F3FA2300BE1B007B0x1B corresponde a +27 graus

15B937740C03A1FC00A40xFC corresponde a -4 graus



Existem três bytes não reconhecidos, 5º, 7º, 9º. A julgar pela dinâmica da mudança, a pressão do pneu está oculta em 7 bytes, e no 9º byte, provavelmente, nos bits de status do sensor. De acordo com várias fontes de informação na Internet, além da funcionalidade do meu sistema TPMS, deve haver um pouco de bateria descarregada, um pouco de perda rápida de pressão e mais alguns bits que não estão claros para quê.



Então, vamos analisar o 7º byte, uma vez que queremos dizer que a pressão está escondida nele.

Tendo digitado estatísticas em diferentes sensores com diferentes pressões, não pude definir claramente a fórmula que recalcula a pressão. E não está claro em quais unidades o sensor transmite pressão por padrão (Bar, PSI). Como resultado, a tabela construída no Excel não forneceu uma correspondência exata com o placar TPMS padrão. Pode-se ignorar essa diferença de 0,1 Bar, mas eu queria o conceito de protocolo até o fim. A excitação prevaleceu.



Se você não consegue entender como o byte de pressão é formado, você precisa fazer um emulador de sensor de pressão e, alterando o valor da pressão, ver o que o painel padrão exibe.



Faltava descobrir a finalidade do 5º e 9º bytes do pacote, mas eles raramente mudam, então você pode aceitar seus valores como no pacote original, mudando apenas o byte de pressão. Agora, a questão é apenas calcular a soma de verificação. Sem ele, o painel padrão irá ignorar meu pacote e não mostrar nada.



Para emular o sensor, você tinha que enviar um pacote. Para isso, eu tinha um transceptor SI4432 conectado a um PIC16F88, que já foi usado para outros fins.



imagem

Fig. 4. Foto da placa de teste



Usando práticas antigas de transferência de dados, esbocei um programa para o PIC que transmite um dos pacotes que recebi com o programa URH. Algum tempo depois de ligar o transmissor, o painel exibiu os dados que foram transferidos para ele! Mas este é um pacote pronto com um CRC pronto, e para que eu possa alterar o byte de pressão, também preciso recalcular o CRC.



Comecei a ler, procurando informações sobre quais CRCs são usados, tentei diferentes Xor, etc., mas nada funcionou. Já pensei que nada daria certo e teria que me contentar com a pressão que recebi de acordo com a minha tabela, mas um pouco diferente do placar original. Mas, na Internet, vi um artigo sobre a seleção de CRC. Havia um programa ao qual você dá vários pacotes e ele tenta encontrar uma soma de verificação e, se for bem-sucedido, gera o valor polinomial e o valor de inicialização CRC. [7] Damos



ao programa vários pacotes:



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


Os problemas do programa:



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


Eu escrevi um programa para calcular o CRC levando em consideração esses dados e passei pelos pacotes, o que recebi antes - veio tudo junto!



//  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
 }


Mãos coçaram para transmitir dados de pressão. Depois de completar o programa de teste com um cálculo CRC, transmiti o primeiro pacote. O painel OEM recebeu o sinal e exibiu a pressão e a temperatura. Um pequeno problema era que o painel padrão possuía uma casa decimal e, transmitindo o valor ao ar, a tela sempre exibia a mesma pressão, pois o resto das descargas não foram visíveis. Valor do byte passado 0..255. Mas, novamente, de alguma forma não está claro. Descobriu-se que a pressão de 0,00 Bar começa quando o 7º byte contém o valor 97. Não está claro por que isso acontece. Mas então tudo fica claro com uma resolução de 0,01 Bar.



Byte P Pressão, 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 julgar pela tabela, a pressão máxima que cabe em um byte é de apenas 1,58 Bar, mas o sistema permite medir pressão de até 4 Atm. Isso significa que 1 bit do bit mais significativo está escondido em outro lugar. Não havia desejo de percorrer todos os bytes e alterar os bits neles. Uma roda de um carro foi encontrada, um sensor foi enrolado nela, um sinal foi capturado. A curiosidade prevaleceu, e na minha cabeça eu apostava onde a batida apareceria. E que será exatamente um bit, e não algum outro esquema de codificação.



Depois de decodificar o pacote, vi este bit. É o 7º bit do 6º byte. Isso significa que o 6º byte contém não apenas o número da roda, mas também a parte mais significativa da pressão do pneu.

15B937740C833C18025C



O bit mais significativo de 0x83 e 0x3C dá 0x13C = 219 que corresponde a uma pressão de 2,19 Bar

A fórmula para converter a pressão em Bar: P = (ADC-97) / 100,

Onde ADC = (B7 >> 7) * 0x100 + B6, onde B6 e B7 são os valores do byte 6 e do byte 7.



Com um valor de 511, temos uma pressão máxima de 4 , 14 Bar. Também não ficou claro por que a barra era de 4,14 Bar, mas acho que é igual a 4 Atm - a pressão máxima permitida para o sensor.



Resta entender pelo que os bits de status são responsáveis. Os bits foram obtidos sangrando a pressão, conectando o sensor a uma fonte de alimentação regulada e reduzindo a tensão. 2 bits permaneceram obscuros. Talvez haja mais, mas eles nunca aceitaram o valor de um durante todo o experimento.



Para simplificar a análise, um programa foi escrito [8]



imagem

Fig.5. A aparência da interface do programa para examinar os pacotes TPMS



Você pode definir o pacote bruto do programa URH no programa em formato hexadecimal e o programa decodifica o pacote, lê a soma de verificação e exibe os dados em unidades normais de temperatura e pressão.



De alguma forma, voltei ao menu do painel padrão e vi que o identificador do sensor não é dois bytes, mas quatro. O painel tem indicadores grandes e pequenos e não notei imediatamente que o 2º e o 5º bytes também estão incluídos na ID do sensor.



15B937740C833C18025C



Assim, apenas o primeiro byte permanece não reconhecido, mas é sempre 0x15 (0b010101), e isso se parece com um certo preâmbulo de um pacote ou seu identificador inicial.



Além disso, os bits de status não são reconhecidos exatamente, mas aqueles que estão faltando.



A curiosidade em saber o que prevalecia dentro do sensor e desmontei um deles (Fig . 6) Fig. 6



imagem

. Sensor TPMS



É baseado no microcircuito Infineon SP372 com uma pequena cinta. Uma busca pela documentação deste microcircuito em particular não resultou em nada. Os que encontrei são pesquisas ou publicidade. Portanto, não foi possível conhecer o protocolo. Mas os artigos mencionam que este é um controlador programável, então o programa pode ser qualquer coisa. Portanto, não me atrevi a comprar o microcircuito separadamente.



Protocolo



Agora, sobre como receber dados do sensor para o transceptor SI4432. Ele foi originalmente planejado para receber dados brutos do SI4432 para que o controlador decodifique Manchester e colete bytes. Mas este transceptor tem uma função de processamento de pacotes. Ou seja, para transmissão, você pode configurar o transmissor para a frequência desejada, modulação, desvio, definir o comprimento do preâmbulo, codificação, palavra de sincronização, taxa de bits, comprimento de dados. Em seguida, grave o pacote de dados original no buffer do transmissor (por exemplo, nosso 15B937740C833C18025C) e inicie a transmissão. O próprio transceptor formará um pacote e o transmitirá, observando todos os parâmetros especificados, enquanto o controlador está livre neste momento para processar outras informações.



Idealmente, gostaria de receber processamento de dados em lote do SI4432 ao receber. Para que o receptor receba o pacote e gere uma interrupção de que o pacote foi recebido. Em seguida, o controlador simplesmente lê o buffer de recepção, que já armazena os dados em sua forma pura, liberando assim o tempo do processador para outras funções.



Comecei a estudar a configuração dos registros para o funcionamento do transceptor para recepção. Isso acabou sendo muito mais difícil do que transferir o pacote. Aqui você precisa conhecer bem a teoria da recepção de rádio, que eu não tenho. Existem tabelas para cálculos de registros no Excel para este transceptor, mas elas não funcionam devido ao fato de o Excel ser russo ou estão truncadas. Existe também um aplicativo do desenvolvedor, mas também não é tudo muito transparente. Depois de passar por muitos exemplos e olhar as tabelas de cálculo, li manualmente os valores do registro de acordo com a documentação.



Eu conectei um logger na saída do receptor e capturei o ar, dependendo do que o receptor distribui. Como resultado, consegui configurar os filtros do receptor para que deixassem meu pacote passar. Ele manipulou a vazão e bateu no pandeiro. A teoria, infelizmente, ainda não está clara para mim.



Para que o receptor possa receber um pacote de dados, ele precisa especificar o comprimento do preâmbulo, a palavra de sincronização que deve estar presente e o comprimento dos dados. Também é possível para o receptor ler o próprio checksum, mas no SI4432 o algoritmo de cálculo não corresponde ao algoritmo CRC dos sensores de pressão.



A presença obrigatória de uma palavra de sincronização de dois bytes pode ofuscar a ideia de receber um pacote, mas aqui foi uma sorte que o envio do sensor comece em 0x15B9 (15B937740C833C18025C) e seja o mesmo para todos os sensores. Isso significa que 0x15B9 foi especificado para a palavra de sincronização. O comprimento do pacote de dados é de 8 bytes, a análise de checksum está desabilitada. Definimos a geração de uma interrupção ao receber um pacote e iniciamos o procedimento de recepção.



Quando o receptor recebe o preâmbulo, palavra de sincronização 0x15B9 e 8 bytes de dados, ele emitirá uma interrupção para o controlador principal, que simplesmente lê 8 bytes de dados do buffer do receptor. Em seguida, o controlador principal irá calcular a soma de verificação, compará-la e decodificar os dados recebidos. Felizmente, tudo correu conforme o planejado!



imagem

Fig. 7. Foto do indicador TPMS padrão e a tela do carrinho "inteligente"



A seguir está um exemplo de inicialização do transceptor SI4432 para receber:



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);     //   


A recepção de dados em si será semelhante a esta:



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;
   }


A função SI4432_ReadFIFO () simplesmente lê 8 bytes do buffer do receptor, que contém os dados do sensor.



A função TPMS_Parsing () analisa a soma de verificação e decodifica as informações em unidades finais de pressão e temperatura, bem como informações de status.



Problemas



  1. Ao ler as informações sobre os sensores, foi mencionada a sincronização dos sensores entre si. Por algum motivo é necessário emparelhar os sensores, havia algo como uma velocidade de mais de 20 km / h durante 30 minutos. Não está claro por que isso é necessário. Talvez isso seja devido ao momento da transferência das informações, mas é o meu palpite.
  2. Não descobri até o final da função dos bits de status do sensor de pressão.
  3. Não está claro sobre a configuração do transceptor SI4432 para recepção, sobre a taxa de transmissão usando a codificação Manchester. Funciona para mim, mas não há consciência do princípio ainda.


Resultados do trabalho



A pesquisa abordada neste artigo levou cerca de um mês de tempo livre.



Como resultado do trabalho de estudo do protocolo do sistema de monitoramento da pressão dos pneus, foram levantadas as questões de transmissão e recepção de dados pelo ar, a codificação do sinal foi brevemente considerada, o transceptor SI4432 foi testado para transmissão e recepção. Essa tarefa permitiu que o TPMS fosse integrado ao projeto principal do carrinho de bebê inteligente. Conhecendo o protocolo de troca, você pode conectar mais sensores e integrá-los ao seu desenvolvimento. Além disso, a pressão controlada pode estar dentro de limites amplos, e não como no sistema padrão 1,1-3,2 Bar, porque a pressão fora dessa faixa é acompanhada por um ruído alarmante do sistema de unidade central padrão. Além disso, o TPMS agora pode ser usado para monitorar a pressão dos pneus de uma motocicleta, bicicleta ou, por exemplo, um colchão de ar. Tudo o que resta é instalar fisicamente o sensor e escrever um programa de nível superior.



Links



  1. Carrinho de bebê "inteligente" "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. Meus utilitários, pacote de amostra, seleção CRC. Arquivo de senha "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