Implementação do software M-BUS sem fio SILICON LABS AN451 Guia do usuário

Esta nota de aplicação descreve a implementação da Silicon Labs de Wireless M-Bus usando um Silicon Labs C8051 MCU e EZRadioPRO®. O barramento M sem fio é um padrão europeu para aplicações de leitura de medidores usando a banda de frequência de 868 MHz.

Camadas de empilhamento

O Wireless M-Bus usa o modelo IEC de 3 camadas, que é um subconjunto do modelo OSI de 7 camadas (consulte a Figura 1).

A camada física (PHY) é definida na EN 13757-4. A camada física define como os bits são codificados e transmitidos, as características do modem de RF (taxa de chip, preâmbulo e palavra de sincronização) e os parâmetros de RF (modulação, frequência central e desvio de frequência).
A camada PHY é implementada usando uma combinação de hardware e firmware. O EZRadioPRO executa todas as funções de RF e modem. O EZRadioPRO é usado no modo FIFO com o manipulador de pacotes. O módulo MbusPhy.c fornece interface SPI, codificação / decodificação, leitura / gravação de bloco e tratamento de pacotes e gerencia os estados do transceptor.
A camada de enlace de dados do M-Bus é implementada no módulo MbusLink.c. A interface de programação de aplicativos M-Bus consiste em funções públicas que podem ser chamadas a partir da camada de aplicativo no thread principal. O módulo MbusLink também implementa a camada de enlace de dados. A camada de enlace de dados formatará e copiará os dados do buffer TX do aplicativo para o buffer MbusPhy TX, adicionando os cabeçalhos e CRCs necessários.
A camada de aplicativo em si não faz parte do firmware do barramento M. A camada de aplicação define como uma ampla variedade de dados deve ser formatada para transmissão. A maioria dos medidores só precisa transmitir um ou dois tipos de dados. Adicionar uma grande quantidade de código para acomodar qualquer tipo de dado ao medidor adicionaria código e custo desnecessários ao medidor. Pode ser viável implementar uma biblioteca ou um cabeçalho file com uma lista exaustiva de tipos de dados. No entanto, a maioria dos clientes de medição sabe exatamente que tipo de dados precisam transmitir e pode consultar o padrão para obter detalhes de formatação. Um leitor universal ou farejador pode implementar um conjunto completo de tipos de dados de aplicativo na interface do computador. Por esses motivos, a camada de aplicativo é implementada usando example aplicações para medidor e leitor.

Padrões Requeridos

EN 13757-4
EN 13757-4
Sistema de comunicação para medidores e leitura remota de medidores
Parte 4: Leitura do medidor sem fio
Leitura do radiômetro para operação na banda SRD de 868 MHz a 870 MHz
EN 13757-3
Sistema de comunicação para medidores e leitura remota de medidores
Parte 3: Camada de aplicativo dedicada

IEC 60870-2-1:1992
Equipamentos e sistemas de telecontrole
Parte 5: protocolos de transmissão
Seção 1: procedimento de transmissão de link
IEC 60870-1-1:1990
Equipamentos e sistemas de telecontrole
Parte 5: protocolos de transmissão
Seção 1: formatos de quadro de transmissão

Definições

Ônibus M—M-Bus é um padrão com fio para leitura de medidores na Europa.
M-Bus sem fio—Wireless M-Bus para aplicações de leitura de medidores na Europa.

FÍSICA—A camada física define como os bits e bytes de dados são codificados e transmitidos.
API—Interface do programador de aplicativos.

LIGAÇÃO-A camada de enlace de dados define como os blocos e quadros são transmitidos.
CRC-Verificação de redundância Cíclica.

FSK—Chaveamento de mudança de freqüência.
Lasca-Menor unidade de dados transmitidos. Um bit de dados é codificado como vários chips.

Módulo-Fonte do código AC .c file.

Descrição funcional M-Bus PHY

Seqüência de preâmbulo

