Ficheiros de Dados das Estimativas do Sinal

O bloco produzido pelos ficheiros howto_co_cx_stat.cc/.h inclui ainda o código necessário para a criação e escrita de ficheiros de dados binários. Os novos ficheiros de dados terão a particularidade de poderem ser carregados de imediato no Matlab e assim serem analisados directamente.

Um ficheiro binário Matlab (.mat) é constituído por um cabeçalho e pelos dados que se pretendem armazenar. Actualmente existem várias versões de ficheiros MAT que foram sendo modificadas à medida que o Matlab sofreu actualizações. Apesar de serem necessárias bibliotecas próprias para a criação destes ficheiros existe a possibilidade de gerar ficheiros MAT de mais baixo nível utilizando, por exemplo, a linguagem C ou C++ [51]. O Matlab apresenta suporte para as versões mais antigas pelo que não haverá problemas com os ficheiros criados desta forma.

O primeiro passo será a escrita do cabeçalho. Este cabeçalho terá diversas opções que deverão ser escritas numa determinada ordem e deverão corresponder exactamente aos conteúdos do ficheiro. Caso isto não aconteça o ficheiro será ilegível. A estrutura do cabeçalho será a seguinte:

typedef struct { long type; long mrows; long ncols; long imagf; long namelen; } MATLAB_MATRIX_HEADER;

O parâmetro “type” irá conter diversas informações. Este poderá ser escrito na forma de um número inteiro com 4 dígitos segundo o formato MOPT, em que cada letra representa um dígito. O número que será escrito no nosso caso em particular será 0000. O dígito relativo ao M diz respeito à arquitectura utilizada pela máquina. O valor 0 irá corresponder a IEEE Little Endian. O O será sempre 0, este é um algarismo reservado para futuras opções. O P será o formato em que os dados serão armazenados e será 0 porque iremos escrever floats com precisão dupla (64-bit). Por último o T, também de valor 0, irá definir o tipo de matriz que será totalmente numérica. Cada valor escrito irá ocupar 8 bytes com esta configuração. Nos tempos que correm os discos rígidos têm grandes dimensões e baixo custo pelo que o tamanho de 8 bytes não deverá causar problemas apesar do elevado volume de dados.

Os parâmetros seguintes definem, pela ordem que são apresentados, o número linhas e o número de colunas da matriz de dados, a flag assinalando números complexos e o tamanho do nome da matriz. A nossa matriz terá sempre 9 linhas e o número de colunas será actualizado automaticamente à medida que sejam escritos novos dados. Só serão armazenados valores reais pelo que a flag relativa à existência de parte imaginária deverá estar a 0.

A escrita no ficheiro binário terá de ser realizada pela seguinte ordem: escrever cabeçalho; escrever nome da matriz; escrever dados. Isto resultará num ficheiro MAT suportado pelo Matlab.

Resta agora saber o que efectivamente será escrito nos ficheiros e para tal olhemos para a Tabela 5.1. Nesta tabela está feita uma representação da estrutura da matriz de um ficheiro de dados bem como o seu conteúdo. À medida que novos valores são escritos no ficheiro novas colunas serão adicionadas. O conteúdo de cada coluna é óbvio excepto o das duas últimas linhas: “NCO Update Flag” e “Timestamp”.

O “NCO Update Flag” é um campo para verificar o processo de sintonia. Cada vez que o NCO é reprogramado este parâmetro é colocado a 1 e desta forma podemos ver com facilidade quando houve um ajuste de frequência.

Tabela 5.1: Estrutura dos dados nos ficheiros binários.

Sample Next Sample

CO Amplitude (dBm) CO Amplitude (dBm) CX Amplitude (dBm) CX Amplitude (dBm)

Phase (degree) Phase (degree) CNR (dB) CNR (dB) Frequency (Hz) Frequency (Hz)

Variance (dB2) Variance (dB2) NSD (dB/Hz) NSD (dB/Hz) NCO Update Flag NCO Update Flag

Timestamp (s) Timestamp (s)

O outro campo desconhecido, o “Timestamp”, foi adicionado para ter uma referência temporal das estimativas. Uma vez que estamos a armazenar dados em binário o “Timestamp” utilizado será o tempo em segundos em formato do UNIX aquando a escrita

74

de uma nova coluna. É possível transformar o valor deste campo numa data completa no Matlab utilizando os seguintes passos:

1. Determinar o tempo no formato Excel (Windows): ExcelTime = UNIXTime/86400 +

25569, em que 86400 corresponde ao número de segundos de um dia e 25569 o número de dias entre 1970 e 1900 (diferença de anos das referências temporais do Windows e do UNIX);

