Universidade Estadual Paulista “Júlio de Mesquita Filho”

UNESP Campus de Guaratinguetá

Departamento de Engenharia Elétrica

Desenvolvimento de um Circuito de Interface para o Sistema de Recuperação de Imagem de Fitas Geradas Através do Sensor MSS

(Multi-Spectral Scanner)

Autor: Michel de Oliveira Garcia

Orientador: Prof. Dr. Galdenoro Botura Jr.

Março de 2000

2

Índice ÍNDICE .................................................................................................................................. 2 I - TITULO DO TRABALHO ............................................................................................ 3

II - OBJETIVOS ................................................................................................................... 3 III - RESUMO DO PLANO INICIAL ................................................................................ 3 IV – FASES DO PLANO DE PESQUISA .......................................................................... 4

IV.1 - LEVANTAMENTO BIBLIOGRÁFICO DA LITERATURA EXIGIDA PARA A PESQUISA .......... 4

IV.2 - IDENTIFICAÇÃO E MODELAGEM DOS PROBLEMAS ORIUNDOS DO USO DO GRAVADOR AMPEX FR-1928, E DO TEMPO DE VIDA DAS FITAS MAGNÉTICAS ......... 5

A) O SISTEMA MSS ( MULTI-SPECTRAL SCANNER ) ............................................. 5

Descrição do funcionamento ........................................................................... 5

O formato dos dados ....................................................................................... 6

B) PRINCIPAIS PROBLEMAS IDENTIFICADOS ........................................................... 9

IV.3 - PROJETO E SIMULAÇÃO DO CIRCUITO ELETRÔNICO DE INTERFACE ........................... 10

VI- CONCLUSÃO .............................................................................................................. 12

VII- REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................... 13 APÊNDICE .......................................................................................................................... 14

3

I - Titulo do Trabalho

Desenvolvimento de um Circuito de Interface para o Sistema de Recuperação de Imagem de Fitas Geradas Através

do Sensor MSS (Multi-Spectral Scanner)

II - Objetivos Fornecer e fortalecer a formação do aluno na área de instrumentação, através do estudo e

desenvolvimento de um circuito dedicado à instrumentação voltada para a recuperação de

Imagem de fitas geradas através do sensor MSS (Multi-Spectral Scanner)

III - Resumo do plano inicial A proposta deste trabalho é de se estudar o sistema de gravação das imagens geradas pelos

satélites “LANDSAT-1”,” LANDSAT-2” e “LANDSAT-3” (geradas entre 1973 e 1984), e

desenvolver uma interface para a recuperação dessas imagens. Foi proposto então, que se

desenvolvesse um hardware que fizesse uma interface entre o gravador o um

microcomputador.

O hardware será constituído de um sistema de processamento, que corresponderá a um

microcomputador compatível com o padrão IBM-PC, uma placa de aquisição de dados e

uma interface que faça a conexão entre o leitor de fitas magnéticas e a placa de aquisição.

Em relação ao circuito eletrônico a ser desenvolvido, ele interfaceará um gravador, que tem

por função fazer a leitura da fita magnética de alta densidade, com a placa de aquisição de

dados.

O gravador utilizado, modelo AMPEX FR-1928, remanescente do equipamento original,

disponibiliza 24 saída seriais de 600 kbits/s. Cada um dos canais de saída é composto de

sinais de dados e de sincronismo (clock), gerados a partir da leitura da fita. Este dados,

apesar de terem sido gravados à mesma taxa de dados, apresentam-se na saída com

características de clock independentes, podendo apresentar diferenças de fase entre os

canais, ou mesmo eventuais perdas de dados em alguns deles. Um circuito dedicado que

viabilize este interfaceamento será desenvolvido, solucionando o problema de sincronismo

4

existente e gerando os sinais necessários para a placa de aquisição de dados instalada no

PC.

Um estudo que virá a ser realizado será o de verificar qual a melhor estratégia a ser adotada

para o projeto do circuito eletrônico que integrará esta interface, de forma a garantir a

aquisição dos dados úteis, mesmo em eventual ausência de dados em algum dos canais.

Uma possibilidade é o desenvolvimento de um circuito baseado em microprocessadores ou

em microcontroladores.

IV – Fases do Plano de Pesquisa As fases propostas para o desenvolvimento do plano de pesquisa são:

1- Levantamento bibliográfico da literatura exigida para a pesquisa

2- Identificação e modelagem dos problemas oriundos do uso do gravador AMPEX FR-1928, e do tempo de vida das fitas magnéticas

3- Projeto e simulação do circuito eletrônico de interface

4- Documentação final

Durante ao período correspondente ao deste relatório foi desenvolvido o seguinte trabalho,

descrito a seguir, em cada uma das fases:

IV.1 - Levantamento bibliográfico da literatura exigida para a pesquisa A bibliografia necessária para a realização do projeto esta concentrada no INPE de

Cachoeira Paulista, por se tratar de manuais do gravador AMPEX FR-1928 da “BENDIX

CORPORATION” para o formato dos dados do MSS e do gerador teste de padrões do

MSS. Este material foi recebido juntamente com o equipamento.

No manual denominado “Multispectral Scanner Test Pattern Genarator (MSS TPG)- EC

2357320”, referência [1], pôde-se encontrar o formato do dado, sua seqüência, o significado

de cada pacote e sua temporização. Por ser um manual do Gerador de teste padrão (TPG),

contém os modelos gerados pelo mesmo (selecionáveis pelo usuário) que serviram de

exemplo do formato dos dados. Foi uma boa introdução do formato dos dados do MSS.

Os manuais Interface “Control Specification MSS Data Interface Assy ICS 2357110” e

“Interface Control Specification MSS TPG ICS 2357320” referências [2] e [3],

5

respectivamente, apresentam detalhes sobre o funcionamento do TPG e do gravador

AMPEX, com diagramas em bloco e descrição dos mesmos. Essa documentação é

importante para se entender como um sinal é gerado, porque um sinal não está sendo

gerado, ou mesmo gerado de forma incorreta. Será portanto útil para solucionar problemas

não previstos.

O manual “Waltz, E., INPERTS MSS Data Interface and Test Pattern Generator Training

Notes 23/05/1973” referência [4] contém os circuitos internos e especificações do gravador

e do TPG. É útil para o treinamento e manutenção nos equipamentos.

O manual “Derouchie, W. ERTM-H-157 Precision Processing Subsistem Software

Milestone 6. Viwer Transform Computation. No. 2361534-6, Revision A 15/12/72”,

referência [5], foi o mais importante para o aprendizado sobre o formato do MSS. Ela

contém todas as especificações para a confecção do software do antigo tratador de imagens

do MSS. Nela estão especificados todos os tratamentos necessários para se extrair os dados

de forma correta, ou seja todos os seus detalhes. Com ele foi possível obter todas as

informações necessárias para extrair das trilhas, os dados.

O manual “INPERTS Specification MSS Data Interface EC 2357110” referência [6] faz um

apanhado geral do formato dos dados, das características do gravador, suas especificações,

ou seja, uma síntese de todo o sistema. Foi através dessa referência que foi possível compor

corretamente as trilhas de forma a obter a imagem.

IV.2 - Identificação e modelagem dos problemas oriundos do uso do gravador AMPEX FR-1928, e do tempo de vida das fitas magnéticas

a) O sistema MSS ( Multi-Spectral Scanner )

Descrição do funcionamento Os satélites “LANDSTAT-1”, “LANDSTAT-2” e “LANDSTAT-3” traziam a bordo o

sistema MSS, que gera imagem em quatro bandas do espectro, cada banda sendo gerada

através de seis espelhos, totalizando, em todo o sistema, vinte e quatro espelhos. Cada

banda utiliza um filtro (lente) diferente, ou seja, as quatro bandas adquirem a mesma

imagem em freqüências diferentes. Essas imagens são posteriormente compostas para

6

formarem a imagem final. O satélite não tira fotos e sim faz uma varredura de uma área e

envia à base terrestre os dados a uma taxa constante.

Os espelhos fazem uma varredura e são reposicionados para começar a próxima varredura.

Nesse intervalo, o satélite envia bits de preambulo para manter a taxa de transmissão

constante, que é de 20Mbps,.

O receptor faz a demultiplexação do sinal recebido serialmente para vinte e quatro canais

(que são as quatro bandas com seis linhas cada) e retira os bits de preambulo, pois esses não

contém informação. Depois disso, os dados estão prontos para serem gravados.

Figura 1- Varredura e transmissão dos dados do MSS

O formato dos dados

O formato dos dados está demonstrado na figura 2.

7

Figura 2 - formato dos dados

Os dados são codificados do seguinte modo:

Preambulo: São 1740 palavras de 6 bits que são geradas pelo satélite quando o

mesmo está reposicionando os espelhos para nova varredura. Eles são gerados para

manter a taxa de transmissão constante(20Mbps). Todas as 1740 palavras são

101010.

Line sync: É a palavra que indica início de transmissão. Essa palavra é 111001.

Após essa palavra, os dados de imagem são transmitidos.

Time Code: São duas palavras que dizem a data e a hora da varredura. A informação

completa está a cada seis trilhas. A data é formada por três algarismos, que indicam

o dia do ano que aquela imagem foi adquirida. A hora é no formato 00:00:00.00. O

MSS dispõe as informações separadas por trilha, ou seja, cada trilha contém uma

parte da informação.

A tabela 1 mostra como extrair o instante do início de cada varredura das trilhas. O

MSS realiza duas varreduras e as envia intercaladamente, ou seja uma no formato

“Ä” e outra no formato “B”, e assim sucessivamente. As primeiras trilhas a serem

enviadas são as 12 últimas (24 a 13), enviadas no formato “A” e “B”, que ele chama

de “1a Palavra” e depois são enviadas as 12 primeiras (12 a 01), chamadas de “2a

8