A sequência de preâmbulo especificada pela especificação do barramento M é um número inteiro alternando zeros e uns. Um é definido como a frequência mais alta e um zero é definido como a frequência mais baixa.
nx (01)
As opções de preâmbulo para o Si443x são um número inteiro de nibbles consistindo em uns e zeros alternados.
nx (1010)
Um preâmbulo com um inicial extra não seria um problema, mas, então, a palavra de sincronização e a carga útil estariam desalinhadas em um bit.
A solução é inverter o pacote inteiro definindo o bit do mecanismo no registro de Controle de Modulação 2 (0x71). Isso inverterá o preâmbulo, a palavra de sincronização e os dados TX / RX. Como consequência, os dados devem ser invertidos ao gravar os dados TX ou ler os dados RX. Além disso, a palavra de sincronização é invertida antes de ser escrita nos registradores de palavra de sincronização do Si443x.

Palavra de Sincronização

A palavra de sincronização exigida pelo EN-13757-4 é de 18 chips para o Modo S e Modo R ou 10 chips para o Modelo T. A palavra de sincronização para o Si443x é de 1 a 4 bytes. No entanto, como a palavra de sincronização é sempre precedida pelo preâmbulo, os últimos seis bits do preâmbulo podem ser considerados parte da palavra de sincronização; portanto, a primeira palavra de sincronização é preenchida por três repetições de zero seguidas por um. A palavra de sincronização é complementada antes da escrita nos registradores Si443x.
Tabela 1. Palavra de Sincronização para Modo S e Modo R

EN 13757-4	00	01110110	10010110	binário
EN 13757-4	00	76	96	feitiço
pad com (01) x 3	01010100	01110110	10010110	binário
pad com (01) x 3	54	76	96	feitiço
complemento	10101011	10001001	01101001	binário
complemento	AB	89	69	feitiço

Tabela 2. Palavra de sincronização do medidor de modo T para outro

SINCRONIZAR	SINCRONIZAR	SINCRONIZAR
PALAVRA	PALAVRA	PALAVRA
3	2	1

Comprimento do preâmbulo de transmissão

O preâmbulo mínimo é especificado para quatro modos operacionais diferentes. É aceitável ter um preâmbulo mais longo do que o especificado. Subtraindo seis chips para o preâmbulo, obtém-se o número mínimo de chips para o preâmbulo Si443x. A implementação adiciona duas partes extras de preâmbulo em todos os modos de preâmbulo curto para melhorar a detecção de preâmbulo e a interoperabilidade. O preâmbulo no Modo S com um preâmbulo longo é muito longo; então, o preâmbulo mínimo é usado. O comprimento do preâmbulo em nibbles é escrito no registrador do comprimento do preâmbulo (0x34). O registro de comprimento do preâmbulo determina o preâmbulo somente na transmissão. As configurações de especificação mínima e comprimento do preâmbulo estão resumidas na Tabela 3.
Tabela 3. Comprimento do preâmbulo de transmissão

	EN-13757-4 mínimo		Preâmbulo Si443x Configurando		Sincronizar Palavra	Total	extra
	nx (01)	salgadinhos	mordisca	salgadinhos	salgadinhos	salgadinhos	salgadinhos
Preâmbulo curto do Modo S	15	30	8	32	6	38	8
Preâmbulo longo do Modo S	279	558	138	552	6	558	0
Modo T (medidor-outro)	19	38	10	40	6	46	8
Modo R	39	78	20	80	6	86	8

O preâmbulo mínimo para recepção é determinado pelo registro de controle de detecção de preâmbulo (0x35). Na recepção, o número de bits na palavra de sincronização deve ser subtraído do preâmbulo mínimo especificado para determinar o preâmbulo utilizável. O tempo mínimo de acomodação do receptor é 16 chips se AFC estiver habilitado ou 8 chips se AFC estiver desabilitado. O tempo de acomodação do receptor também é subtraído do preâmbulo utilizável para determinar a configuração mínima para o registro de controle de detecção de preâmbulo.

A probabilidade de um falso preâmbulo depende da configuração do registro de controle de detecção de preâmbulo. Uma configuração curta de 8 chips pode resultar em um falso preâmbulo detectado a cada poucos segundos. A configuração recomendada de 20 chips torna a detecção de falso preâmbulo um evento improvável. Os comprimentos do preâmbulo para Modo R e Modo SL são suficientemente longos para que a configuração recomendada seja usada.
Há muito poucos benefícios em fazer o preâmbulo detectar mais de 20 chips.
O AFC é desabilitado para o Modelo S com um preâmbulo curto e o Modelo T. Isso reduz o tempo de acomodação do receptor e permite uma configuração de detecção de preâmbulo mais longa. Com o AFC desativado, o Modo T pode usar a configuração recomendada de 20 chips. Uma configuração de 4 nibbles ou 20 chips é usada para o Modelo S com um preâmbulo curto. Isso torna a probabilidade de uma detecção de preâmbulo falso ligeiramente maior para este modelo.
Tabela 4. Detecção de preâmbulo

	EN-13757-4 mínimo		Sincronizar Palavra	utilizável preâmbulo	Assentamento RX	Detectar mínimo	Preâmbulo Si443x Definição de detecção
	nx (01)	salgadinhos	salgadinhos	salgadinhos	salgadinhos	salgadinhos	mordisca	salgadinhos
