Enviar Dados GPS para Servidor Próprio: Guia TAIP e Wialon IPS

🎯 Para quem é este artigo: integradores e desenvolvedores que operam seu próprio backend e querem que o rastreador GPS reporte diretamente ao seu servidor — sem plataforma obrigatória no meio.

Muitas das consultas técnicas que recebemos começam da mesma forma: "já temos nossa própria plataforma, só precisamos de hardware que fale com ela". É exatamente para isso que os equipamentos Rinho foram projetados: o rastreador mede e transmite (suas regras de eventos embarcadas decidem quando e o que reportar); alertas, regras e relatórios de negócio vivem no seu servidor. Este guia cobre o caminho completo para enviar dados GPS para o seu próprio servidor: escolher entre Rinho TAIP e Wialon IPS, apontar o equipamento para o seu host e porta, colocar um receptor no ar, fazer o parsing de tramas reais e prepará-lo para produção.

Passo 1: escolha o protocolo — TAIP ou Wialon IPS

Todo rastreador Rinho — Zero IoT, Smart IoT e Spider IoT — fala dois protocolos de saída abertos:

	Rinho TAIP	Wialon IPS
Ideal para	Receber os dados no seu próprio servidor	Conectar a uma plataforma que já fala IPS
Tipo	ASCII, base Trimble TAIP com extensões Rinho	Protocolo aberto publicado pela Gurtam (v1.1)
Transporte	UDP e TCP, framing idêntico	TCP/UDP
Telemetria	Conjunto estendido completo: temperaturas, bateria de backup, horímetro, identificação de motorista por iButton, CAN bus (OBD-II / J1939)	Conforme definido pelo padrão IPS
Docs e ferramentas	Guia de integração de 30 páginas (PDF) + servidor de exemplo open source	Suportado por Wialon, Navixy, Traccar e outros

A regra prática: se você está construindo sua própria ingestão de dados, use o Rinho TAIP — é o protocolo nativo totalmente documentado, e o restante deste guia percorre esse caminho. Se você está conectando a uma plataforma de terceiros existente, use o Wialon IPS (disponível em toda a linha desde o firmware v1.09.19): veja o anúncio do Wialon IPS para plataformas suportadas e detalhes de conexão.

Passo 2: aponte o equipamento para o seu host e porta

Host de destino, porta e transporte (UDP ou TCP) são configurações por equipamento; a forma mais rápida de defini-los é o configurador web. Os listeners TAIP normalmente rodam na porta 4031 (primária) e 4034 (secundária), mas as portas são totalmente configuráveis. Duas coisas que vale saber antes de fazer o deploy:

• O equipamento se identifica com um campo ID= em cada mensagem — normalmente o IMEI.
• Uma vez online, ele envia um keep-alive a cada 60 segundos (configurável), então seu servidor sempre sabe quais equipamentos estão vivos.

O modelo de hardware não muda a integração: Zero, Smart e Spider são idênticos no nível de protocolo, e qualquer modelo pode gerar qualquer tipo de reporte — o tipo de reporte é configurado por equipamento, não determinado pelo hardware.

Passo 3: coloque o receptor no ar

Sua escolha de transporte define o trabalho do receptor:

• UDP: sem conexão. Mantenha uma tabela NAT mapeando cada ID de equipamento ao IP:porta de origem do seu último pacote, envie comandos de volta para esse endereço pelo mesmo socket e expire entradas sem atividade por um período prolongado (ex.: 24 horas).
• TCP: o equipamento abre uma conexão persistente com o seu servidor. Como TCP é um stream, bufferize os bytes recebidos e extraia tramas >...< completas — um segmento pode carregar várias mensagens, ou uma mensagem dividida entre segmentos.

Nos dois casos, um único datagrama ou segmento pode conter múltiplas tramas: sempre varra todos os >...< nos dados recebidos.

Você não precisa começar do zero. O open source rinho-udp-server (Node.js, licença MIT) escuta em uma porta UDP configurável, faz o parsing de reportes de posição padrão, envia ACKs, rastreia equipamentos ativos, enfileira comandos com retentativas e armazena em MySQL. É um exemplo para aprendizado/testes — não está pronto para produção como está — mas mostra cada peça em movimento. Esta é sua rotina de checksum XOR, na íntegra:

exports.calculateChecksum = function (cmd) {
    var checksum = 0;
    for (var i = 0; i < cmd.length; i++) {
        checksum = checksum ^ cmd.charCodeAt(i);
    }
    var hexsum = Number(checksum).toString(16).toUpperCase();
    if (hexsum.length < 2) {
        hexsum = ("00" + hexsum).slice(-2);
    }
    return hexsum;
}

O checksum é o XOR de cada byte desde > até * inclusive, formatado como dois dígitos hexadecimais maiúsculos. Tramas com checksum inválido são descartadas silenciosamente — nunca recebem ACK.

Passo 4: faça o parsing das tramas

Toda mensagem TAIP segue a mesma estrutura:

>BODY[;#MSGNUM];ID=DEVICEID;*CHECKSUM<

Aqui está um reporte de posição padrão de exemplo (tipo RCQ):

>RCQ28060426153025-3462000-05838000045180A2031280000001103051005121115;#002A;ID=860012345678901;*4E<

Depois do prefixo de 3 caracteres (R + tipo de reporte), a base tem sempre 66 caracteres de posição fixa. Campos-chave desta trama:

Campo	Bruto	Decodificado	Regra
Data/hora (UTC)	060426153025	2026-04-06 15:30:25	relógio GPS do equipamento
Latitude	-3462000	-34,62000°	÷ 100000
Longitude	-05838000	-58,38000°	÷ 100000
Velocidade	045	45 km/h	km/h, não em nós
Curso	180	180°	direto
Entradas	A2	ignição ON (bit 7) + IN05 + IN01	bitmask hexadecimal
Tensão principal	128	12,8 V	÷ 10
Odômetro	00000011	17 m	hex → metros
Satélites / PDOP	10 / 05	10 satélites, PDOP 5	decimal

O RCQ é um dos 14 tipos de reporte que compartilham essa base de 66 caracteres; os sufixos adicionam temperaturas (RCR/RCV), tensão da bateria de backup (RBQ), bateria de backup + horímetro do motor (RHQ), identificação de motorista por iButton (RCT), sessões de motorista (RCU) e dados de CAN bus como PIDs OBD-II (REQ) ou SPNs J1939 (RER). Valores de sensores custom (temperatura BLE, combustível etc.) viajam em um segmento AP= ou PA= (os dois prefixos são equivalentes; a versão do firmware determina qual é usado) com parâmetros tipados name:type:value — note que alguns scripts legados emitem pares name:value sem tipo. Duas conversões que pegam integrações reais: o campo de idade da temperatura é hexadecimal (0x00–0xFF segundos) enquanto o PDOP é decimal, e o horímetro converte hex → segundos de funcionamento do motor. Os mapas completos de campos estão no guia de integração do protocolo (PDF).

Passo 5: produção — ACK, keep-alive e confiabilidade

A confiabilidade se apoia na numeração de mensagens mais ACK. Seu servidor deve confirmar toda mensagem que carregue um #MSGNUM abaixo de 0x8000, ecoando exatamente o msgNum e o ID do equipamento:

Equipamento → servidor:  >RCQ28060426153025-3462000-05838...;#002A;ID=860012345678901;*4E<
Servidor → equipamento:  >ACK;#002A;ID=860012345678901;*38<

• Só envie ACK depois de persistir. Se a gravação no seu banco de dados falhar, não envie ACK — o equipamento retransmite (timeout de 7 segundos, até 4 retentativas por mensagem, até 9 mensagens em voo em paralelo). É isso que garante que nenhum dado se perca.
• Nunca envie ACK para keep-alives. O >KA;ID=860012345678901;*10< chega a cada 60 segundos; apenas atualize sua tabela NAT (UDP) ou o estado da conexão (TCP) e fique em silêncio.
• msgNum ≥ 0x8000 é uma resposta, não um novo reporte. Um comando que você envia como #0042 volta confirmado como #8042 (bit 15 setado). Case-o com o comando pendente — não envie ACK para ele.
• Proteja o perímetro. O protocolo é texto plano com identificação apenas por ID, então restrinja quem pode alcançar sua porta de ingestão (VPN, whitelist de IPs, firewall) e valide os IDs dos equipamentos contra o seu próprio cadastro de dispositivos.

Os comandos usam o mesmo framing no sentido inverso — do seu backend você pode consultar o firmware (>QVR;#0042;ID=860012345678901;*51<), ler o IMEI e o número de série, ou enviar configuração.

Recursos

Rinho Telematics:

• Guia de Integração do Protocolo Rinho (PDF) — 30 páginas: framing, checksum, os 14 tipos de reporte, mecanismo de ACK, comandos e mensagens de exemplo.
• Configurador web — defina host/porta de destino e as opções do equipamento pelo navegador.
• Documentação técnica — referência de firmware e configuração.
• Anúncio do Wialon IPS — se você vai conectar a uma plataforma existente.

Recursos externos:

• rinho-udp-server no GitHub — receptor de referência open source em Node.js (MIT).

Em resumo

• Os rastreadores Rinho reportam diretamente ao seu host:porta por UDP ou TCP — Rinho TAIP para o seu próprio backend, Wialon IPS para plataformas que já o falam. Nenhuma plataforma intermediária é necessária.
• O protocolo é ASCII e totalmente documentado: base de posição de 66 caracteres, sufixos de telemetria estendida e ACK com retransmissão (timeout de 7 s, 4 retentativas) para que falhas transitórias não descartem dados silenciosamente.
• Entre o guia em PDF e o servidor UDP de exemplo, você pode estar fazendo o parsing de tramas ao vivo de um equipamento real no mesmo dia.

Está construindo sua solução sobre o seu próprio backend? Esse é exatamente o perfil para o qual projetamos: protocolo aberto, hardware documentado, suporte direto de fábrica. Comece pela página Para integradores ou fale conosco e ajudamos você a receber as primeiras tramas no seu servidor.