Palavra”, seguindo esta mesma ordem, primeiro “A” depois “B”. Para identificar o

instante de tempo completo, deve-se identificar a 1a e a 2a palavra do tipo A ou B.

As duas colunas ( do tipo A, por exemplo) são correspondentes aos dois bytes do

código de tempo.

Tabela 1- Disposição do Time Code nas trilhas

Trilhas 1a Palavra – A 1a Palavra – B

24 22 20 18 s x 10-1 H x 10 s x 10-2 h

16 14 25 23 s x 10-2 H Min Min x 10

21 19 17 15 1’s Min x 10 0’s Dia x 102

Trilhas 2a Palavra – A 2a Palavra – B

12 10 8 6 Min Dia x 102 s x 10 Dia x 10

4 2 13 11 s x 10 Dia x 10 S Dia

9 7 5 3 s Dia s x 10-1 h x 10

Por exemplo, supondo que se necessite extrair o tempo de uma leitura, pode-se

pegar a primeira coluna das trilhas e decodificar suas palavras. Para isto extrai-se

então os códigos das trilhas 24,16,21,12,4 e 9, compondo de acordo com a tabela, ou

seja, o primeiro byte da trilha 24 corresponde aos décimos de segundo e o segundo

às dezenas das horas e assim por diante.

Dados: São 3600 palavras de dados que o MSS envia por varredura. Para compor a

imagem de um espectro, deve-se “juntar” as trilhas na seqüência correta, pois elas

não estão ordinariamente dispostas. As bandas são compostas da seguinte forma:

Banda 1: Trilhas 3,5,7,9,11,13;

Banda 2: Trilhas 15,17,19,21,23,25;

9

Banda 3: Trilhas 2,4,6,8,10,12;

Banda 4: Trilhas 14,16,18,20,22,24.

Notar que as trilhas são numeradas de 2 a 25.

Line length: São três palavras que indicam quantos bytes foram lidos naquela

varredura. Esse número deve ser sempre constante, pois os espelhos varrem uma

extensão de mesmo tamanho a cada leitura. Tem-se, caso contrário, uma indicação

de que o sistema não está funcionando.

Observação: O MSS trabalha com palavras de seis bits e qualquer referência a bytes deve

ser interpretada como palavra de seis bits (os manuais fazem referência a “six bits bytes”).

b) Principais problemas identificados Um dos problema verificados neste projeto é que as fitas em que os dados foram gravados,

há muito tempo estão guardadas sem serem utilizadas, o que acarreta em problemas como a

perda dos dados armazenados, já que todos os dados gravados magneticamente estão

sujeitos a isso. Não é possível recuperar o dado perdido, portanto é preciso desenvolver

uma estratégia para contornar o problema. Uma possível solução é fazer um pós-

processamento por software para estimar o dado perdido.

Um outro problema identificado surge no momento da leitura da fita. O gravador não

necessariamente está calibrado sendo esta calibração necessária para se ajustar amplitude

de saída do sinal, pois um nível lógico alto pode ser entendido como baixo e vice-versa. A

calibração serve, também, para que os sinais não percam o sincronismo. É necessário

realizar a calibração em vinte e quatro placas, sendo que cada placa processa uma trilha da

fita. Para a realização desta calibração coloca-se uma fita no gravador e realiza-se o ajuste

manual dos potenciômetros até que os sinais estejam sincronizados e com amplitude

correta. Esse ajuste normalmente feito por um técnico experiente, que trabalhou muitos

anos no equipamento. Pode ocorrer de uma ou mais trilhas perderem o sincronismo durante

a leitura. Nesse caso o que se tem a fazer é sincronizar a fita novamente e recomeçar a

leitura.

10

O fato de que uma fita pode colar uma camada na outra, quando permanece enrolada por

um certo tempo,. é um outro problema que tem que ser solucionado. Por isso, a fita

magnética precisa passar por um condicionamento prévio antes de ser utilizada. Ela deve

passar por um aquecimento em um forno específico e ainda rodar algumas vezes no

gravador antes de ser lida.

Por ser gravada em vinte e quatro trilhas em paralelo, os dados precisam ser sincronizados

por um sinal de relógio (clock). Cada uma das vinte e quatro trilhas tem a sua própria base

de tempo, e, apesar de todas serem geradas pelo mesmo circuito, existe uma defasagem,

acrescentada na gravação. Quando os dados são gravados, a fita pode se inclinar um pouco,

fazendo com que o pulso de uma trilha comece antes que o de outra. Isso dificulta a leitura

dos dados, pois pode-se estar lendo apenas parte destes dados. Esse problema é

denominado “skew”.

Com relação ao clock, este pode se perder, mas nesse caso, o próprio gravador se

encarrega de gerar outro.

A peça responsável por puxar a fita, que é um cilindro de metal coberto por uma borracha

especial, desgastou-se após tantos anos de uso (entre as décadas de 70 e 80). Outro

problema, é devido ao fato de que a borracha que reveste o cilindro é muito mole e escorre

após muito tempo sem uso, que foi o caso. Isto gera ruídos na leitura que reflete no sinal

adquirido. Em função disto o INPE já providenciou a confecção de uma nova peça.

IV.3 - Projeto e simulação do circuito eletrônico de interface Após o estudo inicial, o circuito pode ser projetado, com base nos problemas que se quer

eliminar (ou minimizar).

O circuito deve, primordialmente, eliminar a defasagem entre as trilhas e disponibilizar à

placa de aquisição, os dados corretamente. Pensou-se então em uma memória serial que

guardasse uma grande quantidade de dados e os disponibilizasse após um certo número de

dados recebidos.

11

Para isso, podem ser usados registradores de deslocamento com um controle. Uma FIFO

(first in first out), atende exatamente às necessidades acima descritas.

A FIFO funciona da seguinte forma: Os dados entram serialmente e são armazenados,

como num registrador de deslocamento (shift register), e, assim que se desejar pode-se

retirar os mesmos serialmente. A FIFO utilizada é a IDT72413 que armazena 64x5 bits.

Possui uma entrada de clock e cinco de dados. Pode-se retirar os dados da FIFO somente

habilitando o pino S0. Tem uma saída HF(half full), que avisa quando 32 buffers, dos 64

estão cheios. Possui, também, um sinal de reset, o MR(master reset).

O circuito representado é para apenas uma trilha. Como se precisa gerar somente um sinal

para a aquisição dos dados, uma única trilha (no caso, a primeira), precisa de um circuito

desse tipo. As demais trilhas necessitam apenas da FIFO para armazenar os dados, como

será explicado adiante. O circuito, mostrado na figura 3, funciona da seguinte forma:

Os sinais CLOCK/MSS e DATA/MSS são os sinais de clock e dados, respectivamente, do

gravador. ACK1 e PCLK, são sinais que a placa de aquisição de dados envia. DIO_A0 e

REQ são sinais enviados à placa de aquisição.

Quando a placa de aquisição está pronta para receber os dados, envia um pulso ACK1,

“resetando” a FIFO através do pino MR(Master reset). Com isso, todos os buffers são

limpos para serem usados. Após essa operação, a placa de aquisição começa a pulsar a

linha PCLK1, requisitando transmissão de dados para a mesma.

+5V

+5V

+5V

+5V

_____ PCLK1

SO

SO

HF

U1 IDT7241

3 OE

1 HF

2 IR 3 SI 4 D0

5 D1

6 D2

7 D3

8 D4

9 MR

11

AF/E 19 S

0 18 O

R 17

Q0

16 Q

1 15 Q

2 14 Q

3 13 Q

4 12

74LS74

D 2 CLK

3 Q 5

Q 6 PR 4

CL 1 U3A 74F0

4 1 2

R2

100R

R3

100R

R2

100R

U2A

7408 1

2 3

R2

120R

R1

120R C1

58 pF

DATA/MSS

CLOCK/MSS

PCLK1

ACK1

REQ

DIO_A0

12

Figura 3: Circuito projetado

Quando os dados começam a ser lidos da fita, os buffers começam a ser preenchidos com

os mesmos. Isso significa que a linha CLOCK/MSS está pulsando e que pela linha

DATA/MSS estão sendo transmitidos os dados. Deve-se ressaltar que existem vinte e

quatro FIFO’s recebendo os dados das vinte e quatro trilhas. Quando a trilha 1 enviou trinta

e dois bits, a FIFO coloca nível alto na saída HF, indicando que a mesma tem metade dos

buffers ocupados.

Abrindo um parênteses e analisando parte do circuito formado pelos CI´s U2A(porta lógica

E) e pelo 74LS74 (flip-flop tipo D), pode-se observar que a saída Q está em nível lógico

baixo, pois, apesar do flip-flop receber pulsos de clock, sua entrada D (saída da porta E)

está, inicialmente, em nível baixo. A porta E, está ligada à saída Q, que inicialmente está

em nível alto, e à saída HF da FIFO, que está em nível baixo. Parênteses fechado.

Quando HF é posto em nível alto, a saída Q fica em nível alto. O pino SO (shift output) fica

em nível alto, passando o dado para a saída. Quando o dado é deslocado para a saída, o

pino HF cai, o que significa que Q cairá também. A placa recebe através de REQ esse nível

baixo e faz a leitura do dado através de DIO_A0.

Os resistores R1 e R2 e o capacitor C1, servem para condicionar o sinal, pois estavam

chegando com muito ruído, impossibilitando o funcionamento do sistema.

O primeiros testes obtidos com circuito em “wire-wrap” se mostrou que mesmo poderá vir

a ser utilizado, apesar de não ser possível, ainda, tirar maiores conclusões sobre o mesmo.

Usando este circuito e tentando fazer uma gravação preliminar de dados a partir de uma fita

verificou-se que os diversos problemas relatados no item IV.2 deverão ser ainda

contornados, porém, que o circuito proposto desempenhará, em princípio, satisfatoriamente

a função para a qual foi projetado.

VI- Conclusão