Preâmbulo curto do Modo S	15	30	6	24	8*	16	4	16
Preâmbulo longo do modelo S	279	558	6	552	16	536	5	20
Modelo T (medidor-outro)	19	38	6	32	8*	24	5	20
Modo R	39	78	6	72	16	56	5	20
*Observação: AFC desativado

O receptor é configurado para interoperar com um transmissor usando o preâmbulo mínimo especificado. Isso garante que o receptor interoperará com qualquer transmissor compatível com o barramento M.
A especificação do Wireless M-Bus requer um preâmbulo muito longo para o Modo S1 de pelo menos 558 chips. Isso levará cerca de 17 ms apenas para transmitir o preâmbulo. O Si443x não requer um preâmbulo tão longo e não se beneficia dele. Embora o preâmbulo longo seja considerado opcional para o Modo S2, não há razão para usar um preâmbulo longo com o Si443x. Se a comunicação unilateral for desejada, o Modo T1 fornecerá um preâmbulo mais curto, taxa de dados mais alta e maior vida útil da bateria. Se a comunicação bidirecional usando o Modo S2 for necessária, um pequeno preâmbulo é recomendado.
Observe que o limite de detecção para o Modelo S com um preâmbulo longo é maior do que o número de nibbles do preâmbulo transmitidos para o Modelo S com um preâmbulo curto. Isso significa que o receptor Mode S de preâmbulo longo não detectará um preâmbulo de um transmissor Mode S de preâmbulo curto. Isso é necessário se o receptor Mode S do preâmbulo longo for receber qualquer benefício do preâmbulo longo.
Observe que o receptor Modo S de preâmbulo curto detectará o preâmbulo e receberá pacotes de ambos Modo S de preâmbulo curto
transmissor e um transmissor Modo S de preâmbulo longo; portanto, em geral, o leitor de medidor deve usar a configuração do receptor Modo S de preâmbulo curto.

Codificação/Decodificação

A especificação do Wireless M-bus requer dois métodos de codificação diferentes. A codificação Manchester é usada para o Modo S e Modo R. A codificação Manchester também é usada para o link outro para medidor no Modelo T. O link medidor para outro Modelo T usa 3 de 6 codificações.
1. Codificado / Decodificado Manchester
A codificação Manchester é comum, historicamente, em sistemas de RF para fornecer recuperação e rastreamento robustos do relógio usando um modem simples e barato. No entanto, um rádio moderno de alto desempenho como o Si443x não precisa da codificação Manchester. A codificação Manchester é suportada principalmente para compatibilidade com os padrões existentes, mas a taxa de dados para o Si443x é efetivamente dobrada quando não é usada a codificação Manchester.
O Si443x oferece suporte à codificação e decodificação Manchester de todo o pacote no hardware. Infelizmente, a palavra de sincronização não é codificada em Manchester. Uma sequência Manchester inválida foi escolhida intencionalmente para a palavra de sincronização. Isso torna a codificação Manchester incompatível com a maioria dos rádios existentes, incluindo o Si443x. Como consequência, a codificação e decodificação Manchester devem ser realizadas pelo MCU. Cada byte em dados não codificados consiste em oito bits de dados. Usando a codificação Manchester, cada bit de dados é codificado em um símbolo de dois chips. Uma vez que os dados codificados devem ser gravados no rádio FIFO oito chips por vez, um nibble de dados é codificado e gravado no FIFO por vez.
Tabela 5. Codificação Manchester

dados	Boi12		0x34		bytes
	Boi1	0x2	0x3	0x4	mordisca
	1	10	11	100	binário
lasca	10101001	10100110	10100101	10011010	binário
FIFO	OxA9	OxA6	OxA5	Boi9A	feitiço

