Mudanças entre as edições de "Projeto de Estimador de Estado de Enlace - Semestre 2"

De MediaWiki do Campus São José
Ir para navegação Ir para pesquisar
Linha 14: Linha 14:
 
[[Progresso da bolsa - 2018/2]]
 
[[Progresso da bolsa - 2018/2]]
  
−
=Base de conhecimento=
+
[[Base de conhecimento]]
  
−
Este tópico foi idealizado com a intenção de juntar informações encontradas sobre o assunto do projeto para formar uma base de conhecimento para o bolsista atual e também para futuros estudantes do câmpus interessados sobre o assunto, seja para a continuação da mesma bolsa ou para um tcc.
+
[[Contiki]]
  
−
==uIp==
+
[[Resumo sobre estimadores de estado de enlace]]
  
−
Conjunto mínimo de recursos necessários de uma pilha TCP / IP. Como resultado dessa alteração, o uIP somente lida com uma única interface de rede e não implementa o protocolo UDP, porém possui como foco central os protocolos IP, ICMP e TCP. Deste modo, devido ser mais leve e a sua adaptabilidade aos sistemas com baixos recursos (pouco processamento e pouca memória), a pilha de comunicação uIP acabou se encaixando no âmbito da Internet das Coisas e servindo como um dos pilares principais para a sua execução na prática.
+
=Links úteis=
−
 