Esses seis primeiros meses serviram para uma adaptação do bolsista com o sistema, por se

tratar de algo novo para o mesmo. Pode-se dizer que o processo de aprendizagem, com

várias tentativas para se obter algum resultado (ou, às vezes, nenhum), foi de extrema

13

importância, pois é preciso insistência para levar adiante uma idéia, mas é preciso saber a

hora de partir para nova estratégia.

Durante esse período, o bolsista adquiriu uma certa experiência, percorreu alguns caminhos

que serão úteis no decorrer do projeto e detalhes que não foram levados inicialmente em

consideração tornaram-se importantes e neste processo de aprendizagem as soluções foram

encontradas de modo que os mesmos passarão a não ser mais um problema.

O circuito inicial está servindo de base para a elaboração de um novo, que consiga tratar de

forma mais segura a defasagem, distorções e ruídos da fita. Está sendo pensado, também

uma forma de se fazer um ajuste automático na placa de calibração das fitas, para poupar

tempo e trabalho, caso alguma trilha perca o sincronismo.

O prosseguimento do trabalho se dará conforme proposto no plano de pesquisa.

VII- Referências bibliográficas

[1] Multispectral Scanner Test Pattern Genarator (MSS TPG)- EC 2357320.

[2] Interface Control Specification MSS Data Interface Assy ICS 2357110.

[3] Interface Control Specification MSS TPG ICS 2357320.

[4] Waltz, E., INPERTS MSS Data Interface and Test Pattern Generator Training Notes 23/05/1973.

[5] Derouchie, W. ERTM-H-157 Precision Processing Subsistem Software Milestone 6. Viwer Transform Computation. No. 2361534-6, Revision A 15/12/72.

[6] INPERTS Specification MSS Data Interface EC 2357110.

______________________________

Galdenoro Botura Jr.

______________________________ Michel de Oliveira Garcia

14

APÊNDICE

Universidade Estadual Paulista “Júlio de Mesquita Filho”

UNESP

Campus de Guaratinguetá

Departamento de Engenharia Elétrica

Desenvolvimento de um Circuito de Interface para o Sistema de

Recuperação de Imagem de Fitas Geradas Através do Sensor MSS (Multi-Spectral Scanner)

Autor: Michel de Oliveira Garcia

Orientador: Prof. Dr. Galdenoro Botura Jr.

Setembro de 2000

I - Titulo do Trabalho

Desenvolvimento de um Circuito de Interface para o Sistema de Recuperação de Imagem de Fitas Geradas Através do Sensor MSS (Multi-

Spectral Scanner)

II - Objetivos Fornecer e fortalecer a formação do aluno na área de instrumentação, através do estudo e

desenvolvimento de um circuito dedicado à instrumentação voltada para a recuperação de

Imagem de fitas geradas através do sensor MSS (Multi-Spectral Scanner)

III – Descrição

III.1 – Descrição da primeira fase

O projeto proposto foi o de uma interface entre o gravador de fitas do MSS e uma placa de

aquisição de dados da National.Instruments Com isso pretendia-se gravar as fitas no formato

MSS, primeiramente em disco rígido, passando posteriormente para uma mídia, mais prática

de armazenar. Para isso foi necessário fazer uma pesquisa do material existente sobre o

sistema. A bibliografia foi encontrada no INPE de Cachoeira Paulista.

Houve a necessidade de se obter informações detalhadas sobre o gravador, o formato dos

dados gravados em fita e de detalhes técnicos como temporização e formato dos sinais. Além

disso, havia uma grande importância em saber como recuperar as informações de modo a

obter as imagens corretamente. O bolsista teve acesso às informações necessárias, como o

formato dos dados gravados, sua temporização, as especificações técnicas e outros detalhes.

Os principais problemas foram identificados através da própria bibliografia e com ajuda de

funcionários que já trabalharam com o equipamento. Teve-se que levar em consideração,

também, os problemas inseridos na implementação do sistema, como o ruído inserido pelo

cabeamento que liga o gravador e o circuito. Com essas informações disponíveis, o bolsista

teve condições de projetar um circuito que atendesse às necessidades. O circuito consiste de

vinte e quatro registradores do tipo FIFO, uma para cada trilha, de sessenta e quatro bits de

deslocamento e um circuito de controle. O princípio de funcionamento consiste em monitorar

o primeiro registrador FIFO e, quando 32 bits do mesmo estiverem preenchidos, o circuito

de controle fornecerá os dados para a placa de aquisição de dados. Foi feita parte da

montagem do circuito em uma placa do tipo wire-wrap e realizado um teste preliminar, que

se mostrou satisfatório. Com isso, o bolsista terminou a primeira parte do projeto.

III.2 – Descrição da segunda fase A segunda parte do projeto é a de implementação do circuito. Nessa fase, é que os problemas

citados no relatório anterior vão aparecer. Essa fase é decisiva, pois os problemas que não

forem resolvidos acarretarão em informação incorreta nos dados gravados. Nessa fase,

ocorreram problemas inesperados, como o alto nível de ruído, que dificultaram muito a

execução do projeto.

III.2.1 – Simulação do circuito projetado na fase anterior

Esse passo é importante pois é o primeiro teste do circuito, o que vai indicar se o mesmo vai

atingir seus objetivos. Isso pode significar um ganho de tempo no caso do circuito ter falhas,

pois não seria necessário fazer a montagem do mesmo para se verificar o problema. Deve-se

ressaltar que a ferramenta de simulação é apenas um guia, não sendo, portanto uma previsão

fiel da realidade, mesmo porque os sinais que serão trabalhados apresentam muito ruído, o

que não pode ser previsto na simulação.

O circuito projetado e apresentado no relatório anterior foi simulado e os resultados estão

aqui apresentados na figura 1. A simulação foi feita utilizando a ferramenta MAX PLUS II

da ALTERA. Foi usada essa ferramenta, por se tratar de um software de projeto de circuitos

digitais e que no futuro, caso se queira, poderá ser útil para implementar o dispositivo em

uma PLD. Os resistores e capacitores contidos no circuito são necessários para a filtragem e

condicionamento do sinal da fita, e, como o sinal é digital, sua presença na simulação se torna

dispensável, já que, como dito anteriormente, não se pode prever o ruído do mesmo.

Como mencionado anteriormente, são necessários mais vinte e três registradores FIFOs (uma

para cada trilha) para se obter o circuito completo. Como o circuito registrador FIFO possui

a mesma estrutura para todas as trilhas, a simulação realizada foi apenas de uma delas.

Simulação Realizada

Os sinais envolvidos na simulação, foram:

¨ CLOCK/MSS– Sinal de clock enviado pelo leitor/gravador de fitas MSS para sincronismo dos sinais;

¨ DATA/MSS – Dados enviados pelo leitor/gravador;

¨ ACK1 – Sinal enviado pela placa de aquisição para iniciar o processo;

¨ PCLK1 – Sinal de clock enviado pela placa de aquisição.

¨ REQ – Sinal que indica para a placa de aquisição que um dado está disponível;

¨ DIO – Dados enviados para a placa de aquisição;

¨ DADOS5 – Sinal interno do circuito, criado apenas para efeito de simulação. Esse sinal indica quando a FIFO tem metade de seus buffers cheios.

Para começar a transmissão, a placa de aquisição envia um sinal de reset através de ACK1.

Depois, a placa envia constantemente um sinal de clock ( PCLK1) para o circuito. Enquanto

isso, o leitor/gravador envia à placa os dados (DATA/MSS e CLOCK/MSS). Os buffers da

FIFO são preenchidos com os dados recebidos pelo circuito. Quando metade dos buffers

estão cheios, o circuito envia um sinal de REQ e disponibiliza os dados em DIO.

A figura 1 mostra a simulação do circuito. Por uma questão de visualização, o tempo inicial

não é zero, pois até ocorrer o evento esperado, é preciso que muitos pulsos de clock sejam

dados. O sinal de entrada ( que vem do leitor/gravador) é pulsado, para ficar mais fácil de se

identificar. Pode-se perceber que o circuito começa a enviar dados à placa de aquisição com

a subida do sinal DADOS5, que habilita a lógica de controle, gerando o sinal de clock e

enviando os dados à placa de aquisição.

Fig1 – Simulação do circuito projetado

Essa simulação, mostrou que a lógica empregada está correta, não precisando,

aparentemente, ser modificada. Como a simulação se mostrou satisfatória, passou-se para o

próximo passo, ou seja, a montagem do circuito em placa.

III.2.2 – Implementação do circuito

Uma primeira versão do circuito foi montada em placa de wire-wrap para que fossem feitos

testes. Foi montado um circuito para apenas duas trilhas. Esses testes se mostraram, como já

foi dito no relatório anterior, satisfatórios. Após esses testes, foi necessário terminar a

montagem para se testar o circuito em situação real.

A montagem do circuito teve que ser feita de forma cuidadosa para que não houvesse erros.

Apesar de todo o cuidado, erros de montagem foram achados após uma verificação detalhada.

Com todo esse trabalho, o bolsista adquiriu uma boa experiência em circuitos de wire-wrap.

Quando se tentou gravar os dados em disco rígido com todo o sistema funcionando, os

problemas apareceram. O sinal adquirido mostrou-se estar extremamente ruidoso. Verificou-

se que a saída do leitor/gravador MSS precisava de constante ajuste para que o sinal saísse

com o mínimo de distorção possível. Esse ajuste é feito através de potenciômetros dispostos

de forma a facilitar seu manejo nos cartões de saída do gravador. Cada trilha tem o seu

conjunto de potenciômetros, sendo necessário, portanto, fazer o ajuste individualmente para

cada trilha.

O ajuste que necessitava ser feito constantemente, era o do valor da amplitude do sinal de

saída. A primeira vez em que o equipamento era ligado, era necessário verificar se a

amplitude estava correta. Os demais potenciômetros não eram ajustados com freqüência e