Cada byte a ser transmitido é passado um byte de cada vez para a função codificar byte. A função codificar byte chamará a função codificar nibble duas vezes, primeiro para o nibble mais significativo e, em seguida, para o nibble menos significativo.
A codificação Manchester em software não é difícil. Começando pelo bit mais significativo, um é codificado como uma sequência de chip “01”. Um zero é codificado como uma sequência de chips “10”. Isso pode ser feito facilmente usando um loop e deslocando dois bits para cada símbolo. No entanto, é mais rápido usar apenas uma tabela de consulta simples de 16 entradas para cada nibble. A função codificar nibble Manchester codifica um nibble de dados e os grava no FIFO. Os chips são invertidos antes de serem gravados no FIFO para atender aos requisitos do preâmbulo invertido.
Ao receber, cada byte no FIFO consiste em oito chips e é decodificado em um nibble de dados. A função de bloco de leitura lê um byte de cada vez do FIFO e chama a função de decodificação de byte. Os chips são invertidos após a leitura do FIFO para levar em conta os requisitos do preâmbulo invertido. Cada byte de chips codificados em Manchester é decodificado em um nibble de dados. O nibble decodificado é gravado no buffer RX usando a função write nibble RX buffer.
Observe que tanto a codificação quanto a decodificação são executadas em um nibble de dados por vez em tempo real. A codificação para um buffer exigiria um buffer adicional com o dobro do tamanho dos dados não codificados. A codificação e a decodificação são muito mais rápidas do que a taxa de dados mais rápida suportada (100 k chips por segundo). Uma vez que o Si443x suporta leituras e gravações de múltiplos bytes no FIFO, há uma pequena sobrecarga no uso de apenas leituras e gravações de byte único. A sobrecarga é de cerca de 10 µs para 100 chips codificados. O benefício é uma economia de RAM de 512 bytes.
2. Três em seis decodificação de codificação
O método de codificação três em seis especificado em EN-13757-4 também é implementado no firmware no MCU. Esta codificação é usada para o Modo T de alta velocidade (100 k chips por segundo) do medidor para outro. O Modelo T oferece o menor tempo de transmissão e a maior vida útil da bateria para um medidor sem fio.
Cada byte de dados a ser transmitido é dividido em dois nibbles. O nibble mais significativo é codificado e transmitido primeiro. Novamente, isso é implementado usando uma função codificar byte que chama a função codificar nibble duas vezes.
Cada nibble de dados é codificado em um símbolo de seis chips. A seqüência de símbolos de seis chips deve ser escrita no 8chip FIFO.
Durante a codificação, dois bytes de dados são codificados como quatro nibbles. Cada nibble é um símbolo de 6 chips. Quatro símbolos 6chip são agregados como três bytes.
Tabela 6. Codificação Três de Seis

dados	0x12			0x34			bytes
	Boi1	0x2		0x3		0x4	mordisca
lasca	15	16		13		34	octal
	1101	1110		1011		11100	binário
FIFO	110100		11100010		11011100		binário
	0x34		OxE2		OxDC		feitiço

No software, a codificação três em seis é implementada usando três funções aninhadas. A função codificar byte chamará a função codificar nibble duas vezes. A função codificar nibble usa uma tabela de consulta para o símbolo de seis chips e grava o símbolo nas funções Shift Três de Seis. Esta função implementa um registro de deslocamento de 16 chips no software. O símbolo é escrito no byte menos significativo do registrador de deslocamento. O registro é deslocado para a esquerda duas vezes. Isso é repetido três vezes. Quando um byte completo está presente no byte superior do registrador de deslocamento, ele é invertido e escrito no FIFO.
Uma vez que cada byte de dados é codificado como um byte codificado e meio, é importante limpar o registro de deslocamento inicialmente para que o primeiro byte codificado esteja correto. Se o comprimento do pacote for um número ímpar, depois de codificar todos os bytes, ainda haverá um nibble restante no registrador de deslocamento. Isso é tratado com o postâmbulo conforme explicado na próxima seção.
A decodificação de três de seis codificados é o procedimento inverso. Ao decodificar, três bytes codificados são decodificados em dois bytes de dados. O registrador de deslocamento do software é novamente usado para agregar bytes de dados decodificados. Uma tabela de pesquisa inversa de 64 entradas é usada para decodificação. Isso usa menos ciclos, mas mais memória de código. A pesquisa em uma tabela de consulta de 16 entradas para o símbolo correspondente leva muito mais tempo.
Postâmbulo
A especificação do Wireless M-bus tem requisitos específicos para o postâmbulo ou trailer. Para todos os modos, o mínimo é dois chips e o máximo é oito chips. Como a unidade atômica mínima para o FIFO é um byte, um trailer de 8 chips é usado para o Modo S e o Modo R. O postâmbulo do Modo T tem oito chips se o comprimento do pacote for par ou quatro chips se o comprimento do pacote for ímpar. O postâmbulo de quatro chips para um comprimento de pacote ímpar atende aos requisitos de ter pelo menos dois chips alternados.
Tabela 7. Comprimento do Postâmbulo

	Comprimento Postâmbulo (chips)
	mínimo	máx.	Implementação		sequência de chips