+
*[https://ri.ufs.br/bitstream/riufs/6858/2/Diego%20Assis%20Siqueira%20G%C3%B3is.pdf Simulação de pilhas de protocolos para internet das coisas]
−
Assim para tais sistemas utiliza-se a pilha uIP que implementa apenas o conjunto mínimo de recursos necessários ao funcionamento do TCP, o que permite retirar alguns dos mecanismos como: janela deslizante, controle de fluxo, controle de congestionamento, dados urgente e cálculos de verificação em prol de uma considerável economia de memória aos sistemas de pequeno porte.
+
*[http://delivery.acm.org/10.1145/1540000/1537055/a77-ni.pdf?ip=191.36.11.51&id=1537055&acc=ACTIVE%20SERVICE&key=344E943C9DC262BB%2E20BA84C2D88F9A43%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35&__acm__=1535991581_351562e2c5149fded41838285b2f1c15 On the Performance of Expected Transmission Count (ETX) for Wireless Mesh Networks]
−
 
+
*[http://sbrt.org.br/sbrt2016/anais/ST02/1570269791.pdf Avaliação de Desempenho do Protocolo RPL em Ambientes com Mobilidade]
−
Apesar da maioria das implementações TCP utilizarem a janela deslizante para enviar dados em sucessão sem que seja necessário esperar uma confirmação para cada segmento, o uIP não guarda pacotes enviados e permite que somente um segmento TCP por conexão receba uma confirmação de entrega (frequentemente chamado de acknowledgment ou ack) em determinado tempo, inviabilizando a implementação deste mecanismo, já que
+
*[https://www.net.in.tum.de/fileadmin/TUM/NET/NET-2011-07-1/NET-2011-07-1_09.pdf RPL - Protocolo de roteamento para redes de baixa potência]
−
tornará a aplicação mais complexa por não guardar os pacotes enviados.
 
−
 
 
−
O controle de fluxo é implementado no TCP para prover comunicação entre os mais variados tamanhos de memória de diferentes hosts, onde o destinatário da mensagem indica em uma janela o tamanho disponível em seu buffer. Em uIP, a aplicação não pode enviar mais dados do que o host receptor possa armazenar, a aplicação também não pode enviar mais dados do que a quantidade de bytes enviadas permitida pelo servidor (CONTIKI,2012).  Como uIP manuseia apenas um segmento TCP por conexão e o controle de congestionamento serve justamente para limitar o número de conexões simultâneas TCP na rede, este mecanismo não se faz necessário.
 
−
 
 
−
==Rime==
 
−
 
 
−
Diferentemente das arquiteturas de comunicação tradicionais, as camadas de abstração da pilha Rime são extremamente simples tanto em relação à interface quanto a implementação e são combinadas para formar abstrações poderosas em alto nível. Por ser tão simples e genérica, cada camada pode ser utilizada para objetivos diferentes. Desse modo, a pilha acaba por simplificar a implementação de protocolos de redes de sensores e facilitando o reuso de código. Rime possui uma arquitetura limitada que não permite uma estrutura totalmente modular, podendo somente ser substituída a camada mais baixa, que é o módulo abc(anonymous best effort broadcast – permite uma abstração de um canal de dezesseis bits em que envia um broadcast sem endereçamento) e a camada de aplicação. Porém, a presença do código de Rime é pequena e leve não ultrapassando dois quilobytes e exigindo requisitos de memória por volta de dez bytes.
 
−
 
 
−
==RDC==
 
−
 
 
−
A camada Radio Duty-Cycle (RDC) manipula o período de sono dos nós. Esta camada decide quando pacotes serão transmitidos e garante que os nós estejam acordados quando os pacotes forem recebido.
 
−
 
 
−
==Framer==
 
−
 
 
−
O driver Framer é na verdade um conjunto de funções para enquadrar os dados a serem transmitidos e para os dados recebidos. As implementações do Framer estão localizadas no core / net / mac, das quais os mais notáveis são framer-802154 e framer-nullmac.
 
−
 
 
−
=Contiki=
 
−
 
 
−
==O que é o Contiki==
 
−
 
 
−
Contiki é um sistema operacional de código aberto que conecta micro controladores de baixa potência à Internet. Contiki apoia plenamente o padrão IPv6 e IPv4 e os últimos padrões wireless de baixo consumo: 6LoWPAN , RPL, COAP. Contiki é executado em uma grande quantidade de dispositivos sem fio de baixa potência (Contiki et al. 2013).
 
−
O  Contiki  introduziu a  comunicação  IP  em  redes  de  sensores  de  baixa  potência (CONTIKI, 2012), este é desenvolvido por um grupo de desenvolvedores liderados por Adam Dunkels e contém duas pilhas de comunicação: uIP e Rime.
 
−
 
 
−
O kernel é  orientado  a  eventos,  mas  o  sistema  suporta dar preferência à programação multi-threading que  pode  ser  aplicado  em  uma  base  por  processo.  De preferência multi-threading é implementado como uma biblioteca que está ligada apenas com programas que exigem explicitamente multi-threading (DUNKELS et al, 2004). Este  sistema  operacional  oferece  suporte  à  comunicação  IP,  neste  trabalho utilizamos  uma  pilha  de comunicação μIP a qual  também  é  suportada  pelo  sistema operacional,  tanto  nas  versões  quatro  (IPv4)  como  na  versão  seis  (IPv6). μiP e  Contiki  são utilizadas  em  centenas  de  empresas  em  sistemas  de  navios  cargueiros,  satélites  e equipamentos  de  perfuração  de  petróleo,  e  são  altamente  reconhecidos  pela  popular ferramenta de escaneamento de redes nmap (CONTIKI 2.6, 2012)
 
−
 
 
−
==Download Contiki e VMWare Player==
 
−
 
 
−
Para instalar o Contiki acesse:
 
−
*http://sourceforge.net/projects/contiki/files/Instant%20Contiki/
 
−
Foi escolhido o software VMWare Player pra simular a maquina virtual do Contiki. O VMWare pode ser baixado em:
 
−
*http://www.vmware.com/go/downloadplayer/
 
−
 
 
−
==Instalação==
 
−
 
 
−
Em breve...
 
−
 
 
−
Teclado de Inglês para Português:
 
−
> sudo dpkg-reconfigure keyboard-configuration
 
−
 
 
−
==Estrutura genérica da aplicação Contiki==
 
−
 
 
−
<syntaxhighlight lang=c>
 
−
PROCESS(process_name, "The string representation of the process name");
 
−
AUTOSTART_PROCESSES(&process_name);
 
−
 
 
−
PROCESS_THREAD(process_name, process_event_t, process_data_t){
 
−
PROCESS_BEGIN();
 
−
/*Execução do código*/
 
−
PROCESS_END();
 
−
}
 
−
</syntaxhighlight>
 
−
==Erros previstos==
 
−
Tópico reservado para anotar soluções de problemas previstos no uso do mote MicaZ no Cooja.
 
−
 
 
−
===Cooja não compila arquivos para mote MicaZ===
 
−
 
 
−
Esse é um erro que já é deparado em interações iniciais com o Cooja. Qualquer que seja o arquivo .c compilado pro MicaZ, dá o seguinte erro:
 
−
<syntaxhighlight lang=bash>
 
−
In file included from ../../cpu/avr/dev/flash.c:4:0:
 
−
/usr/lib/avr/include/avr/boot.h:112:16: error: attempt to use poisoned "SPMCR"
 
−
#elif defined (SPMCR)
 
−
</syntaxhighlight>
 
−
 
 
−
Este é um bug do avr-gcc e é bem reportado. Então foi fácil consertar. Você precisa corrigir /usr/lib/avr/include/avr/boot.h da seguinte forma:
 
−
<syntaxhighlight lang=c>
 
−
#if defined (SPMCSR)
 
−
#  define __SPM_REG SPMCSR
 
−
#else
 
−
#if defined (SPMCR)
 
−
  #  define __SPM_REG SPMCR
 
−
#else
 
−
  #  error AVR processor does not provide bootloader support!
 
−
#endif
 
−
#endif
 
−
</syntaxhighlight>
 
−
 
 
−
Com isso, os erros de compilação passam a não aparecer mais.
 
−
 
 
−
===Módulo MicaZ não recebe informação===
 
−
 
 
−
Esse problema é caracterizado usando o módulo MicaZ no Cooja. Usando exemplos simples como "examples/rime/example-abc.c", os motes transmitiam as mensagens porém o outro lado não recebia e vice-versa (printf da função receive não aparecia no output do Cooja).
 
−
 
 
−
A solução foi trocar os protocolos no arquivo "platform/micaz/contiki-conf.h", deixando assim:
 
−
 
 
−
<syntaxhighlight lang=c>
 
−
#define NETSTACK_CONF_NETWORK sicslowpan_driver
 
−
#define NETSTACK_CONF_MAC    csma_driver
 
−
//#define NETSTACK_CONF_MAC    nullmac_driver
 
−
#define NETSTACK_CONF_RDC    nullrdc_driver
 
−
//#define NETSTACK_CONF_RDC    sicslowmac_driver
 
−
#define NETSTACK_CONF_FRAMER  framer_802154
 
−
</syntaxhighlight>
 
−
==Criando um makefile==
 
−
Para cada código .c que for criado, é necessária a criar o arquivo que contém as instruções para as ferramentas de compilação da tarefa, o conhecido makefile. O arquivo makefile deve estar no mesmo diretório do código criado para a aplicação Contiki. A seguir, alguns passos de como criar o seu makefile:
 
−
Em breve...
 
−
 
 
−
==Iniciando a implementação==
 
−
 
 
−
===Process===
 
−
Como visto anteriormente, o process é um método essencial para o funcionamento da aplicação. Nesta seção, iremos estar explicando melhor cada método da biblioteca process.h e como são implementados no Contiki.
 
−
 
 
−
Uma process_thread contém o código do processo. Nela há uma protothread que é invocada pelo escalonador de processos. A protothread é uma maneira de estruturar o código de modo que permita que o sistema execute outras atividades enquanto o código está aguardando que algum determinado evento aconteça.
 
−
 
 
−
Vamos agora para os métodos:
 
−
 
 
−
*PROCESS()                           -> Criador do processo.
 
−
*AUTOSTART_PROCESS()                -> Inicia o processo automaticamente passado o seu nome por referência.
 
−
*PROCESS_BEGIN()                    -> Define o inicio de um processo.
 
−
*PROCESS_END()                      -> Define o fim de um processo.
 
−
*PROCESS_WAIT_EVENT()                -> bloqueia o processo atualmente em execução até que o processo receba um evento.
 
−
*PROCESS_WAIT_EVENT_UNTIL()          -> Necessita ser passada uma condição que deve ser verdadeira para chamar o processo.
 
−
*PROCESS_EXITHANDLER(handler)        -> Especifica uma ação quando há uma saída do processo.
 
−
 
 
−
===Timers===
 
−
A utilização dos timers nos permitirá acionar eventos em um determinado momento, acelerando a transição de um
 
−
estado para outro e automatizar um determinado processo ou tarefa.
 
−
 
 
−
No Contiki existem 4 tipos de timers:
 
−
* Simple timer: A aplicação deve conferir manualmente se o timer expirou. ''#include "sys/timer.h"''.
 
−
* Callback timer: Quanto o timer expira o callback chama uma determinada função. ''#include "sys/ctimer.h"''.
 
−
* Timer Event: O mesmo que acima, mas em vez de chamar uma função, quando o timer expira posta um evento sinalizando sua expiração. ''#include "sys/etimer.h"''.
 
−
* Real time timer: O módulo em tempo real lida com o agendamento e execução de tempo real tarefas. #include ''"sys/rtimer.h"''
 
−
 
 
−
===Clock Timer===
 
−
A biblioteca clock é a interface entre o Contiki e a funcionalidade clock da plataforma especificada.
 
−
*CLOCK_SECOND - A biblioteca clock define esse macro para converter segundos na resolução de instante da plataforma.
 
−
 
 
−
===Interface de sistema de arquivo do Contiki===
 
−
A interface do sistema de arquivos Contiki (CFS) define uma API abstrata para ler diretórios e ler e gravar arquivos. A seguir alguns principais métodos e atributos da biblioteca.
 
−
 
 
−
*cfs_open (const char *name, int flags) - Abre um arquivo.
 
−
*cfs_close (int fd) - Fecha um arquivo.
 
−
*cfs_read (int fd, void *buf, unsigned int len) - Lê o dado de um arquivo aberto.
 
−
*cfs_write (int fd, const void *buf, unsigned int len) - Escreve dado em um arquivo aberto.
 
−
*cfs_seek (int fd, cfs_offset_t offset, int whence) - Procura uma posição especifica em um arquivo aberto.
 
−
*cfs_remove (const char *name) - Remove um arquivo.
 
−
*CFS_READ - Atributo que especifica ao cfs_open() que o arquivo aberto é para leitura.
 
−
*CFS_WRITE - Atributo que especifica ao cfs_open() que o arquivo aberto é para escrita.
 
−
 
 
−
===Packet buffer===
 
−
Um packet buffer é uma estrutura que é usada para criar pacotes de saída ou para armazenar um pacote de entrada. Um packet buffer também é usado para realizar operações em um pacote e só é possível armazenar um pacote por vez.
 
−
 
 
−
 
 
−
=Resumo artigo estimador estado de link=
 
−
*[https://dl.acm.org/citation.cfm?id=2240123 Link do artigo]
 
−
O estimador de estado de link de radios no WSN tem um impacto fundamental na performance de rede e também afeta o design de protocolo da camada superior. Este artigo fornece uma pesquisa abrangente sobre literatura relacionada, abrangendo características dos links de baixa potência, os conceitos fundamentais de estimativa de qualidade de links em RSSFs, uma taxonomia de estimadores de qualidade de link existentes e sua análise de desempenho.
 
−
 
 
−
A propagação dos sinais de rádio são afetados por muitos fatores que contribuem para a degradação do sinal. Os efeitos desses fatores são mais significantes se tratando de propagação sinal wireless com baixa potência, tipicamente usados em WSN. De fato, sua qualidade é instável e a conectividade é assimétrica.
 
−
 
 
−
Hoje em dia sabe-se que temos três fatores que levam a links inseguros:
 
−
* O ambiente, no qual causam efeitos de propagação de multi-percursos, contribuindo com os ruídos.
 
−
* Interferência, que resulta em transmissões simultâneas dentro de uma rede sem fio.
 
−
* hardwares transmissores, que podem distorcer os sinais enviados e recebidos devido ao seu ruído interno. No WSN, esses tranmissores transmitem sinais de baixa potência, no qual são mais propensos à ruido, interferência e distorção de multipercursos.
 
−
 
 
−
Na literatura, muitos estudos focam na caracterização estatística de links de baixa potência através de uma teoria de estimação, que é comumente conhecida como Estimador de qualidade do link, para estudar os comportamentos analisados até então. Entregar dados através de links com alta qualidade melhora o rendimento da rede, limitando a perda de pacotes e maximizando vida útil, minimizando o número de retransmissões e evitando a reprogramação de rotas desencadeada pela falha dos links. A estimativa da qualidade dos links também desempenha um papel crucial para mecanismos de controle para manter a estabilidade da topologia. 
 
−
 
 
−
==Hardware de comunicação do rádio==
 
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
 
 
−
==Interferência interna x externa==
 
−
- Interferência externa pode ocorrer em redes que operam na mesma banda de frequência que o WSN;
 
−
- Interferência interna pode ocorrer pela transmissão simultânea de nós pertencentes ao mesmo WSN.
 
−
Interferência externa  tem um forte impacto no desempenho das comunicações WSN porque aumenta a taxa de perda de pacotes, que por sua vez aumenta o número de retransmissões e, portanto, a latência das comunicações.
 
−
 
 
−
==Passos para a estimação da qualidade do link==
 
−
Basicamente, o LQE consiste em avaliar uma métrica, isto é, uma expressão, dentro de uma janela de estimativa w (por exemplo, a cada w segundos, ou com base em w pacotes recebidos / enviados). Nos referimos a essa métrica como o Estimador de qualidade de link (LQE). A avaliação de LQE requer medições de link. Por exemplo, para avaliar o estimador de PRR, medições de link consistem em extrair o número de seqüência de cada recebido pacote. O monitoramento de links define uma estratégia para ter tráfego sobre o link, permitindo medições de link. Portanto, o processo de estimativa da qualidade do link envolve três etapas:
 
−
monitoramento de link, medições de link e avaliação métrica.
 
−
 
 
−
- Monitoramento de links. Existem três tipos de monitoramento de link: (i) monitoramento de link ativo,
 
−
(ii) monitoramento de link passivo e (iii) monitoramento de link híbrido.
 
−
 
 
−
*(i) Monitoramento de link ativo. No monitoramento de link ativo, um nó monitora os links para seus vizinhos enviando pacotes de teste. Os pacotes de sonda podem ser enviados por transmissão, ou por unicast.
 
−
*(ii) Monitoramento de link passivo. Ao contrário do monitoramento de link ativo, as explorações de monitoramento de link passivo tráfego existente sem incorrer em sobrecarga adicional de comunicação. De fato, um nó ouve os pacotes transmitidos, mesmo que esses pacotes não sejam endereçados a ele . Ele também pode ouvir os ACK de mensagens enviadas por diferentes vizinhos. Monitoramento de link passivo tem sido amplamente usado em RSSFs devido a sua eficiência energética comparado ao monitoramento de link ativo.
 
−
*(iii) Monitoramento de link híbrido. O uso de um mecanismo híbrido combinando ativos e monitoramento passivo pode produzir um equilíbrio eficiente entre medições de link atualizadas e eficiência energética.
 
−
 
 
−
- Medições de link
 
−
4.1.2. Medidas de Link. As medições de links são realizadas recuperando informações úteis:
 
−
(i) de pacotes recebidos / confirmações ou (ii) de pacotes enviados. Dados recuperados de pacotes / confirmações recebidos, como números sequenciais, timestamp,
 
−
O RSSI e o LQI são usados para calcular os estimadores de qualidade de link do lado do receptor. Por outro lado, os dados recuperados de pacotes enviados, por exemplo, números de seqüência, timestamp, e contagem de retransmissão de pacotes, permite o cálculo do link do lado do remetente estimadores de qualidade.
 
−
 
 
−
- Avaliação Métrica. Com base nas medições de link, uma métrica é avaliada para produzir
 
−
uma estimativa da qualidade do link. Geralmente, essa métrica é projetada de acordo com
 
−
certa técnica de estimação, que pode ser uma média simples ou mais sofisticada
 
−
técnica como filtragem, aprendizagem, regressão, lógica difusa, etc.
 
−
 
 
−
==REQUISITOS PARA A ESTIMAÇÃO DO ESTADO DE LINK==
 
−
A estimativa eficiente da qualidade do link possui vários requisitos, que são descritos a seguir.
 
−
 
 
−
- Eficiência energética. Como a energia pode ser uma grande preocupação em RSSFs, os LQEs devem envolver baixa sobrecarga de computação e comunicação. Consequentemente, algumas técnicas de estimativas complexas podem não ser apropriadas em RSSFs. Além disso, os LQEs também deve envolver baixa sobrecarga de comunicação. Normalmente, um monitoramento ativo com alta taxa de beacons deve ser evitada, pois consome energia.
 
−
 
 
−
- Precisão. Refere-se à capacidade do LQE para caracterizar corretamente o estado do link, isto é, capturar o comportamento real do link. A precisão da estimativa da qualidade do link impacta grandemente a eficácia dos protocolos de rede.
 
−
 
 
−
- Reatividade. Refere-se à capacidade de reagir rapidamente a mudanças persistentes na qualidade do link. Por exemplo, um LQE reativo permite protocolos de roteamento e mecanismos de controle de topologia para se adaptar rapidamente às mudanças na conectividade subjacente.
 
−
 
 
−
- Estabilidade
 
−
 
 
−
 
 
−
==Uma pesquisa sobre estimadores de qualidade de link==
 
−
LQEs em WSNs podem ser classificados em duas categorias: baseadas em hardware e software.
 
−
 
 
−
===LQE baseado em hardware===
 
−
Três LQEs pertencem à família de LQEs baseados em hardware: LQI, RSSI e SNR. Estes
 
−
estimadores são diretamente lidos a partir do transceptor de rádio2 (por exemplo, o CC2420). Sua vantagem
 
−
é que eles não exigem nenhum cálculo adicional.
 
−
 
 
−
* O RSSI pode fornecer uma estimativa rápida e precisa de se um link é de muito boa qualidade (região conectada). O RSSI mostrou-se muito estável (desvio padrão inferior a 1 dBm) ao longo de um curto intervalo de tempo (2 s), assim, uma única leitura RSSI (através de uma recepção de pacotes) é suficiente para determinar se a ligação está na região de transição ou não.
 
−
* O LQI pode determinar se o link é de muito boa qualidade ou não. No entanto, não é um bom indicador de ligações de qualidade intermédia devido à sua alta variação,
 
−
a menos que seja calculada a média de um certo número de leituras.
 
−
* A SNR é um bom indicador e até um preditor da PRR, mas não é precisa,
 
−
especialmente para links intermediários.
 
−
 
 
−
=Referências=
 
 
*[https://github.com/contiki-os/contiki/wiki/Contiki-Build-System Criando makefile]
 
*[https://github.com/contiki-os/contiki/wiki/Contiki-Build-System Criando makefile]
 
*[https://github.com/alignan/contiki/blob/master/core/sys/process.h Biblioteca process.h]  
 
*[https://github.com/alignan/contiki/blob/master/core/sys/process.h Biblioteca process.h]  
Linha 258: Linha 37:
 
*[https://www.nongnu.org/avr-libc/user-manual/install_tools.html Como instalar avr-libc]
 
*[https://www.nongnu.org/avr-libc/user-manual/install_tools.html Como instalar avr-libc]
 
*[https://repositorio.ufsm.br/bitstream/handle/1/5353/FREITAS%2C%20JOSUE%20PAULO%20JOSE%20DE.pdf?sequence=1&isAllowed=y Uma proposta de arquitetura de pilha de comunicação em rede com um numero reduzido de camadas]
 
*[https://repositorio.ufsm.br/bitstream/handle/1/5353/FREITAS%2C%20JOSUE%20PAULO%20JOSE%20DE.pdf?sequence=1&isAllowed=y Uma proposta de arquitetura de pilha de comunicação em rede com um numero reduzido de camadas]
−
*[https://ri.ufs.br/bitstream/riufs/6858/2/Diego%20Assis%20Siqueira%20G%C3%B3is.pdf Simulação de pilhas de protocolos para internet das coisas]
 
−
*[https://www.net.in.tum.de/fileadmin/TUM/NET/NET-2011-07-1/NET-2011-07-1_09.pdf RPL - Protocolo de roteamento para redes de baixa potência]
 
−
*[http://sbrt.org.br/sbrt2016/anais/ST02/1570269791.pdf Avaliação de Desempenho do Protocolo RPL em Ambientes com Mobilidade]
 
−
*[http://delivery.acm.org/10.1145/1540000/1537055/a77-ni.pdf?ip=191.36.11.51&id=1537055&acc=ACTIVE%20SERVICE&key=344E943C9DC262BB%2E20BA84C2D88F9A43%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35&__acm__=1535991581_351562e2c5149fded41838285b2f1c15 On the Performance of Expected Transmission Count (ETX) for Wireless Mesh Networks]
 

Edição das 12h14min de 18 de setembro de 2018

Espaço do Bolsista

  • Assunto: Projeto de Estimador de estado de enlace
  • Aluno: Nelson Espindola Alves
  • Matricula: 141003075-0

Horário disponível

  • Segunda-Feira - 13:30 às 15:30 (2h)
  • Terça-Feira - 13:30 às 17:30 (4h)
  • Quarta-feira - 9:40 às 11:40 e 15:20 às 17:30 (4h)
  • Quinta feira - 7:30 às 11:30 e 13:30 às 17:30 (8h)
  • Sexta-feira - 15:40 às 17:30 (2h)

Total = 20 hrs

Progresso da bolsa - 2018/2

Base de conhecimento

Contiki

Resumo sobre estimadores de estado de enlace

Links úteis

Disponível em “https://wiki.sj.ifsc.edu.br/index.php?title=Projeto_de_Estimador_de_Estado_de_Enlace_-_Semestre_2&oldid=150356”