este procedimento é feito por um técnico experiente.

Outro problema identificado era o ruído inserido pelo ambiente, pois há vários

equipamentos eletrônicos e microcomputadores no local. Para diminuir o ruído foi

providenciado um cabo, com isolamento eletromagnético, que substituiu o antigo que ligava

o leitor/gravador ao circuito. Somava-se a isso, o fato de que o circuito estava montado em

uma placa de wire-wrap, que pode inserir muito ruído numa freqüência relativamente alta

(100kbps). Por isso, pensou-se em fazer uma placa de circuito impresso para que o ruído

introduzido pelo circuito fosse o menor possível, para que fosse possível verificar as

modificações que eram realmente necessárias ao circuito.

Devido ao tempo relativamente curto, achou-se melhor entregar o serviço a uma firma

especializada. Essa decisão foi motivada, pelo fato do aluno não ter experiência em layout

de circuito impresso e de que uma placa leva um tempo considerável para ser feita.

O layout e a placa foram confeccionados por uma empresa contratada pelo INPE. A

montagem dos componentes foi realizada pelo bolsista e demorou um tempo além do

esperado, pois os componentes especificados não foram prontamente disponibilizados. Não

era prudente retirar os componentes da placa antiga, pois se a nova tivesse qualquer erro,

corria-se o risco de se perder componentes que estavam sendo utilizados nos testes, atrasando

os testes. Enquanto isso, os testes prosseguiram com a placa antiga.

Após a montagem dos componentes na placa, verificou-se uma melhora no sinal recebido.

Mas não se tinha, ainda, um resultado satisfatório, pois eram verificados muitos erros nos

dados gravados. Tornou-se necessário, então, fazer uma análise mais detalhada do sinal em

tempo real, para que os ajustes pudessem ser feitos com mais rapidez. A análise, até então,

era feita por “software”, mas não em tempo real, demandando demasiado tempo. Foi

necessário alterar o “software” de leitura da placa de aquisição de dados, mas o responsável

pelo desenvolvimento do mesmo não se encontrava mais no INPE. Devido a isto o bolsista

se ofereceu a fazer as mudanças necessárias, adquirindo um maior conhecimento no sistema

e em programação, uma vez que o cronograma proposto já havia sido desenvolvido. Todo o

trabalho realizado nesta nova fase também está apresentado neste relatório.

III.2.3 – Software desenvolvido

Faz-se necessário explicar como o sistema é visto pelo computador, pois para o programa

que controla o sistema de aquisição, a origem dos dados é irrelevante e o importante é como

trabalhar com esses dados. Devido a isso, o leitor/gravador e o circuito de condicionamento

são transparentes para o software, pois o mesmo faz a leitura diretamente dos sinais que são

colocados nas entradas da placa de aquisição de dados. Para o programador, a preocupação

é saber como funciona esta placa de aquisição de dados, como interfacear o programa com a

mesma com a mesma, e, depois de ler os dados, como fazer a gravação dos mesmos.

Primeiramente, foram desenvolvidos dois softwares. O primeiro faz a interface com a placa

de aquisição e armazena os dados. O segundo faz a análise dos dados que já estavam gravados

em disco. Isso foi realizado pois se temia que, ao se fazer a análise dos dados juntamente

com a leitura e gravação dos mesmos, alguns destes dados pudessem se perder, simplesmente

devido ao fato do programa não conseguir ler a placa com a freqüência necessária, e com isto

os dados armazenados nos buffers fossem sobrescritos.

Figura 2 – Janela do Visual C++, programa utilizado para desenvolver o software de

interfaceamento.

Apesar dos programas originais não estarem comentados, o aluno conseguiu compreendê-

los, pois teve contato com o programador, que passou todas as informações necessárias para

o bom entendimento de seu funcionamento que possibilitou a adaptação do mesmo às

necessidades da circunstância.

Os softwares foram desenvolvidos através do uso da linguagem Visual C++, que utiliza uma

linguagem poderosa e muito rápida, o C++. Esse programa permite uma visualização gráfica

dos recursos utilizados e tem uma interface com o usuário bastante agradável, facilitando o

trabalho com projetos de vários arquivos. A janela do Visual C++ é mostrada na figura 2.

Os programas são escritos em forma de projeto para facilitar a programação, o entendimento,

e a correção ou alteração dos mesmos. Separa-se o programa em módulos de forma a se

conseguir uma certa independência de cada um. Assim cada módulo tem sua função

específica. A descrição dos programas é feita nos próximos itens.

III.2.3.1 – Descrição do software de aquisição

Esse programa foi feito com a ajuda da ferramenta AppWizard contida no pacote do Visual

C++. Essa ferramenta cria o formato da caixa de diálogo (que pode ser modificada) e um

esqueleto do programa, no qual o programador insere seu código fonte nos espaços

apropriados.

Para a leitura dos dados, foi desenvolvido um software para interfacear com a placa de

aquisição de dados. Esse programa, primeiramente, inicializava a placa. Essa inicialização é

de extrema importância pois é ela define o modo de operação e como os dados fluirão na

placa, se essa será de aquisição ou geradora de sinais. Depois da inicialização verificava se a

placa já tinha os dados disponíveis para leitura. Quando estes estavam disponíveis, fazia a

leitura de forma paralela. O próximo passo devia ser a gravação dos mesmos em disco. Para

separar as vinte e quatro trilhas foram gravados vinte e quatro arquivos, sendo que cada um

recebia um bit dos vinte e quatro lidos. A tabela abaixo mostra como os dados são dispostos

nos arquivos, de forma que a imagem possa ser recuperada, fazendo-se uma combinação

conveniente entre os mesmos.

Arquivo1 Arquivo2 Arquivo3 .......... Arquivo24

Leitura1 D01 D11 D21 .......... D231

Leitura2 D02 D12 D22 .......... D232

.......... .......... .......... .......... .......... ..........

LeituraN D0N D1N D2N .......... D23N

Uma breve explicação dos arquivos mais importantes do projeto Aquisição MSS, o software

de aquisição de dados, é feita agora:

¨ AquisicaoMSS.h – Esse é o cabeçalho (header) principal. Nele estão declarados os outros cabeçalhos e o objeto principal do programa.

¨ AquisicaoMSS.cpp – O programa principal do projeto. Nele estão definidas as inicializações da placa de aquisição, bem como implementada a função de leitura da placa.

¨ AquisicaoMSS.rc – É uma lista de todos os recursos gráficos utilizados pelo programa, como bitmaps e caixas de diálogo.

Além desses arquivos e outros (de extensão cpp e h), teve-se que incluir drivers da placa de

aquisição e cabeçalhos, próprios para a programação em linguagem C.

III.2.3.2 – Descrição do software de análise dos dados

Depois dos arquivos gravados era necessário fazer uma análise dos mesmos para verificar se

os dados estavam corretos. Esse procedimento era mais rápido e mais eficiente que gerar

cada imagem, pois seria necessário fazer uma composição das imagens, o que demandaria

um tempo significativo de processamento. Além disso, a análise deveria ser visual, o que

significa imprecisão na avaliação, sem contar que não seria possível saber quais das trilhas

estariam defeituosas.

A análise é feita de acordo com o sinal esperado. Como já dito no relatório anterior, a

seqüência dos dados era:

¨ Preambulo: seqüência de sincronismo:

¨ Line lenght: indica o número de bytes enviados no frame;

¨ Time code: instante em que a imagem foi feita:

¨ Dados: dados da imagem transmitida.

O software verifica se essa seqüência está correta. Verifica-se, primeiro se todos os bits de

preambulo foram gravados. Depois, extrai-se o Line Lenght e o time code das trilhas. Essa

análise é feita individualmente, para cada trilha, e o resultado é mostrado na tela de forma

que se pudesse verificar visualmente o que estava ocorrendo a cada instante. A caixa de

diálogo utilizada é mostrada na figura 3. Deste modo Tem-se:

• quadro “Spacecraft time code”, mostra a extração do “time code”, nessa ordem: dia, hora, minuto e segundo.

¨ “MSS Line Lenght”, mostra o número de bytes transmitidos naquela seqüência.

• quadro com vinte e quatro “leds”, indica quais trilhas estão em sincronismo. Se o “led” está verde, o sinal está em sincronismo, e quando o “led” fica vermelho, não está.

Com isso tem-se uma maneira muito prática de se verificar quais sinais estão em sincronismo,

facilitando a resolução de um problema isolado numa trilha.

Figura 3 – Caixa de diálogo do software de aquisição de dados

III.2.3.3 – Modificação do programa

O fato do programa ter de ser desenvolvido em Visual C++ não representou dificuldade pois

o bolsista já tinha uma boa base de linguagem C, necessitando apenas de uma familiarização

com programação para ambiente Windows. Foi necessário, então, mesclar os dois programas

(o de aquisição e o de análise) para se fazer uma análise em tempo real.

Para se fazer essa mesclagem, utilizou-se como base o programa de aquisição

(AquisiçãoMSS) fazendo as modificações necessárias para que o mesmo analisasse os dados

e fizesse a leitura e escrita. Aproveitou-se, também a caixa de diálogo do programa de análise,

pois se mostrou muito prática e seria muito útil quando utilizada em tempo real. Obteve-se

um programa que adquire dados e analisa os mesmos em tempo real. Para não haver risco

de perder dados, ou seja, a placa de aquisição sobrescrever dados em seu buffer, teve-se que

ajustar a prioridade dos eventos. Isso ocorre pois a placa de aquisição não se preocupa se o

dado foi lido ou não. Quando um novo dado chega, a placa simplesmente atualiza o buffer,

tendo ele sido lido ou não. Para minimizar esse risco, as funções de leitura da placa e escrita

no HD têm prioridade alta, ou seja, devem ser feitas sem interrupção. A função de análise

tem prioridade baixa, sendo feita numa eventual “folga” entre as outras funções.