Modo S	2	8	8		1010101
Modo T	2	8	4	(ímpar)	101
			8	(até)	1010101
Modo R	2	8	8		1010101

Manipulador de pacotes

O manipulador de pacotes no Si443x pode ser usado em um modo de largura de pacote variável ou em um modo de largura de pacote fixa. O modo de largura de pacote variável requer um byte de comprimento de pacote após a palavra de sincronização e bytes de cabeçalho opcionais. Na recepção, o Rádio usará o byte de comprimento para determinar o final de um pacote válido. Na transmissão, o rádio irá inserir o campo de comprimento após os bytes do cabeçalho.
O campo L para o protocolo wireless M-bus não pode ser usado para o campo de comprimento Si443x. Primeiro, o campo L não é o comprimento real do pacote. É o número de bytes de carga útil da camada de link, não incluindo os bytes CRC ou codificação. Em segundo lugar, o próprio campo L é codificado usando a codificação Manchester ou a codificação Três de Seis para o medidor do Modo T para outro.
A implementação usa o manipulador de pacotes no modo de largura de pacote fixa para transmissão e recepção. Após a transmissão, a camada PHY lerá o campo L no buffer de transmissão e calculará o número de bytes codificados, incluindo o postâmbulo. O número total de bytes codificados a serem transmitidos é escrito no registrador Packet Length (0x3E).
Na recepção, os primeiros dois bytes codificados são decodificados e o campo L é escrito no buffer de recepção. O campo L é usado para calcular o número de bytes codificados a serem recebidos. O número de bytes codificados a serem recebidos é então escrito no registrador Packet Length (0x3E). O postâmbulo é descartado.
O MCU deve decodificar o campo L, calcular o número de bytes codificados e gravar o valor no registrador Packet Length antes que o menor comprimento de pacote possível tenha sido recebido. O menor campo L permitido para a camada PHY é 9, fornecendo 12 bytes não codificados. Isso dá 18 bytes codificados para o Modelo T. Os primeiros dois bytes já foram decodificados. Assim, o registro do comprimento do pacote deve ser atualizado em tempos de 16 bytes a 100 kbps ou 1.28 milissegundos. Isso não é problema para um 8051 rodando a 20 MIPS.
O número de bytes a serem recebidos não inclui o postâmbulo, exceto para o postâmbulo de quatro chips usado para pacotes do Modo T com um comprimento de pacote ímpar. Assim, o receptor não requer um postâmbulo, exceto para os pacotes de comprimento ímpar do Modelo T. Este postâmbulo é necessário apenas para fornecer um número inteiro de bytes codificados. O conteúdo do postâmbulo é ignorado; portanto, se o postâmbulo não for transmitido, quatro chips de ruído serão recebidos e ignorados. Uma vez que o número total de bytes codificados é limitado a 255 (0xFF), a implementação limita o campo L máximo para os diferentes modos.
Tabela 8. Limites de tamanho de pacote

	codificado		decodificado		M-Ônibus
	bytes		bytes		Campo L
	dezembro	feitiço	dezembro	feitiço	dezembro	feitiço
Modo S	255	FF	127	7 graus Fahrenheit	110	6E
Modo T (medidor-outro)	255	FF	169	A9	148	94
Modo R	255	FF	127	7 graus Fahrenheit	110	6E

