Carros são caros no Brasil, e esportivos ainda mais. Quando o VW Up foi lançado aqui, trazendo o motor EA211 1.0 TSI com câmbio manual, ele rapidamente conquistou o coração de entusiastas como eu. Pequeno, leve e surpreendentemente potente, ainda pode ser preparado para extrair mais desempenho. Mas não deixa de ser um carro comum — infelizmente, nunca tivemos no Brasil o Up GTI vendido na Europa.
Na tentativa de deixar o Up com um ar mais esportivo, e sabendo que o painel de instrumentos é quase idêntico ao do Fusca, decidi tentar instalar os relógios auxiliares do Fusca. Além de encaixarem bem, também poderiam trazer uma pegada mais “entusiasta” sem modificar a fiação original do carro.
Algumas pessoas já adaptaram esses relógios em um Fusca, ligando-os diretamente nas linhas de CAN do painel de instrumentos. Eu não tinha confiança de que isso funcionaria no Up, e não queria correr o risco de cortar o chicote do painel. Em vez disso, a ideia foi criar uma solução plug-and-play.
Eu adoro hackear coisas, fazê-las funcionar onde não deveriam e entender como funcionam — então esse era o desafio perfeito.
Desafio 1: Engenharia Reversa dos Relógios
O primeiro passo foi entender como controlar os relógios. Eles foram projetados para ouvir um barramento CAN (Controller Area Network) — um padrão robusto de comunicação automotiva que permite a microcontroladores e módulos trocarem informações sem precisar de um computador central. Em termos simples, diversos módulos eletrônicos do carro transmitem mensagens (chamadas frames) em um par de fios compartilhados. Esses dois fios, conhecidos como CAN High (CAN-H) e CAN Low (CAN-L), usam sinal diferencial. Isso significa que os dados são representados pela diferença de tensão entre eles, o que torna a comunicação muito confiável e resistente a ruídos elétricos — algo essencial no ambiente de um carro.
Como eu não tinha um Fusca para sniffar as mensagens originais do barramento CAN, precisei fazer engenharia reversa do protocolo com base em pesquisa e testes. O processo envolveu:
- Pesquisa: Vasculhar fóruns e documentação de grupos VAG em busca de IDs de frames CAN e formatos de dados. Muitos módulos VW/Audi compartilham protocolos, o que foi uma grande vantagem.
- Testes práticos: Alimentei os relógios em bancada e usei um Arduino com transceptor CAN para enviar diferentes frames até que eles reagissem. Ao enviar um CAN ID específico e mudar sistematicamente os 8 bytes de dados, consegui observar o que fazia os ponteiros de temperatura do óleo e pressão da turbina se moverem, além do que controlava o relógio e a iluminação.
Tabela Mestre de Frames CAN
Aqui está a lista completa de frames que os relógios respondem:
CAN ID | Byte 0 | Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 | Byte 6 | Byte 7 | Descrição |
0x588 | - | - | - | - | Pressão turbina / 2 | - | - | Temp óleo + 60 | Temperatura do óleo & Pressão da turbina |
0x62E | - | - | - | - | Horas × 0x10 | Minutos × 2 ¹ | - | - | Relógio |
0x320 | 0xFF se motor ligado, 0x0 senão | 0x01 se carro em movimento, 0x0 senão | - | - | Velocidade (km/h) | - | Velocidade ajustada (+5%) | - | Estado de condução / Velocidade |
0x470 | - | - | 0=auto, 1-100=% | - | - | - | - | - | Controle da iluminação |
¹ Adiciona 1 se a hora for 16:00 ou mais.
Desafio 2: Extraindo Dados do Carro via OBD-II
Ao contrário dos relógios auxiliares, que apenas escutam frames CAN transmitidos, a porta OBD-II do carro funciona no esquema requisição-resposta. Você não pode simplesmente ouvir a temperatura do óleo; é preciso pedir esse dado. Isso é feito com o protocolo UDS (Unified Diagnostic Services).
Cada requisição OBD-II é um frame CAN enviado a um endereço de ECU (Electronic Control Unit). Embora normalmente associada ao “módulo do motor”, na prática uma ECU pode ser qualquer módulo do carro, como o painel de instrumentos ou o controlador do motor. A requisição pede um dado identificado por um DID (Data Identifier), e a ECU responde com outro frame contendo a informação.
Detalhando Requisições e Respostas OBD-II
A lógica central é enviar uma requisição UDS "Read Data by Identifier" (serviço 0x22
) e interpretar a resposta positiva. No protocolo UDS, a resposta positiva é indicada somando 0x40
ao ID do serviço original, por isso o código de sucesso para o serviço 0x22
é 0x62
. Aqui vai o detalhamento, byte a byte, de cada requisição e resposta.
Frames de Requisição UDS
Parâmetro | Para ECU (ID) | Byte 0 (Len) | Byte 1 (Serviço) | Byte 2 (DID MSB) | Byte 3 (DID LSB) | Bytes 4-7 (Padding) |
Hora Atual | 0x714 (Painel) | 0x03 | 0x22 | 0x22 | 0x16 | 0x55 55 55 55 |
Temp. Óleo | 0x7E0 (Motor) | 0x03 | 0x22 | 0x11 | 0xBD | 0x55 55 55 55 |
Pressão Admissão | 0x7E0 (Motor) | 0x03 | 0x22 | 0xF4 | 0x0B | 0x55 55 55 55 |
Pressão Baro. | 0x7E0 (Motor) | 0x03 | 0x22 | 0xF4 | 0x33 | 0x55 55 55 55 |
Velocidade | 0x7E0 (Motor) | 0x03 | 0x22 | 0xF4 | 0x0D | 0x55 55 55 55 |
Frames de Resposta UDS
Parâmetro | De ECU (ID) | Byte 0 (Len) | Byte 1 (Serviço) | Byte 2 (DID Echo) | Byte 3 (DID Echo) | Byte 4 (Dado) | Byte 5 (Dado) | Bytes 6-7 |
Hora Atual | 0x71C | 0x04 | 0x62 | 0x22 | 0x16 | Hora | Minuto | Padding |
Temp. Óleo | 0x7E8 | 0x04 | 0x62 | 0x11 | 0xBD | Temp MSB | Temp LSB | Padding |
Pressão Admissão | 0x7E8 | 0x03 | 0x62 | 0xF4 | 0x0B | Pressão (kPa) | - | Padding |
Pressão Baro. | 0x7E8 | 0x03 | 0x62 | 0xF4 | 0x33 | Pressão (kPa) | - | Padding |
Velocidade | 0x7E8 | 0x03 | 0x62 | 0xF4 | 0x0D | Velocidade (km/h) | - | Padding |
Estratégia de Polling
Como só dá para enviar uma requisição por vez, implementei uma máquina de estados no Arduino. Assim consigo priorizar quais dados buscar e com que frequência:
- Alta frequência: Pressão de admissão e velocidade, para atualização rápida dos relógios.
- Média frequência: Temperatura do óleo a cada 5s, já que varia devagar.
- Baixa frequência: Hora (30s) e pressão barométrica (5min).
Esse equilíbrio mantém os relógios responsivos sem sobrecarregar o barramento OBD-II.
Desafio 3: Integrando Tudo e Instalando no Carro
Depois de resolver a eletrônica e o código, o próximo desafio foi integrar e instalar. A ideia era que os relógios parecessem OEM, bem encaixados no painel.
Eletrônica: Um Tradutor com Arduino
O cérebro do sistema é um Arduino Uno com dois shields MCP2515 CAN bus. Tudo vai dentro de uma caixa impressa em 3D.
Você pode se perguntar por que usei um Arduino Uno em vez de um microcontrolador mais poderoso (e compacto) como o ESP32. Eu até comecei com um ESP32, mas o Uno trouxe duas vantagens práticas:
- Pode ser alimentado direto pelos 12V do carro através do regulador onboard, sem precisar de conversor buck externo.
- O formato de shields permite empilhar dois MCP2515 sobre o Arduino, resultando em uma unidade compacta e limpa.
Isso deixou a instalação final bem mais simples e robusta.
- Shield 1 conecta ao barramento CAN dos relógios.
- Shield 2 conecta ao CAN do carro via OBD2.
- Arduino e relógios são alimentados pela porta OBD2.
Aqui está o diagrama de conexão:
Montando os Relógios
Projetei um suporte para encaixar no lugar onde normalmente fica o suporte de celular original:
- Modelagem 3D – desenhei o suporte para ocupar o espaço exato no painel.
- Impressão 3D – usei PETG (PLA deforma no calor do Brasil; ABS é mais chato de imprimir). O suporte de PETG está no meu carro há um ano sem problemas.
- Acabamento – colado, lixado e pintado para ficar limpo.
- Instalação – fixado no painel no lugar do suporte de celular original. O encaixe ainda não é perfeito, mas já funciona bem.
Possíveis Melhorias
- Iluminação dinâmica: Hoje fica sempre ligada, mas poderia ser sincronizada com a iluminação do carro.
- Leitura CAN mais eficiente: Usar interrupções seria mais eficiente que polling, mas do jeito que está funciona bem.
Conclusão
Esse projeto juntou engenharia reversa, programação embarcada, hacking de CAN bus e fabricação em 3D. Foi preciso paciência e várias iterações para:
- Entender os relógios.
- Extrair e priorizar dados do VW Up via OBD2.
- Integrar a eletrônica e criar um suporte adequado no painel.
O resultado? Relógios auxiliares do Fusca funcionando plug-and-play no VW Up, com suporte customizado e eletrônica discreta.
Código-Fonte
Você encontra o código-fonte completo para Arduino deste projeto no GitHub.