IV - Conclusão Esse projeto foi de grande valia para o aluno, pois fez com que o mesmo enfrentasse os

problemas de um projeto de grande porte e ter de resolvê-los de forma simples e rápida. O

aluno se deparou com problemas de ruído, que aparentemente não havia maneira de se

eliminar (alguns foram eliminados, outros ainda estão presentes), mas que fizeram com que

a engenharia fosse aplicada, dando uma experiência que não seria conseguida sem a

realização dessa bolsa.

Nessa segunda fase do projeto, houve muitos contratempos que dificultaram em muito sua

realização. O fato do projeto ser realizado no INPE foi um desafio bastante significativo, pois

não era possível fazer os testes a qualquer hora. Outro desafio foi o fato do equipamento estar

em um ambiente muito ruidoso, o que não tinha sido previsto inicialmente. Talvez tenha sido

esta a principal dificuldade com que se teve que conviver.

O fato do aluno ter que partir para modificar o software foi mais um novo e interessante

desafio. Mas esse desvio não foi encarado como prejudicial, pois proporcionou ao aluno se

aprimorar numa linguagem de programação muito poderosa e muito utilizada hoje em dia.

Esse aprendizado contribuirá em muito com o futuro profissional do aluno, que pretende

seguir a área de instrumentação virtual.

Por todos os obstáculos que foram vencidos, o aluno se dá por satisfeito, pois acredita ter

feito um trabalho construtivo, de grande importância para a memória do país e que permitirá,

após este inicio, dar ter prosseguimento ao mesmo com um maior conhecimento e em

melhores condições. Infelizmente o aluno não dar continuidade ao mesmo, pois esta indo

para o último ano de se curso estando a procura de um estágio para que consiga adquirir um

pouco mais de conhecimento em outras áreas.

Finalmente, por tudo que foi realizado, acredito que o projeto inicialmente proposto não só

alcançou como ultrapassou os objetivos pretendidos inicialmente, mostrando que se é

possível desenvolver um sistema que recupere os dados atualmente armazenados em fita e

os coloque em uma mídia mais acessível.

Michel de Oliveira Garcia Orientado Galdenoro Botura Jr Orientador

Anexo (programas de interfaceamento desenvolvidos)

I // AdquireMSS.cpp: implementation of the AdquireMSS class. // ////////////////////////////////////////////////////////////////////// #include "stdafx.h" #include "AquisicaoMSS.h" #include "AdquireMSS.h" #include "Trilha.h" #include "resource.h" #include <time.h> #include "c:\ni-daq\include\nidaqex.h" #include "c:\ni-daq\include\nidaqcns.h" #include <time.h> #ifdef _DEBUG #undef THIS_FILE static char THIS_FILE[]=__FILE__; #define new DEBUG_NEW #endif enum {Livre, Adquirindo, Pronto, Escrevendo, Escrito, Analisando}; enum {search, preambulo, sync}; BOOL aborta; static long int bufcount, bitpont = 65536, bitcount = 0, bitinicio = 0, bitmask; static long int writepont; //long int datapont; long int start, finish, iniciou, LL; u32 ulCount = 32768; i16 iLoopCount = 0; i16 iStatus = 0; i16 iDevice = 1; i16 iGroup = 1; i16 iRetVal = 0; i16 iIgnoreWarning = 0; i16 iDBModeOFF = 0; i16 iOldDataStop = 0; //desabilitado i16 iPartialTransfer = 0; i16 iHalfReady; //unsigned char data[27648]; long int i; BOOL Escreve = FALSE; HANDLE ArquivoSaida; struct Escrita WriteThread[30]; i16 iHalfBufsToRead =4000; // Aprox. 80 segundos de dados CEvent go, processa; CAquisicaoMSSDlg* m_Principal;

