trochometer

Transcrição

trochometer
TRABALHO DE CONCLUSÃO DO CURSO TÉCNICO DE INFORMÁTICA
INTEGRADO AO ENSINO MÉDIO
TACHOMETER
Gabriela Fontanelli D'Angelo
Luiz Henrique Montanher Tiago
Lucas Bulgarelli
Willian Kazuo Koga Onoue
Professora Orientadora:
Márcia Cristina dos Santos Ferreira
São Caetano do Sul / SP
2013
TACHOMETER
Trabalho
de Conclusão
de Curso
apresentado como pré-requisito para
obtenção do Diploma de Técnico em
Informática.
São Caetano do Sul / SP
2013
Dedicamos este trabalho a nossos pais
por todo carinho e amor dedicado a nós
durante todo este tempo e para todos os
nossos professores que tanto admiramos.
AGRADECIMENTOS
Agradecemos primeiramente a nossas famílias por terem nos proporcionado
a oportunidade de estudar e de buscar o conhecimento, realizando mais uma
conquista.
Aos colegas por terem tornado essa jornada mais agradável.
A todos os nossos professores que se dedicaram e repassaram todo o seu
conhecimento para que aprendêssemos mais a cada dia.
A empresa Eletrotécnica Sacch por ter patrocinado este projeto e nos
proporcionado a experiência de trabalhar em conjunto, onde aprendemos
muito.
A todos, nosso muitíssimo obrigado.
RESUMO
O projeto é composto por um programa em Java para controle de
equipamentos para manutenção automotiva, que realiza medidas de diversos
componentes de um veículo automotor. Suas principais funções são: medir a
tensão da bateria, as rotações do motor, o tempo de injeção de combustível,
o sinal da sonda Lambda, e ainda é um voltímetro multifunção. Através desse
equipamento o mecânico será capaz de realizar medições com maior
facilidade e praticidade, sendo assim, um equipamento de grande valia para
o mercado.
Palavras-chave: Equipamentos. Medições. Automotivo.
ABSTRACT
The project consists of a Java program for automotive maintenance
equipments control, which performs measures of several components of an
automotive vehicle. Its main functions are: to measure the battery voltage,
engine speed, the fuel injection time, the voltage of the Lambda sensor, and a
multifunction voltmeter. Through this equipment, the mechanic will be able to
perform measurements easily and with more practicity, this way, a equipment
of large value for the market.
Keywords: Equipments. Measurements. Automotive.
LISTA DE ILUSTRAÇÕES
Figura 1 – Formato do DTC.......................................................................... 16
Figura 2 – Scanner SPCMAX....................................................................... 17
Figura 3 – Voltímetro.....................................................................................18
Figura 4 – Tacômetro.................................................................................... 19
Figura 5 – Osciloscópio................................................................................ 20
Figura 6 – Válvula injetora de combustível................................................... 26
Figura 7 – Tachometer – Tela Inicial............................................................. 50
Figura 8 – Tachometer – Botão Atualiza....................................................... 51
Figura 9 – Tachometer – Botão Conectar..................................................... 52
Figura 10 – Tachometer – Aba Medições (Tensão da Bateria)..................... 53
Figura 11 – Realizando a Medição............................................................... 54
SUMÁRIO
Introdução....................................................................................................................... 10
1. A Informatização nos Aparelhos Eletrônicos de Teste.................................................. 12
1.1 O Surgimento dos Equipamentos de Teste......................................................12
1.2 Equipamentos de Teste Elétricos e Eletrônicos............................................... 12
1.3 Equipamentos de Teste Informatizados........................................................... 13
1.4 A Informatização nas Oficinas Mecânicas....................................................... 13
2. Aparelhos de Medição para Motores Automotivos....................................................... 15
2.1 Scanners.......................................................................................................... 16
2.2 Voltímetro......................................................................................................... 17
2.3 Tacômetro........................................................................................................ 18
2.4 Osciloscópio..................................................................................................... 20
3. A Linguagem Java........................................................................................................ 21
3.1 O que é Java?.................................................................................................. 21
3.2 Surgimento do Java......................................................................................... 21
3.3 Java nos Aparelhos Eletrônicos....................................................................... 22
3.4 Por que Escolhemos a Linguagem Java?....................................................... 23
4. O Tachometer............................................................................................................... 24
4.1 Funções do Tachometer................................................................................... 24
4.1.1 Tensão da bateria............................................................................... 25
4.1.2 Medição das rotações do motor (RPM)..............................................25
4.1.3 Voltímetro multifunção........................................................................ 25
4.1.4 Tempo de injeção............................................................................... 26
4.1.5 Sonda Lambda................................................................................... 26
4.2 Descrição da Comunicação Serial................................................................... 29
4.2.1 O que é comunicação de dados?.......................................................29
4.2.2 Canais de comunicação..................................................................... 30
4.2.3 Comunicação serial............................................................................ 31
4.2.4 Taxa de transferência (Baud Rate).....................................................31
4.2.5 Transmissão assíncrona x Transmissão síncrona............................. 32
4.3 Descrição do Protocolo Serial do Tachometer (Versão 1.0)............................ 35
4.4 Como Utilizar o Software do Tachometer......................................................... 50
Conclusão......................................................................................................................... 56
Referências Bibliográficas................................................................................................ 57
Anexos
Anexo A – Cronograma......................................................................................... 59
Anexo B – DFD – Diagrama de Contexto.............................................................. 60
Anexo C – DFD Nível 0.......................................................................................... 61
Anexo D – DFD Nível 1 – Processo 1.................................................................... 62
Anexo E – DFD Nível 1 – Processo 2.................................................................... 63
Anexo F – DFD Nível 1 – Processo 3.................................................................... 64
Anexo G – Ata de Reunião nº1....................................................................…...... 65
Anexo H – Ata de Reunião nº2.................................................................... …...... 66
Anexo I – Ata de Reunião nº3................................................................................ 67
Anexo J – Ata de Reunião nº4............................................................................... 68
Anexo K – Ata de Reunião nº5...............................................................................69
10
Introdução
O projeto se enquadra nas áreas de informática e mecatrônica para manutenção
automotiva, a parte de software do produto realizada pelo grupo compreende a utilização
de Java (software livre), SQLite (banco de dados livre) e protocolos de comunicação.
O software desenvolvido engloba um programa em Java para controle de
equipamento destinado ao reparador de automóveis, que irá realizar medidas de diversos
componentes de um veículo automotor. Suas principais funções são medir a tensão da
bateria, as rotações do motor, o tempo de injeção de combustível, o sinal da sonda
Lambda, e ainda é um voltímetro multifunção.
Este software trabalha em conjunto com um hardware desenvolvido pela empresa
Eletrotécnica Sacch Ltda. baseado em um microcontrolador da família AVR da Atmel, ou
seja, o mesmo utilizado em kits de aprendizagem como o Arduino.
Através de pesquisas realizadas na internet e também com reuniões e visitas
diretas à empresa patrocinadora, os integrantes do grupo arrecadaram informações para
a construção da ideia e desenvolvimento do projeto. Inicialmente foi tido como base
equipamentos similares de outras empresas que atuam no mesmo ramo e também
protocolos de comunicação de outros equipamentos da própria empresa patrocinadora.
O Tachometer é inédito no mercado brasileiro. Atualmente existem equipamentos
similares mas de uso industrial e nenhum voltado especificamente à medição de
grandezas de motores de veículos. Este produto será de muita utilidade ao reparador de
veículos pois auxiliará o mecânico de forma intuitiva a obter dados dos diversos
componentes dos motores para um fácil e preciso diagnóstico de possíveis falhas de
componentes dos motores, desta maneira agilizando o processo de identificação e
correção das mesmas.
Os equipamentos similares de aplicação automotiva operam de forma autônoma
sem qualquer tipo de conexão a computadores, tablets ou smartphones, sendo que seu
hardware oferece poucos recursos gráficos, de banco de dados e de registros de
11
medições. O Tachometer por outro lado permitirá a conexão a computadores, tablets ou
smartphones, possibilitando um enorme ganho de recursos visuais e de banco de dados
para
armazenamento
das
medições
realizadas
pelo
equipamento
e
também
armazenamento de informações de diversos componentes a serem medidos.
Pelo fato do hardware não possuir displays gráficos e por consequencia também
não possuir os componentes necessários ao acionamento do display gráfico, seu custo e
seu tamanho serão muito reduzidos, o que é uma enorme vantagem competitiva.
12
1. A Informatização nos Aparelhos Eletrônicos de Teste
1.1 O Surgimento dos Equipamentos de Teste
Durante os experimentos que cientistas e engenheiros realizavam no início da
descoberta da eletricidade, estes precisavam de algum meio para identificar e quantificar
os fenômenos elétricos que estavam sendo descobertos, como por exemplo, a tensão, a
corrente, a potência, etc.
Portanto o estudo destes fenômenos se deu ao mesmo tempo em que aparatos de
teste foram sendo desenvolvidos, pois estes eram essenciais para as novas descobertas.
1.2 Equipamentos de Teste Elétricos e Eletrônicos
No início os equipamentos de teste eram puramente elétricos, pois ainda não
existia eletrônica, mas em 1883, o invetor americano Thomas Edison, tentando
aperfeiçoar a lâmpada de filamento que criou, descobriu acidentalmente o efeito
termoiônico, também conhecido como efeito Edison. O efeito termoiônico caracteriza-se
pela emissão de elétrons pela superfície de um metal aquecido. A aplicação mais
importante do efeito termoiônico foi na construção das válvulas eletrônicas, usadas
amplamente em aparelhos de rádio, TV e no primeiro computador eletrônico. Isso permitiu
que os equipamentos de teste fossem aperfeiçoados com a utilização de válvulas
eletrônicas e portanto passaram a ser equipamentos eletrônicos. Isto se deu por muitos
anos, até que na década de 1950 começou a ser utilizado o semicondutor de silício e
germânio na substituição das válvulas eletrônicas, que permitiu uma miniaturização e
consequentemente uma redução no custo dos equipamentos eletrônicos.
13
1.3 Equipamentos de Teste Informatizados
Com a utilização do semicondutor a eletrônica ficou mais barata e infinitamente
menor em tamanho, o que permitiu que se criassem chips para diversas aplicações. Entre
estas aplicações estava o computador que se tornou cada vez mais poderoso e mais
barato, com sua consequente popularização. Mais uma vez os equipamentos de teste se
desenvolveram passando a fazer uso de computadores para o processamento e
armazenamento dos dados obtidos em suas medições. Hoje em dia, os equipamentos de
teste fazem uso intensivo de microcontroladores e microprocessadores para o
processamento e análise dos dados medidos, desta forma a informática (software) passou
a fazer parte dos equipamentos de teste. Com o advento da Internet e das redes, entre
elas as redes Wireless, como Wi-fi e Bluetooth, os equipamentos de teste também
passaram a se comunicar com outros equipamentos de testes, outros computadores e até
com a Internet.
1.4 A Informatização nas Oficinas Mecânicas
A informática nos centros automotivos atende não só a exigência do cliente como
da própria oficina, desenvolvida sob uma estrutura inteligente, que contribui para evitar o
desperdício de tempo e dinheiro nos serviços de reparação e gestão.
Hoje em dia é comum que as oficinas tenham como preocupação a excelência no
atendimento e a qualidade dos serviços mecânicos prestados, buscando ajuda na
tecnologia, como computadores, equipamentos de diagnóstico e instrumentos de medição
que ajudam no dia-a-dia do profissional da reparação, na busca pelo serviço mais
confiável para o seu cliente.
José Palacio, auditor do IQA (Instituto da Qualidade Automotiva), afirma que a
principal finalidade das oficinas investirem em informática é ganhar competitividade e,
com isso, se livrarem de um receio que a maioria delas tem: fechar as portas.
14
O auditor esclarece ainda que, antes de adquirir um sistema de gestão
informatizado, é importante que tanto o dono da empresa quanto o mecânico sejam
qualificados com treinamentos voltados para utilização dos softwares. Além disso, ele
deixa claro que hoje em dia não dá mais para conviver sem a tecnologia e a informática,
já que alguns procedimentos, como diagnóstico de uma avaria ou a regulagem de um
motor, são quase inviáveis e imprecisos se realizados manualmente. Daí a necessidade
de equipamentos que sejam simples de operar mas que realizem diagnósticos e
medições de formas práticas e precisas.
O tempo e a agilidade das informações ligadas à tecnologia são os principais
motivos pelas constantes atualizações dos softwares, que acontecem conforme a
necessidade de cada empresa. Este é um excelente negócio que ajuda oficinas
mecânicas a ganharem novos clientes e deixarem os antigos mais satisfeitos com os
serviços prestados, afinal não basta ter apenas um computador, é preciso ter estrutura.
15
2. Aparelhos de Medição para Motores Automotivos
Os veículos de hoje em dia são muito diferentes de quando foram inventados a
mais de cem anos. Hoje as indústrias automotivas são obrigadas a cumprir rígidas
normas com relação a emissão de poluentes, que só são atingidas mediante
gerenciamento eletrônico do funcionamento dos motores, portanto os motores dos
veículos atuais necessitam de uma central de processamento eletrônico (ECU) e diversos
sensores e atuadores para as mais diversas finalidades. Isso tornou a manutenção
desses motores bastante complexa, pois os mecânicos necessitam além de ter
conhecimentos de mecânica, ter conhecimentos de elétrica e eletrônica, e em alguns
casos conhecimentos de software.
Para auxiliar o mecânico na manutenção desses motores a indústria de
equipamentos de teste vem desenvolvendo equipamentos específicos para a manutenção
de motores, os quais realizam medições em sensores e simulam sinais para acionamento
de atuadores e sensores. Os equipamentos mais modernos possuem microcontroladores
os quais executam software para realização de suas medições.
Devido à complexidade dos sistemas de gerenciamento eletrônico, as próprias
ECU monitoram seu próprio funcionamento, registrando eventuais anomalias de
funcionamento. Tais anomalias podem ser devido à falhas de sensores, de atuadores ou
ainda devido a combustível adulterado ou fora de espicificação. Existem ainda anomalias
devido ao desgaste de diversos componentes que compõem o motor. Estas anomalias
são também disponibilizadas para leitura por equipamentos especializados chamados
scanners.
16
2.1 Scanners
Os scanners são equipamentos que se conectam às ECUs através de um conector
de diagnóstico e se comunicam através de protocolos específicos de comunicação.
Dentre os padrões existentes a nível de hardware existe o OBDII (entre outros), o qual foi
definido pelos fabricantes de veículos como padrão de hardware para a comunicação com
a ECU. Além da padronização do hardware existe também uma tentativa de se padronizar
o protocolo de comunicação (software), porém este ainda não foi definido em sua
totalidade. Atualmente existe o padrão CAN, o qual vem sendo muito adotado pelos
fabricantes de veículos, especialmente os mais novos a partir do ano 2000. Existe ainda
uma padronização para leitura e apagamento de código de falhas, os quais são
conhecidos como DTC (Data Trouble Code). Os DTCs são códigos compostos por uma
letra seguida de quatro dígitos numéricos, de acordo com o diagrama abaixo:
Figura 1, Formato do DTC.
Fonte: (www.marcusfitzhugh.com)
17
Figura 2, Scanner SPCMAX.
Fonte: (www.sacch.com.br)
2.2 Voltímetro
O voltímetro é um aparelho que realiza medições de tensão elétrica em um circuito.
Ele exibe essas medições, geralmente, por meio de um ponteiro móvel ou um mostrador
digital, de cristal líquido (LCD) por exemplo. A unidade apresentada geralmente é o volt.
Muitos voltímetros, na verdade, não são nada mais do que amperímetros com alta
resistência interna. O projeto dos voltímetros é tal que, com sua alta resistência interna,
introduzam o mínimo de alterações no circuito que está sendo monitorado. Assim como
um amperímetro indica a corrente que passa por ele, um voltímetro indica a tensão entre
seus terminais.
Para aferir a diferença de tensão entre dois pontos de um circuito, convém colocar
o voltímetro em paralelo com a seção do circuito compreendida entre estes dois pontos.
18
Por isso, para as medições serem precisas, é esperado que o voltímetro tenha uma
resistência muito grande comparada às do circuito. Voltímetros podem medir tensões
contínuas ou tensões alternadas, dependendo das qualidades do aparelho.
Figura 3, Voltímetro.
Fonte: (www.grupoescolar.com)
2.3 Tacômetro
O tacômetro, também conhecido como taquímetro, é um instrumento de medição
do número de rotações (geralmente por minuto, RPM) de um motor. Pode ser chamado
também de conta-rotações, conta-voltas ou conta-giros.
19
O tacômetro digital eletrônico utilizado para medição de rotação, pode ser utilizado
como um tacômetro óptico ou como um tacômetro de contato permitindo a medição de
rpm nas mais diversas aplicações. Quando operado como tacômetro de contato, permite
o uso como medidor de velocidade linear (metros/segundo).
No modo fototacômetro possui uma mira laser que pode ser usada com precisão
até 100 cm de distância do ponto de medição de rotação.
Por ser um instrumento de última geração dispõe de um indicador de cristal líquido
de grande tamanho facilitando a leitura das medições. Este instrumento também dispõe
de memória de máximo e mínimo.
Figura 4, Tacômetro.
Fonte: (www.impac.com.br)
20
2.4 Osciloscópio
O osciloscópio é um instrumento de medida eletrônico que cria um gráfico bidimensional visível de uma ou mais diferenças de potencial. O eixo horizontal do ecrã
(monitor) normalmente representa o tempo, tornando o instrumento útil para mostrar
sinais periódicos. O eixo vertical comumente mostra a tensão. O monitor é constituído por
um "ponto" que periodicamente "varre" a tela da esquerda para a direita. Ele pode ser
usado para realizar medições de sonda lambda e de tempo de injeção.
Figura 5, Osciloscópio.
Fonte: (www.kit8051.com.br)
21
3. Linguagem Java
3.1 O que é Java?
Java é uma linguagem de programação orientada a objeto desenvolvida na década
de 90 por uma equipe de programadores chefiada por James Gosling, na empresa Sun
Microsystems.
Diferentemente
das
linguagens
convencionais,
que
são compiladas para código nativo, a linguagem Java é compilada para um bytecode que
é executado por uma máquina virtual. A linguagem de programação Java é a linguagem
convencional da Plataforma Java, mas não sua única linguagem.
3.2 Surgimento do Java
Em 1991, na Sun Microsystems, foi iniciado o Green Project, o berço do
Java uma linguagem de programação orientada a objetos. Os mentores do projeto
eram Patrick Naughton, Mike Sheridan, e James Gosling. O objetivo do projeto não era
a criação de uma nova linguagem de programação, mas antecipar e planejar a
“próxima onda” do mundo digital. Eles acreditavam que em algum tempo haveria uma
convergência
dos
computadores com
os
equipamentos
e
eletrodomésticos
comumente usados pelas pessoas no seu dia-a-dia.
Para provar a viabilidade desta idéia, 13 pessoas trabalharam arduamente
durante 18 meses. No verão de 1992 eles emergiram de um escritório de Sand Hill
Road no Menlo Park com uma demonstração funcional da idéia inicial. O protótipo
se
chamava *7
(“StarSeven”), um controle
remoto com uma
interface gráfica
touchscreen. O *7 tinha a habilidade de controlar diversos dispositivos e aplicações.
James Gosling especificou
uma
nova
linguagem de programação para o *7.
Gosling decidiu batizá-la de “Oak”, que quer dizer carvalho, uma árvore que ele podia
observar quando olhava pela sua janela.
22
O grupo estava iniciando um projeto chamado Projeto Green, que consistia na
criação de tecnologias modernas de software para empresas eletrônicas de consumo.
Logo o grupo percebeu que não poderia ficar preso à plataformas, pois os clientes não
estavam interessados no tipo de processador que estavam utilizando, e fazer uma versão
do projeto para cada tipo de sistema seria inviável. Desenvolveram então o sistema
operacional GreenOS, com a linguagem de programação Oak.
Como a equipe de desenvolvimento tomava muito café enquanto estava
trabalhando, foram ingeridas centenas de xícaras de café até que o projeto estivesse
pronto. Finalmente em maio de 1995 a Sun anunciou um ambiente denominado Java,
homenagem às xícaras de café, que obteve sucesso graças ao rápido estabelecimento da
Internet e a incorporação deste ambiente a browsers populares como o Netscape
Navigator e padrões tridimensionais como o VRML (Virtual Reality Modeling Language Linguagem de Modelagem para Realidade Virtual). Além disso, sua natureza portátil e o
projeto robusto permitem o desenvolvimento para múltiplas plataformas, em ambientes
tão exigentes como os da eletrônica de consumo.
3.3 Java nos Aparelhos Eletrônicos
A linguagem Java vem sendo utilizada cada vez mais em equipamentos
eletrônicos (embedded) devido a sua portabilidade e operação multiplataforma, exemplos
disso são aplicativos para celulares (Android) e computadores (Windows, Linux, MAC). O
Java também vem sendo introduzido em microcontroladores e microprocessadores, tais
como ARM-CORTEX M, ARM-CORTEX A, entre outros.
Além de sua ampla utilização em diversas áreas o Java disponibiliza APIs como
jUSB, JavaComm e RXTX (utilizada neste projeto) para comunicação serial possibilitando
que aparelhos eletrônicos se comuniquem com computadores ou dispositivos móveis,
permitindo integração inclusive com a Internet.
23
3.4 Por que Escolhemos a Linguagem Java?
Esta linguagem foi escolhida pelo fato de ser multiplataforma, open source e
orientada a objetos. Foi utilizado como ferramenta de desenvolvimento o ambiente de
desenvolvimento NetBeans. Todos esses softwares são livres e sem custo de aquisição, o
que torna o projeto economicamente viável.
Por ser uma linguagem multiplataforma, permite que nosso software possa ser
executado em computadores Desktop, Notebook, Netbook e com sistema operacional
MAC OS, Windows XP, Windows Vista, Windows7, Windows8 e praticamente todas as
distribuições Linux, portanto o programa será de utilização praticamente universal.
Como o nosso sistema é desenvolvido em Java que é a base para o
desenvolvimento do sistema operacional Android, nosso software poderá facilmente ser
portado para este sistema operacional, tornando-se disponível para SmartPhones e
Tablets.
Também foi levado em consideração o fato de estarmos familiarizados com esta
linguagem devido às aulas e devido a grande quantidade de fóruns e material disponível
sobre Java na internet.
24
4. O Tachometer
4.1 Funções do Tachometer
O projeto reúne diversas funções, que são elas a medição da tensão da bateria,
medição das rotações do motor (RPM) através de um sensor de vibração, um voltímetro
multifunção, tempo de injeção de combustível, e medição do sinal da sonda Lambda.
A injeção eletrônica é um sistema de alimentação de combustível e gerenciamento
eletrônico do motor de um automóvel - motor a combustão. Sua utilização em larga escala
se deve à necessidade das industrias de automóveis reduzirem o índice de emissão de
gases poluentes. Esse sistema permite um controle mais eficaz da mistura admitida pelo
motor, mantendo-a mais próxima da mistura estequiométrica (mistura ideal ar /
combustível), isso se traduz em maior economia de combustível já que o motor trabalha
sempre com a mistura adequada e também melhora o desempenho do motor gerando a
menor quantidade possível de poluentes.
O sistema faz a leitura de diversos sensores espalhados em pontos estratégicos do
motor, examina as informações e com base em outras informações gravadas em sua
memória envia comandos para diversos atuadores espalhados em pontos estratégicos do
motor também. Esse procedimento é efetuado varias vezes por segundo.
Devido a grande quantidade de sensores e atuadores eletrônicos no motor de
veículos equipados com injeção eletrônica existe a necessidade de se utilizar
equipamentos específicos para a atuação e detecção de falhas em diversos componentes
do sistema de injeção eletrônica.
25
4.1.1 Tensão da bateria
Esta função é a mais básica de todas, pois se o veículo esta com a tensão abaixo
do nível mínimo recomendado, todo o sistema pode parar de funcionar ou pode
apresentar falhas intermitentes, portanto antes de se verificar qualquer outro componente
é indispensável a verificação da tensão da bateria.
4.1.2 Medição das rotações do motor (RPM)
A medição das rotações do motor é muito importante para auxiliar no diagnóstico
de problemas relacionados a emissão de poluentes, pois os equipamentos analisadores
de gases utilizados na medição de poluentes necessitam saber com precisão qual o RPM
(rotações por minuto) do motor no momento da medição. Além disso alguns veículos
permitem o ajuste da marcha lenta, sendo que neste caso a leitura do RPM é de extrema
importância.
4.1.3 Voltímetro multifunção
Esta função é muito útil para determinar se alguns sensores estão em
funcionamento, pois medindo a tensão de saída destes sensores pode-se determinar se
estão ou não em bom estado. A maioria dos sensores converte uma ação mecânica ou
uma grandeza física em um sinal elétrico baseado em tensão, como sensores de
temperatura, sensores de rotação, sensor de pressão atmosférica, sensor de vácuo, etc. A
função voltímetro também é muito útil para se determinar se atuadores estão sendo
alimentados corretamente, pois muitas vezes o problema não está nos sensores mas sim
na tensão de alimentação que não chega até eles.
26
4.1.4 Tempo de injeção
O tempo de injeção é o tempo que o injetor de combustível fica ligado (on),
determinando a quantidade de combustível injetada no motor. Nesta função o
equipamento mede os tempos de injetor ligado e injetor desligado (on/off). Esta função é
muito importante para se determinar se um injetor está sendo acionado corretamente.
Figura 6, Válvula injetora de combustível.
Fonte: (www.jalopnik.com.br)
4.1.5 Sonda Lambda
Os sensores lambda tem como função detectar o teor de oxigenio nos gases de
descarga em comparação ao oxigênio de amostragem que fica dentro do sensor (ar
ambiente) e informar a central (U.C.E) em forma de sinal elétrico para que a mesma
possa fazer os cálculos estequiométricos.
Fator Lambda ( λ )
Para entendermos o funcionamento dos sensores de oxigênio primeiramente temos
que conhecer o fator lambda (λ). Neste caso a letra grega lambda (λ) corresponde a razão
de equivalência na relação ar-combustível real entre a relação considerada ideal ou
estequiométrica para uma mistura.
27
Lambda (λ)= relação real – ar/combustível
/
relação ideal – ar/combustível
Relação Ar/Combustível ideal
Gasolina: 14,7:1 ( 14,7 partes de ar para 1 parte de gasolina)
Álcool: 9,0:1 ( 9,0 partes de ar para 1 parte de álcool)
Diesel: 15,2:1 ( 15,2 partes de ar para 1 parte de Diesel)
Dessa forma podemos concluir que quando uma mistura tem mais ar do que o
especificado na tabela acima dizemos que λ >1 ou que a mistura esta Pobre. Já quando a
quantidade de ar esta abaixo da especificada dizemos que λ<1 ou que a mistura esta
Rica.
Funcionamento do sensor de oxigênio
Os sensores lambda trazem em sua composição um componente muito importante
que é o dióxido de zircônio, este material quando atinge uma temperatura superior a
300°C se transforma em um condutor de íons de oxigênio. Com o auxilio deste
componente a sonda consegue identificar por meio de uma variação de tensão a
quantidade de oxigênio presente nos gases de escape. Esta tensão que pode ser medida
em milvolts varia de 0 a 800mv e é enviada para a unidade de comando para que sejam
feitos os cálculos usando como base o fator lambda.
28
Localização do Sensor Lambda
Por funcionar com perfeição somete acima de 300°C, geralmente este dispositivo é
fixado no cano de descarga (escapamento) o mais próximo possível do motor e
obrigatoriamente esta peça deve receber os gases provenientes de todos os cilindro para
que a leitura seja a melhor possível. Existem sondas de 1, 2, 3 e 4 fios, sendo que a mais
eficiente e utilizada no momento é a de 4 fios. Na sonda de 4 fios, 2 fios (GND e Sinal)
são utilizados para a transmissão do sinal lambada, (tensão de 0,2 a 0,8 volts) e os outros
2 fios são utilizados para alimentar um resistor de aquecimento, desta forma este tipo de
sonda lambda pode trabalhar em regiões mais frias, longe da saída do motor, pois a
mesma mantém sua temperatura ideal de trabalho devido ao resistor de aquecimento. A
sonda de 4 fios pode até mesmo estar localizada próxima ao catalizador.
Para que todas as funções anteriores possam ser mostradas na tela de um
computador o equipamento Tachometer deve ser conectado a um computador através de
um cabo USB. O hardware do Tachometer possui um componente que emula uma porta
serial através da conexão USB, portanto para o computador o equipamento Tachometer
possui uma porta de comunicação serial, exemplo COM1, COM2, etc. Esta comunicação
serial necessita além do hardware, um software e regras de transmissã e recepção dos
dados. Estas regras que definem como devemos enviar e receber os dados ao
equipamento Tachometer é denominado Protocolo. No próximo tópico será descrito todo o
protocolo de comunicação serial.
29
4.2 Descrição da Comunicação Serial
Comunicação serial é o processo de enviar dados, um bit de cada vez,
sequencialmente, num canal de comunicação ou barramento. É diferente da comunicação
paralela, em que todos os bits de cada símbolo são enviados juntos. A comunicação serial
é usada em toda comunicação de longo alcance e na maioria das redes de
computadores, onde o custo de cabos e as dificuldades de sincronização tornam a
comunicação paralela impraticável. Para curtas distâncias, barramentos seriais estão se
tornando cada vez mais comuns devido ao ponto em que as desvantagens dos
barramentos paralelos (densidade de interconexão) superam suas vantagens de
simplicidade.
4.2.1 O que é comunicação de dados?
A distância que um dado sinal percorre em um computador varia de alguns
milímetros, como no caso de conexões de um simples CI, até vários centímetros quando
a conexão de sinais envolve, por exemplo, uma placa mãe com conectores para diversos
circuitos. Para estas distâncias, o dado digital pode ser transmitido diretamente. Exceto
em computadores muito rápidos, os projetistas não se preocupam com o formato e
espessura dos condutores, ou com as características analógicas dos sinais de
transmissão.
Frequentemente, no entanto, os dados devem ser enviados para fora dos circuitos
que constituem o computador. Nesses casos, as distâncias envolvidas podem ser
enormes. Com o aumento das distâncias entre a fonte e o destino aumenta também a
dificuldade de estabelecer uma transmissão de dados precisa. Isso é resultado de
distorções elétricas dos sinais que trafegam através de condutores longos, e de ruídos
adicionados ao sinal que se propagam através do meio de transmissão.
30
Embora alguns cuidados devam ser tomados na troca de dados dentro de um
computador, o grande problema ocorre quando dados são transferidos para dispositivos
fora dos circuitos do computador. Nesse caso a distorção e o ruído podem tornar-se tão
severos que a informação é perdida.
A Comunicação de Dados estuda os meios de transmissão de mensagens digitais
para dispositivos externos ao circuito originador da mensagem. Dispositivos Externos são
geralmente circuitos com fonte de alimentação independente dos circuitos relativos a um
computador ou outra fonte de mensagens digitais. Como regra, a taxa de transmissão
máxima permissível de uma mensagem é diretamente proporcional a potência do sinal, e
inversamente proporcional ao ruído. A função de qualquer sistema de comunicação é
fornecer a maior taxa de transmissão possível, com a menor potência e menor ruído
possíveis.
4.2.2 Canais de comunicação
Um canal de comunicação é um caminho sobre o qual a informação pode trafegar.
Ela pode ser definida por uma linha física (fio) que conecta dispositivos de comunicação,
por rádio ou outra fonte de energia radiante.
Em comunicação digital, a informação é representada por bits de dados individuais,
que podem ser encapsulados em mensagens de vários bits. Um byte (conjunto de 8 bits)
é um exemplo de uma unidade de mensagem que pode trafegar através de um canal
digital de comunicações. Uma coleção de bytes pode ser agrupada em um “frame” ou
outra unidade de mensagem de maior nível. Esses múltiplos níveis de encapsulamento
facilitam o reconhecimento de mensagens e interconexões de dados complexos.
Um canal no qual a direção de transmissão é inalterada é referida como canal
simplex, nunca é permitido a transmissão inversa.
Um canal half-duplex é um canal físico simples no qual a direção pode ser
revertida. As mensagens podem fluir nas duas direções, mas nunca ao mesmo tempo.
31
Um canal full-duplex permite que mensagens sejam trocadas simultaneamente em
ambas as direções. Ele pode ser visto como dois canais simplex, um canal direto e um
canal reverso, conectados nos mesmos pontos.
4.2.3 Comunicação serial
Por não ser prático nem econômico transferir todos os bits de uma mensagem
simultaneamente, a mensagem é quebrada em partes menores e transmitida
seqüencialmente. A transmissão bit-serial converte a mensagem em um bit por vez
através de um canal. Cada bit representa uma parte da mensagem. Os bits individuais
são então rearranjados no destino para compor a mensagem original. Em geral, um canal
irá passar apenas um bit por vez. A transmissão bit-serial é normalmente chamada de
transmissão serial, e é o método de comunicação escolhido por diversos periféricos de
computadores.
A transmissão byte-serial converte 8 bits por vez através de 8 canais paralelos.
Embora a taxa de transferência seja 8 vezes mais rápida que na transmissão bit-serial,
são necessários 8 canais, e o custo poderá ser 8 vezes maior para transmitir a
mensagem. Quando as distâncias são curtas, é econômico usar canais paralelos como
justificativa para as altas taxas de transmissão.
4.2.4 Taxa de transferência (Baud Rate)
A taxa de transferência refere-se a velocidade com que os dados são enviados
através de um canal e é medido em transições elétricas por segundo. Na norma EIA232,
ocorre uma transição de sinal por bit, e a taxa de transferência e a taxa de bit (bit rate)
são idênticas. Nesse caso, uma taxa de 9600 bauds corresponde a uma transferência de
9600 dados por segundo, ou um período de aproximadamente, 104 µs (1/9600 s).
32
Outro conceito é a eficiência do canal de comunicação que é definido como o
número de bits de informação utilizável (dados) enviados através do canal por segundo.
Ele não inclui bits de sincronismo, formatação, e detecção de erro que podem ser
adicionados a informação antes da mensagem ser transmitida, e sempre será no máximo
igual a um.
4.2.5 Transmissão assíncrona x Transmissão síncrona
Geralmente, dados serializados não são enviados de maneira uniforme através de
um canal. Ao invés disso, pacotes com informação regulares são enviados seguidos de
uma pausa. Os pacotes de dados binários são enviados dessa maneira, possivelmente
com comprimentos de pausa variável entre pacotes, até que a mensagem tenha sido
totalmente transmitida. O circuito receptor dos dados deve saber o momento apropriado
para ler os bits individuais desse canal, saber exatamente quando um pacote começa e
quanto tempo decorre entre bits. Quando essa temporização for conhecida, o receptor é
dito estar sincronizado com o transmissor, e a transferência de dados precisa torna-se
possível. Falhas na manutenção do sincronismo durante a transmissão irão causar a
corrupção ou perda de dados.
Duas técnicas básicas são empregadas para garantir a sincronização correta. Em
sistemas síncronos, canais separados são usados para transmitir dados e informação de
tempo. O canal de temporização transmite pulsos de clock para o receptor. Através da
recepção de um pulso de clock, o receptor lê o canal de dado e armazena o valor do bit
encontrado naquele momento. O canal de dados não é lido novamente até que o próximo
pulso de clock chegue. Como o transmissor é responsável pelos pulsos de dados e de
temporização, o receptor irá ler o canal de dados apenas quando comandado pelo
transmissor, e portanto a sincronização é garantida.
33
8 bits de dados
1 bit de informação Pacote de dados
8 bits de informação
Eficiência do canal = 8/1 = 0,73
Existem técnicas que compõem o sinal de clock e de dados em um único canal.
Isso é usual quando transmissões síncronas são enviadas através de um modem. Dois
métodos no qual os sinais de dados contém informação de tempo são: codificação NRZ
(Non-Return-to-Zero) e a codificação Manchester.
Em sistemas assíncronos, a informação trafega por um canal único. O transmissor
e o receptor devem ser configurados antecipadamente para que a comunicação se
estabeleça a contento. Um oscilador preciso no receptor irá gerar um sinal de clock
interno que é igual (ou muito próximo) ao do transmissor. Para o protocolo serial mais
comum, os dados são enviados em pequenos pacotes de 10 ou 1 bits, dos quais 8
constituem a mensagem. Quando o canal está em repouso, o sinal correspondente no
canal tem um nível lógico ‘1’. Um pacote de dados sempre começa com um nível lógico ‘0’
(start bit) para sinalizar ao receptor que um transmissão foi iniciada. O “start bit” inicializa
um temporizador interno no receptor avisando que a transmissão começou e que serão
necessários pulsos de clocks.
Seguido do start bit, 8 bits de dados de mensagem são enviados na taxa de
transmissão especificada. O pacote é concluído com os bits de paridade e de parada
(“stop bit”).
Bit de Paridade checa a precisão da transmissão
Start Bit início de transmissão exatamente 8 bits de dados aceitos
Stop Bit fim de transmissão e tempo para receptor reiniciar
34
1 Start Bit 8 Bits de Dados 1 Bit de Paridade
1 Stop Bit
Tempo
Dados Clock
O comprimento do pacote de dados é pequeno em sistemas assíncronos para
minimizar o risco do oscilador do transmissor e do receptor variar. Quando osciladores a
cristal são utilizados, a sincronização pode ser garantida sobre os 1 bits de período. A
cada novo pacote enviado, o “start bit” reseta a sincronização, portanto a pausa entre
pacotes pode ser longa.
Os caracteres enviados através de uma interface serial geralmente seguem o
padrão ASCII (American Standard Code for Information Interchange) de 7 bits.
35
4.3 Descrição do Protocolo Serial do Tachometer (Versão 1.0)
Protocolo de Comunicação.
Antes de detalhar o protocolo de comunicação, vamos definir a nomenclatura utilizada
neste documento para que a descrição fique clara e seja bem entendida.
Nome
Descrição
HOST
Equipamento onde será instalado o software e que inicia a comunicação, podendo
ser desktop, notebook, netbook, tablet ou smartfone.
DEVICE
Equipamento que recebe os comandos do HOST, executa os comando e
responde ao HOST. Neste caso específico é o nosso equipamento de medidas.
FRAME
Conjunto de bytes que o HOST envia ao DEVICE para que este execute comando
ou retorne valores. Para cada FRAME que o HOST envia ao DEVICE, este
também retorna um FRAME informando se o comando foi aceito (ACK) ou não
aceito (NAK).
DID
Device IDentification number, byte de identificação de produto, enviado em todos
os FRAMES do HOST para o DEVICE. Este é o primeiro byte do FRAME. Em
nosso caso o valor do DID em hexadecimal é 02.
LB
Length Byte, ou número de bytes do FRAME após o DID, exceto o CS. O LB
sempre é o segundo byte do FRAME que o HOST envia para o DEVICE e o
terceiro byte do FRAME que o DEVICE responde ao HOST.
CMD
Comando que o HOST envia para o DEVICE. Este é sempre o terceiro byte do
FRAME que o HOST envia para o DEVICE e o segundo quando o DEVICE
responde ao HOST.
DF
Data Fields, ou campos de dados. Este são bytes do FRAME que informam
valores que alguns comandos CMD necessitam para serem executados.
Dependendo do comando CMD podem ser necessários mais de um DF. Para
alguns comandos o DEVICE também responde com DF's. Os DF's ocupam as
posições de número 4 até a penúltima posição dos FRAMES que o HOST envia
ao DEVICE e que o DEVICE responde ao HOST.
CS
CheckSum, ou checagem da soma é um byte que serve para verificar a
integridade do FRAME recebido, tanto pelo DEVICE como pelo HOST. Este byte
tem seu valor calculado de acordo com a fórmula abaixo:
CS = NOT (DID + LB + CMD + [DF] + … ) + 1
ACK
ACKnowledge, ou reconhecimento. Este é o primeiro byte do FRAME que o
DEVICE responde ao HOST, quando o DEVICE reconhece ou aceita o comando
CMD. O valor ACK em hexadecimal é 06.
NAK
Not AcKnowledge, ou não reconhecido. Este é o primeiro byte do FRAME que o
DEVICE responde ao HOST quando o DEVICE não reconhece ou não aceita o
comando CMD. O valor ACK em hexadecimal é 15.
EC
Error Code, ou código de erro. Este é um byte que o DEVICE envia no FRAME de
resposta ao HOST para indicar o tipo de error que houve.
36
Detalhamento do protocolo.
O HOST transmite comandos para o DEVICE (equipamento do Projeto K) como uma
série de bytes que compõe os FRAMES. Os FRAMES serão detalhados na descrição de
cada comando. Após o HOST enviar um FRAME de comando, este aguarda uma
resposta do DEVICE, a qual pode ser um FRAME de reconhecimento (ACK), um FRAME
de não reconhecimento (NAK) ou uma não resposta, ou seja não responder ao HOST. As
respostas do DEVICE (ACK/NAK) são transmitidas dentro de 2 segundos após receber
um comando do HOST, a menos que esteja especificado o contrário na descrição do
comando. Para a transmissão de dados contínua, o tempo de resposta ACK/NAK aplicase a primeira resposta ACK. O HOST pode transmitir comandos para o DEVICE durante
um fluxo contínuo de respostas de dados ACK. A menos que seja especificado, todos os
campos de dados são assinados com 2 números complementares.
O DEVICE irá sempre responder ás transmissões do HOST da seguinte maneira:
Resposta
Descrição
ACK
O comando foi recebido e será realizado. A mensagem está
formatada corretamente, o comando é reconhecido, o comando é
permitido, o CS (checksum) está correto, e uma condição de erro do
sistema não impede a execução do comando. O código ASCII para
ACK é $06 (hexadecimal).
NAK
O comando não pode ser executado. Onde apropriado, a resposta
NAK inclui um código de erro especificando porque o comando não
pode ser executado. O código ASCII para NAK é $15.
SEM
RESPOSTA
O DEVICE não irá transmitir o FRAME de resposta ao HOST se
algum dos seguintes pontos forem verdadeiros:
1 - Nenhum comando foi recebido e os dados contínuos não estão
ativados.
2 - Sinais na linha de entrada serial de dados não estão de acordo
com o formato RS232.
3 - O comando é recebido enquanto a resposta de um comando
anterior está pendente.
4 - O dispositivo de identificação do byte (DID) não é igual a $02.
5 - O byte checksum (CS) estava incorreto.
6 – O DEVICE está rodando um autoteste ou inicializando (0.15 a
1.50 segundos após ligado.
37
Sumário dos comandos:
CMD
(HEX)
Descrição
NAK EC
Error Code
01
Leitura do número serial.
01, 03
02
Escreve número serial na EEPROM
01, 03
03
Lê variáveis de ajuste. (EEPROM)
01, 03
04
Lê 1 variável da EEPROM no enderêço especificado.
01, 02, 03
05
Escreve 1 variável na EEPROM no endereço especificado.
01, 02, 03
07
Status do equipamento.
08
Seleciona uma função no menu do equipamento.
01, 02, 03
09
Aciona/desaciona a função selecionada.
01, 03, 04
0A
Seleciona o número de cilindros na função rotação
01, 02, 03
0B
Realiza leitura da função selecionada
01, 03, 05
01, 03
Descrição dos códigos de erro (EC) associados ao NAK
EC
(HEX)
Descrição
01
Formato do comando recebido inválido.
02
Comando recebido com DF fora do range.
03
Comando não reconhecido ou inválido.
04
Comando ON/OFF fora do range.
05
Comando não pode ser executado no momento.
38
Comando: 01 - Leitura do número serial
Formato de envio HOST → DEVICE:
DID
LB
CMD
CS
02
01
01
FC
Formato de retorno ACK - DEVICE → HOST:
ACK CMD
06
01
LB
DF0 DF1 DF2 DF3 DF4 DF5
04
XX
XX
XX
XX
VH
DF0 - Serial 1º byte Modelo.
DF1 - Serial 2º byte Serie MSB.
DF2 - Serial 3º byte Serie LSB.
DF3 - Serial 4º byte Mês de produção.
DF4 - Versão de hardware
df5 - Versão de software
Formato de retorno NAK - DEVICE → HOST:
Códigos de erro:
NAK
CMD
LB
EC
CS
15
01
01
XX
CALC
01 - Formato do comando inválido.
03 - Comando não reconhecido ou inválido.
VF
CS
CALC
39
Comando: 02 - Gravação do número serial
Formato de envio HOST → DEVICE:
DID
LB
CMD
DF0
DF1
DF2
DF3
CS
02
05
02
XX
XX
XX
XX
CALC
DF0 - Serial 1º byte Modelo.
DF1 - Serial 2º byte Serie MSB.
DF2 - Serial 3º byte Serie LSB.
DF3 - Serial 4º byte Semana de produção.
Formato de retorno ACK - DEVICE → HOST:
ACK
CMD
LB
DF0
DF1
DF2
DF3
CS
06
02
04
XX
XX
XX
XX
CALC
DF0 - Serial 1º byte Modelo.
DF1 - Serial 2º byte Serie MSB.
DF2 - Serial 3º byte Serie LSB.
DF3 - Serial 4º byte Semana de produção.
Formato de retorno NAK - DEVICE → HOST:
NAK
CMD
LB
EC
CS
15
02
01
XX
CALC
Códigos de erro EC:
01 - Formato do comando inválido.
03 - Comando não reconhecido ou inválido.
40
Comando: 03 - Leitura de variáveis de configuração da EEPROM.
Formato de envio HOST → DEVICE:
DID
LB
CMD
CS
02
01
03
FA
Formato de retorno ACK - DEVICE → HOST:
ACK
CMD
LB
DF0
DF1
DF2
DF3
DF4
CS
06
03
05
XX
XX
XX
XX
XX
CALC
DF0 - Offset ADC canal 0 – Tensão da bateria.
DF1 - Offset ADC canal 1 – Voltímetro.
DF2 – Multiplicador ADC canal 0 – Tensão da bateria.
DF3 – Multiplicador ADC canal 0 – Voltímetro.
DF4 – Valor do Oscilador.
Formato de retorno NAK - DEVICE → HOST:
Códigos de erro:
NAK
CMD
LB
EC
CS
15
03
01
XX
CALC
01 - Formato do comando inválido.
03 - Comando não reconhecido ou inválido.
41
Comando: 04 – Lê valor de variável na EEPROM.
Formato de envio HOST → DEVICE:
DID
LB
CMD
DF0
DF1
CS
02
03
04
XX
XX
CALC
DF0 - Endereço da EEPROM - MSB.
DF1 - Endereço da EEPROM - LSB.
Formato de retorno ACK - DEVICE → HOST:
ACK
CMD
LB
DF0
DF1
DF2
CS
06
04
03
XX
XX
XX
CALC
DF0 - Endereço da EEPROM - MSB.
DF1 - Endereço da EEPROM - LSB.
DF2 - Valor da EEPROM
Formato de retorno NAK - DEVICE → HOST:
Códigos de erro:
NAK
CMD
LB
EC
CS
15
04
01
XX
CALC
01 - Formato do comando inválido.
02 – Comando recebido com DF fora do range.
03 - Comando não reconhecido ou inválido.
42
Comando: 05 – Escreve valor de variável na EEPROM.
Formato de envio HOST → DEVICE:
DID
LB
CMD
DF0
DF1
DF2
CS
02
04
05
XX
XX
XX
FC
DF0 - Endereço da EEPROM - MSB.
DF1 - Endereço da EEPROM - LSB.
DF2 – Valor a gravar na EEPROM no endereço especificado por DF1/DF2.
Formato de retorno ACK - DEVICE → HOST:
ACK
CMD
LB
DF0
DF1
DF2
CS
06
05
03
XX
XX
XX
CALC
DF0 - Endereço da EEPROM - MSB.
DF1 - Endereço da EEPROM - LSB.
DF2 - Valor da EEPROM
Formato de retorno NAK - DEVICE → HOST:
Códigos de erro:
NAK
CMD
LB
EC
CS
15
05
01
XX
CALC
01 - Formato do comando inválido.
02 – Comando recebido com DF fora do range.
03 - Comando não reconhecido ou inválido.
43
Comando: 07 – Status do equipamento.
Formato de envio HOST → DEVICE:
DID
LB
CMD
CS
02
01
07
F7
Formato de retorno ACK - DEVICE → HOST:
ACK CMD
06
07
LB
DF0
DF1
DF2
CS
02
XX
XX
XX
CALC
DF0 - Função selecionada.
Possíveis valores
00 – Tensão da bateria.
01 – Rotação.
02 – Voltímetro.
03 – Tempo de Injeção.
04 – Lambada.
DF1 – Função ativada(1) ou desativada(0).
DF2 - Escala ou número de cilindros(depende da função), habilitado
somente para a função 01 - Rotação
Formato de retorno NAK - DEVICE → HOST:
Códigos de erro:
NAK
CMD
LB
EC
CS
15
07
01
XX
CALC
01 - Formato do comando inválido.
03 - Comando não reconhecido ou inválido.
44
Comando: 08 – Seleciona uma função no menu do equipamento.
Formato de envio HOST → DEVICE:
DID
LB
CMD
DF0
CS
02
02
08
XX
CALC
DF0 – Função a selecionar.
00 – Tensão da bateria.
01 – Rotação.
02 – Voltímetro.
03 – Tempo de Injeção.
04 – Lambada.
Formato de retorno ACK - DEVICE → HOST:
ACK
CMD
LB
DF0
CS
06
08
01
XX
CALC
DF0 – Função selecionada.
00 – Tensão da bateria.
01 – Rotação.
02 – Voltímetro.
03 – Tempo de Injeção.
04 – Lambada.
Formato de retorno NAK - DEVICE → HOST:
Códigos de erro:
NAK
CMD
LB
EC
CS
15
08
01
XX
CALC
01 - Formato do comando inválido.
02 - Comando recebido com DF fora do range.
03 - Comando não reconhecido ou inválido.
45
Comando: 09 – Ativa ou desativa a função selecionada.
Formato de envio HOST → DEVICE:
DID
LB
CMD
DF0
CS
02
02
09
XX
CALC
DF0 – Ativa ou desativa a função selecionada.
0 – Desativa a função.
1 – Ativa a função.
Formato de retorno ACK - DEVICE → HOST:
ACK
CMD
LB
DF0
CS
06
09
01
XX
CALC
DF0 – Retorna status da função.
0 – Função desativada.
1 – Função ativada.
Formato de retorno NAK - DEVICE → HOST:
Códigos de erro:
NAK
CMD
LB
EC
CS
15
09
01
XX
CALC
01 - Formato do comando inválido.
02 - Comando recebido com DF fora do range.
03 - Comando não reconhecido ou inválido.
46
Comando: 0A – Seleciona o número de cilindros da função rotação.
Formato de envio HOST → DEVICE:
DID
LB
CMD
DF0
CS
02
02
0A
XX
CALC
DF0 – Seleciona o número de cilindros da função rotação.
0 – 1 cilindro.
1 – 2 cilindros.
2 – 3 cilindros.
3 – 4 cilindros.
4 – 5 cilindros.
5 – 6 cilindros.
6 – 8 cilindros.
7 – 10 cilindros.
8 – 12 cilindros.
Formato de retorno ACK - DEVICE → HOST:
ACK
CMD
LB
DF0
CS
06
0A
01
XX
CALC
DF0 – Retorna número de cilindros da função rotação.
0 – 1 cilindro.
1 – 2 cilindros.
2 – 3 cilindros.
3 – 4 cilindros.
4 – 5 cilindros.
5 – 6 cilindros.
6 – 8 cilindros.
7 – 10 cilindros.
8 – 12 cilindros.
Formato de retorno NAK - DEVICE → HOST:
Códigos de erro:
NAK
CMD
LB
EC
CS
15
0A
01
XX
CALC
01 - Formato do comando inválido.
02 - Comando recebido com DF fora do range.
03 - Comando não reconhecido ou inválido.
47
Comando: 0B - Leitura da função selecionada.
Formato de envio HOST → DEVICE:
DID
LB
CMD
CS
02
01
0B
F2
Formato de retorno ACK - DEVICE → HOST:
ACK
CMD
LB
DF0
DF1
DF2
DF3
CS
06
0B
04
XX
XX
XX
XX
CALC
Os Data Fields dependem da função selecionada.
Função Tensão da Bateria:
DF0 - Retorna 00.
DF1 - Retorna 00.
DF2 - Retorna MSB da tensão.
DF3 - Retorna LSB da tensão.
O inteiro composto por MSB/LSB informa a tensão em milivolts.
Exemplo de retorno: 06 0B 04 00 00 36 63 52
O número hexadecimal formado pelos bytes 36 e 63 (3663 hex) e convertido para
decimal inteiro significa o número 13923. Este valor representar o valor da tensão em
milivolts, o qual representa 13923 milivolts, que é equivalente a 13,923 volts.
Função Rotação:
DF0 - Retorna MSB do RPM.
DF1 - Retorna LSB do RPM.
DF2 - Retorna 00.
DF3 – Retorna o número de cilindros selecionado.
O inteiro composto por MSB/LSB informa a tensão em milivolts.
Exemplo de retorno: 06 0B 04 03 E0 00 00 08
O inteiro 03 E1 em decimal representa 992 rotações por minuto, e 00 significa que
o número de cilindros selecionado é igual a 1
Função Voltímetro:
DF1 - Retorna 00.
DF2 - Retorna 00.
DF3 - Retorna MSB da tensão.
DF4 - Retorna LSB da tensão.
48
A inteiro composto por MSB/LSB informa a tensão em milivolts.
Exemplo de retorno: 06 0B 04 00 00 15 EA 52
O inteiro 15 EA em decimal representa 5610 milivolts, que é equivalente a 5,610
volts.
Função Tempo de Injeção:
DF1 - Retorna MSB do Tempo do injetor ON.
DF2 - Retorna LSB do Tempo do injetor ON.
DF3 - Retorna MSB do Tempo do injetor OFF.
DF4 – Retorna LSB do Tempo do injetor OFF.
A inteiro composto por MSB/LSB informa o tempo de injeção em a tensão em
milivolts.
Exemplo de retorno: 06 0B 04 01 F9 2D 36 8E
O inteiro 01 F9 em decimal representa 505 centésimos de milisegundos, que
significa 5,05 milisegundos de injetor ON(Ligado).
O inteiro 2D 36 em decimal representa 11574 centésimos de milisegundos, que
significa 115,74 milisegundos de injetor OFF(Desligado).
Função Lambda:
DF1 - Retorna 00.
DF2 - Retorna 00.
DF3 - Retorna MSB da tensão.
DF4 - Retorna LSB da tensão.
A inteiro composto por MSB/LSB informa a tensão em milivolts.
Exemplo de retorno: 06 0B 04 00 00 00 66 85
O inteiro 00 66 em decimal representa 102 milivolts, que é equivalente a 0,102
volts.
Formato de retorno NAK - DEVICE → HOST:
Códigos de erro:
NAK
CMD
LB
EC
CS
15
0B
01
XX
CALC
01 - Formato do comando inválido.
03 - Comando não reconhecido ou inválido.
05 – Comando não pode ser executado no momento.
49
Comando: 0C – Status da comunicação.
Formato de envio HOST → DEVICE:
DID
LB
CMD
CS
02
01
0C
F7
Formato de retorno ACK - DEVICE → HOST:
ACK CMD
06
07
LB
DF0
DF1
CS
02
XX
XX
CALC
DF0 - Quantidades de erros de checksum.
DF1 - Quantidades de erros de DID.
Formato de retorno NAK - DEVICE → HOST:
Códigos de erro:
NAK
CMD
LB
EC
CS
15
0C
01
XX
CALC
01 - Formato do comando inválido.
03 - Comando não reconhecido ou inválido.
50
4.4 Como Utilizar o Software do Tachometer
Ao rodar o programa será aberta a janela do Tachometer na aba Info. Nesta aba o
usuário deve inserir o número de série do equipamento, selecionar a porta de
comunicação e acionar o botão Conectar. O borão Conectar só estará habilitado se
houver uma porta de comunicação serial disponível. Caso seja adicionada uma porta de
comunicação serial será necessário acionar o botão Atualiza, para mostrar todos as
portas seriais disponíveis. Assim que o software se conectar ao equipamento, este irá
informar a versão de hardware, firmware e software.
Figura 7, Tachometer – Tela Inicial.
Fonte: (Print Screen)
51
Figura 8, Tachometer – Botão Atualiza.
Fonte: (Print Screen)
52
Figura 9, Tachometer – Botão Conectar.
Fonte: (Print Screen)
53
Agora que o equipamento Tachometer está devidamente conectado, para que as
medições possam ser realizadas deve-se acessar a aba Medições, como padrão a função
Tensão da Bateria estará selecionada (em vermelho):
Figura 10, Tachometer – Aba Medições (tensão da bateria).
Fonte: (Print Screen)
54
Para selecionar outra função, basta clicar em um dos botões azuis, e no caso da
função RPM, é possível selecionar o número de cilindros do carro, e na função Tempo de
Injeção se é negativo ou positivo. Lembrando que além do botão selecionado estar em
vermelho, sempre abaixo do botão Start estará indicada qual função está selecionada.
Após a função desejada estar selecionada, para iniciar a medição deve-se clicar no
botão Start:
Figura 11, Tachometer – Realizando a Medição.
Fonte: (Print Screen)
55
Enquanto a medição estiver sendo realizada, os botões ficam desabilitados (cinza),
o botão da função selecionada fica rosa claro e o botão Start torna-se Stop. Abaixo do
display há uma barra de progressão que varia de acordo com os valores da medição que
estão sendo apesentados no display. Para parar a medição deve-se clicar no botão Stop.
Na aba Config serão adicionados parâmetros de configuração do equipamento.
Estes parâmetros serão opcionais, portanto não estão disponíveis nesta versão.
56
Conclusão
O Tachometer é um produto de grande utilidade ao reparador de automóveis por
reunir diversas funções antes realizadas por aparelhos distintos num único equipamento
prático, de fácil uso e com conexão a computadores, o que permitiu um enorme ganho de
recursos visuais e de banco de dados.
O desenvolvimento deste projeto nos proporcionou além de um aprofundamento
em Java e comunicação serial na área de informática, também conhecimentos
introdutórios na área de eletrônica. Esse projeto também nos possibilitou sair do “teórico”
e fazer um programa (software) útil, e complexo para um equipamento (hardware) que
futuramente ajudará a sociedade de algum modo, o que é muito gratificante para o grupo.
57
Referências Bibliográficas
Tecnologia em alta nas oficinas. Disponível em: <http://www.omecanico.com.br/>.
Acesso em: 13 de maio de 2013.
BIRD, John; Queiroz, Luiz Claudio de; Barroso, Jorge Luiz. CIRCUITOS ELÉTRICOS:
TEORIA E TECNOLOGIA. Sonda lambda controlando a mistura ar combustível.
Consultório técnico da Best Cars Web Site. Acesso em: 13 de maio de 2013.
A história do surgimento da linguagem Java. Disponível em:
<http://trabjava.blogspot.com.br/2010/09/historia-do-surgimento-da-linguagem.html >.
Acesso em: 29 de julho de 2013.
A história da linguagem Java. Encontrado em: <http://www.marcelomoraes.com.br>.
Acesso em: 29 de julho de 2013.
RAVAGNANI, Válter. Relação do tempo de injeção de combustível (Ti) com o sinal do
sensor de oxigênio (sonda lambda). Disponível em:
<http://arquivo.oficinabrasil.com.br/noticias/?COD=865 >. Acesso em: 19 de agosto de
2013.
Drcarro.ie. Sonda Lambda. Disponível em:
<http://blocktotal.blogspot.com.br/2011/04/sonda-lambda_02.html >. Acesso em: 19 de
agosto de 2013.
Controle de Dispositivos Eletrônicos (Acionamento de dispositivos eletrônicos por
meio de uma interface gráfica em Java e um microcontrolador via comunicação
serial). Disponível em:
<http://www3.iesam-pa.edu.br/ojs/index.php/computacao/article/viewFile/92/87 >. Acesso
em: 9 de setembro de 2013.
58
CANZIAN, Edmur. Comunicação Serial - RS232. Disponível em:
<http://www.ebah.com.br/content/ABAAABb40AF/comunicacao-serial-rs232 >. Acesso em:
9 de setembro de 2013.
CANZIAN, Edmur. Comunicação Serial - RS232. Disponível em:
<http://www.cnz.com.br>. Acesso em: 9 de setembro de 2013.
ALVES, Mário Ferreira. ABC do Osciloscópio. Disponível em:
<http://www.ceset.unicamp.br/~leobravo/TT%20305/O%20Osciloscopio.pdf >. Acesso em:
9 de setembro de 2013.
Tacômetro Digital, medição de rotação, rpm DT-2268. Disponível em:
<http://www.impac.com.br/Tacometro_medicao_rotacao_rpm_DT2268.htm >. Acesso em: 9
de setembro de 2013.
59
Anexo A – Cronograma
Cronograma Inicial de Desenvolvimento de Software do
“Tachometer”
Dt.
Inicial
Dt. Final
16/03/13
23/03/13
16/03/13
Tipo
Resp.
STATUS
Definição inicial das funções do equipamento.
HW
S
Concluído
23/03/13
Pesquisa sobre modelos de TCC e comunicação serial com
Java (livros e internet).
DC
G
Concluído
16/03/13
23/03/13
Definição inicial das telas do software.
DC
S
Concluído
23/03/13
30/03/13
Definição Inicial do protocolo de comunicação serial
(detalhamento).
DC
S
Concluído
23/03/13
30/03/13
Esboço das telas do software.
DC
G
Concluído
30/03/13
06/04/13
Documentação do protocolo de comunicação serial
(descrição).
DC
G
Concluído
30/03/13
06/04/13
Montagem de protótipos para teste do protocolo de
comunicação.
HW/FW
S
Concluído
06/04/13
20/04/13
Implementação do protocolo de comunicação em Java.
SW
G
Concluído
20/04/13
27/04/13
Codificação inicial do corpo do programa com telas de
medições e funções de teste.
SW
G
Concluído
20/04/13
04/05/13
Testes iniciais do programa, realizando medições e testes
(protótipos de comunicação).
SW
G
Concluído
20/04/13
04/05/13
Definição do esquemático do hardware, com todas as
funções.
HW
S
Concluído
04/05/13
18/05/13
Desenho do layout das placas de circuito impresso.
HW
S
Concluído
18/05/13
08/06/13
Produção dos primeiros protótipos de PCI.
HW/FW
S
Concluído
08/06/13
15/06/13
Montagem dos primeiros protótipos do equipamento e
provas de firmware.
HW/FW
S
Concluído
15/06/13
27/07/13
Testes do software com hardware.
SW/HW
/FW
G/S
Concluído
27/07/13
17/07/13
Finalização da documentação do TCC, Confecção do
manual do equipamento.
DC
G
Concluído
27/07/13
17/08/13
Caso necessário alteração do hardware/firmware.
HW/FW
S
Concluído
17/08/13
31/08/13
Caso necessário produção de novos protótipos de PCI.
HW/FW
S
Concluído
31/08/13
14/09/13
Caso necessário montagem do hardware e modificação de
software.
SW/HW
/FW
S/G
Concluído
14/09/13
28/09/13
Testes finais, montagem final, teste de campo
SW/HW
/FW
S/G
Concluído
28/09/13
16/11/13
Preparação da apresentação, finalização do TCC, ultimos
acertos.
DC
G
Concluído
Legenda:
Descrição
Responsável
G = Grupo
S = Sacch (Patrocinadora)
Tipo
SW = Software
HW = Hardware
FW = Firmware
DC = Documentação
60
Anexo B – DFD – Diagrama de Contexto
61
Anexo C – DFD Nível 0
62
Anexo D – DFD Nível 1 – Processo 1
63
Anexo E – DFD Nível 1 – Processo 2
64
Anexo F – DFD Nível 1 – Processo 3
65
Anexo G – Ata de Reunião nº1
ATA DE REUNIÕES
TCC 2013
PROJETO K
08/03/2013
Nº 1
Reuniram-se na empresa Eletrotécnica SACCH Ltda., patrocinadora do projeto do TCC
2013, os alunos Gabriela F. D'Angelo, Luiz Tiago, Lucas Bulgarelli, William Onoue para discutir a
viabilidade do projeto. Nesta data foi decidido o desenvolvimento de um Software para controle de
equipamento destinado a manutenção automotiva. Segue abaixo as características do projeto:
•
Software desenvolvido em Java. Escolhemos esta linguagem por ser multiplataforma
e open source. Utilizaremos como ferramenta de desenvolvimento o ambiente de
desenvolvimento NetBeans e como banco de dados o software SQLite. Todos esses
softwares são livres e sem custo de aquisição, o que torna o nosso projeto
economicamente viável.
•
Software Multiplataforma. Isto permite que nosso software possa ser executado em
computadores Desktop, Notebook, Netbook e com sistema operacional MAC OS,
Windows XP, Windows Vista, Windows7, Windows8 e praticamente todas as
distribuições Linux, portanto nosso programa será de utilização praticamente
universal.
•
Como nosso sistema é desenvolvido em Java que é a base para o desenvolvimento do
sistema operacional Android, nosso software poderá facilmente ser portado para este
sistema operacional, tornando nosso software disponível para SmartPhones e Tablets.
•
Para a documentação de toda a monografia de nosso TCC será utilizado o software
livre OpenOffice, o qual oferece excelentes recursos de editoração sem custos de
aquisição.
Como ainda não temos o nome definitivo de nosso TCC chamaremos este projeto de
PROJETO K.
Os demais integrantes do grupo, Ana Flávia Oliveira, Camila Lima e Juliana Queiroz
ficaram incumbidos de pesquisar modelos de monografias de softwares para termos como ponto de
partida para confecção de nossa monografia.
Visto do professor: ___________________________
Data: __________________
66
Anexo H – Ata de Reunião nº2
ATA DE REUNIÕES
TCC 2013
PROJETO K
29/03/2013
Nº 2
Reuniram-se na empresa Eletrotécnica SACCH Ltda., patrocinadora do projeto do TCC
2013, os alunos Gabriela F. D'Angelo, Luiz Tiago, Lucas Bulgarelli, Willian Onoue para definir
detalhes do protocolo de comunicação serial.
Nesta data tivemos o primeiro contato com o hardware do equipamento e fizemos pequenas
simulações de comunicação entre computador e o equipamento através de cabo USB emulando uma
porta serial convencional.
Também foi decidida a pesquisa de material sobre comunicação serial para a documentação
em nossa monografia.
Os demais integrantes do grupo, Ana Flávia Oliveira, Camila Lima e Juliana Queiroz
continuaram incumbidos de pesquisar modelos de monografias de softwares para termos como
ponto de partida para confecção de nossa monografia.
Visto do professor: ___________________________
Data: __________________
67
Anexo I – Ata de Reunião nº3
ATA DE REUNIÃO
TCC 2013
PROJETO K
04/05/2013
Nº 3
Reuníram se na empresa Eletrotécnica Sacch Ltda., patrocinadora do projeto de TCC 2013, a
aluna Gabriela Fontanelli D'Angelo e os sócios da empresa para discutir os tópicos abaixo:
●
Alteração dos integrantes do grupo de TCC, PROJETO K.
Comunicamos aos dirigentes da empresa patrocinadora que devido a problemas de
comunicação e interesse em outras áreas as alunas Ana Flávia Oliveira, Camila Lima e Juliana
Barbosa de Queiroz decidiram deixar o grupo, portanto a partir desta data o nosso grupo é composto
apenas por Gabriela Fontanelli D'Angelo, Lucas Bulgarelli, Luiz Henrique Montanher Tiago e
Willian Onoue.
●
Alteração do professor orientador de TCC, PROJETO K.
Comunicamos a empresa que a partir desta data a professora orientadora de TCC
passa a ser a professora Márcia Cristina e não mais o professor Maicon Silva.
● Possibilidade de pesquisa de campo em empresas concorrentes sobre os
equipamentos similares oferecidos.
Com relação a solicitação da professora Márcia Cristina sobre pesquisa de campo,
nesta data em comum acordo com os dirigentes da empresa chegamos a conclusão que uma
pesquisa de campo com consulta direta às empresas seria inviável, pois estaríamos alertando a
concorrência sobre o lançamento de um produto inédito no mercado. Outro ponto a destacar seria
que dificilmente empresas concorrentes concordariam em participar de uma pesquisa onde a
patrocinadora de um TCC de alunos da ETEC seria uma empresa concorrente.
Como sugestão para uma pesquisa de campo os dirigentes da empresa indicaram
diversas publicações (jornais e revistas) específicas da área de reparação automotiva para consulta
além de disponibilizar catálogos de empresas concorrentes com produtos similares.
Desta forma esperamos realizar esta pesquisa de mercado sem a necessidade de
alertar a concorrência para o lançamento do produto da empresa patrocinadora.
Não houve necessidade da presença dos demais integrantes do grupo nesta reunião.
Visto da professora:_______________________
Márcia Cristina
Data:__________________
68
Anexo J – Ata de Reunião nº4
ATA DE REUNIÃO
TCC 2013
TACHOMETER
(PROJETO K)
12/07/2013
Nº 4
Reuníram se na empresa Eletrotécnica Sacch Ltda., patrocinadora do projeto de TCC 2013,
Gabriela D'Angelo, Lucas Bulgarelli, Luiz Tiago, Willian Onoue e os engenheiros da empresa para
discutir os tópicos abaixo:
●
Apresentação de um novo layout de tela, inclusão de novas abas e funções de
calibração.
●
Escolha do nome definitivo do projeto: Tachometer.
●
Apresentação de melhorias feitas no protocolo serial.
● Atribuição de tarefas aos integrantes do grupo (elaboração do fluxograma e
documentação do protocolo serial).
Elaboração de botões personalizados, pesquisa sobre novos elementos (barra de
progressão, gráfico) que serão possivelmente integrados à interface gráfica do projeto.
●
Visto da professora:_______________________
Márcia Cristina
Data:__________________
69
Anexo K – Ata de Reunião nº5
ATA DE REUNIÃO
TCC 2013
TACHOMETER
(PROJETO K)
19/07/2013
Nº 5
Reuníram se na empresa Eletrotécnica Sacch Ltda., patrocinadora do projeto de TCC 2013,
Gabriela D'Angelo, Lucas Bulgarelli, Luiz Tiago, Willian Onoue junto aos engenheiros da empresa,
onde foram realizadas as seguintes tarefas:
●
Finalização do layout e configuração das novas abas.
●
Implementação de novas funções no projeto.
●
Elaboração do manual de instalação do JDK, NetBeans e RXTX.
●
Início da elaboração de fluxogramas.
●
Inclusão de encriptação simples (XOR) para transmissão e recepção dos dados.
Visto da professora:_______________________
Márcia Cristina
Data:__________________

Documentos relacionados