Esses limites estão normalmente bem acima do caso de uso típico para um medidor sem fio. O comprimento do pacote deve ser mantido pequeno para obter a melhor duração possível da bateria.
Além disso, o usuário pode especificar o campo L máximo que deve ser recebido (USER_RX_MAX_L_FIELD). Isso determina o tamanho necessário para o buffer de recebimento (USER_RX_BUFFER_SIZE).
Suportar um campo L máximo de 255 exigiria um buffer de recepção de 290 bytes e um máximo de 581 bytes codificados em Manchester. O manipulador de pacotes precisaria ser desabilitado e o registro Packet Length não poderia ser usado nesse caso. Isso é viável, mas é mais conveniente usar o manipulador de pacotes, se possível.

Uso FIFO

O Si4431 fornece um FIFO de 64 bytes para transmissão e recepção. Como o número de bytes codificados é 255, um pacote codificado inteiro pode não caber no buffer de 64 bytes.
Transmissão
Na transmissão, o número total de bytes codificados é calculado. Se o número total de bytes codificados, incluindo o postâmbulo, for menor que 64 bytes, o pacote inteiro será gravado no FIFO e apenas a interrupção do pacote enviado será habilitada. A maioria dos pacotes curtos será enviada em uma transferência FIFO.
Se o número de bytes codificados for maior que 64, várias transferências FIFO serão necessárias para enviar o pacote. Os primeiros 64 bytes são gravados no FIFO. As interrupções Packet Sent e TX FIFO Quase Empty estão habilitadas. O limite TX FIFO Quase Vazio é definido para 16 bytes (25%). A cada evento IRQ, o registro de status 2 é lido. O bit de pacote enviado é verificado primeiro e, se o pacote não tiver sido enviado completamente, os próximos 48 bytes de dados codificados são gravados no FIFO. Isso continua até que todos os bytes codificados tenham sido gravados e a interrupção do pacote enviado ocorra.
1. Recepção
Na recepção, inicialmente, apenas a interrupção Sync Word está habilitada. Depois de receber a palavra de sincronização, a interrupção da palavra de sincronização é desabilitada e a interrupção FIFO Quase Cheia é habilitada. O limite de FIFO quase cheio é inicialmente definido para 2 bytes. A primeira interrupção FIFO quase cheia é usada para saber quando os dois bytes de comprimento foram recebidos. Uma vez que o comprimento foi recebido, o comprimento é decodificado e o número de bytes codificados é calculado. O limite RX FIFO quase Full é então definido para 48 bytes. O RX FIFO está quase cheio e as interrupções de pacotes válidos estão habilitadas. No próximo evento IRQ, o registro de status 1 é lido. Primeiro, o bit de pacote válido é verificado e, em seguida, o bit FIFO quase completo é verificado. Se apenas o bit RX FIFO Quase Full for definido, os próximos 48 bytes serão lidos do FIFO. Se o bit de pacote válido é definido, o restante do pacote é lido do FIFO. O MCU mantém registro de quantos bytes foram lidos e interrompe a leitura após o último byte.

Camada de link de dados

O módulo da camada de enlace implementa uma camada de enlace compatível com 13757-4: 2005. A camada de enlace de dados (LINK) fornece uma interface entre a camada física (PHY) e a camada de aplicativo (AL).
A camada de link de dados executa as seguintes funções:

Fornece funções que transferem dados entre PHY e AL
Gera CRCs para mensagens de saída
Detecta erros CRC em mensagens recebidas
Fornece endereçamento físico
Reconhece transferências para modos de comunicação bidirecional
Bits de dados de frames
Detecta erros de enquadramento em mensagens recebidas

Formato do Frame da Camada de Link

O formato de quadro Wireless M-Bus usado em EN 13757-4: 2005 é derivado do formato de quadro FT3 (Frame Type 3) do IEC60870-5-2. O quadro consiste em um ou mais blocos de dados. Cada bloco inclui um campo CRC de 16 bits. O primeiro bloco é um bloco de comprimento fixo de 12 bytes que inclui o campo L, campo C, campo M e campo A.