UINT AdquireDados (LPVOID pParam) { struct Escrita *buf = (struct Escrita *) pParam; iLoopCount = 0; while (!aborta) { iHalfReady = 0; while (iHalfReady != 1) // while (buf[writepont].bufstatus != Livre) { iStatus = DIG_DB_HalfReady(iDevice, iGroup, &iHalfReady); go.SetEvent(); // processa.SetEvent(); Sleep(0); } buf[writepont].bufstatus = Adquirindo; iStatus = DIG_DB_Transfer(iDevice, iGroup, (i16*)WriteThread[writepont].bufpont, WriteThread[writepont].bufsize/sizeof(long int)); if ((iRetVal = NIDAQErrorHandler(iStatus, "DIG_Block_In", iIgnoreWarning))== IDNO) return 0; m_Principal->totalgeral += (ulCount/2); /* bitmask = 128; for (int i = 0; i<(long int)ulCount/2; i++) { (buf[writepont].bufpont)[i] = data[datapont]&bitmask? -1:0; bitmask /= 2; if (bitmask == 0) { bitmask = 128; datapont++; if (datapont >= 27648) datapont = 0; } }*/ buf[writepont++].bufstatus = Pronto; go.SetEvent(); // Sleep(0); // processa.SetEvent(); if (writepont >= 30) writepont = 0; if (iLoopCount%36 == 0) { start = finish; finish = GetTickCount(); m_Principal->total_time = max(finish - iniciou, 1); m_Principal->ratemedio = (double)m_Principal->totalgeral/max(finish - start, 1); m_Principal->totalgeral = 0; m_Principal->linelength = (LL - 2)/25 - 2; m_Principal->BufferReady.SetEvent(); } ++iLoopCount; if (Escreve && (iLoopCount >= iHalfBufsToRead)) aborta = TRUE; }

AfxMessageBox ("Aquisicao Terminada"); /* Clear the block operation. */ iStatus = DIG_Block_Clear(iDevice, iGroup); /* Clear DB mode for the device. */ iStatus = DIG_DB_Config(iDevice, iGroup, iDBModeOFF, iOldDataStop, iPartialTransfer); /* Unconfigure group. */ iStatus = DIG_Grp_Config(iDevice, iGroup, 0, 0, 0); return 1; } UINT AnalisaDados (LPVOID pParam) { int ipont = 0; struct Escrita *buf = (struct Escrita *) pParam; Trilha* trilhas[24]; int track; for (track=0; track<24; track++) trilhas[track] = new Trilha(track); while (!aborta) { processa.Lock(); while ((buf[ipont].bufstatus == Escrito)) { buf[ipont].bufstatus = Analisando; for (track=0; track<24; track++) { m_Principal->TrackSync[track] = trilhas[track]->Analisa(buf[ipont]); } LL = trilhas[0]->LineLength(); buf[ipont++].bufstatus = Livre; if (ipont>=30) ipont = 0; } } for (track=0; track<24; track++) delete trilhas[track]; return 1; } UINT EscreveDados (LPVOID pParam) { struct Escrita *buf = (struct Escrita *) pParam; int pont = 0; Trilha* trilhas[24]; int track; for (track=0; track<24; track++) trilhas[track] = new Trilha(track); unsigned long int BytesWritten; while (!aborta)

{ go.Lock(); while (buf[pont].bufstatus == Pronto) { buf[pont].bufstatus = Escrevendo; if (Escreve)WriteFile (buf[pont].Arquivo, buf[pont].bufpont, buf[pont].bufsize, &BytesWritten, NULL); // buf[pont].bufstatus = Escrito; // processa.SetEvent(); // Sleep(0); if (!Escreve) for (track=0; track<24; track++) { m_Principal->TrackSync[track] = trilhas[track]->Analisa(buf[pont]); } LL = trilhas[0]->LineLength(); buf[pont++].bufstatus = Livre; if (pont>=30) pont = 0; // pont++; // if (pont > 29) pont = 0; } } for (track=0; track<24; track++) delete trilhas[track]; return 1; } /* aqui voce coloca os leds */ UINT RecebeDados (LPVOID pParam) { AdquireMSS Aquisicao; Aquisicao.Processa((CAquisicaoMSSDlg*) pParam); return 1; } ////////////////////////////////////////////////////////////////////// // Construction/Destruction ////////////////////////////////////////////////////////////////////// AdquireMSS::AdquireMSS() { i32 lTimeout = 180; // 10 segundos i16 iGroupSize = 4; //32 bits i16 iPort = 0; i16 iDir = 0; //input i16 iSignal = 3; //burst mode i16 iEdge = 0; // not used for burst mode i16 iReqPol = 0; i16 iAckPol = 0; i16 iAckDelayTime = 7; //PCLK period of 700 ns (Aprox. 1.4 MHz) i16 iDBModeON = 1; /* CFile ArquivoDados; ArquivoDados.Open ("c:\\mss\\msspci.dat", CFile::modeRead ); ArquivoDados.Seek (10300, CFile::begin ); ArquivoDados.Read (data, sizeof(data));

ArquivoDados.Close(); datapont = 0;*/ /* This sets a timeout limit (#Sec * 18ticks/Sec) so that if there is something wrong, the program won't hang on the DIG_DB_Transfer call. */ iStatus = Timeout_Config(iDevice, lTimeout); if ((iRetVal = NIDAQErrorHandler(iStatus, "Timeout_Config", iIgnoreWarning)) == IDNO) return; /* Configure group of ports as input, with handshaking. */ iStatus = DIG_Grp_Config(iDevice, iGroup, iGroupSize, iPort, iDir); if ((iRetVal = NIDAQErrorHandler(iStatus, "DIG_Grp_Config", iIgnoreWarning)) == IDNO) return; /* Configure handshaking parameters for burst, active high request and 1.4 MHZ clock PCLK */ iStatus = DIG_Grp_Mode(iDevice, iGroup, iSignal, iEdge, iReqPol, iAckPol, iAckDelayTime); if ((iRetVal = NIDAQErrorHandler(iStatus, "DIG_Block_PG_Config", iIgnoreWarning)) == IDNO) return; /* Turn ON software double-buffered mode, with half-buffer overwrite protection (iOldDataStop). */ iStatus = DIG_DB_Config(iDevice, iGroup, iDBModeON, iOldDataStop, iPartialTransfer); if ((iRetVal = NIDAQErrorHandler(iStatus, "DIG_DB_Config", iIgnoreWarning)) == IDNO) return; } AdquireMSS::~AdquireMSS() { } void AdquireMSS::Processa(CAquisicaoMSSDlg* Principal) { /* * Local Variable Declarations: */ m_Principal = Principal;

static i16 piBuffer[65536] = {0}; // i16 iHalfReady; u32 ulPtsTfr = 32768; CFileDialog PerguntaArquivo (FALSE, "dat","Msspci.dat",OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, "Arquivos de dados (*.dat)|*.dat|Todos os Arquivos (*.*)|*.*||"); if (PerguntaArquivo.DoModal() == IDOK) { ArquivoSaida = CreateFile (PerguntaArquivo.GetPathName( ), GENERIC_WRITE, 0, NULL, OPEN_ALWAYS, FILE_FLAG_NO_BUFFERING, NULL); if (ArquivoSaida == INVALID_HANDLE_VALUE) { AfxMessageBox ("Erro na abertura"); return; } Escreve = TRUE; } for (int i=0; i<30; i++) { WriteThread[i].bufstatus = Livre; WriteThread[i].Arquivo = ArquivoSaida; WriteThread[i].bufpont = (long int *)VirtualAlloc (NULL, ulCount*2, MEM_COMMIT, PAGE_READWRITE); if (WriteThread[i].bufpont == NULL) { AfxMessageBox ("Erro na alocacao dos buffers"); return; } WriteThread[i].bufsize = ulCount*2; } /* Start the double-buffered pattern generation input. The 'piBuffer' here is the circular acquisition buffer. NOTE: any warnings are ignored. */ AfxMessageBox( "Clique OK quando estiver pronto"); iStatus = DIG_Block_In(iDevice, iGroup, piBuffer, ulCount); if ((iRetVal = NIDAQErrorHandler(iStatus, "DIG_Block_In", iIgnoreWarning))== IDNO) return; iStatus = 0; CWinThread* T2 = AfxBeginThread (AdquireDados, WriteThread, THREAD_PRIORITY_HIGHEST); // CWinThread* T0 = AfxBeginThread (EscreveDados, WriteThread, THREAD_PRIORITY_HIGHEST); CWinThread* T0 = AfxBeginThread (EscreveDados, WriteThread, THREAD_PRIORITY_ABOVE_NORMAL); CWinThread* T1 = AfxBeginThread (AnalisaDados, WriteThread, THREAD_PRIORITY_HIGHEST);

aborta = FALSE; go.ResetEvent(); finish = GetTickCount(); iniciou = finish; start = finish; bufcount = 0; writepont = 0; return; } void TerminaAquisicao() { if (iStatus == 0) { AfxMessageBox(" Aquisicao de dados MSS terminada com sucesso"); } else AfxMessageBox(" Aquisicao interrompida em virtude de erro"); int tries; CloseHandle (ArquivoSaida); for (i=0; i<30; i++) { // free(WriteThread[i].bufpont); tries = 0; while (WriteThread[i].bufstatus != Livre && tries < 100) { go.SetEvent(); processa.SetEvent(); Sleep(5); tries ++; } VirtualFree (WriteThread[i].bufpont, 0, MEM_RELEASE); } /* Disable timeouts. */ //** iStatus = Timeout_Config(iDevice, -1); aborta = TRUE; }

II // AquisicaoMSS.cpp : Defines the class behaviors for the application. // #include "stdafx.h" #include "AquisicaoMSS.h" #include "AquisicaoMSSDlg.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif ///////////////////////////////////////////////////////////////////////////// // CAquisicaoMSSApp BEGIN_MESSAGE_MAP(CAquisicaoMSSApp, CWinApp) //{{AFX_MSG_MAP(CAquisicaoMSSApp) // NOTE - the ClassWizard will add and remove mapping macros here. // DO NOT EDIT what you see in these blocks of generated code! //}}AFX_MSG ON_COMMAND(ID_HELP, CWinApp::OnHelp) END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CAquisicaoMSSApp construction CAquisicaoMSSApp::CAquisicaoMSSApp() { // TODO: add construction code here, // Place all significant initialization in InitInstance } ///////////////////////////////////////////////////////////////////////////// // The one and only CAquisicaoMSSApp object CAquisicaoMSSApp theApp; ///////////////////////////////////////////////////////////////////////////// // CAquisicaoMSSApp initialization BOOL CAquisicaoMSSApp::InitInstance() { // Standard initialization // If you are not using these features and wish to reduce the size // of your final executable, you should remove from the following // the specific initialization routines you do not need. #ifdef _AFXDLL

Enable3dControls(); // Call this when using MFC in a shared DLL #else Enable3dControlsStatic(); // Call this when linking to MFC statically #endif CAquisicaoMSSDlg dlg; m_pMainWnd = &dlg; int nResponse = dlg.DoModal(); if (nResponse == IDOK) { // TODO: Place code here to handle when the dialog is // dismissed with OK } else if (nResponse == IDCANCEL) { // TODO: Place code here to handle when the dialog is // dismissed with Cancel } // Since the dialog has been closed, return FALSE so that we exit the // application, rather than start the application's message pump. return FALSE; }

III // AquisicaoMSSDlg.cpp : implementation file // #include "stdafx.h" #include "AquisicaoMSS.h" #include "AquisicaoMSSDlg.h" #include "AdquireMSS.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif ///////////////////////////////////////////////////////////////////////////// // CAboutDlg dialog used for App About UINT MostraProgresso (LPVOID pParam) { CAquisicaoMSSDlg* Principal = (CAquisicaoMSSDlg*) pParam; int saveLL; char strrate [10]; int itrack; long int inicio, ratecount; int segundo; // int SaveSync[24]; BOOL SaveSync[24];//mod CWnd* JanelaTaxa = Principal->GetDlgItem(IDC_TAXA); CWnd* JanelaDia = Principal->GetDlgItem(IDC_TCDIA); CWnd* JanelaHora = Principal->GetDlgItem(IDC_TCHORA); CWnd* JanelaMinuto = Principal->GetDlgItem(IDC_TCMINUTO); CWnd* JanelaSegundo = Principal->GetDlgItem(IDC_TCSEGUNDO); CWnd* JanelaLineLength = Principal->GetDlgItem(IDC_LINELENGTH); CStatic *Sync[24]; Sync[0] = (CStatic*)Principal->GetDlgItem(IDC_Sync3A); //Trilha 2 Sync[1] = (CStatic*)Principal->GetDlgItem(IDC_Sync1A); //Trilha 3 Sync[2] = (CStatic*)Principal->GetDlgItem(IDC_Sync3B); //Trilha 4 Sync[3] = (CStatic*)Principal->GetDlgItem(IDC_Sync1B); //Trilha 5 Sync[4] = (CStatic*)Principal->GetDlgItem(IDC_Sync3C); //Trilha 6 Sync[5] = (CStatic*)Principal->GetDlgItem(IDC_Sync1C); //Trilha 7 Sync[6] = (CStatic*)Principal->GetDlgItem(IDC_Sync3D); //Trilha 8 Sync[7] = (CStatic*)Principal->GetDlgItem(IDC_Sync1D); //Trilha 9 Sync[8] = (CStatic*)Principal->GetDlgItem(IDC_Sync3E); //Trilha 10 Sync[9] = (CStatic*)Principal->GetDlgItem(IDC_Sync1E); //Trilha 11

Sync[10] = (CStatic*)Principal->GetDlgItem(IDC_Sync3F); //Trilha 12 Sync[11] = (CStatic*)Principal->GetDlgItem(IDC_Sync1F); //Trilha 13 Sync[12] = (CStatic*)Principal->GetDlgItem(IDC_Sync4A); //Trilha 14 Sync[13] = (CStatic*)Principal->GetDlgItem(IDC_Sync2A); //Trilha 15 Sync[14] = (CStatic*)Principal->GetDlgItem(IDC_Sync4B); //Trilha 16 Sync[15] = (CStatic*)Principal->GetDlgItem(IDC_Sync2B); //Trilha 17 Sync[16] = (CStatic*)Principal->GetDlgItem(IDC_Sync4C); //Trilha 18 Sync[17] = (CStatic*)Principal->GetDlgItem(IDC_Sync2C); //Trilha 19 Sync[18] = (CStatic*)Principal->GetDlgItem(IDC_Sync4D); //Trilha 20 Sync[19] = (CStatic*)Principal->GetDlgItem(IDC_Sync2D); //Trilha 21 Sync[20] = (CStatic*)Principal->GetDlgItem(IDC_Sync4E); //Trilha 22 Sync[21] = (CStatic*)Principal->GetDlgItem(IDC_Sync2E); //Trilha 23 Sync[22] = (CStatic*)Principal->GetDlgItem(IDC_Sync4F); //Trilha 24 Sync[23] = (CStatic*)Principal->GetDlgItem(IDC_Sync2F); //Trilha 25 // CBitmap InSync[3]; // InSync[0].LoadBitmap(IDB_BITMAP1); // InSync[1].LoadBitmap(IDB_BITMAP2); // InSync[2].LoadBitmap (IDB_BITMAP3); CBitmap InSync, OutSync;//mod InSync.LoadBitmap(IDB_BITMAP2);//mod OutSync.LoadBitmap(IDB_BITMAP1);//mod for (itrack=0; itrack<24; itrack++) { // Principal->TrackSync[itrack] = 0; // SaveSync[itrack] = 0; // Sync[itrack]->SetBitmap (InSync[Principal->TrackSync[itrack]]); Principal->TrackSync[itrack] = FALSE;//mod SaveSync[itrack] = FALSE;//mod Sync[itrack]->SetBitmap (Principal->TrackSync[itrack]? InSync:OutSync);//mod } char str[10]; if (Principal->aborta) return 0; JanelaDia->SetWindowText("***"); JanelaTaxa->SetWindowText("*****"); JanelaHora->SetWindowText("**"); JanelaMinuto->SetWindowText("**"); JanelaSegundo->SetWindowText("*****"); JanelaLineLength->SetWindowText("****"); inicio = 0;

segundo = 0; ratecount = 0; Principal->ratemedio = 0.; Principal->totalgeral = 0; Principal->linelength = 0; saveLL = Principal->linelength; while (!Principal->aborta) { Principal->BufferReady.Lock(); if (inicio == 0) { inicio = GetTickCount(); } for (itrack=0; itrack<24; itrack++) { if (Principal->TrackSync[itrack] != SaveSync[itrack]) { SaveSync[itrack] = Principal->TrackSync[itrack]; // Sync[itrack]->SetBitmap (InSync[Principal->TrackSync[itrack]]); Sync[itrack]->SetBitmap (Principal->TrackSync[itrack]? InSync:OutSync);//mod } } if (Principal->linelength != saveLL) { sprintf (str, "%8i", Principal->linelength); saveLL = Principal->linelength; JanelaLineLength->SetWindowText(str); } // Principal->ratemedio = (double)Principal->totalgeral/total_time; // sprintf (strrate, "%6.1f", Principal->ratemedio); // JanelaTaxa->SetWindowText(strrate); if (segundo != (Principal->total_time/1000)) { segundo = Principal->total_time/1000; sprintf (str, "%8i",segundo); JanelaSegundo->SetWindowText(str); } sprintf (strrate, "%6.1f", Principal->ratemedio); JanelaTaxa->SetWindowText(strrate); } return 1; } class CAboutDlg : public CDialog { public: CAboutDlg(); // Dialog Data

//{{AFX_DATA(CAboutDlg) enum { IDD = IDD_ABOUTBOX }; //}}AFX_DATA // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CAboutDlg) protected: virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support //}}AFX_VIRTUAL // Implementation protected: //{{AFX_MSG(CAboutDlg) //}}AFX_MSG DECLARE_MESSAGE_MAP() }; CAboutDlg::CAboutDlg() : CDialog(CAboutDlg::IDD) { //{{AFX_DATA_INIT(CAboutDlg) //}}AFX_DATA_INIT } void CAboutDlg::DoDataExchange(CDataExchange* pDX) { CDialog::DoDataExchange(pDX); //{{AFX_DATA_MAP(CAboutDlg) //}}AFX_DATA_MAP } BEGIN_MESSAGE_MAP(CAboutDlg, CDialog) //{{AFX_MSG_MAP(CAboutDlg) // No message handlers //}}AFX_MSG_MAP END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CAquisicaoMSSDlg dialog CAquisicaoMSSDlg::CAquisicaoMSSDlg(CWnd* pParent /*=NULL*/) : CDialog(CAquisicaoMSSDlg::IDD, pParent) { //{{AFX_DATA_INIT(CAquisicaoMSSDlg) // NOTE: the ClassWizard will add member initialization here //}}AFX_DATA_INIT // Note that LoadIcon does not require a subsequent DestroyIcon in Win32 m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME); aborta = FALSE; } void CAquisicaoMSSDlg::DoDataExchange(CDataExchange* pDX) { CDialog::DoDataExchange(pDX); //{{AFX_DATA_MAP(CAquisicaoMSSDlg)

// NOTE: the ClassWizard will add DDX and DDV calls here //}}AFX_DATA_MAP } BEGIN_MESSAGE_MAP(CAquisicaoMSSDlg, CDialog) //{{AFX_MSG_MAP(CAquisicaoMSSDlg) ON_WM_SYSCOMMAND() ON_WM_PAINT() ON_WM_QUERYDRAGICON() //}}AFX_MSG_MAP END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CAquisicaoMSSDlg message handlers BOOL CAquisicaoMSSDlg::OnInitDialog() { CDialog::OnInitDialog(); // Add "About..." menu item to system menu. // IDM_ABOUTBOX must be in the system command range. ASSERT((IDM_ABOUTBOX & 0xFFF0) == IDM_ABOUTBOX); ASSERT(IDM_ABOUTBOX < 0xF000); CMenu* pSysMenu = GetSystemMenu(FALSE); if (pSysMenu != NULL) { CString strAboutMenu; strAboutMenu.LoadString(IDS_ABOUTBOX); if (!strAboutMenu.IsEmpty()) { pSysMenu->AppendMenu(MF_SEPARATOR); pSysMenu->AppendMenu(MF_STRING, IDM_ABOUTBOX, strAboutMenu); } } // Set the icon for this dialog. The framework does this automatically // when the application's main window is not a dialog SetIcon(m_hIcon, TRUE); // Set big icon SetIcon(m_hIcon, FALSE); // Set small icon // TODO: Add extra initialization here return TRUE; // return TRUE unless you set the focus to a control } void CAquisicaoMSSDlg::OnSysCommand(UINT nID, LPARAM lParam) { if ((nID & 0xFFF0) == IDM_ABOUTBOX) { CAboutDlg dlgAbout; dlgAbout.DoModal(); }

else { CDialog::OnSysCommand(nID, lParam); } } // If you add a minimize button to your dialog, you will need the code below // to draw the icon. For MFC applications using the document/view model, // this is automatically done for you by the framework. void CAquisicaoMSSDlg::OnPaint() { if (IsIconic()) { CPaintDC dc(this); // device context for painting SendMessage(WM_ICONERASEBKGND, (WPARAM) dc.GetSafeHdc(), 0); // Center icon in client rectangle int cxIcon = GetSystemMetrics(SM_CXICON); int cyIcon = GetSystemMetrics(SM_CYICON); CRect rect; GetClientRect(&rect); int x = (rect.Width() - cxIcon + 1) / 2; int y = (rect.Height() - cyIcon + 1) / 2; // Draw the icon dc.DrawIcon(x, y, m_hIcon); } else { CDialog::OnPaint(); } } // The system calls this to obtain the cursor to display while the user drags // the minimized window. HCURSOR CAquisicaoMSSDlg::OnQueryDragIcon() { return (HCURSOR) m_hIcon; } void CAquisicaoMSSDlg::OnOK() { // ::SetPriorityClass(::GetCurrentProcess(), REALTIME_PRIORITY_CLASS); BufferReady.ResetEvent(); // AfxGetApp()->SetThreadPriority (THREAD_PRIORITY_TIME_CRITICAL); CWinThread* pShowThread = AfxBeginThread (MostraProgresso, this, THREAD_PRIORITY_TIME_CRITICAL); AdquireMSS Aquisicao; Aquisicao.Processa(this); // CWinThread* pThread = AfxBeginThread (RecebeDados, this, THREAD_PRIORITY_TIME_CRITICAL);

// CDialog::OnOK(); } void CAquisicaoMSSDlg::OnCancel() { char strrate[10]; aborta = TRUE; BufferReady.SetEvent(); sprintf (strrate, "%6.1f", ratemedio); AfxMessageBox(CString("Taxa media = ")+strrate); // JanelaTaxaMinima->SetWindowText(strrate); CDialog::OnCancel(); }

IV // stdafx.cpp : source file that includes just the standard includes // AquisicaoMSS.pch will be the pre-compiled header // stdafx.obj will contain the pre-compiled type information #include "stdafx.h"

V // Trilha.cpp: implementation of the Trilha class. // ////////////////////////////////////////////////////////////////////// #include "stdafx.h" #include "AquisicaoMSS.h" #include "Trilha.h" #ifdef _DEBUG #undef THIS_FILE static char THIS_FILE[]=__FILE__; #define new DEBUG_NEW #endif ////////////////////////////////////////////////////////////////////// // Construction/Destruction ////////////////////////////////////////////////////////////////////// Trilha::Trilha(int track) { bitpont = 0; bitcount = 0; bitpos = 0; bitinicio = 0; bitmask = 1<<track; estado = search; data = 0; pont = NULL; size = 0; insync = 0; EndOfBuffer = FALSE; } Trilha::~Trilha() { } int Trilha::getbits (int numero) { if (bitpos == 0) data = 0;

while (bitpos < numero) { if (bitpont >= (long int)(size/sizeof(long int))) { bitpont -= size/sizeof(long int); EndOfBuffer = TRUE; return FALSE; } data = data << 1; data |= (pont[bitpont++]&bitmask)? 1:0; bitpos++; } bitcount += numero; bitpos = 0; return TRUE; } int Trilha::getbits (int numero, long int &result) { if (!getbits (numero)) return FALSE; result = data; return TRUE; } int Trilha::getbitsinv (int numero, long int &result) { if (!getbits (numero)) return FALSE; long int temp = data; result = data & 1; for (int ibits = 1; ibits<numero; ibits ++) { temp = temp >> 1; result = (result<<1) | (temp & 1); } return TRUE; } int Trilha::pulabits (int numero) { bitpont += numero; bitcount += numero; return TRUE; } BOOL Trilha::Analisa (struct Escrita pParam) { pont = pParam.bufpont; size = pParam.bufsize; EndOfBuffer = FALSE; while (!EndOfBuffer) { switch (estado) { case search: // insync = 0; bitspreambulo = 0; if (!getbits (4)) break; if (data == 0x0A) estado = preambulo;

else if (data == 0x05) { case search5: if (!getbits (1)) { estado = search5; break; } if (data == 0) estado = preambulo; } else { if ((bitcount - bitinicio)> 45000) insync = 0; pulabits (1000); } break; case preambulo: if (!getbits(4)) break; if (data == 0x0A) { // insync = 2; bitspreambulo += 4; break; } if (bitspreambulo > 100) if (data == 0x0F) { case preambuloF: if (!getbits(3)) { estado = preambuloF; break; } if (data == 1) estado = sync; else { estado = search; bitspreambulo = 0; } } else if (data == 0x0E) { case preambuloE: if (!getbits(2)) { estado = preambuloE; break; } if (data == 1) estado = sync; else { estado = search; bitspreambulo = 0; } } else if (data == 0x0B) {

case preambuloB: if (!getbits(4)) { estado = preambuloB; break; } if (data == 9) estado = sync; else if (data = 0x0C) { case preambuloBC: if (!getbits(1)) { estado = preambuloBC; break; } if (data == 1) estado = sync; else { estado = search; bitspreambulo = 0; } } } else //(data!=F) && (data!=E) && (data!= B) { estado = search; bitspreambulo = 0; } else //bitspreambulo <= 100 { estado = search; bitspreambulo = 0; } break; case sync: // bitssweep = bitcount - bitinicio; // if (bitssweep > 44200 && bitssweep < 44260) insync = 1; // else insync = 0; insync = 1; bitinicio = bitcount; case TC: if (!getbits(12, timecode)) { estado = TC; break; } pulabits (3771*6); case LL: if (!getbitsinv(18, linelength)) { estado = LL; break; } pulabits (1800*6); estado = search; } }

return insync; }

Header files

I // AdquireMSS.h: interface for the AdquireMSS class. // ////////////////////////////////////////////////////////////////////// #if !defined(AFX_ADQUIREMSS_H__8C50D6CE_C720_11D2_8C0E_0080C87585B0__INCLUDED_) #define AFX_ADQUIREMSS_H__8C50D6CE_C720_11D2_8C0E_0080C87585B0__INCLUDED_ #if _MSC_VER >= 1000 #pragma once #endif // _MSC_VER >= 1000 #include "AquisicaoMSSDlg.h" UINT RecebeDados (LPVOID pParam); class AdquireMSS { public: void Processa (CAquisicaoMSSDlg*); AdquireMSS(); TerminaAquisicao(); virtual ~AdquireMSS(); protected: }; #endif // !defined(AFX_ADQUIREMSS_H__8C50D6CE_C720_11D2_8C0E_0080C87585B0__INCLUDED_) II // AquisicaoMSS.h : main header file for the AQUISICAOMSS application // #if !defined(AFX_AQUISICAOMSS_H__8C50D6C4_C720_11D2_8C0E_0080C87585B0__INCLUDED_) #define AFX_AQUISICAOMSS_H__8C50D6C4_C720_11D2_8C0E_0080C87585B0__INCLUDED_ #if _MSC_VER >= 1000 #pragma once #endif // _MSC_VER >= 1000

#ifndef __AFXWIN_H__ #error include 'stdafx.h' before including this file for PCH #endif #include "resource.h" // main symbols ///////////////////////////////////////////////////////////////////////////// // CAquisicaoMSSApp: // See AquisicaoMSS.cpp for the implementation of this class // class CAquisicaoMSSApp : public CWinApp { public: CAquisicaoMSSApp(); // Overrides // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CAquisicaoMSSApp) public: virtual BOOL InitInstance(); //}}AFX_VIRTUAL // Implementation //{{AFX_MSG(CAquisicaoMSSApp) // NOTE - the ClassWizard will add and remove member functions here. // DO NOT EDIT what you see in these blocks of generated code ! //}}AFX_MSG DECLARE_MESSAGE_MAP() }; ///////////////////////////////////////////////////////////////////////////// //{{AFX_INSERT_LOCATION}} // Microsoft Developer Studio will insert additional declarations immediately before the previous line. #endif // !defined(AFX_AQUISICAOMSS_H__8C50D6C4_C720_11D2_8C0E_0080C87585B0__INCLUDED_)

III // AquisicaoMSSDlg.h : header file //

#if !defined(AFX_AQUISICAOMSSDLG_H__8C50D6C6_C720_11D2_8C0E_0080C87585B0__INCLUDED_) #define AFX_AQUISICAOMSSDLG_H__8C50D6C6_C720_11D2_8C0E_0080C87585B0__INCLUDED_ #if _MSC_VER >= 1000 #pragma once #endif // _MSC_VER >= 1000 #include <afxmt.h> ///////////////////////////////////////////////////////////////////////////// // CAquisicaoMSSDlg dialog class CAquisicaoMSSDlg : public CDialog { // Construction public: void OnOK(); void OnCancel(); BOOL aborta; double ratemedio; long int total_time; long int totalgeral; int linelength; CEvent BufferReady; int TrackSync[24]; CAquisicaoMSSDlg(CWnd* pParent = NULL); // standard constructor // Dialog Data //{{AFX_DATA(CAquisicaoMSSDlg) enum { IDD = IDD_AQUISICAOMSS_DIALOG }; // NOTE: the ClassWizard will add data members here //}}AFX_DATA // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CAquisicaoMSSDlg) protected: virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support //}}AFX_VIRTUAL // Implementation protected: HICON m_hIcon; // Generated message map functions //{{AFX_MSG(CAquisicaoMSSDlg) virtual BOOL OnInitDialog(); afx_msg void OnSysCommand(UINT nID, LPARAM lParam); afx_msg void OnPaint(); afx_msg HCURSOR OnQueryDragIcon(); //}}AFX_MSG DECLARE_MESSAGE_MAP() }; //{{AFX_INSERT_LOCATION}}

// Microsoft Developer Studio will insert additional declarations immediately before the previous line. #endif // !defined(AFX_AQUISICAOMSSDLG_H__8C50D6C6_C720_11D2_8C0E_0080C87585B0__INCLUDED_) IV //{{NO_DEPENDENCIES}} // Microsoft Developer Studio generated include file. // Used by AquisicaoMSS.rc // #define IDABOUT 11 #define IDM_ABOUTBOX 0x0010 #define IDD_ABOUTBOX 100 #define IDD_DIALOGBOX 101 #define IDS_ABOUTBOX 101 #define IDC_ICONDIALOGAPP 102 #define IDD_AQUISICAOMSS_DIALOG 102 #define IDR_MAINFRAME 128 #define IDB_BITMAP1 129 #define IDB_BITMAP2 130 #define IDB_BITMAP3 131 #define IDC_TAXA 1000 #define IDC_TAXAMIN 1001 #define IDC_TCDIA 1002 #define IDC_TCHORA 1003 #define IDC_TCMINUTO 1004 #define IDC_TCSEGUNDO 1005 #define IDC_Sync1A 1006 #define IDC_Sync2A 1007 #define IDC_Sync3A 1008 #define IDC_Sync4A 1009 #define IDC_Sync1B 1010 #define IDC_Sync2B 1011 #define IDC_Sync3B 1012 #define IDC_Sync4B 1013 #define IDC_Sync1C 1014 #define IDC_Sync2C 1015 #define IDC_Sync3C 1016 #define IDC_Sync4C 1017 #define IDC_Sync1D 1018 #define IDC_Sync2D 1019 #define IDC_Sync3D 1020 #define IDC_Sync4D 1021 #define IDC_Sync1E 1022 #define IDC_Sync2E 1023 #define IDC_Sync3E 1024 #define IDC_Sync4E 1025 #define IDC_Sync1F 1026 #define IDC_Sync2F 1027 #define IDC_Sync3F 1028 #define IDC_Sync4F 1029 #define IDC_TAXAMAX 1030

#define IDC_LINELENGTH 1032 // Next default values for new objects // #ifdef APSTUDIO_INVOKED #ifndef APSTUDIO_READONLY_SYMBOLS #define _APS_NEXT_RESOURCE_VALUE 131 #define _APS_NEXT_COMMAND_VALUE 32771 #define _APS_NEXT_CONTROL_VALUE 1033 #define _APS_NEXT_SYMED_VALUE 101 #endif #endif

V // stdafx.h : include file for standard system include files, // or project specific include files that are used frequently, but // are changed infrequently // #if !defined(AFX_STDAFX_H__8C50D6C8_C720_11D2_8C0E_0080C87585B0__INCLUDED_) #define AFX_STDAFX_H__8C50D6C8_C720_11D2_8C0E_0080C87585B0__INCLUDED_ #if _MSC_VER >= 1000 #pragma once #endif // _MSC_VER >= 1000 #define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers #include <afxwin.h> // MFC core and standard components #include <afxext.h> // MFC extensions #ifndef _AFX_NO_AFXCMN_SUPPORT #include <afxcmn.h> // MFC support for Windows Common Controls #endif // _AFX_NO_AFXCMN_SUPPORT //{{AFX_INSERT_LOCATION}} // Microsoft Developer Studio will insert additional declarations immediately before the previous line. #endif // !defined(AFX_STDAFX_H__8C50D6C8_C720_11D2_8C0E_0080C87585B0__INCLUDED_)

VI // Trilha.h: interface for the Trilha class. // //////////////////////////////////////////////////////////////////////

#if !defined(AFX_TRILHA_H__3E51D801_DD7C_11D2_BE58_444553540001__INCLUDED_) #define AFX_TRILHA_H__3E51D801_DD7C_11D2_BE58_444553540001__INCLUDED_ #if _MSC_VER >= 1000 #pragma once #endif // _MSC_VER >= 1000 struct Escrita { HANDLE Arquivo; long int *bufpont; long int bufsize; int bufstatus; }; class Trilha { public: Trilha(int Track); getbits (int numero); getbits (int numero, long int &data); getbitsinv (int numero, long int &data); pulabits (int numero); Analisa (struct Escrita pParam); int LineLength() {return linelength; } virtual ~Trilha(); protected: enum {search, search5, preambulo, preambuloF, preambuloE, preambuloB, preambuloBC, sync, TC, LL}; long int bitpont; int bitpos; long int bitcount; long int bitinicio; long int bitmask; long int timecode; struct Escrita *buf; int estado; long int bitspreambulo, data, linelength; long int *pont; long int size; int insync, bitssweep; BOOL EndOfBuffer; }; #endif // !defined(AFX_TRILHA_H__3E51D801_DD7C_11D2_BE58_444553540001__INCLUDED_)