Figura 4.2: Vis˜ao geral da arquitectura f´ısica do transceiver
MHz com modula¸c˜ao FSK. A tabela na figura 4.2resume as caracter´ısticas f´ısicas da camada PHY.
A camada PHY deve ent˜ao providenciar: • Activa¸c˜ao e desactiva¸c˜ao do transceiver
• Verifica¸c˜ao de ocupa¸c˜ao do meio – CCA (Clear Channel Assessment) • Correcta transmiss˜ao e recep¸c˜ao de pacotes atrav´es do meio
4.4
Estrutura dos pacotes
Um pacote ´e uma unidade de transporte de dados utilizada pelas redes de comuta¸c˜ao de pacotes. Os dados a transmitir s˜ao divididos em grupos de bytes com tamanho fixo, ou vari´avel, juntamente com bytes extra - overhead - para efectuar a detec¸c˜ao dos pacotes na recep¸c˜ao. O fluxograma presente na figura 4.3, mostra, de uma maneira muito b´asica, as opera¸c˜oes de transmiss˜ao e recep¸c˜ao de pacotes. Posteriormente na descri¸c˜ao da camada MAC, ser´a apresentado, em mais detalhe, estas opera¸c˜oes
Figura 4.3: Processo geral de recep¸c˜ao e transmiss˜ao da camada PHY
No protocolo implementado, a verifica¸c˜ao de erros ´e realizada na camada PHY, e n˜ao na camada MAC como no 802.15.4 e outros standards. Isto permite uma maior simplicidade nas
camadas superiores, bem como o descarte de pacotes com erros mais rapidamente. Os pacotes tˆem os seguintes campos:
• Preamble • 1st Delimiter • 2nd Delimiter • Header • Payload
• FCS (Frame Check Sequence)
A figura4.4mostra a estrutura dos pacotes PHY.
Figura 4.4: Estrutura dos pacotes e tamanho dos campos
4.4.1 Preamble
O campo Preamble ´e constitu´ıdo por uma sequˆencia de bits alternados, com um compri- mento de 5 Bytes.
Este campo foi projectado para trabalhar com a UART configurada com um start-bit, ’0’ l´ogico, e um stop-bit, ’1’ l´ogico, e sem bits de paridade, para possibilitar uma sequˆencia alternada de bits n˜ao limitada pelos bits de sincronismo impostos pela UART.
Tem dois objectivos:
• Determina¸c˜ao do valor m´edio do sinal desmodulado na recep¸c˜ao
• Identifica¸c˜ao de baudrate, de modo a possibilitar que n˜ao seja estritamente necess´ario que as UART’s do emissor e receptor estejam configuradas com o mesmo baudrate. N˜ao foi implementado nesta vers˜ao do protocolo.
Os factores que influenciam o comprimento deste campo s˜ao maioritariamente o tempo de subida da RSSI e o tempo de leitura da ADC. Cada leitura do n´ıvel da RSSI ´e na realidade constitu´ıdo por 16 leituras, e correspondente m´edia. O tempo que o microcontrolador demora a efectuar o processamento do n´ıvel da RSSI imp˜oe assim o tamanho deste campo. Sendo este tempo invari´avel, obriga a utiliza¸c˜ao de diferentes tamanhos do campo Preamble para as diversas taxas de transmiss˜ao. Dando como exemplo o caso implementado, basta apenas 5 Bytes do campo Preamble para uma taxa de transmiss˜ao de 30 kbps, enquanto que para 100 kbps s˜ao necess´arios no m´ınimo 15 Bytes.
4.4. Estrutura dos pacotes
4.4.2 1st Delimiter
Este campo ´e de extrema importˆancia e corresponde ao primeiro delimitador do pacote, e separa o Preamble do resto do pacote. Este campo foi tamb´em projectado para trabalhar com a UART configurada como anteriormente.
Sendo o Preamble composto por uma sequˆencia alternada de bits, n˜ao ´e poss´ıvel determi- nar em que instante, o receptor assume o start-bit da trama UART de um Byte do Preamble. Sendo assim, caso n˜ao haja uma protec¸c˜ao contra esta assump¸c˜ao, a n˜ao ser que o receptor assumisse o start-bit correcto, o pacote seria considerado inv´alido, pois os dados descodifi- cados iram estar incorrectos. Assim, para evitar esta situa¸c˜ao, insere-se um Byte com todos os bits a ’0’, para que a UART do transceiver receptor assuma o start-bit do 2nd Delimiter correcto. ´E apresentado um exemplo na figura4.5 para mostrar a importˆancia deste campo.
Figura 4.5: Utiliza¸c˜ao do 1o delimitador para receber correctamente os restantes campos do pacote
4.4.3 2nd Delimiter
Este campo ´e uma protec¸c˜ao contra o caso em que o receptor assume o start-bit correcto de um byte do Preamble ou do 1st Delimiter. Neste caso, ´e recebido 1 ou mais bytes que seriam incorrectamente assumidos como se tivessem informa¸c˜oes sobre o pacote, o que levaria a que fosse invalidado.
Assim para separar o Preamble e o 1st Delimiter dos campos com informa¸c˜oes relevantes para a integridade do pacote, ´e inserido este campo delimitador. Este campo apenas necessita de ter o comprimento de 1 Byte, e pode assumir basicamente qualquer valor. Nesta imple- menta¸c˜ao utilizou-se um comprimento de 3 Bytes, pois os 2 Bytes restantes, est˜ao reservados para futuras ideias.
4.4.4 Header
O campo Header indica o n´umero de bytes no campo Payload. Este campo apenas pode conter valores de 00h a 7Fh, de maneira a limitar o tamanho do Payload a 127 bytes.
4.4.5 Payload
Este campo tem tamanho vari´avel e pode no m´aximo ter um comprimento de 127 bytes. ´
E o campo que transporta a mensagem a ser transmitida.
4.4.6 FCS – Frame Check Sequence
O ´ultimo campo do pacote ajuda a verificar a ocorrˆencia de erros, e tem comprimento de 2 bytes. O m´etodo de verifica¸c˜ao de erros ´e um simples checksum, devido `a simplicidade e ao tempo reduzido para a computa¸c˜ao do mesmo, que ´e um aspecto muito importante devido `a baixa capacidade de processamento do microcontrolador.
Neste checksum, todos os bytes do payload s˜ao somados e aproveita-se o resto da divis˜ao inteira por 10000h. Este resultado segue na transmiss˜ao no campo FCS. Na recep¸c˜ao, repete- se o processo de calcular o checksum e o resultado ´e comparado com o valor FCS recebido. Caso os resultados a comparar sejam idˆenticos, o pacote ´e considerado v´alido, caso contr´ario ´e descartado.
Este tipo de checksum ´e o mais simples e b´asico, e n˜ao garante a detec¸c˜ao de todos os erros. Apesar de que para pacotes de tamanho reduzido seja aceit´avel, este ´e tamb´em um aspecto a melhorar no futuro.