2. Converter o formato de data Excel para o formato de data numérico do Matlab com o comando x2mdate;

3. Tornar o número representativo da data do Matlab numa string legível com a função datestr.

Uma última nota é a forma como o número de colunas é actualizado. Uma vez que o cabeçalho é escrito de uma só vez este terá de voltar a ser escrito com o novo número de colunas uma e outra vez até à criação de um novo ficheiro ou interrupção do programa. No caso de interrupção forçada surgiu a dúvida de que poderia haver uma corrupção do ficheiro se o número de colunas fosse incrementado e esta não fosse escrita na sua totalidade. Isto de facto acontece. Para solucionar este problema o número de colunas só é incrementado após a escrita de todos os valores da coluna. Desta forma, em caso de interrupção forçada, a coluna incompleta, apesar de ser escrita, não é mostrada na leitura do ficheiro e já não ocorre a corrupção do mesmo.

Igualmente parecem redundantes algumas das variáveis armazenadas. É sempre preferível armazenar toda a informação que descreve o funcionamento interno para, em caso de necessidade, diagnosticar anomalias.

5.2.4.3 Funcionamento

O funcionamento do processo de aquisição pode ser explicado com a descrição da classe “acquire”.

O primeiro passo será, tal como no processo de tuning, o carregamento das variáveis a partir do ficheiro de configuração e a inicialização de outras que sejam necessárias. De seguida são criados os directórios, caso não existam, para o armazenamento dos ficheiros de dados com auxílio do módulo TREEGENmodule.py. Feito isto é iniciado o flow graph do processo com a frequência central determinada no processo de tuning.

O procedimento seguinte será a aquisição dos dados. Nos blocos de análise estatística serão calculadas as estimativas do sinal que posteriormente serão escritas de forma contínua em ficheiros .mat.

Com as amostras da aquisição dos dados será avaliado o sinal recebido. Ao contrário do processo de tuning agora são feitas estimativas com algoritmos próprios, pelo que o limite aceitável para efectuar o seguimento irá ser dado pela CNR. O valor da CNR, determinado pela média das últimas 3 estimativas instantâneas, irá ser comparado ao valor de CNR mínimo. Caso esteja abaixo deste valor não é efectuado qualquer ajuste de frequência mas o sistema prossegue com a escrita dos ficheiros e actualização da GUI. Neste caso o processo fica a aguardar melhores condições e enviará um aviso via correio

electrónico ao utilizador para o alertar do caso de baixa CNR. Se pelo contrário a CNR tiver um valor acima do limite procede-se à análise e ajuste de frequência.

O ajuste de frequência irá permitir fazer o seguimento à custa da frequência do NCO. É sabido que a frequência do sinal irá ter variações diárias não superiores a 5 kHz. Um ajuste de frequência fino com a reprogramação do NCO evitará que o sinal caia fora da largura de banda do filtro FIR de decimação devido ao deslizamento de frequência. Este ajuste de fino irá ser realizado quando existirem variações significativas (±5 Hz por defeito) da última frequência estimada. Além da variação de frequência diária, com o decorrer do tempo, os desvios de frequência do beacon e dos osciladores locais do receptor poderão causar um desvio acumulado sistemático de alguns kHz por ano. Isto poderá implicar a necessidade de um ajuste esporádico no oscilador local para impedir que o sinal fique além da frequência de corte do filtro da IF2 de 10.7 MHz (±7.5 kHz) no

frontend analógico. Assim, se a frequência estimada estiver acima ou abaixo 3 kHz dos 10.7MHz da frequência central do filtro a cristal, irá ser feita a reprogramação do sintetizador ±5 kHz (channel spacing do sintetizador de frequências), dependendo do sentido do desvio, e feito um ajuste no NCO de ± 2kHz para compensar o offset introduzido. Estima-se que 3 kHz será um valor aceitável para se proceder à reconfiguração do frontend. Após ser realizado qualquer ajuste de frequência no NCO a nova frequência central será configurada nos blocos de estimativas e buffers de dados.

A sequência aquisição, avaliação e seguimento irá ser realizada de forma continuada até o programa ser interrompido. A avaliação e o seguimento irão repetir-se sequencialmente a cada 2 segundos. A cada actualização as novas estimativas irão ser passadas à GUI com recurso às funções do módulo events.py e posteriormente serão actualizados os elementos da interface.

Os ficheiros de dados para as duas FFT’s irão ser fechados a cada 6 horas e ao final de cada dia independentemente de não terem sido concluídas as 6 horas de aquisição num ficheiro. Também ao final do dia, se a opção estiver activa, irá ser feita uma cópia de segurança dos dados para uma pasta de partilha Dropbox