Campo L
O campo L é o comprimento da carga útil de dados da camada de enlace. Isso não inclui o próprio campo L ou qualquer um dos bytes CRC. Inclui o campo L, campo C, campo M e campo A. Eles fazem parte da carga útil do PHY.
Como o número de bytes codificados é limitado a 255 bytes, o valor máximo suportado para o campo M é 110 bytes para dados codificados em Manchester e 148 bytes para dados codificados em Modo T três em seis.
A camada de enlace é responsável por calcular o campo L na transmissão. A camada de enlace usará o campo L na recepção.
Observe que o campo L não indica o comprimento da carga útil PHY ou o número de bytes codificados. Na transmissão, o PHY calculará o comprimento da carga útil do PHY e o número de bytes codificados. Após a recepção, o PHY decodificará o campo L e calculará o número de bytes a decodificar.
Campo C
O campo C é o campo de controle do quadro. Este campo identifica o tipo de quadro e é usado para as primitivas de serviço de troca de dados de link. O campo C indica o tipo de quadro - ENVIAR, CONFIRMAR, PEDIR ou RESPONDER. No caso de quadros SEND e REQUEST, o campo C indica se um CONFIRM ou RESPOND é esperado.
Ao usar a função básica Link TX, qualquer valor de C pode ser usado. Ao usar o Link Service Primitives, o campo C é preenchido automaticamente de acordo com EN 13757-4: 2005.
Campo M
O campo M é o código do fabricante. Os fabricantes podem solicitar um código de três letras a partir do seguinte web endereço: http://www.dlms.com/flag/INDEX.HTM Cada caractere do código de três letras é codificado como cinco bits. O código de 5 bits pode ser obtido tomando o código ASCII e subtraindo 0x40 (“A”). Os três códigos de 5 bits são concatenados para formar 15 bits. O bit mais significativo é zero.
Longe
O campo de endereço é um endereço de 6 bytes exclusivo para cada dispositivo. O endereço exclusivo deve ser atribuído pelo fabricante. É responsabilidade de cada fabricante garantir que cada dispositivo tenha um endereço de 6 bytes exclusivo. O endereço para enviar e solicitar quadros é o próprio endereço do medidor ou outro dispositivo. Os quadros de dados de resposta de confirmação são enviados usando o endereço do dispositivo de origem.
Campo CI
O campo CI é o cabeçalho do aplicativo e especifica o tipo de dados na carga útil dos dados do aplicativo. Enquanto EN13757-4: 2005 especifica um número limitado de valores, as primitivas de serviço de link permitirão que qualquer valor seja usado.
CRC
O CRC é especificado em EN13757-4: 2005.
O polinômio CRC é:
X16 + x13 + x12 + x11 + x10 + x8 + x6 + x5 + x2 + 1
Observe que o M-Bus CRC é calculado sobre cada bloco de 16 bytes. O resultado é que cada 16 bytes de dados requerem 18 bytes para serem transmitidos,

Informações adicionais

Para obter informações adicionais sobre a implementação da camada de link, consulte “AN452: Guia para programadores de pilha de barramentos M-Wireless”.

Gerenciamento de energia

A Figura 2 mostra o cronograma de gerenciamento de energia para um medidor examparquivo usando o Modo T1.

O MCU deve estar no modo Sleep sempre que possível para conservar energia. Neste example, o MCU está hibernando quando o RTC está em execução, ao aguardar a inicialização do cristal de rádio e ao transmitir do FIFO. O MCU irá despertar do sinal EZRadioPRO IRQ conectado a um despertar do Port Match.
Ao transmitir mensagens mais longas do que um bloco, o MCU deve acordar para preencher o FIFO (baseado na interrupção quase vazia do FIFO) e então voltar a dormir.
O MCU deve estar no modo inativo executando a partir do oscilador de baixa potência ou oscilador de modo burst ao ler do ADC. O ADC requer um relógio SAR.
Quando não estiver em uso, o EZRadioPRO deve estar no modo Desligar com o pino SDN elevado. Isso requer uma conexão com fio ao MCU. Os registros EZ Radio Pro não são preservados no modo de desligamento; portanto, o EZRadioPro é inicializado em cada intervalo RTC. A inicialização do rádio leva menos de 100 µs e conserva 400 nA. Isso resulta em uma economia de energia de 10 µJ, com base em um intervalo de 10 segundos.
O cristal EZRadioPRO leva cerca de 16 ms para um POR. Isso é longo o suficiente para calcular o CRC para cerca de oito blocos. O MCU voltará a hibernar se concluir todos os CRCs antes de o cristal se estabilizar. Se a criptografia for necessária, ela também pode ser iniciada enquanto aguarda o oscilador de cristal.
O MCU deve funcionar a 20 MHz usando o oscilador de baixa potência para a maioria das tarefas. As tarefas que requerem um tempo limite preciso devem usar o oscilador de precisão e o modo inativo em vez do modo de hibernação. O RTC fornece resolução suficiente para a maioria das tarefas. O cronograma de gerenciamento de energia para o medidor T2 exampO aplicativo é mostrado na Figura 3.

A implementação do transceptor deve ser otimizada para o caso normal, quando o medidor é ativado e não há leitor presente. Os tempos limite mínimo / máximo de ACK são suficientemente longos para que seja possível usar o C8051F930 RTC e colocar o MCU no modo de hibernação.
As opções de construção são fornecidas para leitores de rede ou alimentados por USB que não precisam usar o modo de hibernação. O modo inativo será usado em vez de hibernar para que o USB e o UART possam interromper o MCU.

Estúdio Simplicidade
Acesso com um clique a MCU e ferramentas sem fio, documentação, software, bibliotecas de código-fonte e muito mais. Disponível para Windows,
Mac e Linux!


Portfólio IoT www.silabs.com/IoT	SW / HW www.silabs.com/simplicity	Qualidade www.silabs.com/quality	Suporte e Comunidade community.silabs.com

Isenção de responsabilidade
A Silicon Labs pretende fornecer aos clientes a documentação mais recente, precisa e aprofundada de todos os periféricos e módulos disponíveis para implementadores de sistemas e softwares que usam ou pretendem usar os produtos da Silicon Labs. Dados de caracterização, módulos e periféricos disponíveis, tamanhos de memória e endereços de memória referem-se a cada dispositivo específico, e os parâmetros “típicos” fornecidos podem variar e variam em diferentes aplicações. Exemplo de aplicaçãoampOs arquivos aqui descritos são apenas para fins ilustrativos. A Silicon Labs reserva-se o direito de fazer alterações sem aviso prévio e limitação às informações, especificações e descrições do produto aqui contidas, e não oferece garantias quanto à precisão ou integridade das informações incluídas. A Silicon Labs não se responsabiliza pelas consequências do uso das informações fornecidas neste documento. Este documento não implica ou expressa licenças de direitos autorais concedidas de acordo com este instrumento para projetar ou fabricar quaisquer circuitos integrados. Os produtos não são projetados ou autorizados para uso em qualquer Sistema de Suporte à Vida sem o consentimento específico por escrito da Silicon Labs. Um “Sistema de Suporte à Vida” é qualquer produto ou sistema destinado a apoiar ou sustentar a vida e / ou saúde, que, se falhar, pode-se razoavelmente esperar que resulte em ferimentos pessoais significativos ou morte. Os produtos da Silicon Labs não são projetados ou autorizados para aplicações militares. Os produtos da Silicon Labs não devem, em nenhuma circunstância, ser usados em armas de destruição em massa, incluindo (mas não se limitando a) armas nucleares, biológicas ou químicas, ou mísseis capazes de lançar tais armas.
Informações sobre marcas registradas
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® e o logotipo da Silicon Labs®, Bluegiga®, Bluegiga Logo®, Clockbuilder®, CMEMS®, DSPLL®, EFM®, EFM32®, EFR, Ember® , Energy Micro, logotipo Energy Micro e suas combinações, "os microcontroladores mais ecológicos do mundo", Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, ISOmodem®, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY® , Telegesis, o logotipo da Telegesis®, USBXpress® e outros são marcas comerciais ou marcas registradas da Silicon Labs. ARM, CORTEX, Cortex-M3 e polegares são marcas comerciais ou marcas registradas da ARM Holdings. Keil é uma marca registrada da ARM Limited. Todos os outros produtos ou nomes de marcas mencionados aqui são marcas comerciais de seus respectivos proprietários.

Laboratórios de Silício Inc.
400 Oeste Cesar Chavez
Austin, Texas 78701
EUA
http://www.silabs.com

Documentos / Recursos

Implementação de software M-BUS sem fio SILICON LABS AN451 [pdf] Guia do Usuário
SILICON LABS, C8051, MCU e, EZRadioPRO, Wireless M-bus, Wireless, M-BUS, Software, Implementation, AN451

Referências

Manual do usuário

Introdução